Ruminations on ROVL IDs

More information on using IDs with your ROVL

ID capability was added to the ROVL in December 2023. See here for potential uses and important limitations on this capability.

With any type of broadcasted signal, you have to expect occasional reception errors. In AM radio, errors manifest as static. With Wi-Fi and cellular data signals, errors manifest as slower data throughput. Wi-Fi and cellular system have lots of bandwidth, and so engineers can add error detection and correction signals and overhead data that makes sure all the data that are sent are received in the correct order and without errors. There's enough bandwidth to re-send messages if the receiver fails to acknowledge receipt of a good message.

On the other hand, when sending the ID nybble, the ROVL sonar signal has only the power to transmit about eight bits per ping, and has only the power to transmit one or two pings per second. The ROVL spends about half of its data budget sending error detection bits. Even so, as multipath and other signal issues increase, you need to expect that IDs will occasionally be unreadable and will even more occasionally incorrectly decode an ID payload as the wrong ID.

If you are using IDs, you need to expect some errors and design your software to be tolerant of those errors. For example, you might require that you receive several identical IDs in a row before you decide you are receiving the ID correctly.

Example: Suppose you have a configuration like this and you have decided the lead AUV will use the ID payload to broadcast which mission segment is currently active, using the 16 possible values of the ID. You might require that each follower receive three (or five, or n) identical ID payloads before switching to the indicated mission segment.

Another situation: The error detection system can determine that in 15 out 16 cases where an ID is garbled, the decoded result is known to be an error. Unfortunately, that leaves 1 in 16 chances of a random pattern being decoded as the incorrect value. In a Mk III system using IDs in both directions, the transceiver polls for the ID it wants to hear from. If the transponder correctly identifies its own ID being broadcast, it will respond with an ping carrying its ID. The transceiver decodes the returned ID and supplies it to the host, along with the ID it was requesting. There are several outcomes that can occur, and your system software design needs to be robust enough to deal with any of them:

• The transponder correctly decodes its own polled ID and the transceiver correctly decodes the response ID. This is the normal (and most common) case.

• The transponder determines the polled ID was garbled, in which case it does nothing. The transceiver eventually gives up waiting and reports a missing response, and which ID was missing.

• The transponder incorrectly decodes someone else's poll ID and responds with its own ID. If it is closer to the transceiver than any other responding transponder, it "wins." The transceiver reports the ID received (which may be garbled, be the ID actually sent, or be an incorrectly decoded ID), and the computed location of the unintended responding transponder.

The third case implies that a simplistic system will occasionally receive a spurious position for a given ID (if there are multiple transponders in the operating area). When the host decodes positions, it should match the polled ID and the returned ID and be prepared to discard anything that is not a match. Even with low odds, occasionally you will get a spurious position with matching IDs. Sanity checks should be used to detect and filter these out.