Nope, not without changing the hardware. The hardware only has three brightness levels:
The way it produces those levels is by turning power on and off, and by inserting and removing a resistor along the path of current. The control chip provides the power, and it can either do that directly or it can add its internal resistor.
High = power on, internal resistor off
Low = power on, internal resistor on
Off = power off
Those are the only three levels available.
The high mode’s brightness can be modified by changing the resistors on the aux board, or by replacing the resistors with potentiometers… but that’s pretty much the whole extent of the ways it can be adjusted.
I know it is used in the KR4. I was asking and it provides more granularity in the low modes and lower low modes. I was wondering if it is incorporated and can do the same for the other drivers, like Lume1 and FWAA.
@ToyKeeper Can you make the choice of switching on after lockout a runtime config? I’ve had too many times where I’ve unlocked my light in the dark and been blinded because I had a high ramp step saved.
I would prefer not to use manual memory if I could avoid it.
Just KR4 so far, and other lights which use KR4 firmware… like KR1, DT8, and the linear version of D4v2.
I also got it working on K9.3, but haven’t published that yet because it was just an experiment and isn’t really what I’d consider solid yet. I actually was trying to get it working on the LT1 lantern, but didn’t feel like grabbing the lantern, so I did it on my other 2-tint light, a K9.3. Then after that was working, I grabbed the lantern and started to port the changes… but quickly found out that the LT1’s control chip (attiny85) doesn’t have the features I needed. Oops.
I don’t have a Lume1 driver yet, so I can’t really do much with it. Have been meaning to get a FW3X or E07X or something, but I just haven’t yet.
I think the next item to try PFM / dynamic PWM on is the FET+1 version of the D4v2. Or the D4Sv2. Or maybe the K1. Or maybe this t1616 FET+1 light gchart sent me… it’d be interesting to find out how to do this on the t1616, since it’s a pretty different architecture.
… or maybe I could finally spend some time on implementing DSM instead (delta-sigma modulation). That’s more more difficult though, since it would require deeper changes and the ideal implementation requires a hardware feature which isn’t exposed in C. I could probably work around that though… and tried a few different algorithms to generate the DSM pattern efficiently.
In theory, that could produce lower lows on some lights, but it would also slow down the pulse rate quite a bit to reduce output. Go too low, and the individual pulses would be visible like a strobe light.
I really don’t know what the deal is with FWAA. I’ve heard it runs fw3a-219 firmware, but I’ve also heard it’s a FET+1 driver, and … those two things aren’t compatible. It sounds like someone made a mistake, but I’m not sure who or what exactly the mistake was, because Lumintop didn’t provide the the source code they used. So it’s on my ever-growing list of license violations to clean up.
TK - if you haven't yet, add WildTrail to the list for the WT1M and WT3M (just launched) - been working with them and they are using a Lexel driver and Anduril version which I don't think they even have the source code for... :FACEPALM: . I was hoping we could get them to launch with Anduril 2 latest, but they already built up the first batch... It's a 3 channel driver with USB-c charging. Lexel did a decent job of it, but he's out of touch now -- really, really hoping he's ok, improving. He's got some serious issues goin on.
Hi! wow, dynamic pwm works really well. I’m using it on 3 lights (4 now) and the low ramp is so much easier to control. Stepped ramps are also more usable with a low number of steps now because of the better curve (or is it just placebo).
So, I successfully modified the kr4-219b build with Dynamic PWM added . At first I tried playing with level_calc.py, but as I had a solution (need to run it twice, once for dynamic pwm up to 255, another time with 126 (=50%) as max), I realized I could have just copy-pasted
I used the PWM1_LEVELS and PWM_TOPS from the newest kr4 build (with 255 instead of 0 as the last value, to keep the cc driver on). I used the PWM2_LEVELS from the kr4-219b build.
I feel like I would like the ramp to be a bit steeper/faster towards the top for the d4v2 219b (sw45k). I feel like I could modify the N.NN (5.01) bit in level_calc.py, but I don’t understand what this one is… or use the cubic ramp?
Next I’ll try to pre-boost the leds a bit more, they are still too slow to effectively do OFF 2H without muscle memory (meaning that, by the time it lights ups, it is already ramping up). The w1 FY (yellow) on the 5A driver are ok, but the e21a on the 7.5A driver are much slower (these are d4v2’s). The KR1 w2 is also fast enough to not miss level 1.
D’oh. Every time I look at the internet, my todo list gets longer.
Oops, I forgot to apply it to that build! I suppose I should add that to the list too…
The pre-boost thing is implemented as “jump start”, and can be configured with 9H from off in advanced mode. It seems like most lights need a value ranging from 20 to 50, and it just has to be dialed in individually for each light.
To make the ramp steeper in high modes, give it a larger exponent for the ramp shape. Like, the default uses 5.01, but if you increase that to 7 or 9 or something, it’ll squish the ramp down so it’s slower at the low end and steeper at the high end.
Would this by any chance be able to get PWM FET dimming working on a Lume1? From what I understand the reason it was disabled is because the PWM frequency used by the 10-bit buck/boost channel didn’t work well for the FET channel (too low) and generated audible noise.
It would be a pretty huge upgrade for Lume1 drivers if it could