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

I’d like to have this kind off UI for example:

Used in an dual switch light the e-switch sets modes and the (forward) clicky just turns on the light. Easy to use, predictable and somewhat “tactical”.

Definately in for either of these drivers - nice work :+1:

As far as FW goes - the ability to switch between programmable dedicated modes & a ramp, with options for memory or high/low start.

Cheers :beer:

Interesting work :+1:
My favorite firmware of the moment is on the Dr Jones H17F where you can choose the number of modes (though limited) but enough, the value of each mode configurable with a programmable hidden mode and also secondary group.
The only improvements on this to me would be faster acting thermal regulation, voltage readout in actual voltage and some more configuration steps.
I like set modes so I can know how
much time/ light I should get out of a given cell at a chosen mode.

Nice work Mike C and thanks for the chance at checking one out. I’m in.

+1 what some of the other commentors have mentioned, repeated below

Preference in a UI are for -

  • Hidden strobe/beacon
  • Direct access to Min (something like Long Hold from Off)
  • Direct access to Max (something like Double-Click from Off)
  • Direct access to Memory mode (simple Click for On)
  • With Simple Click for Off
  • Direct access to Modes changes (typically Long Hold while On)
  • Electronic Lock-out/Unlock (typically triple-Click or Extra-long Hold while Off)
  • The 256 increments would be perfect for either a “Ramping”/Stepless level changes and/or
  • If fixed levels, then 4-5 well spaced increasing levels that users can customize (similar to Zebralight’s L1/2/3, M1/2/3, H1/2/3)
  • Ability to enter into a Tactical mode, where button presses do not change levels but function as On/Off, (reset by removing battery)
  • Also the recent adaptation of a wave-like cycling of fixed step levels would be nice, L-M-H-M-L… (as an alternative to the traditional method of cycling of L-M-H-L…)

Battery Checking, Thermal Cut-off, etc. user configureable also good, and usually accessed through long series of key combinations (such as 10-18 taps etc)

This is what I want in a EDC UI

Something simple to this would be awesome.

I’m in. I maybe put one in an L2 with an Osram white flat. Good to adjust current!
My needs from a firmware that ramping smooth. Short click on/off. Be able to reach moon, last used mode and turbo from off with short cut. battery level blinking out.

Some good suggestions in here, thanks. I can do a lot of it already, but there are some neat suggestions in here I might be able to implement. Keep ’em coming!

For E-switch and dual switch lights I have the ability to enter config menu to change UI and other settings. From off I turn the light on and keep E-switch pressed and it will start blinking. Each blink is a step in the config menu. For example, release on first blink and you are in the “select UI” menu, release on second and you’re in “mode memory options” etc etc. I haven’t really come up with a satisfying way to do this with clicky switch though. I want it to be easy, but not so easy it will interfere with regular mode selection. I’m now thinking three clicks directly from cold start. If light is on longer than a second or so, window to enter setup is gone. Any other suggestions on this?

By design. I found that these regulators need a pull down resistor or they tend to flash on start-up before the enable pin is properly pulled down by MCU. First I was using 0402 resistors, but man do I hate those tiny little things so I decided to save board space and do it this way with 0603 instead. I did try putting the current set resistor this way too, the opposing pin to middle GND pin, but fitting both resistor ends on the middle GND pin proved to be too much of a hassle to assemble. One works nicely though, I put ’em on during initial assembly for reflow, no need to add after.

I have no idea how to make MCPCBs and the only one I know that does this is Led4Power. I could never make MCPCBs at that quality or price so they are only option I know of. I don’t know enough about his designs though. If they are high side mosfets on his MCPCBs I could probably use them with my current Slim-4 design. Maybe I should look into it, having the Slim-4 with an external mosfet for boost/full blast would be pretty neat!

Yes (it’s in the thread title :slight_smile: ) I remember your black magic comment, and my reply still stands, the stuff you do is magic to me! Your latest competition entry for example… Jaw dropping!

This is a very interesting driver concept!
Would you mind to share the digi-pot type you selected?

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.

Those drivers… are :LOVE: lovely!

UI suggestions:

Whilst I like ramping, I still prefer fixed modes because I can estimate run-time, and select a suitable brightness level, e.g. if I know it is going to have to last so many hours.

So make the ramp halt at fixed intervals, corresponding to modes. e.g. press and hold, torch ramps up to next level, then stops. Press and hold again, ramp up to next level. Brief press, then release and hold again, ramping reverses, this time stopping at each lower mode.

This is the Narsil, Anduril etc. ramping behaviour, except that they don’t halt at fixed intervals. Narsil does give a brief flicker as the threshold from 7135 only, to FET PWM s transitioned, but that’s not very helpful if you want a bit more power, but still to have confidence in your run time.

I’d like to see a quick and easy way to access batt-check. It’s a feature I use a lot, every time I pick up a torch that has it. It would be nice if the torch flickered a warning each time the voltage dropped to another level, corresponding to say 3/4, 1/2, 1/4 remaining (3 blinks, 2 blinks, 1 blink), then a continuous brief blink say once/minute below 1/8.

I’d like a “flashy” mode that turns the e-switch (or a forward clicky) into a momentary switch enabling me to e.g. signal morse, or an alpine distress signal, or just flash it around briefly and silently. Output level in this mode to be as memorised in normal operation.

Not sure how to get back out of this mode though. Perhaps only suitable for e-switch, where a battery disconnect could revert to normal operation.

And an energy efficient alpine distress mode that could last all night. 3 or 6 blinks, repeated every minute.

I like what you’ve done with the hardware. Fresh thinking.

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

I see the Consonance regulators automatically limit their junction temperature to a safe level by throttling back. Neat. Maybe good enough for overall thermal management of the torch if in close thermal contact with the shelf (e.g. silicone thermal rubber packing). Do they PWM nicely for the lowest levels ?

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.

Very interested to see how this develops.

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

Thank you sir!

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.

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

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.

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

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

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

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.

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.

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.

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.

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.