Driver giveaway: Constant current 17mm drivers, winners (finally) announced, post #2.

[Mike_C]

@Barkuti

Those drivers… are :heart_eyes: lovely!

Thank you sir!

@Tom Tom

Do you have a feel for what the thermal limitations will be, worst case, i.e. high cell voltage, low LED Vf, intermediate current setting ?

I have not done enough testing on this. The 1.5A CN5711 on the Slim-4 is a lot bigger than the 1A CN5710 regulators, but I have not really tested how the thermal throttling actually works on either of them. I intend on hooking one up without PCB just to test. I built a light with the Slim-4 and took it with me on my three month vacation. I didn’t notice any throttling if it did throttle, but will admit I didn’t have it on intermediate mode for a longer period though, max was maybe five minutes or so. The light is with Convoy M1 host and SST-40 LED.

@Tom Tom

Perhaps FAT-3 with direct drive FET will be more practical than SLIM-4. providing you have found a Pfet with a sufficiently good Rds-on.

To be honest, I don’t know all the characteristics to look for with FET choice but I think I picked one with a low enough Rds-on (Vishay Si7157DP).

@Tom Tom

Do they PWM nicely for the lowest levels ?

I should hook it up and test that, but haven’t. Looks OK to the eye, but I might be too slow to pickup visible flickering.

@Tom Tom

I’m guessing that you intend a spring bypass lead through the hole in the centre of the spring pad, then linked to the big + via on the other side.

The spring via is so the battery + wire can have direct contact with the + feed of the FET (Fat-3) or 1.5A regulator (Slim-4) on the other side. As Cereal_killer writes, these are high side regulators and spring bypass to LED+ will result on true direct drive.

[Tom_Tom]

@Cereal_killer

@Tom Tom

I’m guessing that you intend a spring bypass lead through the hole in the centre of the spring pad, then linked to the big + via on the other side.

He explained, with pictures, how it switches the high side.

Batt+ spring bypass goes to FET source, LED+ is fet drain. If you do the spring bypass to the led+ pad it will be true direct drive [only].

Thanks, I understand perfectly how the high-side drive with the regulators or Pfet works, but mislead myself looking at the layout :person_facepalming:

Clearly the + and - vias are for the LED connection only.

That hole in the spring pad does still look useful for doing a spring bypass, if the other end of the wire is connected correctly. Or a stud is used, instead of a spring.

Those CN5710 regulators do look interesting. A refreshing change from so many basic 7135 designs.

http://www.consonance-elec.com/pdf/datasheet/DSE-CN5710.pdf

[dingwat]

Mike, I’m curious: what’s the reason for the numerous large plated through holes? Are those test points? I see what appear to be labels, but they look huge for test points.

Also, I don’t see an ICSP land pattern; what’re you using to program these?

Regarding firmware, I’m a fan of Anduril. I love a ramping UI, and my usual use really just wants a sane ramp with shortcuts from off to moonlight and turbo as well as shortcut to turbo while in the ramp. Anduril and NarsilM both fill this need (and on the barebones end, the Thrunite TH20 UI accomplishes this well), but the extra features are nice to have, particularly lockout, momentary, muggle, and battery check. Conveniently, it sounds like TK will be working on t1634 support for Anduril, so your MCU choice is great

Cool CN5710-based design! As Tom Tom said, it’s neat to see designs departing from the 7135.

[Cereal_killer]

@Tom Tom

That hole in the spring pad does still look useful for doing a spring bypass, if the other end of the wire is connected correctly. Or a stud is used, instead of a spring.

I believe that’s the intended design (atleast that’s what the design says to me), as is usual in linear drivers the lower the total resistance the better… Bypassing the batt+ spring to the FET’s source will mean the only real source of resistance in the current path would be that of the FET itself.

[Tom_Tom]

@Mike C

To be honest, I don’t know all the characteristics to look for with FET choice but I think I picked one with a low enough Rds-on (Vishay Si7157DP).

I took a quick look at https://www.vishay.com/docs/62860/si7157dp.pdf and seems like a sensible choice, for a Pfet. Good Rds(on) when the gate is driven sufficiently.

