The anduril click combinations of babbel
If you have infinite non flashlight enthusiasts all with D4v2’s trying to figure out how it works, at some point someone will operate the light flawlessly and without error, probably even setting temp config accurately, albeit accidentally
(tongue-in-cheek) Have you read my post above and understood what it says, specially the part where I mentioned that I checked the changelog and saw your mod there, among other changes?
As a side-note, did you intentionally try to be rude AF, or couldn’t you just help it? (/tongue-in-cheek)
and understood what it says?
refactored how channel modes are defined, and converted emisar-2ch build
Saying that one light has been “converted”, doesn’t logically entail that all others stopped working, much less silently stopped working: they should have at least generated a compile time error like with the “#error this build doesn’t work right now” or similar that’s already there for a number of lights.
Also, the above warning only mentions that the channel modes have been changed – neither the TS10 nor the FC13 are multi-channel, so “channel modes” don’t apply to them, therefore it’s logical to expect these lights to be unaffected.
So, at the very least there should have been a explicit mention in the changelog stating that “ALL LIGHTS WILL NEED TO BE CONVERTED AND HAVE STOPPED WORKING IN THE MEANTIME”, or similar.
Being a development branch doesn’t justify any of the above: it’s not reasonable to expect all lights but one to simply stop working without an explicit warning, ideally via compile-time errors but at the very least a explicit mention in the changelog.
Thanks to @SammysHP timely if not exactly kind alert that TK’s latest revision (728) is silently broken for all lights except the emisar-2ch, and my estimate that it will probably be some time before that is fixed, I just built a new set of hexes for the next-to-latest rev.727 plus my to 8C mod: https://durval.com/xfer-only/anduril_-_multi-channel_-_727-8C_quick_aux_switch.zip
Already tested in my Wurkkos TS10 and FC13 and it seems to be working great. TK already incorporated Sammy’s ADC fix, so it should work without that issue in the Wurkkos TS11 too.
Bug reports, suggestions, etc welcome!
I guess that would be true if these “non-flashlight enthusiasts” were monkeys 
In that case, I would bet that if you wait just a bit longer, they would blink Shakespeare’s complete works in morse code too
I was a little confused because you’re not the average Anduril user, but able to understand what happens in the code. I never had the intention to be offending.
Well, it is a development branch - but yeah, it is interesting how it only gives a warning even though no modes are defined… might be able to do something with preprocessor macros, I guess, but it’s probably not really worth the effort vs just porting the targets to it.
Hello from Ubuntu 22… Finally an install that actually ran…
Would one of you people that are epically smarter than I am(although thats not hard to do, I’m sure… ), like to tell me what I’m doing wrong with docker? 
raccoon@R:~$ docker pull siterelenby/anduril-builder
Using default tag: latest
latest: Pulling from siterelenby/anduril-builder
Digest: sha256:0890a9a8c059ba6b75b8eeac3deebdfec6cdba6c3ab75edfa0f8feefd0c21cfc
Status: Image is up to date for siterelenby/anduril-builder:latest
docker. io/siterelenby/anduril-builder:latest
What’s Next?
View summary of image vulnerabilities and recommendations → docker scout quickview siterelenby/anduril-builder
raccoon@R:~$ sudo docker run --rm -v /home/raccoon/A2-732/lashlight-firmware:/src anduril-builder
Unable to find image ‘anduril-builder:latest’ locally
docker: Error response from daemon: pull access denied for anduril-builder, repository does not exist or may require ‘docker login’: denied: requested access to the resource is denied.
See ‘docker run --help’.
I’ve tried just installing docker engine, and it could never download or local build an image. Then installed docker desktop and it would download images but then in a terminal I could never get the docker daemon to start. Lots of screwing with permissions ensued with no change. I can run the image in the desktop enviroment but have no idea how to send the anduril code to it… But it only runs a few seconds anyway.
I now have docker desktop and the docker engine installed sepparetely, and then I can download images by terminal or in the graphical enviroment.
done in a terminal, I get the above… it downloads the image fine, but then can’t freaking find it to bloody use it!!!
Congrats! I hope this is the beginning of a fruitful and pleasant relationship between you and Linux 
Would one of you people that are epically smarter than I am(although thats not hard to do, I’m sure…
I do not use docker for this (instead, I’ve built a VM with the whole she-bang installed in the more traditional way), but I will try and replicate what you did and get back to you, give me a few minutes.
OK, just did it and it works for me; I believe it will work for you with the folliowing changes:
sudo docker run --rm -v /home/raccoon/A2-732/
lashlight-firmware:/srcanduril-builder
You have to specify the full image name, ie instead of “anduril-builder”, please try with “siterelenby/anduril-builder”
Also, I believe you probably meant “flashlight-firmware” instead of “lashlight-firmware” in the middle of the pathname for the anduril sources location, please have a look at that too,
And please keep us posted, looking forward to your further Linux exploits
EDIT: @AK-Adventurist
Granted, and of course TK can do whatever the heck she wants and I would still be grateful to her for her work – but to silently break all lights but one with no warning in the process and hardly a warning on the changelog is quite disappointing, specially considering the high quality of her work in general.
might be able to do something with preprocessor macros, I guess, but it’s probably not really worth the effort vs just porting the targets to it.
That could have been accomplished by a literally one-liner like this:
for f in `ls -1 cfg-*.h | grep -v emisar-2ch`; do mv ${f} ${f}.orig-20230718L063134 && (echo '#error this build is broken'; cat ${f}.orig-20230718L063134) >${f}; done
Or at least a explicit, clear mention in the changelog that all other builds (but for the emisar-2ch) are broken… that would have been even less effort, and would have saved us all a ton of time and breath.
Aha! that did it! woohoo! 
Can’t believe that missing f… the other, adding siterelenby/ I would have never thought of since I was just following provided directions…
Docker runs the enviroment now, which is great; but no matter what directory i give it, it returns;
nothing in /src looks like an anduril source directory.
BUT at least it tries to do something!
I’ve tried it on the previous branch release 657, and the current multi channel release 732, same result.
Any thoughts? 
Guess I could tag @wolfgirl42 since its her Docker image I’m playing with(Docker wont even attempt to build a local image from the command given at @SammysHP 's version. so I went with hers, it had an image on the hub)
The jury is still out on fruitful relationship with Linux… Although it was the easiest setup ever, and so far everything I install outside of Docker works(go figure lol). I don’t like the desktop enviroment(never did like gnome much), but since Decker requires it, I’ll cope. Might install xfce, see if they can co habitate(looks like its possible but one fiasco at a time lol) And the software manager sucks, along with the settings utility… but I can learn the terminal stuff for that again. I hope .
Check the path to the source. Which directory do you use, the full flashlight-firmware repository or a subdirectory of it?
Docker doesn’t need any desktop environment or a GUI in general at all, just imagine all servers needing graphics.
You’re completely right, I feel like I must have typed that command out from memory or something on a day where the memory wasn’t doing so well…
There are three parts to a Docker image’s full path, but only two are mandatory. e.g. for the anduril builder, e.g. for SiteRelEnby/anduril-builder:latest:
Most importantly, there’s the image name itself, anduril-builder, which identifies what the image is, what Docker should be looking for at all, then there’s the tag (latest - the part after the : which indicates the specific version (the default being latest which will use the latest version available) that should be run).
The non-mandatory one that I neglected to include is the registry (siterelenby/, but can also be a private server, e.g. my-internal-docker-registry.siterelenby.net/), which is essentially a server that stores Docker images, where if Docker doesn’t find an image matching the name stored locally, it will connect to that server to check there and download it if found, but if there is not a specified server and the image given can’t be found locally, it instead goes to https://hub.docker.com/, which is a public server where people and companies can publish their projects and products for others to use - this allows things like docker run ubuntu to run Ubuntu Linux easily with a minimum of boilerplate.
I work with containers and complex CI pipelines and stuff every day to put lights on the table so it can be a little easy to forget not everyone I discuss it with is as familiar, I guess. I really need to write some better documentation around some of my stuff but I’ve just had a lot going on recently, was possibly either very distracted and/or on one substance or another when I wrote that, so definitely sorry for any confusion, I don’t really know what I was thinking giving such offhand/incomplete info, but for a way that should actually be directly copyable to use, try from the appropriate folder:
For Windows users from cmd: docker run --rm --pull=always -v "%cd%":/src -it siterelenby/anduril-builder:latest
and for Linux/Mac/WSL users: sudo docker run --rm --pull=always -v "$(pwd -P)":/src -it siterelenby/anduril-builder:latest
I’ll put it on the todo to add a note to the error with some oneliners to actually run it in a reasonable way. sorry for the confusion. When I left the registry off I guess maybe I had been hacking on anduril myself and I run different versions of the builder with different extra changes, plus just since I publish the image to docker hub then some of my own tools use a builder version without the registry name to keep the two separate.
My docker image fork should detect some of the edge cases of directory path vs script path now and tell the user what’s needed (it’s the disconnect between TK’s repo that has her firmware under ToyKeeper/ where build-all.sh has a hardcoded ../../.. but most people other than her hacking on anduril on a version that only has the relevant code, so build-all.sh by default goes one level too shallow, but also that the user still needs to mount the right path to the image as well, which for some reason I forgot to include any code to do so, if you just naively run docker run anduril-builder without the volume mount info, it’s going to not have it available even if the image is already on the system. Can be worked around in various ways but I’m already spreading my spoons thinly just to exist day to day at the moment but I’ll try to at least get a bit of info together for the error results for users. Really, that’s something that when there’s a migration to a SCM system more people can participate in, I’d like to have a go at improving some of the build tooling because I’ve run into limitations from assumptions before.
You should specify, in place of /home/raccoon/A2-732/flashlight-firmware, the directory containing the Toykeeper subdirectory; eg, for rev 727 and presuming you expanded the downloaded compressed file into /home/raccoon/A2-727, that would be /home/raccoon/A2-727/~toykeeper/flashlight-firmware/multi-channel, ie your complete command would be:
)docker run --rm -v /home/raccoon/A2-727/~toykeeper/flashlight-firmware/multi-channel:/src siterelenby/anduril-builder
Or using the easier command wolfgirl42 just posted, just cd there first, ie:
cd /home/raccoon/A2-727/~toykeeper/flashlight-firmware/multi-channel
sudo docker run --rm --pull=always -v "$(pwd -P)":/src -it siterelenby/anduril-builder:latest
The hex files will then be generated in the ToyKeeper/spaghetti-monster/anduril/ subdirectory.
BTW, Toykeeper’s multi-channel is in a high state of flux right now. I would stop at rev 727 for the time being, as that was just before the latest refactoring which I’m not sure is over yet, and rev 727 has already been tested by me and is working perfectly at least for my Wurkkos lights (TS10 and FC13).
Or you could go to the latest (rev.734 right now) since at rev 732 TK posted “fixed Wurkkos builds”, but be prepared for things to break unexpectedly and in ‘interesting’ ways and with hardly any warning, like it happened to me with rev 728 (it’s a development branch after all, so as discussed TK can do whatever she wants, she is under no obligation to release anything working or otherwise).
EDIT: just compiled rev 734 and flashed it to my TS10 and it seems to be working, at least didn’t put my flashlight in a comma like rev 728 so it should be safe for you too.
I can see you’re on the right track, indeed the terminal (aka “command-line” or “the shell”) is the place you want to be for most of your Linux experience (except of course for eminently graphical stuff like browsing the internet or doing spreadsheets/documents etc). Don’t loose heart and keep going – in the end I’m sure the time and effort you’re investing will be returned many times over.
Re: docker, it can be used entirely on the command-line, and GNOME is fine for a beginner, I wouldn’t worry about that at your current stage.
Please don’t worry, your work with the docker image is great and already worked like a charm, provided the user fills in the correct directory.
I just posted a more complete explanation for @AK-Adventurist which I think will solve most if not all of the issues he has been seeing.
And your latest idea with embedding the current directory transparently in the command line is great, it should make it easier for the user: just cd to the correct directory and paste the docker command, I’ve incorporated it in my explanation.
my 8C mod (721-8C_quick_aux_switch_-_20230616.diff) still applies (with just a minor, harmless warning) to rev 734, ditto my other patches to fix compile-time errors if the configuration undefines #USE_SIMPLE_UI ( 727-undef_USE_SIMPLE_UI_fix.diff) and USE_MANUAL_MEMORY (/725-undef_USE_MANUAL_MEMORY_fix.diff), the resulting hexes have just been flashed to my TS10 and FC13 and seem to be working well.
Won’t post hexes due to lack of demand and having other stuff on my plate right now, but if anyone wants/needs them, just holler.
The original point off the AUX-LEDs was to replace tritium vials. You can’t see trits in daylight and they are used to find a light in the dark.
But today many people find AUX-LEDs pretty und want to see them at daylight which can empty a T10 battery in 3 weeks.
When you have a single dim green locator LED e.g. under the switch it can last years on a 18650
It’s also very usefull for battery level indication, knowing at a glance if I have enough remaining battery for the task ahead is much better than having to do a series of clicks and count flashes.
It also shows the lockout status.
Just wanted to jump in here and say thanks again to @wolfgirl42 @dmenezes and @SammysHP , I did indeed get a working docker environment after you last posts and advice above!
Took until yesterday for me to have any time to touch it again, few hours digging in the code, and I have a working config file that compiles for the Sofirn SC31 Pro. (Pre multi channel! )
Finally got to do what I wanted all along; removal of “features” from that light(tactical mode, momentary mode, and all strobes/beacon. And activating one it missed(3C from lock to off).
Even managed to set my ramps pre compile. Not sure yet about setting turbo modes and a few other things at compile, but I’m getting there.
Yay! Way to go, my friend! 