I guess that nixes machine-readable input with phone’s ambient light sensor, it will not be able to read the buzzes reliably, especially if they are adjacent to ‘0’ which is a short blink.
I think it would have been more flexible, more robust, and less confusing to evolve the message by treating existing fields as immutable, or ideally prefix the output with a message version # (not the Anduril Version #):
<version><message>
Where:
version 1 = 1YYYYMMDD
version 2 = 2YYYYMMDDBBPP
Imagine, we wanted to add something useful like a build ID “ZZZ”, and either the manufacturer / product space was close to becoming exhausted. A Version 3 message could be defined:
Overall, more people care more of the time about the model code than the build date - if you want the build date, you probably want the whole version string, while if you’re just checking the model code because you’re updating, you don’t need the build date of the current version.
It’s easy to just add a digit. Like, Version Check could blink out:
12345-2024-01-01
The punctuation makes it easier to divide the data into distinct segments. The number of digits in the date won’t change any time soon, but the number of digits in the model ID could… and it wouldn’t be a problem if more digits are needed.
OTOH, if Anduril ever supports more than 99 manufacturers, I hope things will have evolved enough by then that it can have 2-way communication with a computer, and/or have more of a single unified build with support for many hardware types. That would require a much more capable MCU, but maybe after a few dozen more brands are onboard, that’ll be more feasible.
I’ve done a small amount of work looking into this with someone else, but it ended up on hold due to everything going on in my life, but it’s definitely a project for the future.