Extended driver 3.0 6A + 21700 mods

Hello. I want to present my latest project – the extended driver 3.0.
This solution is based on two components: standard driver board (17 / 22mm) and a special MCPCB substrate, which, in addition to the diode / LEDs also cases the driver executive element - MOSFET transistor. This solution considerably improves cooling so that all elements in the flashlight that emit heat do not cause the effect of artificial heating of the controller board through electric current stabilizing element.

This problem is common in linear controllers based on current stabilization by a FET transistor. Not only does the board heat up from the working LED, but also it receives a lot of heat from the operating current transistor.

This situation often results in discrepancies in temperature readings by temperature monitoring mechanisms. This is due to temperature sensors in the driver (in the processor or in an external element) heating up too quickly, which directly results in the reduction of the flashlight power. All this while the case is still relatively cool.

The power used on the transistor depends on the current flowing in the circuit and on the excess voltage it must break in order to stabilize this value. From a simple equation for power P = I * U, knowing the value of: supply voltage, current flowing in the diode circuit, Vf of the diode for a given current value, you can easily calculate the loss of power in the transistor and how easy it is to exceed the acceptable value … And here we have the solution to the puzzle: why in Chinese FET controllers the modes are usually: Low , Medium maximum around 30% (usually in practice it is less, ~ 20%) and very high value HI. Unfortunately, this element is very impractical when it comes to cooling. Its thermal pad is usually a drain and it must be electrically insulated from the case. Ok, but enough about boring things, let move back on to the subject.

In the presented driver, it isn’t a modulated PWM signal that provides LED supply current but it is done by regulated direct current. This has a number of advantages such as:

-the use of higher efficiency lm / W LED powered by low direct current,

-longer battery life (we take a constant value and do not tire it with high current peaks),

-it often results in no audible PWM signal,

-the flashlight does not interfere with other devices working in the vicinity (e.g. wireless bicycle counters).

The controller is based on the Atiiny25 processor, which through a very precise operational amplifier, controls the opening of the MOSFET transistor. The current is measured on a resistor of a very low value (5mΩ). The processor applies a current to the operational amplifier input. The signal from the measuring resistor is delivered to the second input. The amplifier turns these two voltages into a transistor control signal in such a way so as to maintain a constant diode current.

Functionally, the new version of the driver is similar to the extended 2.0 driver described below:

Extended driver 2.0

I am not a big fan of fireworks, n-clicks and any other complications of already simple and proven solutions.

So we have:

Three groups of modes switched between each other (4-mode EDC, 3-mode BICYCLE, 2-mode TACTICAL) - each mode in it can be freely programmed from among 16 brightness levels available during the programming process.

Default / factory mode settings in individual groups:

EDC: 0.2% / 5% / 33% / 100%
Bicycle: 7% / 45% / 100%
Tactical: 8% / 100%

Functional clicks:

1-click: switch to the next mode in loop

2-click: switch to the previous mode in loop

3-click: strobe mode with the intensity of the mode from which we called it (different operating frequencies depending on the group we are in: 4Hz EDC group, 2Hz bicycle, 16Hz in the tactical group - in this group the intensity is always 100%).

4-click: Precise measurement of voltage under load - the controller informs us about the tenth of V after 3.X. E.g. 8 flashes is 3.8V; 5 flashes are 3.5V etc. The range is from 0-10 where 10 indicates 4.0V (the battery cell just unplugged from the charger), while no flash (3.0V) means that in a moment you will be receiving a low voltage level warning. This way of measuring proves correct in diagnosing new lamps and an associated drop of voltage in the whole construction (a contact quality, etc.), since we are given the information which physical voltage is found on the driver level.

5-click: change the mode group EDC->Bicycle-Tactical

Configuration clicks:

6-click: Programming a given mode from a palette of 16 available brightness levels. While being in the mode we wish to change. Displaying the sequence occurs in the lowest mode upwards. Every mode displays for about 1,5 of a second. After reaching 100% there’s one twinkle, then it displays modes downwards. The mode is programmed during the display invoked by a click or by the mechanism of turning off the switch. If we cease to do anything during the procedure of presenting modes upwards and downwards, the light brightness will remain as previously set.

7-click: Disable / enable the memory of the last mode used

8-click: Factory settings reset: Default modes for all groups including moving to EDC group and turning on the memory. Does not reset thermal settings.

