Hi Anduril user’s !
I noticed that the momentary turbo does not work for 4H from the “ON” state (3H for those who do not have tint ramping).
To fix it, I have to comment out line 423:
if (! arg) { // first frame only, to allow thermal regulation to work
Do you have the same behavior?
Thank you and good day
Hi, multi-channel Emisar D2 user here, Model number 0135,
emisar-2ch
, using ToyKeeper’s latest Anduril 2 version,anduril.2023-08-07.emisar-2ch.hex
: At my end, momentary turbo 3H/4H works just fine and as expected, so I do not have the same behavior.4H from ON for momentary turbo works with every channel mode, whether there is tint ramping or not, and 3H from ON for momentary turbo works when there is no tint ramping with the selected channel mode; all exactly as displayed in the diagram.
Hi thank’s for your help. I rollback two custom modification ans it’s working again :
- reduce #define HOLD_TIMEOUT from24 to 20 & reduce #define RELEASE_TIMEOUT from 18 to 16
- Apply #2027884 & #2027883 correction suggestion from https://bugs.launchpad.net/flashlight-firmware/+bugs?orderby=importance&start=0
I will investigate which of this two changes cut my turbo off
Glad to hear it’s working. @Protiron@lemmy.world if you are still stumped I was going to suggest posting to this thread on budget light forum where Toykeeper is active: https://budgetlightforum.com/t/anduril-2/62656/1604
Speaking of testing locally - how do folks test code changes? Actually flash them to driver, or is there some kind of way of simulating the inputs and outputs? I’m guessing there isn’t an Anduril emulator.
Yes, you could (theoretically) use an emulator for the microcontroller. I tried it a few times. And it isn’t fun. It takes a lot of effort to simulate all inputs, outputs are hard to interpret and all kind of effects of the real light aren’t reproduced.
In reality we flash the build onto a flashlight and try it. Sometimes it’s only a prototype, disassembled. And rarely it’s an actual devboard which has all relevant parts of the flashlight nicely accessible (basically the microcontroller with required electronics, regulated power supply, low power LED to see the output, several LEDs for aux and button and the switch itself).
To test it I flash my flashlight … :(
Good question, just wanted to point out your link
[https://bazaar.launchpad.net/~toykeeper/flashlight-firmware/multi-channel/view/head:/ToyKeeper/spaghetti-monster/anduril/ramp-mode.c#L423]()
markdown is broken but copy-pasting the url works.
Thank you, I fix it. Does Momentary Turbo 3H/4H work four you?
I don’t own a multi-channel, but I did see something that looks interesting in the code (not familiar with the codebase and haven’t worked with C much):
Could be a red herring but the function
channel_has_args
looks kind of like it might be doing the same work asif(!arg)
for single-channel. Again this could be totally wrong but IF that were the case, then I’d expect that adding to the if statement could potentially help catch this? Likeif (! arg) || (! channel_has_args(cfg.channel_mode)
.Also in following the code style the actual statement would also need to include an IFDEF for multi-channel-config but maybe not necessary for you test locally?
Also in following the code style the actual statement would also need to include an IFDEF for multi-channel-config but maybe not necessary for you test locally?
So Mementary Turbo 3H work for you? If you don’t own multi channel, MT should be 3H from ON. I think l423 be identical for simple or multi channel.
I can’t find where arg should be equals to 0… steady_state always call with arg <> 0
Sorry for the extraneous information about the ifdef. The important part was whether adding this extra check would fix the bug in the same way as deleting the original line did.
I can’t find where arg should be equals to 0… steady_state always call with arg <> 0
From what I could assume in the comments, this refers to the very first state in that steady-state (“first frame”) right when you have done 4H. Then it sets the current level to the appropriate turbo (
set_level_and_therm_target
).Your bug would be that it never set the level to turbo because it never executed
set_level_and_therm_target
because! arg
evaluates to false.Your bug fix was to delete the check, but that means that every instant it will keep trying to set the level to turbo instead of just setting it during the first frame and then maintaining the steady-state.
My potential fix was to add something so that the statement
if (! arg) || (! channel_has_args(cfg.channel_mode)
would evaluate to true during the first frame so it can then callset_level_and_therm_target
exactly once.@SammysHP@feddit.de (if you have a moment) does this seem close to the mark?
| (! channel_has_args(cfg.channel_mode)
I test that asap. I already try to comment it and it’s work fine :
//if (! arg) { // first frame only, to allow thermal regulation to work uint8_t tl = style_2c ? 150 : turbo_level; set_level_and_therm_target(tl); //}
But I am surprised that the functionality appears in the diagram and that no one remarks that it does not work (3H without Multi channel or 4H with) https://lemmy.world/post/1038159
It appears in the diagram because it works. Just tested it again on my dual-channel D4V2, and it works like a charm.
On reflection i think this is incorrect.
arg
seems to represent the output level as of when the event was triggered.