Discussion on the blueprint improve-catoa-ranging registered at https://blueprints.launchpad.net/goby/+spec/improve-catoa-ranging

For our reference, the WHOI manual including CATOA: 401004-SPEC Micro-Modem Synchronous Navigation Guide

Below, MMDriver refers to the class goby::acomms::MMDriver that implements the goby::acomms::DriverBase for the WHOI Micro-Modem. The source code is in goby/src/acomms/libmodemdriver/mm_driver.[h/cpp].

Current Implementation of CATOA ranging

• The user is responsible for setting [MicroModemConfig.nvram_cfg]: "SNV,1" and [MicroModemConfig.nvram_cfg]: "TOA,1" in the extensions to DriverConfig so that $CCCFG,SNV,1 and $CCCFG,TOA,1 get sent to the modem on startup (turning on synchronous transmission and the CATOA message).
• $CCCLK is sent by MMDriver (void goby::acomms::MMDriver::set_clock()) when
  • MMDriver is started (startup)
  • After reboot ($CAREV,INIT,*)
  • Any time the clock reported by $CAREV,AUV,* deviates from the system clock by more than ALLOWED_SKEW (currently 2) seconds.
• $CCCLK is resent after sending until the reported $CACLK deviates from the system clock by less than ALLOWED_SKEW (currently 2) seconds. ALLOWED_SKEW is necessary to compensate for delays in the hardware between the modem and computer. In field testing, 2 seconds is a realistic bound (FreeWave buoys can be slow). ALLOWED_SKEW should probably be a configuration parameter instead of a static member of MMDriver.
• In my testing (0.93.0.30), the $CATOA always precedes the corresponding data message (CACYC, CARXD, CAACK). Thus, within void goby::acomms::MMDriver::process_receive(const NMEASentence& nmea), the CATOA message is used to populate (if MODE==3, i.e. good) the static protobuf::ModemRangingReply ranging_msg, which keeps its value over calls to process_receive (definition of static). All we know is that the transmissions was synchronous (on the second), but we don't know which second the message was sent. Thus, we report the CATOA time of flight (TOF) plus n seconds out to a reasonable max range (10k meters at the moment). Since the CATOA itself does not contain any information about the source of the message that it is tied to, we have to find the corresponding data message, which can either be:
  • CACYC - the CATOA from this is discarded because it doesn't contain the actual sender of the $CCCYC (since third party CYCs are allowed)
  • CARXD - flush_toa is called to populate the ranging_msg source and destination from that of the CARXD and signal_range_reply is signaled (for users of MMDriver).
  • CAACK - flush_toa is called to populate the ranging_msg source and destination from that of the CAACK and signal_range_reply is signaled (for users of MMDriver).

A valid goby::acomms::ModemRangingReply (defined in modem_message.proto) for a CATOA should look like this:

$CATOA,102301.0123,3
$CARXD,1,3,1,0,abcdef

becomes

base
{
  src: 1 # from RXD
  dest: 3 # from RXD
  time: "2011 May 02 10:23:01.0123"
  time_source: MODEM_TIME
}
# ambiguity must be resolved at a higher level
one_way_travel_time: 0.0123
one_way_travel_time: 1.0123
one_way_travel_time: 2.0123
one_way_travel_time: 3.0123
one_way_travel_time: 4.0123
one_way_travel_time: 5.0123
one_way_travel_time: 6.0123
type: MODEM_ONE_WAY_SYNCHRONOUS
}

What needs implementation

• Validation and testing of the current implementation above
• Better error checking and recovery when MODE != 3 (currently CATOA with MODE != 3 are silently discarded)