better low modes with dynamic PWM

Nope, not without changing the hardware. The hardware only has three brightness levels:

  • High
  • Low
  • Off

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.

Is this the same with button led brightness on d4v2?

O.K. thanks for the info. :+1:

Yes, it uses exactly the same mechanism.

The upside is, it’s completely passive so it can run for a very long time. Low mode lasts for years.

The downside is, it isn’t adjustable.

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, 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, 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