Anduril ... 2?

[trakcon]

@digitalcircuit

Since I’m interested in keeping up-to-date, I figured I’d set up a custom build with all my preferences baked in instead of having to reconfigure every time. I also prefer Anduril 2’s original behavior without USE_2C_MAX_TURBO, which isn’t a runtime configuration option, so I have to build from a modified source tree anyways for the Emisar/Noctigon lights I have.

—
However, it doesn’t look like it’s possible to enable the auto-lockout timer by default via a configuration #define - could this be changed?

My guess (not compile-tested) would be the following: modify lockout-mode.h, replacing…

uint8_t autolock_time = 0;

…with…

#ifndef AUTOLOCK_TIME
#define AUTOLOCK_TIME 0 // autolock time in minutes, 0 = disabled
#endif
uint8_t autolock_time = AUTOLOCK_TIME;

—
I’m also enabling a slower Noctigon KR4 ramp near moonlight, which for me significantly improves how easy it is to pick a specific low brightness, inspired by kr4 slow bottom ramp, default 10 min autolock by mkong1 · Pull Request #18 · mkong1/anduril · GitHub - perhaps this should be considered an official default?

#define HALFSPEED_LEVEL 14
#define QUARTERSPEED_LEVEL 6

—
Regardless, thank you for Anduril 2 - I love it! I like the configuration change to turbo mode (ramp ceiling has meaning now). I could see why others don’t though, hence maybe making it a runtime configuration option. Regardless, I’m happy with custom builds, and there’s something really nice about having the power to modify and reflash flashlight firmware

You can set autolock to a default time. See here: Anduril ... 2? - #696 by trakcon

[digitalcircuit]

@trakcon

You can set autolock to a default time. See here: Anduril ... 2? - #696 by trakcon

Thanks for the heads up! That’s pretty close to what I’m currently doing, and it’s good to have it documented here, too.

In hindsight, I should have been more clear that I’m asking if ToyKeeper would be willing to consider making the default value of autolock_time configurable via #define AUTOLOCK_TIME or such, much like how RAMP_STYLE is handled in ramp-mode.h.

This is not at all required, it’d merely make it more convenient to update.

EDIT 2021-7-12: I’ve proposed the autolock change as a merge request on Launchpad

—

For context, my current workflow with it being a modification to lockout-mode.h looks like this:

cd anduril2/ToyKeeper/spaghetti-monster/anduril/
make clean
bzr revert —no-backup version.h
bzr revert —no-backup lockout-mode.h # Revert patch for lockout-mode.h
bzr pull
patch “lockout-mode.h” “[other directory]/autolock-10min-by-default.patch” # Apply patch for lockout-mode.h
make all

I’ve already created digitalcircuit-cfg.h (modeled after hank-cfg.h) which is #included by cfg-emisar-d4sv2-digitalcircuit-w2.h and cfg-noctigon-kr4-nofet-digitalcircuit-e21a-2700k.h. Both of my custom cfg~~[…].h files also #include the original official cfg~~[…].h files, meaning there’s no conflicts with fetching source updates and I’ll get all changes that I don’t specifically override (I #undef any conflicting #defines).

With #define AUTOLOCK_TIME, there would be no need to revert a patch (that could break if lockout-mode.h is modified) then apply it again after updating.

—

Pie-in-the-sky would be a way to read out the temperature calibration value so I could compile that in too, no need to redo it on every flash. I’ll look into this at some point. If any flashlight manufacturer precalibrates their temperature sensor, it could be useful to have an official way to bake in the offset and disable factory-reset auto-calibration, too.

[digitalcircuit]

Separating out the “pie-in-the-sky” comment at the end of my last post, this is a third, larger but hopefully more universally useful change idea:
Make Anduril 2 able to “display” saved configuration values/clicks

Ever configure a flashlight, make some changes you like, but not write them down elsewhere, so by the time you flash a new firmware version in 5 months you don’t remember the ramp ceiling, floor, temperature limit, autolock timer, etc? Enter the configuration menu, but instead of clicking when it’s “buzzing”, click-and-hold to cause the light to blink out the current value using the same technique as the blinky mode for displaying voltage/temperature.

For things like the hybrid memorized level timer, this allows canceling if someone entered it then wished to exit (a zero value doesn’t cancel changes, unlike most other configuration entries).

This would also add a way to read temperature offset for anyone who flashes new firmware often.

—

