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

There is a voltage divider on board, it’s 3K / 1K divider, you can see 302 and 102 marked resistors. I don’t use it for voltage measurement though, to read voltage on 1S drivers I use MCU VCC as voltage reference, then connect internal reference voltage (1.1V) to the ADC and measure it. Essentially I don’t need the divider, at least not one of the resistors, but as it is now I use it for OTSM power off detection.

I put in a divider in case it would of be use, like for future 2S versions. However, there certainly won’t be 2S versions. I just did a test with a CN5711 and a MT-G2 LED. They are rated for 6V but I thought perhaps the thermal throttling might save it, but nope, it fried with accompanying smoke signals just shy of 8V. They simply aren’t suitable for 2S.

On the positive side, the CN5711 connects to the positive side (I’m just repeating myself :wink: ) of the LED, which makes the CN5711 itself suitable for LEDs with a grounded thermal pad (like black flat).

An update… I’ve been testing my new version of the driver, isn’t it pretty?

Well, I actually do have boards, I’m just testing a bunch with this test platform before committing to building any. The new version has an improvement. With a little trickery I have converted the 256 step 10K digipot into a 768 step 30K digipot. This means I have constant current adjusting down to ~60mA instead of ~160mA.

I’ve also been testing with a 50K digipot. It’s a better option if really low constant current modes are of interest, but because of the resistance range of the digipot the higher output steps are too big. One step of the 50K digipot changes over 0.4A at the top end. This prevents having a smooth ramping algorithm over the entire range. I might offer it as an option, choose between smooth ramping or really low constant current outputs with jerky horrible nasty ramping. I’ve done the same trickery with this 50K digipot and converted it into a 768 step 150K digipot, which means adjustable constant current down to about 12mA. Could that be of interest for those that prefer traditional mode change UIs because the ramping is just plain ugly. However, 150K ohm is well above max specified resistance in the datasheet (30K) so I don’t know if there is any flickering. I can’t see any but I should hook it up to an oscilloscope and check.

what do you mean with digipot?

usually at some level its better to PWM the CC circuit than trying to get it running very low
less tint shift and smoother ramping

I’m curious how both chips (the CN5710 and CN5711) react to PWM. Especially how they handle Fast PWM since the datasheet says that the max recommended is 2KHz. I have neither the oscilloscope nor the know-how for assessing such capability. :frowning:

Not sure I understand the question. With digipot I mean digital potentiometer.

Of coarse. I’ve been using 10 bit PWM on 160mA with these previous versions, it works fine. I’ll use it on this new 60mA setup too. It’s just that I like to use as much CC without PWM as possible, for no other reason than to see how low I can go. Practical and usable? Maybe not, it’s just for fun. I don’t find the tint shift at these low output levels to be noticeable unless you really look for it… which I don’t.
EDIT: Obviously tint shift is different depending on LED choice. I haven’t used these drivers on many different types of LEDs, I might very well notice it after more testing.

I use 10 bit fast PWM on them and the transition from 160mA constant current to PWM is smooth. It looks good, but how good it is I can’t tell. We have an oscilloscope here at work, but honestly I wouldn’t be able to tell if they react good or bad to PWM because I wouldn’t really know what I’d be looking at. I can say that with 10 bit fast PWM, the lowest usable value is 5. It’s smooth increase from there up, but lower and the LED basically goes out, barely visible and no visual difference from 4 down to 1.

:+1: Thanks! 2KHz just sounds bad, glad Fast PWM works. I’ll have to give that a shot when my parts come in.

Development is on going… not at lightning speed exactly… Anyhow, now I’ve at least reached the stage where I can start testing all switch combos in a real light so I’ve built a dedicated test unit. Posted in the mod today thread but worth posting here too.

I’ve had a L4 laying around hardly used for ages so why not give it new life as a driver firmware testing unit. My drivers are 17mm though, so I made a specific version for the L4 with integrated E-switch. As it’s bigger I can fit more regulators on it, so I now have full constant current PWM free ramping from 0.05 amps up to theoretically as high as 8.5 amps.

New custom L4 driver:

Flashing latest firmware:

The only LED I have around that can handle up to 8.5 amps is the SST-40 so that’s what I used. So, now I finally have a test unit. I need one because testing on a bench platform is not the same as using a real light.

Not sure if this is the best thread for tech questions/discussions on this driver. But if you could summarize as brief as you can the basics of CC drivers. I know there's no PWM's and therefore very efficient. But I thought heat is a problem when running at lower than max output. Also don't know whether resistance is still an enemy since it doesn't boost voltage, or does it?

For the UI I'll cover the basics:

  • my priority is always 1 click ON, 1 click OFF with no delays, and press&hold for ramping. Whether ramp levels are only 2-7 or a smooth 200+ (maybe 100+) would be configurable/switchable some how. Ramp direction can be switched based on timing since the last ramp. It's important to have last level memory, but be able to override memory with easy access to lowest and highest levels.

This is basically what Anduril does, based on Narsil, but we are seeing more and more commercial lights operate this way, and I like to think BLF has been an influence on this trend.

More magic. :slight_smile: :beer:

There’s no where else to ask, plenty of technical questions in here already, ask away :slight_smile:

