You could also just give it a smaller value, like 6 to allow a 6-frame window to stop at moon before ramping.
And to make the timing easier, you could make it not turn the light on until that window starts. Slower feedback from off, but it gives a timing hint for the shortcut. Tradeoffsā¦
It runs at 62 frames per second, or 0.016 ms per frame. So a value of 12 is just barely under 1/5th of a second.
People have had difficulty with a window of 18 frames on the Q8, and Iāve found that 31 frames feels too long, so I used a default of 24.
Zebralights, IIRC, use a window of 0.5s or 31 frames:
Frames 1-31: Light is at low, release to go to high.
Frames 32-62: Light is at low, release to stay at low.
Frames 63-93: Light is at med, release to stay at med.
Anyway, I just wrapped the definitions of HOLD_TIMEOUT and RELEASE_TIMEOUT to make them definable from the UI code instead of having to dive into headers. So, after this update is pushed, just stick an extra line in the main UI file and itāll override the toolkitās defaults.
The HOLD one is how many frames it takes to go from a āpressā to a āholdā, or how long a single click can be. The RELEASE one is how many frames it waits after a click to see if another click will happen. To cause a full click event to be sent to the UI code, what happens isā¦
User presses button. āEV_click1_pressā event gets sent to the UI code.
Anywhere from 1 to HOLD_TIMEOUT frames happens. Letās say 12 frames.
User releases button. āEV_click1_releaseā event gets sent to the UI code.
Light waits RELEASE_TIMEOUT frames, and nothing happens. Now weāre at frame 36.
āEV_1clickā event gets sent to the UI code, indicating that it was only a single click and itās too late for a double click to happen.
The events arenāt quite immediate thoughā¦ they go into a queue and get sent/processed later when the MCU is in an idle loop. In normal circumstances, this only delays things by a few microsecondsā¦ enough for the current interrupt (WDT, PCINT, ADC) to finish. Iāve generally been very careful to avoid anything time-consuming during interrupts, because those need to be serviced quickly and then go back to the regular code flow as soon as possible. The queue offloads the time-consuming parts to a safer part of the code.
Iām kind of just rambling now though, twiddling my thumbs while waiting for DHL to show up with new lights.
Hang on there a minute. On a bright sunny day blinking out temperature or voltage might be rather hard to see if done at moonlight levels. At the risk of adding ANOTHER configuration, it might be nice to be able to select the intensity of these blinks.
With moonlight configured to be really low, maybe, I donāt know. On my D1 / D4 with stock firmware moonlight is easy to see during a day. Actually with D1 itās well above the threshold of being painful to look at, even during a day.
Though it may not be moonlight. My complaint about the current level is that the amount of light is disturbing.
If I shine it at my hand to avoid disturbing others, the reflection blinds me.
It doesnāt take moonlight to avoid the issue.
The nitecore MH20ās e-switch is blinking the battery voltage when tightening the tailcap, so why not doing the same with the D4ās front emitters and use the 3 clicks for something else ? A shortcut to 7135 100% for example.
Is there a hex file available of Anduril for a TA FET+1+16 (or 8AMCs) driver? I want to order 2 drivers from lexel and would like em to be flashed with anduril, Lexel can flash them for me with any kind of firmware but he needs/wants the hex file as he ācanāt calibrate Anduril like heās used to in Narsilā.
I myself have no clue what a HEX file is used for or if there is any difference between the hex file for a FET+1+8 and a FET+1+16 driver :person_facepalming:
Thanks goshdogit, yes Iāve downloaded all the files there and add to the AS project, I think the error is the fsm-adc.c file or its comments, never have this issue when compiling Narsil.
Itās already massively sped up compared to RampingIOS, and IIRC dimmer tooā¦ and only blinks once. Itās basically using the same boot blink I used in Ferrero Rocher, just a quick blip to confirm power is connectedā¦ without causing any meaningful delay. But if youāre in a dark place and trying not to be noticed, itās still a good idea to cover the light before connecting power.
No, I donāt think itās quite ready for stable release yet. This is all still alpha or beta code. Itās not even merged into trunk yet.
In general, the ramp (including moon level and ramp shape) needs to be calibrated for each combination of driver type and emitter configuration. A FET+7+1 and FET+16+1 have different ramp shapes, a single XP-G2 and a quad XP-L have different ramp shapes, a raptor-claw and failboat 7135 chip have different moon levels, a 1-channel/2-channel/3-channel driver all have different configurations, an old XM-L and new XM-L2 have different moon levels, a 1-cell (or parallel cell) host and 2/3/4-cell serial host have massively different ramp values (and need different methods of measuring voltage), hosts with/without indicator LED need different configs, hosts with/without a tail clicky need different configs, etc. The full set of configurations grows exponentially with each option.
There is the approach of trying to build a .hex file for every possible config, and hosting dozens or hundreds or thousands of them in the repository, but this means an awful lot of completely untested builds and itās expensive in terms of repository size. Itās mostly just useful as a brute-force way to test builds to make sure each configuration can at least compile. I donāt think Iāll be hosting all those .hex files though.
My preferred solution is to provide sources only, plus a very small number of stable and well-tested .hex files targeted to very specific and popular hardware ā like one for the D4, one for the Q8, and one for the FW3A. For hardware produced in smaller quantities, itās someone elseās job to build and test.