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?