It’s a new linear driver by Led4power that does not use pwm for dimming so it has much better efficiency at lower currents. No relation to IO.
Thanks Rufusbduck
Meant to put it in the original thread.
That where they talk about it being sold by IO.
That’s refer to XM-L2 on copper, that HKJ probably need if he damage his leds while doing testing the driver.
Updated the OP with new tests of batteries, and enabling turbo mode. Also tested the medium against a PWM based medium mode in a Nanjg driver configured at 4.2A.
LD-1 has 10mohm sense resistor in current path,even on turbo,that's 50mV extra voltage drop.Could you post a pic of your setup,especially at which place on driver you soldered negative wire?Best place is very close to sense resistor(otherwise gnd ring will cause extra voltage drop that can be higher than 50mV).
Also very nice test Nanjg vs LD-1. It's important to note that results will be even better(worse for pwm) if that nanjg had 2 extra chips,because LED efficiency is worse at 5A vs 4.2A.
Thanks for doing the LD-1 / Nanjg efficiency conparison, saves me from doing that :-). The driver does what theory promises.
Not being able to get much over 5A on Turbo using a single li-ion is consistent with my numbers, to get over 5A the voltage at the driver connections must be almost 3.8V, not many batteries can keep up 3.8 V at 5A load for long, and in a flashlight there's even some voltage loss before the driver (spring, switch).
I mostly use modes in the 1 lm to 10 lm range, sometimes 0.1 lm or up to 50 lm, and more like 100 lm to 200 lm for biking… but anything above that is pretty uncommon for me. So, more efficient low/med modes sound very interesting.
Looks like this should be able to get about 40% or 45% longer run times on low/med modes, compared to PWM. Maybe less on lights which aren’t driven as hard, and more on lights with a higher maximum.
With PWM above 10 kHz, the output looks very similar to true current control… but the runtime is still shorter. I don’t mind this very much on 1x18650 lights, but it’d be really nice to get a current-controlled driver for smaller lights like 1xAA or even 1xAAA.
I soldered the LED wires where you said to wire them in your thread OP. The neg. wire is on the large flat pin of the FET - I wouldn't try anything on my own - don't know enough 
. Actually that is how we wire the neg. wire on the BLF DD drivers too.
Ohh - so if you wanted to lock down the driver to turbo mode, can the resistor simply be bridged, eliminating that 50 mV drop?
That's where I put the minus led wire too, on the FET.
Bridging the sense resistor removes the option of making a switch for moon2
Yes,negative led wire should go on fet,I was asking for battery negative wire,or did you do measurements with driver already mounted in pill?
Shorting sense resistor will make this driver practically single mode direct drive,but I don't see the point of this mod.
Already mounted in a big copper pill, soldered driver edge to the pill in 3 spots. Ok bout the resistor - I thought you were pointing the added V drop from it, implying it could be removed, but I think I see - it's just part of the design.
Updates just made in the OP - verification against HKJ's measurements.
Nice work Tom, however the modes get implemented LFP has come up with a really nice driver.
You can calculate how much nanjg will produce at 0.09A : (0.09/0.16)*44=24.75lm
Now you can calculate gain of LD-1 : 34/24.75~37% more brighter at 0.09A.
I updated the OP with info on using it in a Yezl Y3 (tailcap button and side e-switch).
Nice testing of the e-switch modes!, you really made a good effort of testing the driver. I'm still away for the holidays and back next tuesday, I will think of useful tests leftover to do.
Driver mounted like that has almost no thermal transfer,I recommend you some kind of potting;if you don't like permanent potting,thermally conductive silicone sheets and "cubes" (http://www.fasttech.com/products/0/10003973/1285500-thermal-conduction-silicone-rubber-cubes-1105cm10-) will be better than nothing.
That's correct,there is a slight delay when you change modes in UI_1,because of -double click to decrease mode- ability.
Driver waits for short period of time after e-switch is pressed to see if there will be another e-switch press.
I can change the code for instant mode changes,but there will be no more double press for mode-- ability.
I'm curious about this, because this is how I typically do it, assuming the - wires connecting between the PCB's would hopefully be sufficient for thermal conductance. I was really thinking this isn't much worse than typical ways a driver is mounted, because they are usually just mounted on a thread of a ledge, and maybe 2-3 solder contact pts, if there a brass mount or copper mount available. If the pill is all aluminum, options are usually worse - I've found if you can press fit the driver in, it usually it is not electrically making contact, so even though it looks like the dirver is sitting on the shelf making contact form the copper ring on the driver to that small ledge, it's not really making contact at all, so you have to jam in some copper material to get a good electrical contact, but then, the thermal transfer is limited to just the contact surface doing the elctrical contact.
Would simply adding more wire or copper material connecting between the two driver grounds (battery neg.) be better? I know O-L seems to prefer something like that on his high amp 7135 based drivers. I believe he sees a lot of thermal sag with simple stacked 7135's, but if he spreads them out to another slave board, and adds copper heat sinking, it reduces the heat sag.
Or could I simply solder on copper material to the driver outer ring, adding mass, and adding more surface area to better dissapate the heat?
More on Modes
I'm getting quite used to the 3 groups of modes now with the e-switch control, and their are some pros/cons as any light, or any mode set would have - personal preferences vs. real issues. Only issues that might be real issues so far:
- ramping between 50% and 100%, down or up, is difficult to see going on - much more noticeable in the lower 50%. This was responsible with my initial confusion of how ramping worked -- I just didn't notice ramping was working at all when in that higher range.
- when doing the 7 sec hold to switch mode groups, if you are in a low or moonlight specially, the blink that occurs at 7 secs is hardly noticeable - every so slight flicker if you really concentrate, but very easily missed. This probably gave me a great deal of problems initially, but now that I know, it explains a lot.
- I keep triggering the temp threshold setting by doing 1/2 clicks on the power switch in sequence -- this is very frustrating... Not sure how to avoid this. It's difficult to test the functionality of the power button because every time, I trigger this temp threshold setting.
- The blinks, count, frequency, meaning, etc. gets very confusing. I see them too often and not sure what I did to get them. Certainly one reason is the temp threshold form the issue above, but not sure if there's more to it, or if that explains it all. Maybe for the proto units, the temp threshold is ok, but I'd consider disabling this user setting once in production, or implemened a different way.
led4power explained it pretty clearly how these mode groups work. The 3rd mode group is your standard 3 or 4 modes, like in group #1, 4 if you have moonlight enabled.
-ramping will be fixed easily,increasing speed in 50-100% area,and decreasing in 0-50%
Based on all tests and measurements,I think I will remove user temperature threshold and turbo,and put timer on high option instead. Since turbo is only slightly higher than 5Amps with xm-l2,it makes no sense(if someone still wants that 0.5-1Amp extra,it can be done by stacking resistor,all other modes will be also higher by same percentage-10%-20% which is not much,so no problems),and without external temperature sensor with good thermal connection with led star or flashlight body,it's hard to implement good and accurate overtemperature function(driver overtemperature-100-120Cstays).
Good example is Tom's way of mounting this driver in Y3.It practically floats in air,with no thermal connection with flashlight body,so it measures its own temperature,not flashlight.This is why user overtemp protection without external sensor is problematic.
So,with user overtemp removed,there will be no more 10 or 15 clicks to change user temp threshold,so no more problems with activating those functions with half clicks either (I thought that 10+ fast half clicks is enough to prevent that,what do you do with your flashlight Tom
).
Also with e-switch only one changeable function remains -UI change,I will increase time threshold to 10-15 sec for that.
Now different blinks problem,I have an idea:we should set some kind of standard for all custom drivers when we talk about warning/info blinks.This way it will be easier to remember what each blink means.
For example:
low_voltage_1_threshold_blink - 5 blinks,3Hz ->this is for higher (3V for ex.) voltage threshold,drivers still works but power/current is restricted
low_voltage_2_threshold_blink - 10 blinks,3Hz->empty battery,driver shuts down (2.8V for ex.)
high_temp_1_threshold_blink - 6 blinks,1Hz ->user threshold temperature(desirable max. flashlight temp) is reached,driver decreases current
high_temp_2_threshold_blink - 3 blinks,1Hz ->driver threshold temperature(set in firmware) is reached,driver decreases current
Of course,if driver doesn't have overtemp function,it wont use blinks for overtemp.