# Field Notes: BEDS Data Retrieval 01/11/2016

**Date:** January 11, 2016 1:46 PM
**Author:** Eric Martin

## Objective: ##

To accompany Brian Keift on the R/V Paragon and attempt to communicate with a BED instrument post-motion event through acoustic telemetry. This has been a problem in the past and I am tasked with improving at-sea performance. My goals today were to observe and experiment with the equipment to help characterize the problem.

## Observations: ##

Well seas were calm and we were able to reproduce the problems Brian had talked to me about. It did seem that uploaded data from the BED was unreliable and wholly unsuccessful. We attempted today using a standard Benthos Universal Deck Box, or UDB, connected via a standard omni-direction transceiver head. As with most acoustic communcation problems, understanding the limits of the environment was the first goal. We know that the unit has moved down the canyon, and as such could be partially buried. Given this, we did observe better communication with the instrument when positioning the Paragon “down-canyon” from the waypoint Brian had surveyed in. However, simple acoustic interference does not explain all of problems observed today.

We explored use of the support zmodem protocol with the microprocessor running picoDOS on the BEDS using a topside laptop and a keyspan USB/RS232 transceiver hooked up to the UDB’s serial port. Terminal communication was conducted through use of hyperterminal and zmodem transactions done through the same software.

Firstly, by observing communications passed out of the tranceiver’s buffer to the serial port on the UDB, it was clear that not all bytes received by the UDB during zmodem interactions transparently arrive on the serial port. After initiating the zmodem transfer at the remote host, a number of messages come up from the BEDS and automatic replies are sent, but those must originate from the UDB. It is my understanding that the Benthos UDB support zmodem transfers onboard, so I am concerned that the UDB is not acting as a transparent transceiver at all points of the file transfer. I would like to investigate this further.

It is clear that due to the handshaking interactions required to send each packet, communication breakdowns in both directions are leading to a significant slowdown in communication as we were spending significant time waiting for protocol timeouts way outside the bounds of the sound speeds and expected packet lengths. For example, when a packet request is misinterpretted by the BEDS an and appropriate error message is generated and accurately received topside, but the zmodem would not re-attempt based on this error, instead waiting for a message timeout.

Also, at slow acomm baud rates ( <600 bits per sec), we observed that the physical time required to transmit 1 kilobyte of data was longer than the allotted period of time zmodem would wait for information on its serial port, and thus the packet would timeout and attempt to request a new packet while the other was still being transmitted. This could be defeated by finding a way to have the UDB flush its buffer more quickly or by extending the timeout period on the zmodem transfer. What this limits currently is our ability to significantly slow down acomm baud rates for more reliable communication.

Also, there were many instances in which requests for data packets were met with no reply from the subsea electronics. It is not clear if any data at all is received subsea and whether it gets through the buffer of the modem electronics.

## Action Items: ##

[ ] Determine if the UDB is stepping in on the zmodem conversation.
[ ] Attempt to resolve timeout configurations to increase zmodem response and provide a more robust transfer.
[ ] Understand response logic for the subsea zmodem implementation and whether the missing replies are expected.
[ ] Troubleshoot low acomm baud timing issues.
[ ] See if the supported KERMIT protocol can offer more benefit.