10-click: Increasing the temperature protection threshold by 5 * C
12-click: Lowering the temperature protection threshold by 5 * C

The low battery cell voltage warning starts when the cell, in a working mode reaches about 2,9-3,0V. Then a single flash appears and a reduction to another, lower level from the programmable modes palette (we reach ~2,9V in the given mode, and after a flash, we drop to another, lower mode)

Temperature monitoring
This procedure always works in the background and monitors current driver temperature. It is based on a Attiny25 processor internal temperature sensor . After reaching safety threshold (default 60*C) the driver flawlessly reduces power, then tries to equalize to the set work mode. If the heat isn’t effectively absorbed, next reduction occurs while holding to the preset safety threshold. After cooling the lamp (for instance, cool air blow around the lamp case) the face value returns for the programmed mode.

According to my guidelines, my friend Pyra is the codemaker of this project.

I have a problem to display pictures so only links below

Below is a table of programmable driver modes for the SST-40 bin N5 diode powered by Li-Ion 21700 Samsung 5000mAh cell:

Programmable table modes table for the 4x SST-20 bin L4 / 4x Luxeon V2 bin Y module (the values ​​are practically identical, so I standardized them to one table) power supply 21700 Samsung 5000mAh cell:

Mod Convoy S12 (4x SST-20 / 4x Luxeon V2) optics: medium and wide:





Mod S21A
4 optics: ref. OP, TIR spot (narrow), TIR medium, TIR wide, TIR elliptical bicycle.




Convoy M21A SMO


NIGHT SESSION:
Manual settings F / 4.5, exposure time 2.5 sec. ISO 200

As a reference FW3A 3x XP-L HI 6500K 900lm mode:

S12 4x SST-20 bin L4 5000K medium 100%

S12 4x SST-20 bin L4 5000K wide 100%

S12 4x Luxeon V2 bin Y 5000K medium 100%

S12 4x Luxeon V2 bin Y 5000K wide 100%

S21A SST-40 bin N5 5000K ref OP 100%

S21A SST-40 bin N5 5000K TIR spot 100%

S21A SST-40 bin N5 5000K TIR medium 100%

S21A SST-40 bin N5 5000K TIR wide 100%

S21A SST-40 bin N5 5000K TIR elliptical bicycle 100%

M21A SST-40 bin N5 5000K ref SMO 100%

Everything nice and fine, but why the SST-20 5000K, a horribly greenish poor man’s XP-L HI emitter :person_facepalming:

Nice work :wink:

Question: do you intend to “produce” more of these drivers or fully modded lights?

Pic links work fine. Advanced Post Editor mode, click on the "Insert/edit image" icon on the toolbar, paste in your pic url, reduce the dimensions if too large. These below are direct from your hosting, direct from the link urls in your post:

sub’d

Thanks guys, I’ve corrected the first post :wink:

This is a pretty darn nice design. I'm very interested in 6A drivers for both clicky and e-switch lights. What's your plans?

I don't see any pics of the driver itself. I think the UI you are describing is for a clicky/power switch? Will it be suitable for e-switch lights?

Will you go public with this so we can build/use it or are you building/selling them?

Might have missed it but I don't see anything in the UI to do temperature calibration?

Nice, I like the UI and and customizable capabilities of the driver.

It looks like the hardware might be based on these convoy linear drivers?

With the FET on the MCPCB, what limits the max current you can use?

Please excuse my for my lack of knowledge, but how is this driver unique from led4power LDB4 driver?

I am asking because it look like the LDB4 driver use external MOSFET as linear element for constant current drive the same way: https://led4power.com/product/ld-b4-2-12amp-17mm-constant-current-led-flashlight-driver/

Just like you use an example using led4power MCPCB. The LDB4 go up to 12A and can be configure to power level less than that, such as 6A too.

Can we see a photo of your driver?

Hi Bocian, what brand name of this optic ?

I only use these drivers in the modified flashlights I sell. The driver board is based on a deeply modified linear Convoy driver:
https://www.aliexpress.com/item/32989372464.html
I see that you have a puzzle why the factory ramping versions of these drivers have low modes once displayed and other times not. This phenomenon depends on the operational amplifier they used. The most precise and desirable is OPA333 marked as OAXQ but they also use OPA336 marked as J36 and you can even find markings S8K6 and S83W so it’s a bit of a lottery. OPA333 is quite an expensive operational amplifier so they probably use cheaper substitutes.

