better low modes with dynamic PWM

TK, is the dynamic PWM only implemented for the KR4 driver? I would love to be able to get lower lows on the Lume1 driver and on the FWAA driver.

pol77, in post #30, BurningPlayD0h mentions using the new code in a KR4.

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.

Lume1 lowest modes are limited by the hardware.
Smoother ramp at the lower end, yes.

What about the 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.

If I understand correctly, you want to be able to make Lockout go to Off mode instead of Ramp, so you can then turn on at moon, yes?

The process would then be:

  • 4C: Go to Off mode
  • Wait briefly
  • 1H: Go to Ramp mode and turn on at moon

Anduril2 has a shorter way to do this:

  • 4H: Go to Ramp mode and turn on at moon

There is also an option to make the saved brightness reset to something predictable after the light is off for a while. This allows the benefits of automatic memory and manual memory simultaneously.

Thanks for all the work you are doing!

If the attiny85 can’t do what’s needed, then I guess the FWAA will never have lower lows :slight_smile:

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. :frowning:

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 :partying_face: . 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 :person_facepalming:

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.

I know you’ve added dynamic PWM in the new tint ramping builds for K9.3, but has it been implemented in the latest hex for OG K9.3?

Nope, not yet. The older K9.3 code is pretty unique and needs some changes before it can be compatible.

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

That’s one reason but there is also the issue with the FET-BB transition. With linear drivers when the FETs turns on it’s in addition to the linear channel(s), at the transition the FET starts at 0% then progress to 100% as we ramp up, therefore it ramps up smoothly without any jump in brightness.

With the lume1 it’s either BB or FET, the FET channel would need to start where the BB left the current to, which is 3A, except, we don’t know what FET PWM level corresponds to 3A since it varies with Vf, cell’s state of charge and internal resistance of the circuit. You might have to estimate some minium FET PWM level that sort of work without having the output increase* when you ramp down to BB, it’ll probably need a big margin of error and you’ll still get a large jump between BB and FET when cell’s SOC is high.

Edit : * Actually, this already happens since the BB output is higher than the FET at 100% at low SOC.
Even with a buck converter like in the Fireflies Lume1 driver, at some point 100% FET ≈ 100% buck, but when the cell is full, 100% buck ≈ 25% FET. If the transition level is lower than 100% then the brightness will jump up when ramping down at some SOC.

Right, I didn’t know Lume1 wasn’t able to drive both channels at once… Now I’m wondering if channel switching feature would be easy enough to implement. One channel being only buck-boost, and one channel being only FET.

You would have two seperate ramps, but it would be like having an efficient EDC light and a pure FET hot rod in one body.

I don’t see how channel switching would help. One thing I can think of is reading the cell voltage to change the transition level accordingly, it would still be approximative with a jump between the two channel, but at least it would have some amount of FET PWM dimming to help thermal throttling, however… that means recalculating the ramp on the fly, which isn’t something Anduril can do.

I can confirm that the FWAA uses the FW3A-219b fw. I don’t know what that means for the possibility of lower lows, but moonlight is disappointingly high on this light. A user made a proper config for the FWAA here that fixed an issue at top of ramp but didn’t touch the PWM.