First time I hear of this. At first I thought you were referring to the half-carry flag, but on second thought it would not make sense in the context you described.
Yeah, not the half-carry flagā¦ the regular carry flag. Itād be super handy if C exposed that somehow, to find out if an int rolled over during addition.
Since thatās not available without assembly, I can get more or less the same thing by using a 7-bit int instead of 8-bit. I think itāll probably work if I do 8 bits of PWM plus 7 bits of DSM, to get a dimming range of 0 to 32640.
The 32640 figure is 255 << 7. It occurred to me that I canāt go all the way up to 32767, because then it would try to roll over 255 sometimes, and itād go back to zero.
Also not sure how to handle clock speed changes on something like this. Itād probably have pretty noticeable bumps in the ramp each time the clock speed changed. So on a regulated driver, Iād probably just stay at the same speed all the time. Otherwise, Iād need to finally rewrite the ramp calculator to properly handle speed changes, and thatās hard.
Anyway, Iām working on adding DSM to the emisar-d4k-3ch build. I canāt make any promises, but if it works, it should fix the poor resolution (and bad ramp shape) of the main channelā¦ and may also improve the other channels too.
2 Thanks
Do you think the DSM will be able to make moonlights lower as well? Theyāre still pretty high on the multichannel and boost drivers from Hank.
Also, did you get around to adding saturation ramp to the 3ch firmware? Even in the 2.5D ramping mode instead of full 3D channel ramping.
OK, I think I follow you now. Well, having faced this kind of issue more than once, what I do is (a) use an unsigned int datatype (uint16 in the specific case you mention, IIUIC) and (b) check whether the result is less than either of the operands, eg:
uint16 op1, op2, result;
[...]
result = op1 + op2;
if (result < op1 || result < op2) {
// roll-over
}
Sorry if Iām stating the obvious, but over the years I found this method works well and is much more legible and portable between datatypes than the alternatives Iāve seen so far. OFC it does extra work, up to 2 comparisons, tho ā so it would not serve if you are eg in an ISR and canāt afford the extra cycles ā but experience has taught me that in these cases itās best to code the entire ISR in assembler to begin with.
I rewrote the d4k-3ch code to make it use PWM+DSM on all 3 channels. Hereās the current build, for anyone interested in trying it:
https://toykeeper.net/torches/fsm/anduril2/anduril.2023-10-13.emisar-d4k-3ch.hex
It greatly improves the resolution of low modes on the 8-bit channel, and moderately improves the two 16-bit channels (mostly with reduced flicker and a bit nicer low modes). It also makes extra-smooth ramping even smoother, like when using sunset mode or thermal regulation. When tint ramping, low brightness levels have much higher tint resolution now. The HSV mode also has much better brightness control, since itās 15-bit now instead of 8-bit.
It does not make ramp level 1/150 any lower, though. Thatās set by hardware and I canāt change it. Itās as low as the hardware allows thoughā¦ meaning the regulator is on (required to allow any light at all to come out), but its control voltage is zero (lowest possible level).
I also havenāt added saturation to the HSV ramp yet. Itās still just hue and value adjustable, with saturation locked at 100%. But the saturation changes should be much more feasible now with the new code.
Another thing which still isnāt done is the adjustable āwhiteā mode, which would basically be the same as the āallā mode but with adjustable gamma curves.
Anyway, itās a big improvement but thereās still more to do.
1 Thank
Read through your changes today, I am in awe 
I think a separate floor/ceil per channel might be a useful thing to set for cases like this so if someone wanted they could raise the floors on the other channels - the hard part is going to be how to structure its configuration without confusing peopleā¦ If you have any ideas Iād be happy to discuss, my first thought is to use the 9H menu somehow since that already enumerates all the channel modes. Maybe as āfloor offsetā somehow?
1 Thank
Neat. Your post is showing as #6666, on Friday the 13th in October.
Also, my first DSM-capable build came out to 13666 bytes. It didnāt work, but the fixed version is close enough that I could probably get the size the same for a special Friday-the-13th release. 
The plan is to have a gamma value for each hardware channel, with ā¦ I dunno, an adjustment range of 1 to 32, with 16 being neutral? Then the gamma would be applied in the āwhiteā channel mode, to balance the channels better.
Iāll need to find a quick AVR-compatible method of doing gamma calculations, but that will probably not be a huge problem. Also, not sure where in the UI to put a menu for entering the values.
Another change I need to make is adding a sine wave function, and using it in HSV and auto-tint modes and maybe also in manual tint modes. Itād give nicer-looking results than a triangle wave, but itāll need a lookup table since that kind of calculation suuuucks on AVR.
3 Thanks
Yeah, if I was going to be in that hotel room for a while, Iād go down to the local dollar store and pick up a few pillow case slipcovers.
If the management is iffy, it could be fun to take a cushion down to the front desk and them demonstrate theā¦ āhidden tracesā to the staff. 
1 Thank
Looks like SFT40 3000k 95 CRI are in stock! I asked Hank a few weeks ago when theyād be in and he didnāt know. So at the time I ordered a KR1 SFT40 5000K and it arrived today.
The tint on the 5000k is very nice! I now want to replace all the greenish 6500k with these or 3000k.
2 Thanks
Any CRI/DUV measurements?
1 Thank
I have 4 of Hankās 5000k SFT40 in a D4Sv2, in turbo they are 5056k, 65 cri, and DUV=0.0038
Not the neutralest beam of all time, but they stay consistent in that cct and DUV range through the whole ramp, unlike sst20 5000k that turns green in the midramp.
2 Thanks
I donāt have any devices to measure it, but my green-hating eyes are quite pleased with the tint.
4 Thanks
James, do you notice a very similar lumens output comparing SFT-40 6500k to SFT-40 5000k in your KR1 or other similar Hank flashlight?
Sorry, I only have one KR1 so canāt do a fair comparison. I donāt know what flux bins Hank uses but that would be a good way to estimate the output differences between the CCTs. My hunch would be the 5000k has less output but not visually noticeable.
Iāll try to get a side-by-side pic of the 5000k and one of my other SFT40 6500k lights.
1 Thank
Hereās a pic. On the left is KR1 SFT40 5000k, on the right is Wurkkos TS11 SFT40 6500k (I believe). The former has a reflector and the latter a TIR. White balance is locked at 5000k. Both lights are around mid-ramp.
In real life, side-by-side the 6500k makes the 5000k look rosy. On itās own, the 5000k is very close to pure white without any tint. Maybe I won the tint lottery but I think the 5000k is fantastic.
4 Thanks
My experience is pretty much the sameā¦ On its own when I first turned on my D1K SFT40 5000K, I thought it was essentially a normal SFT40. Compared it to a D1V2 SFT40 6500K, a T1R and an S11 with the same and the 5000K is quite pleasant.
Less glaring, slightly rosy to neutralā¦ Iām quite happy with it!
1 Thank
Looks terrific. Iām won on the SFT-40 5000k. Thanks, James!
I measured my D1V2 with SFT40 6500k by app. 2300lm and 5000k by 2100lm ā¦ i am curious about the 3000k version 
1 Thank
Hereās a test of the 3000k. Unfortunately the output is much lower than the 6500k. But even at half the lumens, it visually wonāt appear all that much different. The good news is the tint is reported to be great. So itās a tradeoff of output for tint/ CRI.
He will test the 5000k soon. Iām guessing that will be a nice middle ground (and your test seems to show that). If the output of the 5000k is even 80% of the 6500k, Iād be happy never seeing an ugly green 6500k again.
2 Thanks
The 5000 K SFT-40 should have the same output as the 6500 K variant, at least according to the product description at Kaidomain. The flux binning of the 5000 K is the same as for 6500 K.
The CRI is of course much worse with 70.
And whether the tint of the 5000 K variant is really always good and has no green tint is anything but certain and above all always depends on what exactly is ordered from Luminus (the risk of āvomit greenā is just as high with 5000 K as with 6500 K, at least if a broad color grouping is ordered).