One option might be using a free proxy that provides HTTPS termination like Cloudflare. It’s normally simple to set up (if you’re willing to hand over your DNS to them). As with anything like this it has pros and cons and may not fit your needs. If it does then it can be a 10 minute job.
As others have said, health is more important though.
On a KR4-nofet 5a driver (E21A), dynamic PWM seems to work quite well! It’s a much better approach than simply slowing down the ramp as I had tried.
Small heads up - in lockout-mode.c, the JUMP_START_MOON code doesn’t seem to apply to the “click and hold” moon there, which confused me at first as I use that most often (due to autolock).
In normal “off” mode, the jump start does give a noticeable boost to the speed of moon level waking up. Most of the time there’s still a ramp up, but it’s faster. Other times I see a subtle flicker to higher brightness, but nothing eye-searing - if anything, it feels like a nice “yes the flashlight is on” confirmation.
Given this, if anyone wants to compare with/without the moon jump start, try it in “off” (active) versus “lockout” (no jump start).
Yeah, it should probably jump-start in more places… not just hold-from-off. It also should be runtime-configurable, because it seems the optimal value is different depending on the hardware. Not sure where to fit another option into the UI though. Or, more generally, where to fit some awkwardly global settings into the UI, like double-click style, mid-ramp blinks, jump-start level, and maybe other things which don’t fit anywhere else. Maybe 9H or 11H from off? Extend the Ramp 10H menu? The button mappings are already pretty cluttered…
I also need to apply the dynamic PWM thing to some other t1634 lights, and possibly even to some single-channel t85 lights.
Perhaps on a day when I’m more awake. *yawn*
This is a wonderful upgrade to so many lights! Thank you.
If you end up adding a bunch of runtime configurable items, it would be nice to include the double click to turbo (Anduril 1 style) in there, which is now, if I understand correctly, only configurable during compiling.
EDIT: Maybe you meant the same by double click style 
EDIT2: 9H seems reasonable to me.
Flashed the new version to my KR4 and it’s a night-and-day improvement, no pun intended.
Level 1 starts up faster from off, and the low-end is much smoother and more gradual when ramping.
Also enjoying the change where 2C from on goes to full turbo (in full/advanced mode at least), this is a very sensible change IMHO. Don’t know if that’s recent or not, but thought I’d give my positive feedback regardless.
Thanks for making these changes! I’ve flashed a few of my lights and the low modes are much more usable now. It would be great to see these changes for the K9.3 as well.
I absolutely would like to see an advanced configuration menu. I wouldn’t worry too much about cluttering the UI as a menu like that would probably only matter to the most advanced users.
I prefer the original Anduril 2 double click style of 2C to top of ramp, so I’d definitely like to see a runtime configuration option for that.
Great work ToyKeeper!
I just flashed the 2021-08-16 builds on my D4v2’s (both 9A CC driver, one with 219B’s, the other with SST20’s). I used KR4-219B and KR4, which hopefully was correct.
With the KR4 build, moonlight at level 1 now starts almost immediately. Sometimes it flashes, s0metimes it still fades in as usual.
With the KR4-219B build, it still fades in in the same speed as before. I have no issue with that (in contrary, I even prefer that somehow), just reporting. Sometimes is flashes before fading in.
Ramping is much smoother, more controllable and in short just better than before. Thank you for fixing that!
Would it be possible to get firmwares without the moonlight jump-start? My moonlights worked quite well before and I sometimes find that flash really disturbing when I want to enable moonlight for using its low brightness specifically.
Yes. Now that I’ve heard a wider variety of results from different lights, it’s pretty clear that the option needs to be configurable… so I plan on adding that soon. Then people can set the jump-start however they like.
I may also attempt to make the behavior more consistent, by force-resetting the PWM phase when the light turns on. If my guess is correct, this should greatly improve the consistency from one activation to the next. As-is, the wave generator is free-running, so the timing is random. It wasn’t an issue when the wavelength was imperceptibly short, but with the longer cycles now, it’s more important.
The configurable jump start with force-reset PWM works great and is basically always consistent (temperature aside)!
For my Noctigon KR4 with E21A in 2700K, I noticed the following:
| Jump start value | Result |
| 25 | Default - only slightly faster fade-in |
| 30 | Faster soft fade-in |
| 35 | Very slight fade-in, almost instant |
| 37 | Generally instant on - see following note on temperature |
| 40 | Flashes briefly to a higher brightness if light is even slightly warm |
Note: with Jump Start level 37, it works fine if I’ve kept the light on ramp level 65 or lower (including off). However, if I run the light to turbo/ramp level 150 and wait 2 minutes (throttling to custom limit of 40°C), entering moonlight mode will result in slight flashes while it’s still above warm/hot. Once it’s cooled down to “noticeably warm”, it works fine. If it’s particularly cool (around 21°C or lower), there’s a very slight fade-in, still fast enough to let go of the button in time when ramping up from “Off” state.
Though unintended, for me, that could even be seen as a feature - it takes time for one’s eyes to adjust, so the flashlight gives a confirmation flicker if it was recently in turbo.
If others notice this as well, in theory the jump start level could be temperature compensated, but that feels rather complex? Besides, what I’ve heard suggests the LEDs should have a more difficult time turning on if hot, not vice-versa.
Wondering how “dynamic PWM” will effect drivers with switching topology ( like Lume1). In MEL7135 drivers i can get super moonlight by disabling dynamic_underclocking.
I assume that it will be even less predictable. It all depends on the time characteristics of the 7135. Does the turn on time change depending on the temperature?
Yesterday, I installed the KR4 and KR4-219b firmwares from 2021-08-23 onto my two D4v2. It feels like the jump-start with a short flash is disabled completely again, which I find really nice. I never had any issues with level 1 moonlight with both my 9A drivers. The short flash at a high brightness kind of defeated the purpose why I entered moonlight completely IMO, I don’t want my light to flash when I want to use an ultra low brightness specifically. I tested the heck out of it and the flash is now gone completely, I guess that’s because the standard jump-start level is set so low. I didn’t look at the code yet, but as user “digitalcircuit” reported, that’s probably it.
I initially created my own Anduril2 config with disabling the jump-start completely, but I like the way the official firmware comes now.
Great work, ToyKeeper! Amazing how quick things get sorted out recently.
Is there any information about how Hank is handling the situation? I’ve had a lot of people asking on Reddit how they should proceed when ordering a new Hanklight. My general recommendation currently is to ask Hank specifically for the most recent firmware specifically.
This is highly experimental code, still in development. I hope that Hank doesn’t use the firmware files that are available from ToyKeeper’s server, but asks ToyKeeper for a “good” version.
From my limited experience, I would say that TK only releases new firmwares when they are ready and working, AFAIK there is no beta-channel. In general, isn’t that basically the thing of open-source?
I just ordered a Hank light and figure by the time it gets here (a few weeks?), there will have been a few more Anduril builds anyway. So I expect to reflash it, no big deal. Being able to reflash it is why I bought it after all.
As you say, that sounds unusual. I haven’t seen a light behave like you’re describing. I only have a very small sample size though. What I’ve seen is that it typically starts slower when hot, like when it was just at a high brightness mode.
It seems that the optimal pulse strength varies quite a bit with hardware. I set the default at 21, because that’s the sweet spot of the fastest light I have available for testing. On another, I find 30 is about right. And you had to turn it up as high as 37.
A better solution would be to modify the hardware… but that hasn’t happened, so this workaround exists to try to improve things as much as possible.
As long as a miscellaneous or “global” config menu is being added, I’m planning to add another setting or two there before I bother Hank about the new versions. In particular, the double-click behavior changed from Anduril 1 to Anduril 2, and it seems to be a divisive change, so I’m hoping to make that configurable. Then I’ll ask if he can update the revision he’s using.
I used to publish builds more often, but then I found out that both users and manufacturers were using those versions on the assumption that they were stable instead of experimental… so I’ve really cut back on how often I upload new .hex files.
There are still some experimental builds though, so it’s always a use-at-your-own-risk sort of thing. I don’t often do the full test suite, because it takes a very long time… especially thermal tests. So most of the time, I focus the testing on whatever part of the code changed recently, and anything else I think might have been affected.
I don’t know what the effect would be. So the dynamic PWM thing is only enabled for KR4, and I’ll try it on other devices as I have time. Next is probably K9.3.
Noted, and thank you for the context! It’ll be interesting to see what other folks discover if they try tuning the jump start level, too.
Additional context:
Before jump start was added (or if I set it to 0 now), my KR4 with 5a driver’s E21A 2700K LEDs always turned on to lowest level even after max ramp (level 150 up to 40 C, custom thermal limit), so perhaps lack of that issue allows a secondary effect of the warmer driver circuit to result in faster reaction times…? I’m not sure.
Regardless, I’m happy with the current jump start behavior as a way of making the most of the unchanged hardware design. It’s a noticeable improvement over previous behavior, and well worth spending around 5-10 minutes of my time dialing in the right level (after which I added it to my custom build config).
Would it make sense to have a subdirectory called experimental, testing, etc in the firmware download folder , making the distinction of what’s “ready” and what would benefit from wider testing?
I don’t know if that’d worsen the situation by implying files outside that directory are more stable, raise expectations for how you publish, etc - feel free to disregard!
(I’m also not sure if Launchpad’s recipes for automated builds would be useful to offer .hex files for recent commits. Unfortunately, it looks like it’s geared towards building a Debian package and not really anything else , though I might have overlooked something in ~15 minutes of searching for details.)
As you say, Launchpad is mostly designed to produce .deb packages. It also frequently has a large backlog on the build servers. So I haven’t really looked into whether it’s capable of producing automated builds for this project. It’s a pretty simple matter to just build locally and sync it to a site.
I’m hoping to do some restructuring soon… In particular:
I’m also hoping to modify the fsm and anduril code to make things easier to customize at a deeper level on a per-build basis… replacing functions as necessary, or adding hooks, etc.
And, of course, I have a pile of patches to merge. I’ve been embarrassingly slow about that.