Yes, I only have plans to start with momentary.
I was designing a new driver for my 2 Yezl Y3, removed the 85, inserted a 20 pin QFNL and liked what I saw 
The BLF GT used a similar solution… but instead of a linear regulator, it used a buck regulator. The top 15/16ths of the ramp used current control, and the bottom 16th used PWM at 1/16th power. It worked really well.
We tried to use a 7138 chip at one point, but the results weren’t great. It could regulate both ends of its range, but the response curve between wasn’t a useful shape. So that driver design got scrapped.
The Convoy H1 uses the 7138. I’ve got the D4 V2 UI running on it and I love it. But the problem I see with it is the max PWM speed spec is 10 kHz which I’m sure some BLF’ers would complain about.
Do you know what Hank’s 5 amp drivers are using? Op-amp controlling a FET in its linear region?
If it would help get these chips off the ground, I’d be glad to design a great driver around them. But I’m not an expert when it comes to some of this EE stuff so it helps to reference specific chips or at tested designs, etc. I’d do a simple FET + 1x7135 but it seems like people feel that’s not good enough anymore.
Yes and no. I didn’t make firmware for it, but gchart did… so most of the work is already done.
http://www.ghart.com/blf/firmware/
Merging that in is still on my todo list, because I’m slow. I really should do that soon, before my branch diverges too much.
Yeah, extra resolution would definitely be nice for the bottom of the ramp.
I’ve tried a bunch of methods to increase the resolution. Some worked, some didn’t. And some worked on my test host, but failed when installed on another light.
The most effective and reliable methods I’ve tried were the ones which increased resolution in an analog domain. Sometimes digital works, but it’s a lot more prone to failing. This is mostly because the analog components have an inherent noise floor, and no digital solution can increase resolution below that noise floor. When approaching that limit, it’s necessary to lower the noise level in order to make the signal more precise.
Like, let’s say a ramp can go from 1 to 10000, and there is a noise component of +/- 10. Toward the top of the ramp, let’s say it’s at level 9000, it doesn’t really matter if it varies from 8990 to 9010. But toward the bottom at level 100, going from 90 to 110 is probably visible… and even lower at a level of 15, varying randomly from 5 to 25 makes the signal basically unusable.
But give it a second analog path with everything scaled down to 1%, and we get something which can go from 0.01 to 100, with a noise component of +/- 0.1. Now level 15 is a lot more stable, varying only from 14.9 to 15.1.
It’s not always feasible to do this, due to space constraints on the driver… but when possible, it’s almost always the most effective solution.
Er, it might also be worth mentioning that the “noise” isn’t necessarily visible within a single light. Sometimes it’s visible, like the flicker seen at low levels on the KR4, but I’m also talking about the variation within a production run. Produce a thousand items, using a dozen different types of LEDs, and there will be a lot of variation. At the bottom edge of its output range, some items will work great while others don’t light up at all. So I’m mostly trying to stick to solutions which work for the whole batch, not just individual items.
In the case above, that often means that an individual light has a range of 1 to 10000, but the +/- 10 part is a static property of that light. Like… it’s always +5 or it’s always –7. So toward the bottom of its range, I could calibrate the ramp so it looks perfect on my +5 sample, but then when the same code runs on a –7 sample, it looks all wrong. I might set the ramp to start at “4,4,4,5,5,5,6,6,6,7,7”, but on another item it ends up looking like “0,0,0,0,0,0,0,0,0,1,1”.
If it helps at all, the exponent option can be an arbitrary number. Like, if “seventh” is close but not quite right, try giving it 6.9 or 7.03 to fine-tune it.
Anyway, I don’t have answers for Tiny1 circuit design, so I’m not helpful here… but I’d definitely recommend reading through gchart’s code if you haven’t yet.
Hmmm… No.
It’s nice of you being so modest, but it’s not a thing until FSM supports it 
.
I totally understand that. I did a lot of measuring, for example to see how different 7135 behave in which condition with which LED and which firmware settings. I settled with a specific hardware and firmware for my bread-and-butter clicky lights. But this includes handpicking not only the 7135 but also all capacitors. The result is totally worth it. I get consistent brightness levels and OTC timing without need for calibrating. But that works as a hobby, for gifting some lights, and just having fun in DIY. Not in a large scale production.
.
The fine tuning I did by hand. Wrote me a ramping table test state in Anduril to check the critical parts of the table on a step by step basis. The result puts a smile on my face every time I use this light. Again, this obviously does not work on a production scale.
.
Don’t worry. My following post is for the others here. 
But when you ever come to the point that FSM supports the 1-series, I want to be helpful myself, have some drivers ready and provide some testing.
Well yes… and no. The updates haven’t been merged into TK’s repository yet, but the link that TK shared leads you to my updates that integrate 1-Series support into FSM. I have it up and running on Sofirn SC31B (just because I have a few sitting around and it made a decent host) via a PIC-to-ATTYINYx16 adapter board.
I also just threw together a 20mm FET+1 driver and updated programming key. I’m still waiting on the boards to arrive. The programming key is nearly identical to my old one, but I decided it was better to switch around the Gnd and Rst positions (mainly to avoid frying the chip if you reverse the key and also because it works better with PCB layouts).
First, it’s cool to see HQ in here after checks notes 19 months between posts.
I’m not much use in this thread - but I wanted to comment on the 10kHz PWM. Nobody can see that. They can find ways to measure it and show that, but it will never be visible to human eyes. The only issue you’ll run into is if something ends up making a 10kHz tone, which all but the oldest of us will be able to hear. I don’t fully understand why PWM is occasionally audible in lights, but that’s my take. Also, you can get away with a lot slower PWM if the signal’s waveform also has a DC component.
Now I need to get me the hardware.
I’ll go with the 416 xplained nano board after looking at the options. With ~8€ it’s cheap enough not to try my luck with the AliExpress stuff. I will need to upgrade to a newer AVR studio, though.
.
One question still:
Which Attiny1616 do I need, MFR or MNR?
Their own datasheets are inconclusive, as they stated the specs differently. The 2020 datasheet version says
ATtiny1616-MNR 16 KB/2 KB 20 20 MHz 1.8V to 5.5V VQFN -40°C to +105°C
ATtiny1616-MFR 16 KB/2 KB 20 16 MHz 2.7V to 5.5V VQFN -40°C to +125°C
Why does the MFR type only support 16MHz?
Mouser/Farnell list both versions as 20MHz. Does the MFR support 20MHz at least below 105C?
.
@gchart
I’m not a firmware pro. I can do stuff where I want and need to, it just takes me a lot of time. I’ll be patient and wait for the official integration.
ProgKey: swapping the pins (grd to the center) looks perfect as the pins inbetween, PA1-PA3, might not be as relevant to us and then the routing falls into place almost by itself.
.
@Scallywag
time surely flies
.
Just for the fun of it: I did some quick-and-dirty board sketching (changing the MCU on existing brds) and it will work out nicely. Yes, the routing is different as we no longer use space under the MCU or between the pins. But there is a lot of space around the MCU now, especially compared to the 85.
.
Very exciting developments and many thanks to ToyKeeper, gchart, HarleyQuin for the work! Actually I've been recently working on a driver with 3 channels control just like what TK was talking about, using a buck regulator for most of the range, a separate channel for very low brightness levels, and finally one for FET, though practically speaking the lowest range doesn't need much resolution for brightness levels I think.
Thanks for popping in, loneoceans! I always look forward to seeing what you cook up
I’m excited for development on low-brightness channels. So far the standard has mostly been a 1x7135 channel, and it does alright. I’d be most excited for an example of how to do it well that others could implement on their future designs
New 20mm FET+1 boards just came in and I assembled one today and threw it in a Sofirn SC31B. So far everything is working great. 
sorry, I hadn’t cleaned flux off yet
I admire your skills and abilities gchart. Well done.
Really nice work!
Outstanding! Any updates? I'm working with Anduril2 now. I assume that's a FET+1.
Well, not a whole lot to update on I guess. Driver works great, and Anduril is running well on it. I haven’t tried Anduril2 yet. Want to make sure it’s fairly stable before I mess with it.
It’s getting pretty close. I probably would have merged it already, but I’ve been trying to get a bit more feedback first and am hoping to give it an updated diagram or two. However, there’s so much stuff to put into the diagram, it keeps either turning into a tangled mess or a reference table. So perhaps I should split it into several diagrams.
When every mode change required going through “off”, the diagram layout was much simpler. But with new shortcuts between a few different modes, I end up with lines crossing each other. It’s nice during use, but makes for a messy flowchart.
gchart sent me a fully populated 20 mm FET+1 1616 driver, a pogo pin cable assembly, and a XNANO 0416 dev kit. I was able to get Anduril running on it today:
- created a AS 7 project for the 1616
- plugged in gchart's Anduril/fsm source code
- got the XNANO USB dongle board recognized by Windows (must use a good high qual USB-A to Micro USB-B that supports power data)
- used AS 7 to program the driver via its Tools-->Device Programming method
It's working!
Temp calibration was Dead On!! I never saw this before with any Narsil/Anduril light, ever (gchart mentions it's accurate in the OP)
Now I have a working dev/test platform for this processor. Just have to get it in to a light for full testing.
Woohoo!
PS - I think you meant a USB cable that supports data. Many do not - they only have the power wires.
I’ve noticed that with a lot of “charger cables”, especially those that come included with cheap stuff. Bonus points if they’re super short (8 inches/20cm or less).