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:
Modify the build system so, instead of a flat list of cfg-*.h files, it has a directory structure… like cfg/username/modelname/config.h . This would help unclutter the base directory, help keep related files together, make it easier to structure the files, allow for expanding what can be configured, and make it easy to keep both personal and manufacturer configs in the repository.
Fork the current fsm branch into an anduril1 archival branch, since it’s effectively dead now.
Merge the anduril2 branch into fsm, and merge fsm into trunk.
Do some housekeeping on the published builds, to move old builds to an archive and move new builds to the base directory. Maybe also restructure how builds are published, to match the new config hierarchy.
Move FSM’s hwdef and other includes into the FSM directory, since they’re really not useful for other projects. Maybe even move the hwdefs so they’re in the same directory as the configs. This would keep all the model-specific files in a single place.
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.
That’s awesome TK!
Exactly what can be found in many Anduril lights.
I now really have a good excuse to buy a programmer from Hank for my Emisars / Noctigons
It’s in the anduril2 branch in Launchpad, or in my anduril2 file dump. It’s pretty much always a work in progress though, so use at your own risk.
Anyway, I got some test results from a wider variety of lights… and I’m seeing jump-start levels anywhere from 21 to 50 depending on the exact hardware being used. So it’ll probably take some tweaking on a per-light basis, for people who care to configure it.
That’s added and working now. The user can finally choose their turbo style, with different settings for simple and advanced modes. The available styles are:
0: no turbo, only ceiling
1: Anduril 1 style (Ramp 2H -> full power)
2: Anduril 2 style (Ramp 2H -> ceiling, unless already ramped up to ceiling)
This also controls the level of the momentary turbo shortcuts.
Turbo style is the 4th item in the ramp extras menu, or in the simple UI menu.
Some other new options were just added too, so some menus have changed…
Smooth ramp: (Smooth ramp 7H)
Floor
Ceiling
Speed (new)
Ramp extras: (Ramp 10H)
Automatic memory
Manual memory timer
Ramp after moon? (Off -> 1H) (new)
Advanced UI turbo style (new)
Simple UI menu: (Off 10H)
Floor
Ceiling
Steps
Simple UI turbo style (new)
Hopefully this will let each person get the style they like.
Indeed it is, but some talented individuals have risen to the task admirably and have produced some very helpful diagrams. I hope they can include the latest improvements.
I’ve been testing this with my E21A D4V2 and it’s been great, ultralow is so much more convenient now and makes the light more useful for me. Output appears more stable and startup is quicker. I especially love the ability to enable/disable ramp after moon activation, that’s a huge one for me.
I don’t quite understand though, how does exactly does the ramp speed configuration work? How many values are available? I only tried it up to about 20 clicks, which was maddeningly slow. What does each click represent exactly?
Also sorry dumb question but I am wondering, which hex would I flash to the DT8? I have both a 219b and a W2, do I just flash the respective KR4/KR4-219b versions?
The control chip has a timer which ticks at about 62 “frames” per second — one tick every 16ms. It’s pretty close to the speed of a common video screen. Normally, the ramp moves at one ramp step per frame, and there are 150 ramp steps, so it takes about 2.4s to ramp from end to end.
The ramp speed option changes it to one ramp step every N frames. So it slows things down… one step every 2 frames, every 3 frames, every 4, etc. Doing N clicks in the config makes the ramp 1/Nth as fast.
For reflashing a DT8, the readme file in my .hex file collection explains how to determine which file to use. The models file will probably be useful too. Basically, match up the model number.
Is there a way to add adjustable/more brightness levels for the AUX leds? I agree with a statement by ToyKeeper I saw on Youtube. The low setting is too low and the high is too high.