More concretely, this would involve modifying number_entry_state() in config-mode.c to handle else if (event == EV_click1_hold_release) { […], switching to displaying the current configuration value, which would be passed up through config_state_base() from any function that calls it.

For almost all entries (ramp floor/ceiling, discrete ramp steps, temperature limit, autolock timer, etc), it’d blink the number of times you clicked to get the same config value. Example: a ramp ceiling configured to 120 down from 150 would blink 3 times, pause, then blink 1 time - same technique as displaying voltage/temperature, blink_num() from fsm-misc.c.

For temperature calibration (not limit), it’d blink the current internal temperature offset value therm_cal_offset, since the number of clicks to calibrate is relative to the current temperature (knowing you’d click 20 times when it’s currently 20 degrees Celsius isn’t new/useful information).

Additionally, functions that call config_state_base() would need some indication that the new value shouldn’t be saved, e.g. by setting number_entry_value to the maximum uint8_t value, #define CONFIG_CANCELED 255 (I’m unsure if clicking 255 times is used anywhere).

(Zero can’t be used as it’s a valid option for the hybrid memory configuration menu.)

—

I might be able to implement this with enough fumbling about, but it seemed wise to float the idea here first to see if it’d be a good idea, if there’s concerns about code size, etc. As I’m very new to FSM and Anduril’s codebase, I may be overlooking potential pitfalls.

EDIT 2021-7-12:
I overlooked that config_state_base() handles multiple configuration entries. It’d need to have the full list of current configuration values passed into it as an array of some sort.

This sounds more memory/storage intensive; if possible, feedback on this design would be appreciated before attempting these larger changes.

EDIT 2021-7-13:
Alternatively, another function pointer could be passed in to config_state_base() (perhaps loadfunc) that would fetch the current configuration value for a given step number. I’m not sure which is more program data and RAM efficient given the constraints of low-cost microcontrollers.

—

Aside, I hope I’m not annoying anyone with these replies. I’m excited about Anduril 2 and having two flashlights running it.

[trakcon]

@digitalcircuit

Make Anduril 2 able to “display” saved configuration values/clicks

I like this idea.

[thefreeman]

@digitalcircuit

That’s a fair point. I hadn’t realized HALFSPEED_LEVEL and QUARTERSPEED_LEVEL were for dynamic underclocking, so in hindsight this might have unexpected effects elsewhere.

It does appear to slow down ramping at lower brightness levels, and Anduril itself doesn’t appear to have any specific code for setting the ramp speed outside of USE_SET_LEVEL_GRADUALLY (which code says is only for thermal regulation). After reading through spaghetti-monster.txt, my understanding is that slowing down the EV_tick rate from the default of roughly 62.5 Hz affects EV_click1_hold as well (“This event is sent once per timer tick as long as the button is held”), which reduces the frequency with which the following code in ramp-mode.c is called that actually ramps up or down:

memorized_level = nearest_level((int16_t)actual_level + (step_size * ramp_direction));

An immediate side-effect of this I see is the earlier if-condition of (arg % HOLD_TIMEOUT != 0) in ramp-mode.c for discrete ramping, potentially resulting in slowing down the discrete ramp stepping too (“the ‘arg’ value indicates how many timer ticks since the button state went from ‘press’ to ‘hold’.”).

If it’s more proper to add “nice” delays directly in ramp-mode.c, that’s fine! I’m still learning how Anduril and the overarching FSM project work.

EDIT: It looks like another option would be to add delays to smooth ramping by mimicking the stepped ramp delay, as noted here for the D4V2 with KR4 driver: https://reddit.com/r/flashlight/comments/o3qrf2/d4v2_ramp_is_too_fast_can_it_be_fixed_with_a/h2g9vj4?context=3

That would be extra code compared to adjusting the dynamic underclocking, and I’m not sure which approach is more “proper.”

I just tested this by measuring the ramp duration with my scope at 10MHz (no underclocking), 5MHz (halfspeed), and 2.5MHz (quarterspeed), no change in the speed of the ramp whether it’s smooth or stepped ramp.

But I think this would be very a useful option to have because this would be much quicker than modifying the ramp which is time consuming, especially for drivers with extremely low moonlight like I making.

[digitalcircuit]

@thefreeman

I just tested this by measuring the ramp duration with my scope at 10mHz (no underclocking), 5mHz (halfspeed), and 2.5mHz (quarterspeed), no change in the speed of the ramp whether it’s smooth or stepped ramp.

But I think this would be very a useful option to have because this would be much quicker than modifying the ramp which is time consuming, especially for drivers with extremely low moonlight like I making.

Thank you for testing this with your scope! I guess I tricked myself into thinking the underclocking had made a change.

I’ve implemented a new version inspired by the stepped-ramping delay code for slowing down smooth ramping - if/when you’ve got the time and interest, would you give it a try?
Merge […] anduril2_opt_ramp_low_slower into lp:~toykeeper/flashlight-firmware/anduril2

@digitalcircuit (Launchpad merge review)

slower ramp with RAMP_SMOOTH_HALF/QUARTERSPEED_LEVEL

Added two new #define options to further slow down ramping speed near
floor, RAMP_SMOOTH_HALFSPEED_LEVEL and RAMP_SMOOTH_QUARTERSPEED_LEVEL.

If neither are set, no change to ramping.

If either are set, when ramp is at/below HALF or QUARTER level, smooth
ramping speed is slowed down by a half or fourth, respectively. This
may make it easier to manage low moonlight levels on drivers with
limited precision near moonlight.

NOTE: PWM#_LEVELS should still be non-linear and determined via
level_calc.py! This should only be used when there’s no possible
additional precision to have in near-moonlight levels.

As noted on the merge request, I’m unsure if this is the best approach - I’m happy for ToyKeeper to modify it, request changes, or go about it entirely differently. The alternative of modifying the ramp with level_calc.py might unnecessarily inflate the number of identical levels (e.g. when customizing ramp floor).

For my KR4-nofet custom test build atop this change, I’ve put a #define RAMP_SMOOTH_HALFSPEED_LEVEL 14 which seems decent, though other values are likely fine, too.

I’ve also submitted for review the #define DEFAULT_AUTOLOCK_TIME feature I had mentioned earlier.

EDIT 2021-7-12:

Tinkering with level-calc.py, I uncommented the pwm_max question and tried recreating the KR4 ramp according to the comment in cfg-noctigon-kr4-nofet.h, and the cubic ramp actually would provide greater control in the lowest power levels as well:

@python3 level_calc.py

PWM1 values:

0,0,0,0,0,1,1,1,1,1,2,2,2,3,3,3,4,4,5,6,6,7,8,8,9,10,11,12,13,14,15,17,18,19,21,22,24,25,27,29,31,33,35,37,39,41,43,46,
48,51,54,56,59,62,65,68,72,75,78,82,86,89,93,97,101,106,110,114,119,124,128,133,138,144,149,154,160,166,171,177,183,190,
196,203,209,216,223,230,237,245,252,260,268,276,284,292,301,310,318,327,337,346,355,365,375,385,395,405,416,427,438,449,
460,472,483,495,507,519,532,544,557,570,584,597,611,625,639,653,667,682,697,712,727,743,759,775,791,807,824,841,858,876,
893,911,929,947,966,985,1004,1023

@cfg-noctigon-kr4-nofet.h

#define PWM1_LEVELS

0,0,1,1,2,2,3,3,4,4,5,5,6,7,8,9,10,11,12,13,15,16,17,18,20,21,23,24,26,27,29,31,33,35,37,39,41,43,45,48,50,53,55,58,61,
63,66,69,72,75,79,82,85,89,92,96,100,104,108,112,116,120,125,129,134,138,143,148,153,158,163,169,174,180,185,191,197,203,
209,215,222,228,235,242,248,255,263,270,277,285,292,300,308,316,324,333,341,350,359,368,377,386,395,405,414,424,434,444,
454,465,475,486,497,508,519,531,542,554,566,578,590,603,615,628,641,654,667,680,694,708,722,736,750,765,779,794,809,825,
840,856,872,888,904,920,937,954,971,988,1005,1023

With that in mind, I’m wondering if ToyKeeper or Hank intentionally opted to remove some of the levels near the bottom of the ramp.

[thefreeman]

@digitalcircuit

Thank you for testing this with your scope! I guess I tricked myself into thinking the underclocking had made a change.

I’ve implemented a new version inspired by the stepped-ramping delay code for slowing down smooth ramping - if/when you’ve got the time and interest, would you give it a try?

It works as described, exactly 2 and 4 times the ramp duration :+1:

[digitalcircuit]

@thefreeman

It works as described, exactly 2 and 4 times the ramp duration :+1:

Sweet! Thank you for testing this.

—

Meanwhile, I’ve filed a third merge request to allow disabling the temperature auto-calibration on factory reset (so you can compile in the right THERM_CAL_OFFSET for your specific flashlight, then never need to manually recalibrate). This goes alongside my second request that you just tested, adding RAMP_[X]SPEED_LEVEL, and the first request to make default autolock_time configurable. I’ve merged all three together into a big ’ol test firmware that I’ll be using for now.

If anyone else wants to follow along to try these out and has bzr/brz available, it’d be like this:
bzr branch lp:~toykeeper/flashlight-firmware/anduril2
cd anduril2
bzr merge lp:~digitalcircuit/flashlight-firmware/anduril2_define_autolock
bzr commit -m “Merged digitalcircuit/anduril2_define_autolock”
bzr merge lp:~digitalcircuit/flashlight-firmware/anduril2_opt_ramp_low_slower
bzr commit -m “Merged digitalcircuit/anduril2_opt_ramp_low_slower”
bzr merge lp:~digitalcircuit/flashlight-firmware/anduril2_opt_disable_autocal_therm
bzr commit -m “Merged digitalcircuit/anduril2_opt_disable_autocal_therm”

Note that you’ll have to create/modify a custom cfg-[…].h file to specify the new #defines to enable these changes. If others are interested for reference, I can make a branch that has my custom digitalcircuit-cfg.h alongside cfg-emisar-d4sv2-digitalcircuit-w2.h and cfg-noctigon-kr4-nofet-digitalcircuit-e21a-2700k.h.

—

Fingers crossed that ToyKeeper will have time to review these at some point, and possibly offer feedback on the making Anduril 2 capable of displaying back configuration values idea too. (Aside, I apologize for some of the email spam with edits/etc - still learning Launchpad.)

[pol77]

Does anyone know what are the changes in the new Anduril2 builds posted here: Index of /torches/fsm/anduril2 by ToyKeeper, dated 11 and 14 July 2021?

Also, there is a 219b and a 219 build. It used to be 219 for all Nichia 219 emitters, c and b. Are they now separate and why?

[SammysHP]

@pol77
https://bazaar.launchpad.net/~toykeeper/flashlight-firmware/anduril2/changes

[pol77]

@SammysHP

@pol77
~toykeeper/flashlight-firmware/anduril2 : changes

Thank you, that was very helpful. Unfortunately, it does not say why there is a 219 and a 219b build. What is the difference between the two?

[TIFisher]

Anybody have an idea why I can’t get to TK’s .txt manual file? Worked fine a few weeks ago, but now I’m getting a website error message….

http://toykeeper.net/torches/fsm/anduril2/anduril-manual.txt

[Tom_E]

@TIFisher

Anybody have an idea why I can’t get to TK’s .txt manual file? Worked fine a few weeks ago, but now I’m getting a website error message… “http://toykeeper.net/torches/fsm/anduril2/anduril-manual.txt”:http://toykeeper.net/torches/fsm/anduril2/anduril-manual.txt

Works for me, maybe you got something blocking on your side?

[raccoon]

@TIFisher

Anybody have an idea why I can’t get to TK’s .txt manual file?

I don't know...

It works for me.

[TIFisher]

Tried both Chrome and DDG, same error. I don’t see anything in my browser settings that would prevent it from loading. Weird.

[Rayoui]

I flashed one of the new hex files just to test. The newest hex releases seem to have double click direct to turbo enabled. At least the D4v2_219 version does. I know some folks were looking for this.

Unfortunately that’s not what I want for my use. I reverted back to the January release.

[pol77]

@Rayoui

I flashed one of the new hex files just to test. The newest hex releases seem to have double click direct to turbo enabled. At least the D4v2_219 version does. I know some folks were looking for this.

Unfortunately that’s not what I want for my use. I reverted back to the January release.

Were you able to find the difference between the 219 and the 219b versions? I have been using the 219versins both for Nichia 219b and 219c emitters with no issues so far, so what is this new 219b about?

[digitalcircuit]

@Rayoui

I flashed one of the new hex files just to test. The newest hex releases seem to have double click direct to turbo enabled. At least the D4v2_219 version does. I know some folks were looking for this.

Unfortunately that’s not what I want for my use. I reverted back to the January release.

For Hank’s lights, all Anduril 2 official firmware files newer than May 14th will have USE_2C_MAX_TURBO set in hank-cfg.h, so unless Anduril 2 makes this a runtime configuration option, one will need to compile their own firmware builds to #undef USE_2C_MAX_TURBO to get Anduril 2’s normal behavior back.

(Asides from testing fixes and baking in other preferences/thermal calibration, undoing USE_2C_MAX_TURBO was part of my motivation for making my own digitalcircuit-cfg.h which reverts this from hank-cfg.h.)

[Rayoui]

@pol77

Were you able to find the difference between the 219 and the 219b versions? I have been using the 219versins both for Nichia 219b and 219c emitters with no issues so far, so what is this new 219b about?

Unfortunately I didn’t take the time to compare the versions before I reverted back. I have 219b sw40 in my D4v2 and am running the 2021-01-25 219 build and I haven’t had any issues.

@digitalcircuit

For Hank’s lights, all Anduril 2 official firmware files newer than May 14th will have USE_2C_MAX_TURBO set in hank-cfg.h

Thanks for the info. I haven’t had any problems with the 01-25 builds so I’ll just keep using those for the time being.

Enough people have asked for this to become a runtime option that I’m surprised it hasn’t happened yet. I know nothing when it comes to coding, otherwise I’d attempt to do it myself.

[stephenk]

Sorry if this is a stupid question, but which Anduril configs do the Emisar DT8 and Noctigon KR1 use? I can’t see files for these lights.