However the threshold voltage needed is on the knee of the curve, it doesn’t start turning on fully until 3V or so (at 25C). And as it gets hotter it needs more volts, at least 4V at max Tj (125C). Typically (not absolute max.etc)

See page 4 of the .pdf, graph “On-Resistance vs. Gate-to-Source Voltage”.

If you are using a Schottky for reverse polarity protection, and knowing that the MCU may not drive fully to the rails, with cell voltage below maybe three and a bit volts you might not be driving it hard into saturation.

This is the difficulty with Pfets, they rely on holes for conduction rather than electrons, and the physics is rather different. Much easier to make a logic-level Nfet than a Pfet.

Also Pfets tend to have higher gate capacitance, making PWMing them at high frequencies a bit trickier. If the gate drive isn’t strong enough (e.g. just an MCU pin) they can spend a lot of time in linear mode during the transitions (i.e. getting hot).

Just something to look out for when evaluating. I think it should work well in this application.

[Cereal_killer]

He’s switching the pfet with an nfet so the gate signal (to the P-FET) will always be full battery voltage,not at the mercy of what the attiny can output and no vdrop from the polarity diode.

[Tom_Tom]

@Mike C

@Tom Tom

Do they PWM nicely for the lowest levels ?

I should hook it up and test that, but haven’t. Looks OK to the eye, but I might be too slow to pickup visible flickering.

I read the data sheet again. Page 6. Maximum recommended PWM is 2 kHz. Which is fine by me, for low levels where my eyes don’t respond fast.

I only really notice slow PWM when it is raining, or looking at waterfalls, or waving the torch around madly, light-painting etc. and becomes almost psychedelic. However my dog does see it, and averts his gaze on night-time walks, if I bring the wrong torch.

Otherwise just a resistor from an output pin (do you have any left ?) could do the job, DC or fast PWM, if you have enough timer-counters left.

Page 7 also worth a read.

[Tom_Tom]

@Cereal_killer

He’s switching the pfet with an nfet so the gate signal (to the P-FET) will always be full battery voltage,not at the mercy of what the attiny can output and no vdrop from the polarity diode.

Sounds good. Up to the point that the cell voltage dips (under load) into the region where full gate drive is questionable.

But why does anyone still use a Schottky to protect the MCU from reverse polarity ?

You can do the same thing with just one tiny cheap Pfet, no other components, and have essentially zero voltage drop to the MCU.

And perfect calibration of e.g. V-bat readout by the MCU without dodgy variable components at the buyer’s whim, their temperature sensitivity etc. getting in the way.

This also indirectly knocks on to temperature readings as well.

My only caveat is that, whilst the Pfet is conducting, it conducts in both directions. Yes they do. Not generally taught. So any decoupling on the MCU side is actually still directly connected to e.g. the LED +V rail, with all the glitchiness and spikes that might entail. A slightly more sophisticated filtering network than a 4R7 resistor and a cap. might be needed. Or not.

[thijsco19]

Very nice looking drivers!
Good to have some new designs.

Im not that familiar with all the firmware’s out there and Im not that picky on a firmware. But what I would like to see is both ramping and set modes available.
For example for a electronic switch (or combination), regular mode operation. Single click start low, and use single clicks to move upwards. Click and hold to ramp from current mode up -> when max reached ramp down -> when min ramp reached ramp back up. When single click withing this ramp feature, proceed to next level thats higher than current level. (when max go to min)
From on double click to go down.
From off click and hold to go to max or a custom set level.

This is just something I just though about.
Yes Im in, would like to use the slim-4 with a white flat for a nice throwy light.

[MRsDNF]

@Mike C

@MRsDNF

Are these 17mm in diameter?

Yes, it’s in the thread title.

Things really do get worse with age.

[Flashy_Mike]

@Mike C

No problemo! I use the AD5160. I’ve found the 10K version provides best combo of resolution over range and lowest output for these particular regulators. I power them directly from an IO for lowest parasitic drain on E-switch lights.

Thanks!

[Boaz]