I described the use of these in the OP, but in short the regulators on these drivers use current sense resistors from 1,2 K ohm and up. That’s a handy resistance value, so on one of them I use a 256 step 10K digital potentiometer instead of a fixed resistor which makes it fully adjustable. When it reaches it’s max current I turn on another regulator with fixed current and reset the adjustable one back to lowest current setting. The CN5710 is rated up to 1 amp, the larger CN5711 is rated to 1,5 amps. I’ve also “converted” the 256 step 10K digipot into a 768 step 30K digipot which makes the regulator adjustable from max down to about 0.05 ~ 0.06 amps in 768 steps.

It’s not one regulator covering the full range, it’s several. Fat3 has 3, Slim4 has 4 and this new L4 version has 8 of them. These regulators also have thermal throttling as opposed to thermal shutdown. I tested it and posted it in here on post #39, it works well: Driver giveaway: Constant current 17mm drivers, winners (finally) announced, post #2. - #39 by Mike_C

No boost. Only current regulation.

I have to ask about this. When exactly does the light turn on? As soon as you press the button? Or as soon as you release it? Currently I have short cuts from off and I don’t want the light to cycle through modes when entering the short cuts from off, so I have a very slight delay for multiple press detection. Narsil and Anduril don’t have this delay? Does that mean they don’t have multiple press short cuts from off, or they cycle through the modes when entering these shortcuts?

For NarsilM, I do it on button release for both 1 click ON, and the 1 click OFF. Anduril does it differently - I think for going ON, it uses the button press, but for going OFF, she does have a noticeable delay but I believe she's trying to fix that.

NarsilM will have small delays for multi click sequences, so for example: a dbl click goes to turbo, but for a triple click I don't want the user to get a blinding flash, so I delay to properly detect when the multi click sequence has ended. My earlier versions did not have that detection/delay and I got complaints.

Ok, just read that post bout doing the thermal test - Wow! That's pretty cool. We'll have to see how that plays out in the real world I guess, unless you already know or you know what to expect. I don't understand everything though, bit I assume this driver will be capable of true smooth ramping? If so, could we still apply the non-linear intensity ramping TK came up with and is used in both NarsilM and Naduril? We use a python script that TK wrote to generate the tables, parameter driven.

Thanks for the explanation.

I do smooth ramping with these drivers. The actual mode values used in my firmware (and stored in eeprom) are current values in mA. For example for 3 amps the mode value is 3000. I use the current sense formula in the datasheet to calculate the digipot position and how many additional regulators need to be turned on to meet the entered current. My ramping is an algorithm that increases/decreases the LED current exponentially based on the current value, and it’s rather smooth. I haven’t settled on the final algorithm yet but it’s good enough to continue on with other things.
I could even go one step further and have lumens values instead of current, but that would mean separate formulas for each LED type. I know, it’s absolutely unnecessary, but this kind of stuff is the fun part of the hobby for me :slight_smile:

OK, that's all cool for what sounds like a pretty good smooth ramping, maybe even better than ours because switching channels on ours isn't the greatest, least in NarsilM for a triple channel.

Progress is slowly moving forward. I had a break from firmware development and spent some time designing drivers, among others a driver with a micro USB port that I’ll use for flashing the driver, so no need to even unscrew the head… if it works… But that’s done and OSH Park have the ball on that project, so back to firmware again.

Okidoki, I finally have basic firmware functionality including configuration system for all switch types. I can finally get down to the details some of you have posted. I hope those of you that have posted haven’t lost interest yet and can answer a few inquiries I have about some suggestions. I’ll be asking every now and then.

I’ve only once had a flashlight with forward clicky and I didn’t like it at all so I’ve not used forward clicky since then. Because of that my firmware isn’t really written with forward clicky in mind. However, I’m interested to see if I can make it work. You state that with FC on guppy3drv you can double click for turbo. Does this shortcut only work from cold start? Or can you do two short offs and go to turbo at any time? I am kind of curious on how this double click short cut with clicky switches work, doesn’t it interfere with normal mode changing? If you turn the light on and want to switch modes instantly, isn’t the short cut to turbo going to kick in instead of fast mode cycle? Or dose guppy3drv assume you don’t change modes rapidly? I have support for clicky switch short cuts but having a double click short cut really interferes with normal mode changing. That’s ok if you only have three modes, but then the double click short cut is useless.

^ You have to select your mode from half press momentary. Press-press for turbo then press all the way to click.

Just thinking that if the light is started in lowest mode and you want to step up only one mode brighter but not to turbo/boost, how would you do that? To me it seems the same press sequence would be used.

Leave on just a little bit longer before release and press. Put more time between inputs.

OFF—-Press until light (lowest)— some time—-release/press to next mode brighter—full press to click to lock on.

For Turbo

OFF -Press until light(lowest)—quickly release/press to turbo— full press to lock on.

EDIT- this is how it works for H17f. On Guppy 3drv you might have to quickly release/press 2 time for turbo.

Aha, ok thanks. You basically have to wait for a “multi press detection timeout” before the next press. I have multiple off press detection, but as being a reverse clicky guy it would be fairly annoying to have to wait between off presses with a 4 to 5 mode light. Out of curiosity, do you know exactly how long the timeout is on H17f or guppy3drv? I’ve set mine to half a second.

With H17f and possible guppy3drv there is no waiting on the off presses to change modes. IF you do wait you will either go back to mode memory, or reset to beginning of mode sequence.

Edit, removed video link. Wasn’t working