Thanks, I added that as a compile-time option. By default it’s turned off, but can be enabled per build target or in config-default.h to affect all build targets.
Turning it on saves 4 bytes and reverts “Ramp 2C” back to how it behaved in Anduril 1.
There is also an “Off 2H” action to access momentary turbo (or momentary ceiling in simple mode). This has changed from the old behavior of “Off 2H” being a shortcut to “ceiling, then ramp down if held”.
I really like the candle-mode, but most times it is too “nervous”- the flickering rate is high for me. Is ist possible to implement an adjustable “framerate”? So brightness & flickering could be matched to the situation. I would love the possibility : ) The lightning mode could also benefit from this 
(okay, in this case only the pauses should be shortened/extended).
Will it be possible to update old drivers? I can’t relly get, what “it would break backward compatibility” means.
- Christian
The intensity of candle mode can be configured at compile time by setting CANDLE_AMPLITUDE to a different value. The default is 25. It controls the difference between the dimmest and brightest parts of the animation. With lower values, it makes the individual steps easier to see, so it looks less smooth. With higher values, it’s more smooth but flickers too intensely like it’s a camp fire instead of a candle.
At some point, I’m hoping to increase the frame rate and/or make it use intermediate steps between the ~25 ramp levels it uses, to make it look more smooth without increasing the intensity. However, this is … tricky.
Old drivers can be updated, but it depends on the type of light. Some are easy, some require soldering to access the right parts, and some are glued so thoroughly they’re nearly impossible to open.
Sounds good! TK - pm'ed you with a question. Need to re-sync locally from 559 to 561.
Usually a “bzr pull” or “brz pull” should do the trick… if you downloaded it with a “bzr branch” originally and haven’t modified any of the files it tracks.
If modified, then you’d have to commit your changes and then “bzr merge” to get the things which changed. And if you changed the same parts I did, it’ll have merge conflicts. So usually I keep one copy to mirror what’s upstream, and another copy that I can work in.
Hhmm, don't know the bazaar commands, after all, they are bazaar 
I just dnld. All I'm doing at this point is creating and modding cfg files. Also modded anduril.c to load the cfg file I want to use.
Been using git at work and recently just recently did branch and merges, but we use tortoise git as the git UI.
I'm not seeing much right now that I want to change - you've been adding most things I wanted, like voltage calibration.
I created a running list of possible future mods and this is what it looks like now:
Beacon mode can be dropped now, and that I had as a custom mod before.
A bigger change would be to support 2 e-switches but that might have to be done as a different SM UI, think as you mentioned before. I got a couple 2 e-switch lights to mod but would need the driver support as well, though could wire up a modded driver.
Some feedback another photographer, is that they didn’t realize that stepped ramping was available. Maybe the diagram needs to show two separate parallel bars, one for ramping and the other for stepped ramping, with the 3 click link?
If my two cents are helpful, changing one option per invocation fits my personal workflow better. I usually need to figure out and think carefully about my intended setting and how many clicks it needs, such that I’m not thinking about the next setting anyway and will need to go back. E.g., calibrating the flashlight temp to room temp requires me to get the room temp, convert to C and get the # of clicks, letting the flashlight rest, quickly getting into temp config, and then rattling away the clicks. I’m in no mental state to quickly jump into what I want the temperature ceiling to be, or how many clicks above 30C that is.
Yeah, out of all the changes in Anduril 2, reworking the diagram has ended up taking the longest. It’s tricky to arrange so much info in visual form and still keep the layout clean.
I’m not surprised the documentation is taking time.
Along with things like simple mode, documentation is a huge part of having an accessible UI. If the docs are good then manufacturers will be happier that their lights are targeting all users instead of just experts. It also makes it easier for us to lend or recommend lights with Anduril to others.
The state diagram is great and my brain grocks it. I wonder if a more task-oriented diagram (similar to the text manual doc) would be more helpful to others.
I’m imagining this taking the form of a more tutorial style set of images or maybe even GIFs and a bit of HTML holding them together.
As with the text manual, this would allow someone to have a useful flashlight even if they didn’t get to the end.
This would take even more work than the existing docs though.
I don’t think Launchpad allows previewing HTML but if it did then that’d be perfect.
Have you considered a website or even a domain that redirects to the readme?
(Opinions from a random internet stranger. Feel free to ignore)
I got 3 lights running Anduril2. About to dnld to a HK04. I did some light rev engineering on the HK04. They use a 3 leg part (FET?) with resistors preceding it to implement the single 7135 channel. Turns out they precisely reproduced 0.35 amps with the circuitry! I tested it simply by lots of measured ramping over the first flicker - seems pretty dead on averaged to 0.35 amps.
The HK04 driver uses 2 large/typical FET's in parallel for the main FET channel, and has switch LED's, and USB-C charging. The charging appears to share the one color switch LED, and uses another switch LED - I think they are green and red. I destroyed the switch PCB in getting it out so am replacing it, but don't have a 2 color (4 wire) switch PCB to use, so not supporting the 2nd color for charging. The one I'm suing though has 4 LED's but all wired together.
So even though it's a custom ATTiny85 based driver, it looks like a FET+1 with 1 color AUX/switch LED's to the firmware. Interesting...
I’m sorry if this has been covered already, but there is no downloadable hex file for Anduril 2 yet, correct? The firmware repository website layout has me on the verge of a stroke (there doesn’t seem to be a file associated with each “revision”?) and want to make sure I didn’t miss something 
Correct, at the moment you have to compile it yourself.
The docs are taking a while mostly because I’ve hardly had any time to work on it. I have a lot of a tutorial written up, and mostly just need to make the diagrams to go along with it. The plan is to start with the simplest parts, then proceed in order of increasing complexity. People wouldn’t need to read the whole thing to use a light; just the beginning.
About short URLs, there is one which links to the latest revision in the repository, but I don’t have one specifically for the manual. I’m planning to put the tutorial up here on BLF as its own thread.
That seems to be a common issue. People don’t have bzr (or brz), which are the intended ways to access the repository… so they look for a way to download the whole thing, and can’t find it. It’s a pretty legit problem with Launchpad. However, there is a way to do it:
Then extract the .tgz file.
However, if you’re going to be compiling it anyway, it’s probably easier to just use a Linux container. Compiling it can be a little tricky otherwise. So for that, the process would be a bit different…
apt install build-essential gcc-avr avr-libc binutils-avr avrdude brz makebrz branch lp:~toykeeper/flashlight-firmware/anduril2cd anduril2/ToyKeeper/spaghetti-monster/andurilmakeOr something like that, anyway. Has been a long time since I set up a new host for this.
This should produce a full set of supported builds… one .hex file for each cfg-*.h file.
I’m not sure if avrdude actually works from inside of WSL. It may be necessary to flash using a Windows tool instead.
Thank you Sammy and TK! I’ve got some free time the next few days so maybe this is something I’ll mess around with. 
I'm compiling Anduril2 fine under Windows using AS 7.0, all source files combined in one folder
I haven’t compiled Anduril2 (yet), but that’s how I always compile the original.
:BEER:
One last question, I’ve downloaded the .tgz which seems to contain the entire repository but I’m still not sure what the actual file path and names are for Anduril 2. It just seems to be the latest revision (I assume?) of Anduril and the different model-specific files - is it just the ones under spaghetti-monster>anduril?
Yep - you trace it down under TK, under Spaghetti Monster, then Anduril -- that Anduril is Anduril 2 - check the manual, think there's another way too. Not on my home computer right now...
I am still changing Anduril.c to include the cfg file of choice.. I've made up 1 or 2 cfg files as well.