I think I would like to see:
Party and Tactical strobe run at memorised brightness.
Party strobe to have a slightly longer, but still motion freezing, on-time such as 4-5ms.
Tactical strobe to be 50/50 on/off time.
I know a bit about Macs and it might be possible to update your OS. If you go to the Apple menu and select “About This Mac” and tell me the exact model I can tell you the maximum OS that the machine can run. In regards to editing code on the Mac, probably the most used application is program called BBEdit and there’s a free mode. You can find older versions here that will be compatible with older versions of macOS:
http://www.barebones.com/support/bbedit/updates.html
You would use BBEdit to make small changes to the Anduril source code and save the changes as a text file in BBEdit. I’m less certain on the rest so I could be wrong, but I believe you would then use a Terminal command to “compile” your newly changed code and I believe that the complied code is then the hex file that you would then flash onto your light.
Instead of 7 Click do a 6H to change the auxiliary mode I am trying to do it myself but I’m as dumb as they come when using a cpu I’ve downloaded VS and C++ got the spaghetti on the plate but I dont know how to configure debugger or any pathways correctly…so I gave up for now…sad face
I would like that too. At least, for tactical strobe. It’s too bright, which makes it annoying. OTOH, I guess that’s usually the point of a tactical strobe. Do you think it could be changed to use the memorized level without making people mad?
I can see how that would be better for light painting. It uses a 33% duty cycle now, in part to try to make it more “tactical” like the name implies… but also because it was written on an Emisar D4, where 50% overheats quickly.
Using a lower brightness would help. Switching from 33% max power to 50% mem level seems like it would be a nice upgrade… except for people who actually want to do the whole “tactical” thing.
The on-time is a compile option. I generally set it as short as the hardware can handle.
Usually I find that ~0.5ms works well for freezing motion, but some lights can’t activate for such a short time. On those I’ve generally used 2 to 4ms… but then instead of freezing motion, the frames get motion blur.
In any case, the on-time requires editing a line in the cfg-*.h file for an individual light. I may eventually add a runtime option for it somewhere, but probably not very soon… and it would only exist on lights with at least 16 KiB of ROM, not on older models like attiny85.
…
Perhaps when I have time, it would make sense to refactor the entire strobe group a bit. Like, set up an array of config values, 2 values per strobe mode, with 1H/2H adjusting the first/primary value up and down, and maybe … um, perhaps 4H adjusting the second? Then each individual mode could interpret those values however it likes.
As a rough idea, it could be something like…
- Party strobe: speed + duty cycle
- Tactical strobe: brightness + speed
- Police strobe: 1st color + 2nd color
- Bike mode: brightness + [none]
- Candle: brightness + intensity
- Lightning: [none] + [none]
This may again make things not fit on attiny85, but it would be nice to have on newer torches.
2 Thanks
If you’re on Windows, I hear the easiest way is to install Ubuntu or Debian in a WSL container, then follow the instructions for Linux-based development.
I don’t have Windows or MacOS though, so you would need someone who isn’t me to answer questions. Or there are a few guides available.
Edit: It sounds like Docker is even easier, as linked in thefreeman’s reply below.
thank you I will give it a shot… great job on the new Emisar 2 channel config toyin’ with it now it’s freakin’ awsome
1 Thank
Thanks for the extensive reply. Adjustable brightness would be very useful for use of tactical strobe for light painters, as it allows more flexibility. The only other white light flashlight with adjustable strobe brightness has been discontinued to issues around minimum orders. Going from 33% to 50% duty cycle isn’t essential, but would create better light trails.
The party strobe at 1.3ms to 2ms just isn’t really bright enough for creating light trails when attached to light painting tools. The aforementioned discontinued light had a flash mode at 5ms which still had a high degree of motion freezing, but didn’t suffer anywhere as near a “real world” brightness drop.
I started a bit of work on fully-configurable strobe a while back, but it never worked quite right (mostly in adjustment; there are some combinations of frequency and duty cycle for tactical and for ontime and delay for party that either don’t work or do something weird, while others work fine). If there’s demand I’ll try and find some time though, maybe if I get my devboard project up and running to reduce the annoyance of having to constantly reflash to test.
Yup, I’m a total muggle in the software/programming world,
followed the guidance in that thread and succeeded compiling hex files for TS10, SP10 Pro, etc…
no customization or editing yet, only compiling what’s available here :
~toykeeper/flashlight-firmware/anduril2
(~toykeeper/flashlight-firmware/anduril2 : revision 657 , click “download tarball”)
1 Thank
Yes Sir! 
(especially for me who knows basically nothing about C language, let alone Assembler )
1 Thank
For any software-muggle who’s interested in compiling Anduril hex file, please read that thread, SammysHP’s Docker method works great.
I’m using Windows 10 laptop btw.
terminal: PowerShell, I didn’t try with Command Prompt, YMMV.
On windows, I’ve been using WSL2 with great success. windows subsystem for linux - version 2 - uses a real linux kernel from what I understand, and you can access the linux filesystem in windows explorer with the “explorer.exe .” command (from linux, and don’t forget the “.” at the end).
So, yesterday it took me less than 2 minutes to fire up ubunty (straight from windows), update the linux programs, update the repository and compile.
This is the method I use Anduril ... 2? - #353 by elendur (I just added a few steps to what ToyKeeper originally suggest doing).
2 Thanks
Thank you,
I’ll try your method later, next weekend maybe.
Which version of Linux do you use for Step #1 ?
ubuntu. I’m not going the lie, the first run takes more than the 2 minutes I quoted, but it’s easy afterwards. Just take notes of what you do so you can come back to it later.
1 Thank
Whoa-
I got on here hoping to digest some programming info, (lol, need more sleep for that I guess) but found it cool to find someone that knows the difference between tig and stick (now that’s my language) and programming 
1 Thank
Yup, that’s so cool !
I did a little bit of stick weld yesterday,
I know very little about MIG,
nothing about TIG and less than nothing about programming
2 Thanks
I’m sure it won’t be so simple for me,
not because of the complexity of the method but because of my lack of knowledge.
but hopefully I’ll be able to overcome the trouble,
like when I was trying SammysHP’s method with Docker and anduril-builder image
Docker and WSL2 work well together. Just install the Docker Desktop package, then in WSL2 Docker should work out of the box, or if not, you might need to set up the group (usermod -a -G docker $(whoami)), reopen any open WSL programs/terminals, then it should work.
This is like “another level of TIG welding” to me 
, now I’m even more clueless than before.
Docker and WSL2?
I thought it’s :
A. Docker + SammysHP’s anduril-builder image = compile/build hex files.
(SammysHP’s method mentioned by @thefreeman)
or
B. WSL + Linux = compile/build/make hex files.
(ToyKeeper’s method mentioned by @elendur)
I’ve tried method A and most builds have succeeded (a few failed),
and I’ve got hex files for my SP10 Pro, TS10, SC21 Pro (all reflashes have been successful).
1 Thank