If you search for references to “USE_SUNSET_TIMER” in that file, I think you’ll find the answer. In fact, you can easily find any interaction with sunset by searching the whole repository for that flag. Note that only the first matches are shown per file, unless you click “Show X more matches.”
Before moving to github, anduril was on a non-distributed version control system (bazaar), which means the revision IDs are not necessarily unique, and infact count up different depending on your branch. In fact, in the previous bazaar repo, branch commit numbers only go up to r659. As @Reader9 notes, commit versions/dates will be more helpful unless you use git commit IDs.
By the way, you can find out the date @Reader9 found by going to a version control blame view (bzr annotate for bazaar). This is built into github online which you can see here by clicking the “blame” tab on the top left from the normal code view.
From there you can actually see the code before this change in 2020. If you click on the commit message on the left for that line, it will take you to the changes and full message, where it’s clear that sunset was renamed from goodnight. So just click the goodnight file and load the deleted diff, and you can see the similar logic from before it was moved here.
Must’ve been the latter. You can see the changes from multi-channel here, it’s much more of a higher level architectural change, with no real structural changes to the ramp mode code. The very minimal changes suggested by @Reader9 should work just fine.
Yes. set_level(0) should turn the light off (technically, it’s slightly more complicated than that due to how anduril uses different states, but works that way effectively).
The light would certainly go off if dimmed_level reached 0 in isolation, but it might have more parasitic drain, continuing to execute whatever code was in the current state machine path. And of course avoid all the things in the off-mode state, including future button presses like waking up.
Thankfully as alluded to (searching for other uses of the flag), sunset mode will still call off state
Well, technically, it will still sleep in both steady_state and off_state regardless, more affects events in terms of switching it back on, but yeah. Also nice one on finding that.
Ah I must’ve missed it, still getting my bearings on this codebase. Are you referring to this microcontroller sleep mode or something else? Where from steady_state does it eventually called?
It was the current and latest revision @toykeeper had made when i downloaded it earlier this year. She was posting them as linear revisions to the main code as she made them, so i dont see how they cant be in line and unique updates, they were at the time… At any rate that is half of the source that I have used to build my “branch”(probably the wrong term).
That one(657) because it was the last time for several months that the config files for hardware I am using would compile. Changes to multi channel “broke” several lights being supported/compatible for several months.
The other I am using is from her later revision in about mid June, rev725, technically part of multi channel, but a lot was still not updated. It was the last revision before ALL build targets stoped compiling for me(and a few others here) with her at the time current infrastructure changes.
725 has has apparently been moved, deleted or some such with the unfortunate switch to Git a little while back.(I liked bazzar ).
I’ll look in a few days and so if I can find it in Git, if it looks like it matters.
At some point I should try to get the newest source and see if it will compile in my Docker install without too much trouble… The latest posts in the compile on docker thread here seems to show that for the latest source, I need to update dependencies for it to work, and that was such a nightmare to install the first time, I’m sure I won’t get it to work.
Add in that I see no functional gain for any light I own on multichannel, I have little draw to try the latest version. I’m perfectly happy to stay in the older revisions, IF I can get folks to still help me moddify the things that are over my head… Thankfully both @wolfgirl42 and @dmenezes (and a few others) have been verry kind with “hand holding” and leading me through this stuff in the past few months.
Thats the newest that I am working with, so any code help given should need to be compatible with that( I think I have all my lights functioning on this, since it added tactical mode and I am using that as a 4th comfigurable output ramp) As I say, maybe mods built on the latest will be perfectly compatible, I don’t know. I stopped getting the newer source after that time because it stopped compiling at all for any build targets I own(ed).
That clarifies things and ends up verifying myself and others have said. Just to summarize, commenting the two lines @Reader9 is all that is needed, and the ramping code has not really changed from your r657 all the way to latest github code.
To clarify, nothing is lost when switching to git, it’s just that in bazaar, revision IDs are not uniquely identifying. r658 is different on the main branch vs another. On github, just a revision ID makes it crystal clear what version of the code is that you are using, so it’s easier for others to help you.
Now that you have provided more detail, it’s easy to point you to exactly where you are in git. With that, what I mentioned here still holds true about compatibility with your version of the code:
You can verify this by going to my link I quoted above on github and clicking on the parents: " 2 parents 9634e4a + bb81bf1". That first parent (bb81bf1) has the exact some commit date and message as r657 that you linked and was meant to show you explicitly that the ramp code did not really change compared to what @Reader9 linked.
I have bought 2 Wurkkos TS10 4000K blue aux before 3 weeks and after I get it I examined that thay was in advanced mode with aux on high.
I reset one and go to simple mode with aux on low and test it and it works ok like other 5 TS10 which I have.
I gave this example to my friend.
After a few days I met with him and see that he was play with it and it show some features which I don’t see in anduril user manual diagram.
After 4 clicks from off this flashlight give sign by aux that it is lock but after tap on switch it turn on like it wasn’t locked, which is not problem because he never use locking feature.
Second feature which is interesting is that when light is on and I go to click click hold - this turn of main light and also aux will turn off. With one click aux turn on with short blink of mainleds. Everything other works like other TS10s. He like that possibility that he can turn light of without aux turn on autimatically and without disabling aux. I can’t find how to program it on my lights and my friend doesn’t know to say me how he get that option because flashlight start to works on that way after ‘playing and clicking switch many times when he try to learn about anduril features’. His TS10 works in simple mode with stepped ramp in 5 stages.
After we reset his TS10 to factory settings he lose that click clich hold from on to turn off mainled without aux on and locking with 4 clicks again works.
After few days he again on some way enable that 3H option but locking again doesn’t works.
My other TS10 after 3H from on give momentary turbo.
My question is how to program that feature which my friend have, is it anduril bug or option which are not documented?
Click click hold can also be written as “3H”. 3H is momentary turbo. The behavior you described here sounds like maybe the momentary turbo level is drawing too much power for the battery leading to a shutdown.
I think in the same direction and try with other batteries but it do the same. Also I measured battery voltage on standby and with load and it was good.
The same battery works good in other TS10.
When this thing occur 4C locking doesn’t work either from on or off.
I would love it if Anduril 2 had a “Vintage / Throwback” setting for gifting Anduril 2 lights to people that will never use its features.
Vintage Setting
1C from off - Turns on the light
1C from on - Turns off the light
10H from on - Reverts to normal Anduril mode
When entering “Vintage” setting, the following defaults should be set:
Thermal Limit - 40c
Brightness for Vintage setting should be set to whatever brightness it was at when putting it in that mode.
Basically a dumbed down “Muggle” mode that makes it as close to idiot proof as possible, at least until the new and improved version of idiot is released.
IIRC, you mentioned a couple of months ago the possibility of removing Extended Simple UI from those hex files that currently have it, or something to that effect.
Because ESUI is included in the file I recently flashed to a Wurkkos TS21 (http://toykeeper.net/torches/fsm/anduril2/anduril.2023-10-31.sofirn-sp36-t1616.hex / 2023-10-31 15:1928K), I’m having a difficult time getting the TS21 setup with the Tactical Mode group’s 3 slots setup the way I want without it inadvertently going into ESUI.
So I’d like to know if you have an SP36-t2616.hex file available without ESUI, but with the Tactical Mode (6C) group included? Thank you!
How’s that possible? Entering Simple UI is 10C, entering Tactical Mode is 6C. And once you are in Tactical Mode, you can’t directly switch to Simple UI.
