Extended driver 3.0 6A + 21700 mods

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:
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.

As I promised. Pictures are a bit dark because I had poor light.

1 Thank

What is the button you use on the spring? Looks like one from a pair of jeans

Haha. No, this is not component of the pants :smiley: It is silver plated brass. To be precise, it is conductive part of Omten 1288 reverse switch.

BTW. Current bypass is not copper braid for removing tin (as many people use which is only slightly better than ordinary silicone insulated wire but also very short-living). It is a special braid (reinforced with thin nylon threads) intended for mechanical work on powering the speaker coil.

1 Thank

Question for you, what is additional purpose of using spring bypass for linear driver? I understand for fet direct drive, but not linear drive. Since driver is linear and heating is relate to current not resistance, reduceing resistance in spring will only lead to slightly less heating in spring and slightly more heating in fet where all heat is in causing hot part to become hot faster. Why not leave spring with no bypass to allow additional heat to dissipate away from driver head to rest of flashlight body with more distribution and less work? But maybe my reason is incorrect. Thank you.

The lower resistance here may lead to more heat in FET but only during first 1/3 or half of battery, no? After that it will lead to longer run times with the reduced resistance right?

I don’t like to dispatch heat in place I can’t control. Dispatching heat in places like springs, electric contact surfaces results in damaging and deforming these components in time. You are right that lowering ressistance in flashlight circuit for a linear driver causes more heat dispatch in FET element (but only on fresh charged battery - bigger voltage difference between power supply and LED forwarding voltage for selected current value). But finnaly we have longer time of full current stabilization on selected mode.

1 Thank

Where did you get the tir throw optic and the nicd looking round thingy;)? do they fit nicely?