Ahem, no, that would be about 342 years, if you check your maths.
But whose counting ? 
Oh, so this case is for dual switch lights, not single switch clicky.
I basically have this done, just have to add it to dual switch configuration and have it as a setting. I would not make this default standard behavior but rather an option that can be enabled/disabled.
Yes, it’s for e-switch lights with either reverse clicky or solid tail.
Oops, missed a zero and a point… Attiny1634 draws 0.1uA in sleep mode, not 1uA. The years are right, the amp draw wasn’t. My mistake.
Great work, Mike! Did you get the issue with clickies figured out? What was the issue?
And may I ask where you sourced the CN5710/5711 from?
Just got back from more traveling, things have been still for a while but I’m back at it. Still working in clicky functionality. I have the major issues worked out but still doing stress tests. I really can’t stand issues that sometimes might happen, I wan’t full reliability on off time presses.
The initial issue is that the more pins I have outputting to the strings of regulators, the faster the OTSM cap is drained. 47uF was fine when only one or two regulator strings where on, but more and the OTSM functionality started to fail. Took a while to figure out what the issue was. I’ve gone up to 100uF and that issue appears solved but I am still working on the OTSM code for some circumstances.
I get the CN571x regulators from here: https://lcsc.com/ So far they have been nothing but fast and reliable. Gotta tip my hat to Schoki, he was the one who tipped me off about these regulators and where to get them 
Thanks for the update, Mike. I hope your travels were pleasant.
I did see them at that website but I had never heard of them up to that point 
Sorry, not firmware related… just studying the driver design. But I was looking for your voltage dividers, but it looks like most of the resistors are for pull down or current setting. Am I missing them? Or does the 1634 have a fancy way of reading voltage?
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 ) 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. 
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. 
There’s no where else to ask, plenty of technical questions in here already, ask away
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.