What are my options for 4V-8.4V 3-mode drivers?

I'd like to build an Aleph light engine that can handle two RCR123s as a power source and can output 3 levels of current-controlled power at 3.7V. Is this what the Shark+Remora combo is for, or is there another driver that would be better-suited to this application?

The Shark/Remora is too large to fit into a Aleph LE

Phooey. Is there anything else that would do the job, then?

There was talk of a Son of Buck uP but I don't think it came about.

I wonder if a board similar to the Remora could be created that could attach to any Aleph-sized single-mode driver and add multiple modes to it? It would certainly make the product line more flexible.

.....

AFAIK the Shark is for multiple-LED heads only and the Remora is only compatible with the Shark boards.

Single mode SOB would be your only option. Heard of the SOBuP briefly but so far it didn't make it to the SOB lineup yet...

IMO I wouldn't put too many modes in a small light, more modes mean more complication on the driver board. Just keep it simple and remain in single mode if possible.

3 modes is not too much for a small light. 2 modes is pretty much the minimum for a bright light to be useful nowadays -- one mode for seeing things up-close, and another mode for seeing things far away. Having a single mode limits the usefulness of a light to being for-distance-only or for-closeup-only, which means I'd have to carry two lights to do the job of one.

A dimmer mode does help in short range illumination. But then you'll have to determine if it's really worthwhile to pay the extra buck on a multimode driver (eg. GDuP costing $45-50). If the SOBuP really materializes then expect the pricing to be similar to the GDuP's.

I have on my todo list to make some SOBuPs.

At the moment we are going through a financial re balancing and this will take a month or so. Until then I am not able to do much.

There are a lot of things I want to do at the moment and will need to prioritize what I can work on and what I can't.

What I can work on that has no up front cost is software. That is what I am trying to focus on. There are a number of new products that will require a microprocessor and the code for these can be started now.

Wayne

Understood. I'm sure there is a market (besides me ) waiting for the SOBuP when it arrives.

By the way, the auto-calibration programming in the newer GDuP drivers is great. That is definitely a feature worth keeping. If there were a way to periodically test the current flow while the emitter is on, and recalibrate without having to shut the emitter off first, that would be even better, especially for high-current applications, because it would eliminate any risk of thermal runaways. Something to think about while you're writing code.

fyrstormer said:

Understood. I'm sure there is a market (besides me ) waiting for the SOBuP when it arrives.

By the way, the auto-calibration programming in the newer GDuP drivers is great. That is definitely a feature worth keeping. If there were a way to periodically test the current flow while the emitter is on, and recalibrate without having to shut the emitter off first, that would be even better, especially for high-current applications, because it would eliminate any risk of thermal runaways. Something to think about while you're writing code.

Click to expand...

I think thermal runaway is addressed with thermal throttling. If the converter gets too hot (LED + converter) the GDuP will throttle from high to medium. Thermal throttling currently only throttles when in high.

My assumptions that medium and low are probably never going to need thermal throttling.

Wayne

If you don't mind me asking, how does the GDuP sense the temperature of the LED? Does there have to be a thermal pathway from the LED to the driver, or does it sense a significant drop in Vf, or does it use some other mechanism?

I ask because I have used GDuP drivers in installations where the LED got hot enough that the driver recalibrated itself when the light was shut off for a moment and then turned back on. While the temperature of the LED was still within safe limits (as far as I could tell), no blue-shifting or anything like that, it would be nice if the driver could sense that the current flow is increasing as the LED heats up and could adjust the output voltage to compensate, to keep the circuit operating exactly as intended.

The GDuP uses the internal temperature sensor inside the uP. This requires close coupling of the GDuP to the LED which in a light engine both are together in the same can in most cases.

When the GDuP is turned on it takes the last stored calibrated value to set the LED current and if this is way off it will re-calibrate. As such if you run the light and let it get very hot the LED Vf will have shifted quite a bit and if you cycle the power it will re-calibrate.

No worries next time you power up at room temperature it will re-calibrate again.

Wayne