Ah, sorry about that. The flashing scripts are still a mess. I’ve been meaning to clean that up, and keep forgetting.
The FW3X uses an external temperature sensor. I added some minor new mechanisms to handle better that when I updated the FW3X code late last year. The MCU’s built-in sensor is definitely easier though.
Anyway, for new lights, I’m recommending avr32dd20 for the MCU. It’s like an attiny1616, but better in pretty much every way. The DAC in particular is nicer, which helps a lot for controlling a regulator. It also has dual voltage capabilities and built-in voltage dividers, to reduce driver component count.
For a digital signal, the exact voltage doesn’t really matter. It’s either on or off. This is the case for a simple FET+1 driver, because both of the power channels are digital. In this case, the MCU can connect VCC directly to BAT+ and measure the battery through VCC.
But sometimes it’s necessary to hold the MCU’s power at a steady voltage. For example, take an original Noctigon KR4. It controls a regulator by outputting PWM through a lowpass filter to generate analog control voltage. The PWM signal is on or off, 100% or 0, where 100% is the MCU’s input voltage… and that digital signal gets lowpass filtered to generate an output voltage somewhere between 0 and VCC.
If the output voltage needs to be constant, the input voltage also needs to be constant. So it uses a voltage regulator on the input.
But then it can’t measure the battery by looking at VCC, because VCC never changes. It needs to connect a different pin to BAT+ so it can measure voltage there. However, the MCU’s analog measurement peripheral can only measure up to about 1V… so it needs the voltage divided down into that range.
The most common voltage dividers used at the moment effectively divide by 4.3. That lets it measure a full 4.2V li-ion cell, while keeping the gain staging as close as possible to maximum. But for a 2S or 3S or 4S battery, it would need a different divider value.
Yeah. I’m tempted to change 2C because I don’t really like the “re-turbo” function either. But I’m not sure what it ideally should do, or how many people would get mad about changing it. I don’t really use turbo, so I’m not sure what people want it to do.
We’ve got a few factors to account for though…
- memorized level: Whatever brightness the user last ramped to without a shortcut.
- current level: The actual brightness right now.
- target level: The brightness it wants to be at, if it wasn’t overheating.
- ceiling level: The top of the current ramp. May be lower than turbo.
- turbo level: The currently configured maximum. May be at or above the ceiling.
So it can end up in a situation like the following…
- memorized: 50
- target: 150
- ceiling: 130
- turbo: 150
Then the question is what to do on a double click if the current level is 140, or 110. At the moment, 2C would bump it back up to level 150 in both cases. But it could instead drop back to level 50 in one or both cases, maybe. Or maybe 150 and 130, or 50 and 130, or maybe something else?
I’ve been wanting an option somewhere to set a default sunset timer. I’m not sure where to put it, but I really like the idea of having an automatic timer on the main ramp mode and candle mode, if the user has enabled the option for it.
Also, I’ve been thinking about adding a “child mode” where the options are even more limited than usual and it shuts itself off after ~10 minutes.
Sorry, I’m planning to keep smooth steps enabled by default in factory builds. However, I also intend to make personalized builds easier to create and maintain, so people can bake their personal settings in to the firmware.
If you have a single channel D4S with lighted switch and 0135 (emisar-2ch) or 0136 (emisar-2ch-fet) firmware, you should be able to use the new 0137 (emisar-2ch-fet-joined) firmware on it. It should work a little better than the non-joined firmware.
It uses linear ch1 + DD FET by default, which is channel mode 2. If you don’t want the DD FET, enable channel mode 1, switch to it, then disable channel mode 2. That puts it in linear-only mode.
The second linear regulator isn’t connected to any LEDs, so it isn’t used. The firmware sort of supports it, but only far enough to turn it off.
There are no plans to add extra build targets for those. The dm11-boost firmware was originally written for a DM11, but it works fine on several other models too, so it’s simplest to keep it at just one build target for the entire set.
If I knew it was going to be used that way though, I would have given it a more generic name. 
There are some other models which changed over time too… like, it looks like Hank stopped using the original kr4-boost driver and switched to one which is compatible with dm11-boost instead. I only found out about it when I was trying to help some confused users, and got Hank to send me hardware to figure out the problem… only to discover that there was no problem. Hank simply changed the hardware, and it meant using different firmware too.
I can’t really complain though. As a side effect of all that, he sent me a nice new KR4-boost with 219B sw45k + sw35 mixed. It’s a really nice light… great-looking beam and an efficient driver.
I think my D4K-boost (w/ 519A 5700K dedomed) is probably still more practical though. The beam is a little nicer, and the battery lasts longer. Both lights weigh 139 g with battery and clip, but one has a 3000 or 3500 mAh cell while the other has a 5000 or 5500 mAh cell.