That would seem to indicate that the firmware used is the last pre-production test code. However, I asked Hank if my just-shipped order uses the 2019-03-21 final production code, and he responded by saying “Yes, it’s with the latest firmware.” So, go figure. Not sure I’d be able to tell the difference anyway.
No, I never added anything like that. It’s not as simple as it might seem. Version numbers are complicated. For example, a program on my computer has version number “2.1.5+deb1+cvs20081104-13.2”. It’s not even a big program. That’s the version number for “eject”, and all it does is eject and retract the tray on optical drives.
Basically, to serve useful purposes, it’d have to be pretty long… like maybe one of the following:
- Checksum of the source code (plus a big reference table somewhere to look up what it means)
- Build date plus branch name and build target ID
- Branch name and revno (like 188.1.213) plus something to indicate which build it was
- Some sort of long and manually-updated version number which throws an error if not specified.
None of this is easy to communicate to a human by simply blinking a pixel on and off.
To be useful, the number would need enough detail to answer common questions. For example, is this the full-power build or the reduced-power 219C version? How old is it? Which repository version was this based on? Does it have bugfix X or feature Y? Is it part of the main repository or was it made from a different branch? Who built it? Does it match an actual repository version at all, or was it cowboyed without checking in the changes?
Tom tried to do a simple version number scheme with Narsil and NarsilM, and it worked okay at first when there was only one person making builds and only a couple of commercial lights using it… but it got messy pretty quickly when there were more people and more products involved. There are now a bunch of different versions all called “1.3”, but they’re all different and most don’t have the improvements Tom put in the official 1.3. People took earlier versions and bumped the number, which ended up being misleading in terms of how the code behaves.
So, long story short… no. I haven’t even tried to bake in a version number. It’s complicated, and I’m not sure it would even be a net gain.
Thanks. I’ve been meaning to ask Hank to fix that link, but I also need to merge the code into a public branch first. The revision history graph is a bit of a mess due to some recent refactoring and multiple concurrent projects, so I was hoping to clean things up a bit more before uploading.
This is the same on RampingIOS V3. The main things which are different are the blinky modes, and an easier-to-reach lockout mode.
Yeah, that’s unfortunate. Got any ideas how to work that into the UI without adding much complexity?
It could have two memorized levels instead of one… one for the ramps, and one for momentary. We can’t really do “hold to ramp” in momentary mode though. The simplest method I’ve thought of so far is to do 5 clicks in ramping mode to set the momentary level, then turn the light off, then 5 clicks to enter momentary. The symmetry works out to make it reasonably easy to remember. The upside is it would allow turbo in momentary without setting a ceiling to the maximum. The downside is that it’d require extra inputs and it’d be a bit less intuitive. And a more neutral aspect is that the momentary level would have its own separate memory, which could be desirable or not.
I don’t think this one uses glue. The driver screws into the shelf, similar to a BLF Q8.
However, I don’t think it’ll have pogo pads. And the LED wires are very short and thick so they can carry a lot of current, so the driver will almost certainly require unsoldering the LED wires to access the MCU.
I’m not sure. Maybe it was fun using lightning mode at 14,000 lm?
No maybe about it, lightning mode at high output is definitely fun! 
26,000 lumens especially! lol
What Anduril light has 26k lumens? 
Or is it a Dale custom? :weary:
I know it’s a complex solution but if one was really determined, a machine-readable blink-out would work.
I mean: do the same thing as optical programming but in reverse. Now it’s flashlight blinking out some binary code and a smartphone app receiving it.
M43 has calibration function 14fast click and hold. Temperature should be 25C.
Interesting. Thanks! That’s not in the manual. It only goes up to “12 Fast Clicks & Hold”.
Do you know of any other undocumented functions in the M43?
Sorry for asking a dumb question but what does “Temperature should be 25C” actually mean? Does that mean I need to make sure that ambient temperature around the (cold?) flashlight is 25°C before I click 14 times and hold?
Just checked out HAM’R…
LP, he’s saying the base setting should be 25C…I think. I found the M43 UI too confusing so I pulled it, stripped the driver, and piggybacked in an FET driver. I have Anduril in my M43 now too. And a Master/ 3 Slave configuration if I remember right. It gets really really REALLY hot in Turbo, way fast! 12 Samsung emitters will do that in this small of a light.
Thanks Matt, it was one of those wild hair moments. (unfulfilled due to the lack of the extension tubes Sofirn quit on)
Anduril works fine in Ham’r because the drivers are separated from the heat source by a significant amount of aluminum. By filling the head of the light with the base of the finned addition there is a LOT of mass underneath the emitters. My M43 has the drivers virtually up against the bottom of a comparatively thin emitter shelf, as such it floods heat into the Master driver in a very quick manner and Anduril isn’t set up for this… too much too fast by a wide margin so the thermal issues arise in the driver. Again though, in the even more powerful Ham’r it’s simply not a problem.
lol… I found some behind the scenes footage from Dales HAM’R build!
Maybe this is a similar issue to what TA is experiencing trying to get Anduril to function on the MF01S?
You’re an active member on BLF…
You’re well informed and have some pretty in depth knowledge from what I can see…
Yet you’re able to resist buying every amazing new flashlight that comes around!?
Here’s a link exploring some commercial buck and boost drivers, tests and modifications:
I send you link to extended manual.
It means that temperature of flashlight body should be 25C. After 14 times and hold light blink twice and button blink green - calibration is done.
if light blink once and button blink red than calibration failled due to large(>16C) difference between temperature of light and estimated temperature by m43.
The consequence of this procedure that you can adjast “50C” stepdown in some range .e.g. if you calibrate M43 at 20C stepdown would be at 45C
I will also ask for a link to the extended M43 instruction
i am interested in this manual as well. Thank you for the link. Could someone who knows how please enlighten those who do not, on how to get this translated into English?
thank you!