Anduril ... 2?

Thank you for your answer.

Yes, aux leds are changing color, when flashlight is off.

I wil try 7 clicks method. :+1:

Kind regards

Little problems with AndĆŗril
1lumen (Netherlands) und Darren Yeo - Tech, Tools % Tutorials (Australia)
:stuck_out_tongue_closed_eyes: :netherlands: :australia:

1 Thank

The video is 2 hours long, very quiet, and has no subtitles. What specific points did you want to share from it?

When you click on the link they should talk about things non flashlike people donā€™t care about.

(the video should start at a time mark)
Edit: I see the time stamp is fā€¦ed
from ca. 53min onward

They are just complaining that Anduril is too hard to use in real life. When they needed light, they were lost with the UI and ended up with a non-working flashlight.

Lol. I just came here to ask a question, and see our video posted hereā€¦ Just shared my personal opinion, and experienceā€¦

Just a quick question to @ToyKeeper .
I had a custom firmware built by gChart on my Emisar D1 v2 with FC40 for testing purposes. Today, I wanted to put the original Anduril 2 version back on, so I checked your list Index of /torches/fsm/anduril2 and another website, and none of them had a working firmware.

So I asked on Reddit, and somebody said I need the DM11 12V, which fortunately worked.
My question: could you please add that firmware to the D1 v2 list as well?

I have a D1 v2 with FC40 and its running anduril.2022-10-21.noctigon-dm11-12v.hex
Itā€™s what it came with.

1 Thank

How about to add timed turbo stepdown?

Yeah, that one worksā€¦ the 3 actual D1 v2 firmwares donā€™t. So it might be helpful to have that DM11 12V version in the D1 list as well, with the correct name. D1 v2 12V for example.

Several models use the same firmware, there would be a lot of duplicates if there were a firmware for each models.

Well, then they could be added to all of them :slight_smile:

First Iā€™ve heard of it.

I used to try to keep track of this sort of thing manually, in the PRODUCTS file. That quickly got out of hand though, since there are a lot of cases where the product name and the build target name donā€™t match, because manufacturers do all sorts of crazy things and donā€™t tell anyone. Sometimes a single product can run several different firmwares and the choice depends on factors the user may not even knowā€¦ like which particular driver type or hardware revision the light was built with.

So I added a numeric ID for each individual build target, and added that number to the Version Check function. That way, people can ask the light what flavor it is, and be assured theyā€™re getting the right answer. Just look up the number in an auto-generated MODELS table, to get the name of the build target it uses and the type of control chip it needs to flash.

And to guide people through that process, I made a short README file which should show up at the top if the page when looking at the .hex files. Hereā€™s what it says:

TL;DR: I canā€™t fix it in the manner requested, because itā€™s out of my control. But if you read the readme, thereā€™s a different solution which is simple and reliable.

3 Thanks

But for new models you should also search other developers in case the model number is missing. Or ask here in BLF who has a firmware.

e.g. I couldnā€™t find 0714 on TKs Modellist, tought I was to dum to count.

Firmware Wurkkos TS10
I found 0714 on: gabe on launchpad it is from @gchart

https://bazaar.launchpad.net/~gabe/flashlight-firmware/anduril2/view/head:/ToyKeeper/spaghetti-monster/anduril/MODELS

1 Thank

Short-term, yes. I got pretty behind on things due to some personal issues, so there are a few build targets I donā€™t have yet. But Iā€™m working on getting peopleā€™s branches merged soon.

Thank you @toykeeper. I understand, and that makes sense.
So, if people are looking for one that is not on the list, itā€™s probably best to just askā€¦

Yes, if the number shown in Version Check isnā€™t on the list, itā€™s probably best to ask. Itā€™s probably a new model which hasnā€™t been merged yet.

But most (like your D1) are on the listā€¦ even if not under the name you might expect.


Edit: I just noticed this post is comment #1337. Leet. :stuck_out_tongue_closed_eyes:

3 Thanks

@ToyKeeper I thought I should put some of my general thoughts on testing different builds here instead of getting in the way in threads where itā€™s not relevantā€¦ :sweat_smile:

I like the new change in 710 to the post-off voltage reading, but it still has a couple of issues:

  • If the off aux mode is on high, it seems weird to let it drop to low even if the light was only used on moon mode
  • In general and related to the above, there should be a logical separation between the aux voltage mode such as a gap of maybe half a second or so(?) where the aux are entirely off before entering the normal aux mode, to make it clear something specific is happening. I tried to write a way but it ended up becoming too complicated to be worth it for me.
  • blink_once() still causes voltage aux to activate afterwards (e.g. locking/unlocking the light), as does anything else that uses set_level() in any way not related to user-operation of the main emitters, primarily for a short time. In general including some of my own hacking on it, I came across a few edge cases already enough that I think the easiest way might be to have a variable that can be set by operations that call blink_once() or similar methods that use set_level() but shouldnā€™t trigger voltage aux, so it can be something like skip_post_off_voltage=1; set_level(foo);, then when the voltage aux would have activated, instead, it is skipped and skip_post_off_voltage reset.

Wouldnā€™t it be enough to limit the readout to the X to off transition where X is a set of states to be determined? This would skip some special cases and momentary modes, though.

Yeah, that might actually be simpler. {ramp, strobe} mode => {off, lock} mode to activate it. I ruled that out as an approach earlier because I came up blank on a way to accurately determine the previous state when in off/lock state, but if that was doable then it could go in EV_enter_state which would bypass a lot of the current weirdness, and if that could be done that might be the most efficient way, and would bypass the need for prev_level altogether.

Just for the people who donā€™t read on
21700 D4KTi COLORFUL version is available - #5924 by ToyKeeper and following.

Anduril2 is now (2023-05-10) on #657 and there is an additional version Anduril-Multichannel from #700+ on.

TK updated the manual to fit both versions in Rev. 706
(Edit: Since itā€™s 706 the new manual is at the moment in the Multi-Cannel branch only)

Wurkkos gets the model IDs 0700 to 0799 (TS10, TS11, fc13, emisars added)
MODDELS.txt was updated

AndĆŗril 2 from TK
Rev. 657 (2023-03-28)
https://code.launchpad.net/~toykeeper/flashlight-firmware/anduril2
Anduril2 changes History
https://bazaar.launchpad.net/~toykeeper/flashlight-firmware/anduril2/changes/
Some late changes:
ā†’ new Tactical mode
ā†’ strobe modes got 4C to go backwards
ā†’ low bat warning on single color aux LEDs

New AndĆŗril multichannel from TK
At April 2023 ToyKeeper made a multichannel version of AndĆ¹ril 2
It starts at revision number 700
Rev. 710 (2023-05-03)
https://code.launchpad.net/~toykeeper/flashlight-firmware/multi-channel
ā†’ post-off voltage display
ā†’ UI change for multichannel

Thank you @ToyKepper for all the work!

3 Thanks