Archeon had a great ui . Starts in mode 1 always .....3 modes Each mode ramps by holding button from bottom 1 lumen to 100%. Release it sets the output a click advances modes if you click quick e nuff if not back to mode 1 each mode ramps to any output you want . Simple and brilliant

fat3

[Mike_C]

@dingwat

Mike, I’m curious: what’s the reason for the numerous large plated through holes? Are those test points? I see what appear to be labels, but they look huge for test points.
Also, I don’t see an ICSP land pattern; what’re you using to program these?

The holes are used for programming “acupuncture style”.

@dingwat

Conveniently, it sounds like TK will be working on t1634 support for Anduril, so your MCU choice is great

Interesting, I didn’t know TK was looking at the 1634. Hard to follow everything that’s going on here. Nice to hear, I’ve been using the 1634 for quite some time now but no one else seemed interested in using it. I made some 1634 drivers back in March 2017: Mike C drivers: v8 series, ATtiny1634 based.

@Tom Tom

It doesn’t start turning on fully until 3V or so (at 25C). And as it gets hotter it needs more volts, at least 4V at max Tj (125C).

Aha, I didn’t know that. I’ve built a few and they all turn on lower than 2.7V, but probably not fully as you say. I’m all ears when it comes to these things. Do you have another suggestion? In regards to it’s PWM characteristics, I don’t care at all because I don’t use PWM on it. I only use it for full blast on, I have the CN571x regulators for lower modes.

@Tom Tom

But why does anyone still use a Schottky to protect the MCU from reverse polarity ?
You can do the same thing with just one tiny cheap Pfet, no other components, and have essentially zero voltage drop to the MCU.

It actually isn’t there for reverse polarity protection, even if it does that too. It’s there for the OTSM cap. But once again, I’m all ears for these things. Will a Pfet prevent OTSM cap drain? No reverse leakage? The diode does a good job of it. In my calibration and voltage reading I have a simple compensation routine for the voltage drop over the diode. Sure, it’s not perfect calibration, but during my tests with other methods of calibrating voltage, perfection is not easily obtained anyway. I have about 5% tolerance, I’m totally fine with that. Still, interested in the Pfet solution, I’d surely need to test it to make sure it doesn’t leak the OTSM cap. If it’s just a simple component replacement and I can fit it, no reason not to implement it in future versions.

[Tom_Tom]

@Mike C

It actually isn’t there for reverse polarity protection, even if it does that too. It’s there for the OTSM cap. But once again, I’m all ears for these things. Will a Pfet prevent OTSM cap drain? No reverse leakage? The diode does a good job of it. In my calibration and voltage reading I have a simple compensation routine for the voltage drop over the diode. Sure, it’s not perfect calibration, but during my tests with other methods of calibrating voltage, perfection is not easily obtained anyway. I have about 5% tolerance, I’m totally fine with that. Still, interested in the Pfet solution, I’d surely need to test it to make sure it doesn’t leak the OTSM cap. If it’s just a simple component replacement and I can fit it, no reason not to implement it in future versions.

The Pfet is a great solution for reverse polarity protection, but as I said it conducts both ways, so current can flow either way, as long as the FET has gate drive.

To use it for reverse protection, you actually connect it “backwards” so the body diode is conducting when in the correct configuration (i.e. source and drain reversed from what you might conventionally expect).

E.g. see http://www.ti.com/lit/an/slva139/slva139.pdf

And https://www.infineon.com/dgdl/Reverse-Batery-Protection-Rev2.pdf?fileId=db3a304412b407950112b41887722615

Page 7. For a more detailed explanation of how it is typically used in e.g. automotive electronics.

Problem is, for e.g. OTSM, is that, unlike a diode, the Pfet will continue to conduct in either direction as long as it has gate drive, meaning that in a typical torch, even when the drive to the LED is disconnected by the MCU, there is a “reverse” (actually forwards, in the usual sense) current path back through the Pfet, which will instantaneously discharge the OTSM cap into the LED. Whether e-switch or clicky. Until it ceases to drive the gate.

I haven’t thought about your high-side drive arrangement, there may be some better possibilities with that.

