Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Migration of unmigrated content due to installation of a new plugin

Table of Contents

iAcommsDriver

iAcommsDriver provides our standard interface between MOOS and the WHOI uModem. It implements the GOBY uModem driver class and allows other MOOS applications to make use of the modem through several MOOS variables.  It provides two main methods of interface.  The unified interface should be used by new applications, at least for receiving acomms messages.  The simple interface is primarily designed for a human to use with uPokeDB, but can provide adequate transmission functionality for some applications.  

Simple Interface

Great for simple applications or human use.

...

Sometimes the simple interface is cumbersome because applications have to subscribe to many variable to get enough information about incoming acomms transmissions. With the unified interface, only one variable is required to send or receive data.  The HoverAcomms library provides a number of useful functions for creating and interpreting the transmission and reception objects.

Transmitting

Note that the simple transmitting method is supported regardless of the "enable_legacy" setting. Alternatively, use the Use the AcommsTransmission class defined in the HoverAcomms library. Post the serialized object to ACOMMS_TRANSMIT and the acomms driver will set the rate, destination, data, etc. all from the information stored in that object.

...

With each receipt an object of the AcommsReception class defined in the HoverAcomms libary is posted to the binary string ACOMMS_RECEIVED. This posting is still available if "enable_legacy" is turned on. 

Logging

Several postings are made specifically for logging purposes, but applications may use them as well. These postings are always enabled. The serial communications between the host and modem are also recorded in a goby_log.txt file in the same directory pLogger uses.

...

Enabled using the "enable_ranging" process config, this option syncs all transmissions to a PPS pulse provided by PPS. Both sending and receiving modems must have this option enabled to work. If the legacy option is enabled the The travel time will be posted to ACOMMS_ONE_WAY_TRAVEL_TIME , otherwise the travel time will be and is also contained in the AcommsReception object.

...

  • Two way ranging
  • Driver crashes if pLogger is not started first
  • Acomms stats may be incorrect if, for example, one and a fraction of three available frames are used

...

pAcommsSimulator

pAcommsSimulator is designed to run on the shoreside MOOS community and provide a simulation back-end for any number of connected iAcommsDriver's.  The acomms simulator is in active development and new feature requests or bug reports are welcome.  Please email jleight@mit.edu.

Simulator Configuration

Code Block
ProcessConfig = pAcommsSimulator
{
    IterateMode = 0    // regular iterate and mail
    AppTick     = 20

    sound_speed = 1450  // m/s
    p_partial_loss = 0.1
    p_complete_loss = 0.1
    p_sync_loss = 0.1
    p_loss_per_frame = 0.5
}

The currently loss configuration is:
    p_partial_loss - probability that some, but not all frames are lost.  In the case of single-frame packets, partial losses cannot occur.  
    p_complete_loss - probability that all frames are lost, but the packet is still received.  One way ranging will also still occur.
    p_sync_loss - probability that a packet is not heard at all.  The receiver will never enter the receiving state.
    p_loss_per_frame - given that a partial loss occurs, the probability that any given frame within the packet is lost.  If no frames are lost after this probability is applied, one frame is randomly selected to be lost.  Similarly, if all frames are lost, one frame is randomly preserved.  

Given this configuration, the probability of no loss is simply:
    p_no_loss = 1 - (p_partial_loss + p_complete_loss + p_sync_loss)

Except in the case of single-frame packets where it is:
    p_no_loss = 1 - (p_complete_loss + p_sync_loss) 

Driver Configuration

iAcommsDriver communicates with pAcommsSimulator by establishing a connection to the same MOOSDB the simulator is running on.  An example iAcommsDriver configuration for simulation:

Code Block
ProcessConfig = iAcommsDriver
{
    IterateMode = 0    // regular iterate and mail
    AppTick     = 5
    PortName = /dev/ttyUSB1
    ID       = 5

    PSK_minipackets   = false
    enable_ranging    = true
    show_range_pulses = true

    in_sim = true
    sim_server = localhost
    sim_port = 9000
}

In this case, the shoreside MOOS community on which pAcommsSimulator is running is found at localhost, port 9000.  

Features

Implemented:

  • Approximate timing of transmission/reception length for different rates
  • All standard rates and mini packets
  • One way travel times
  • All fields used by HoverAcomms library

Not implemented:

  • Complete / accurate receive statistics
  • LBL pings
  • two way ranging
  • time warp

If you are using the HoverAcomms library to interact with iAcommsDriver, you should not encounter any issues using the simulator.  However many fields, particularly in the receive statistics, are either not populated or populated with dummy (and potentially incorrect) values by the simulator.