I do not plan a version controlled by an electronic (soft) switch, only mechanical reverse switch.

Of course, I could programmatically get modes higher than 6A for 100% but I do not need it in my products, because I do not produce them for the “woow effect” but stable operating modes.

The optics I use is a trade secret :stuck_out_tongue:

Interesting driver, thank you Bocian for showing it.

Though I have to say I’m frustrated with seeing so many good drivers that are all not just proprietary but incompatible with BLF open source firmwares. UIs designed to suit their makers rather than fully tweaked to my needs really kill them for me.

I agree with Agro - it's interesting but not in the BLF spirit - guess this thread is in the wrong place. It's a commercial endeavor and therefore should be listed as such. For commercial use, you should at least list somewhere it can be bought.

You also seem to intentionally not want to even publish a picture of it, which is rather strange.

I love opennes and believe it is good for everyone involved but at the same time I feel there’s space for both those who are fully open about what they do as well as those who keep some stuff for themselves.

L4P doesn’t share all details of his products either. And he is not merely tolerated here, I don’t feel any specific animosity against what he does.
Now Bocian also shares some details, like the part about opamps above. I see no reason to treat him any worse.

I agree that the Commercial section of the forum might be a better place for this kind of posts though.

Gentlemen, I don’t understand what you have a problem with. My only intention was to present what I have been working on recently. Not with the intention of selling you anything. Is there a provision in the BLF regulations that each project must involve the publication of all technical details, models of used components, firmware for download, etc. Treat this topic as a curiosity, without any unnecessary comments or just ignore it. I will put the photo of the driver when I have one modified on hand.

I don’t quite understand why driver makers should make their drivers compatible with BLF firmware. Why can’t the firmware makers make their firmware driver compatible? Which BLF firmware is compatible “out of the box” with operating FETs in linear mode? If there isn’t any, the driver developer is assumed to make these changes to existing BLF firmware themselves? What’s wrong with the other way around?

It’s a bit like loneocean’s GXB172 driver. There where comments about it being a shame that it isn’t compatible with BLF firmware. Well, he used ATtiny841 for it and he has released gerbers. What’s stopping any firmware developer from porting current BLF firmware to the 841 and making the necessary changes? I’ve ported my own firmware from the 85 to the 841, it wasn’t difficult.

There is nothing revolutionary about this driver. It’s a FET driven in linear mode. The opamp is to keep the current at the same level because LEDs (and FETs in particular) tend to have “thermal runaway” which means the hotter they get, the more current they draw even though the voltage is constant. In order to keep the current constant and prevent runwaway, the FET gate voltage has to be altered. It’s all in the datasheets. It’s the same principle as the GXB172 except the opamp in the GXB172 (also OPA333) alters boost IC feedback voltage instead of FET gate voltage. If the BLF community really wants an open source BLF driver like this with BLF firmware, what is stopping BLF from making one?

Sorry, just saying what it is. It's just very odd to see a driver design thread with only pics of flashlights and beamshots - basically all aspects of a flashlight except the driver. Doesn't anyone else find that strange? There's great detail of it's performance and UI, and all the pics of the flashlights, I'd assume it's implemented in some sort of production phase so it must exist.

I'll stop here. Enuf said already...

Sorry if this isn’t the appropriate moment, and I don’t want to throw wood into the fire, but isn’t this the link with the driver?

I’m not questioning that part at all, I sure would have included a photo. But what does that have to do with BLF firmware compatibility :question:

That’s the previous 2.0 version, it’s a 7135 based driver, not the linear driven FET version 3.0. Bocian included the link for reference as firmware functionality is similar.

He already said the hardware is based on the convoy linear FET driver in post #11.

I think I get where Tom E is coming from because this seems like an unusual thread. There is a lot of information that seems like it is presenting a product to sell. But it seems it’s actually just details of some mods he’s done that he is selling (locally I guess).

These linear FET drivers have a lot of potential (as is apparent from led4powers drivers’ popularity), and this convoy driver which is cheaply available and uses the common attiny MCU has potential to be a nice BLF modding platform. This particular FW is unfortunately not shared by the OP but I think it’s a matter of time until someone develops open source FW for it.