My only concern about using a simple Schottky instead is because of the concerns with previous Attiny versions, in standard, and selected low voltage versions, and the experiments with BOD, possible flash corruption whilst saving settings in particular circumstances etc. Where a few more 100 mV supply might help.

[Tom_Tom]

@Mike C

I’m all ears when it comes to these things. Do you have another suggestion?

I’ll look into it, but I don’t think you need to worry particularly, with your choice. It’s easy for me to look at data sheets and do “design review” at a distance and question edge cases, but your practical experience counts for much more.

[Mike_C]

@Tom Tom

My only concern about using a simple Schottky instead is because of the concerns with previous Attiny versions, in standard, and selected low voltage versions, and the experiments with BOD, possible flash corruption whilst saving settings in particular circumstances etc. Where a few more 100 mV supply might help.

Yeah, I was testing that stuff extensively some time ago. I found the post: Attiny25/45/85 FW Development Thread - #1523 by Mike_C
Besides wanting more memory it was the BOD functionality for OTSM that lead me on to the 1634. With the 1634, BOD enabled and a 47uF cap I get about 7 seconds of reliable off time when measuring with 125ms intervals. I could not get anywhere near that with BOD enabled on the 85.

[Agro]

BTW, these drivers won’t fit Emisar D1 because they are double-sided, will they?

[Mike_C]

@Agro

BTW, these drivers won’t fit Emisar D1 because they are double-sided, will they?

I don’t have one so I can’t say. I tried a quick search for a photo showing the spring side of the D1 driver but couldn’t find one. I only found photos showing top side of driver so I can’t see what it is that prevents using double sided drivers in the D1.

[Mike_C]

@Mike C

@Tom Tom

Do you have a feel for what the thermal limitations will be, worst case, i.e. high cell voltage, low LED Vf, intermediate current setting ?

I have not really tested how the thermal throttling actually works on either of them.

I’ve now done some thermal throttling tests on the CN5711 (the 1.5A regulator on Slim-4). I did not test a floating regulator, I did the tests with a Slim-4 driver out on my wooden desk, not mounted in a flashlight host.

The amp measurements are from the power supply display, the volt measurements are with a DMM, the temperature measurements are with the 1634’s internal temp sensor. I set the digi-pot for a value that would regulate current to 0.75A, which is half of the CN5711 rating.

I first tested with power supply measured at 4.35V. Current drawn was 0.74A and voltage over LED was 2.87V. Initial startup the temp reading was 25C, after 5 min 58C, then no more increase after leaving it like this for 30 minutes. Current drawn throughout this test was 0.74A, so no throttling in these conditions.

I obviously have to turn it up a bit… I turned voltage up to a 6.3V, which is a little above max 6V rating. Voltage over LED was still at 2.87V throughout the test.
Initial startup the temp reading was 33C. The higher voltage most certainly impacts result, but it’s the increments that are of interest. Behold, after 20 seconds the regulator started throttling down. Throttling speed decreased as the current dropped.

Startup: 33C, 0.74A (no throttling)
20 sec: 60C, 0.7A
1 min: 81C, 0.5A
2 min: 86C, 0.46A
5 min: 87C, 0.44A
1 hour: 88C, 0.44A

I then lowered voltage to 5V and the current slowly increased and halted at about 0.7A, no change after 10 minutes. I lowered the voltage further down to 4.5V and the current increased back to the initial non-throttled 0.74A, no change after 30 minutes.

10 min at 5V: 82C, 0.7A
30 min at 4.5V: 73C, 0.74A (no throttling)

So in my books the temperature throttling of these regulators appears to work as advertised. With them I don’t really see the need of a temperature throttled mode as they appear to take care of it well enough themselves. I’ll still have overheating protection, especially with the Fat-3 on full blast, but for now my plans of implementing a thermal throttling routine appears to be unnecessary. Of coarse the temp measurements themselves have to be taken with a few buckets of salt but I trust them enough to be able to determine weather the temperature is increasing, decreasing or stable.

Edit: Edited so results are somewhat easier to read.

[Tom_Tom]

Very encouraging