Anduril Version Check formats

I’m writing a small utility to parse the blinks from an Anduril light and present the result, as a fun project.

Two questions:

  1. From the manual section “Version Check Mode” there are 2, maybe 3 formats:

Anduril 1: YYYYMMDD
Anduril 2 before 2023-05-30 : YYYYMMDDBBPP
Anduril 2 after 2023-05-30 : BBPPYYYYMMDD???

I just wanted to make sure I understood the 3rd one, seems odd that digits were swapped. Anyone know if that is the case, and why?

  1. Is the date based on the day the build happens, regardless of the Anduril version, or is it associated with a branch / tag / commit in the repository?
1 Thank

According to @containerfan 's diagram, the newest format is:

1 Thank

Ah, thanks for the clarification.

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:

version 3 = 3YYYYMMDDBBBPPPZZZ

This is unambiguous, flexible, and future-proof.

1 Thank

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.

1 Thank

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.

3 Thanks

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.