Known Issues

Below is a list of the known issues for the VectorNav C Library.

- Wireless and Other Unreliable Communication Channel Issues

# Wireless and Other Unreliable Communication Channel Issues

When using the VnSensor object for high-level communication with a VectorNav sensor, issues may arise with communication over a wireless or other wireless communication device. Many of these issues arise because some of the data that is transmitted may be corrupted or lost and will not be recognized by the VectorNav sensor or the VnSensor code. As a result, often times a request to read a register from the sensor (e.g. VnSensor_readModelNumber) will return with an error E_TIMEOUT. To better understand why this problem arises and how possible solutions to this issue work, it is useful to know more about how the VnSensor code handles communication with the VectorNav sensor.

The VnSensor code enters into a special mode when a request to read a register is made or when a write register request is made with the option to waitForReply is set to true (e.g. VnSensor_writeAsyncDataOutputFrequency). When these type of requests are made, the VnSensor code must receive a response from the sensor to either get/parse the register value returned or to verify the values were written to the sensor. Associated with the waiting is a responseTimeout value which tells the code how long to wait before it gives up waiting on a response, default value is 500 milliseconds. In this event, the VnSensor code will return the error E_TIMEOUT to indicate this event. Additionally, while the VnSensor code is waiting for a response from the sensor, it will periodically retransmit the original command in case the first one sent got corrupted or lost. This value is controlled by a retransmitDelay value which tells the VnSensor code how long to wait before retransmitting again. The default value of this is 100 milliseconds.

Now normally the default responseTimeout and retransmitDelays are sufficient for communication channels that are largely reliable such as connecting over a serial port or using a USB to serial converter cable. In this scenario, most communication will consist of a single command transmitted to the sensor and the sensor will then respond and be received by the VnSensor code. The default values allow for the occasional blip in the data transmission. However, when the communication channel is not as reliable and there is an increased chance of data dropping or becoming corrupted (e.g. wireless or long serial cable lengths), these default values will result in an increased chance that the communication with the sensor will not be completed, resulting in a greater chance of receiving the error E_TIMEOUT. The best solution is to increase the reliability of the communication channel but if this is not an option, then adjusting the responseTimeout and retransmitDelays may result in acceptable interaction with the sensor.

In such a scenario and with the default values, the VnSensor code will only wait for 0.5 seconds and will send out the command a total of ~5 times before failing. If we can increase the number of retransmits, we increase the odds that a successful communication interaction is completed. As an example we have experienced in-house, using a Digi International XBee 802.15.4 non-PRO version communication module configured for 115200 baud communication, we had trouble with the VnSensor's default values for communication with the sensor on a single desk. However, we were able to adjust these values and get acceptable performance for a single data collection task. For our scenario, we configured the responseTimeout to 10 seconds and configured the retransmitDelay to 20 milliseconds. This configuration would allow sending out the command ~500 times before failing. With this configuration, we found that our register writes would complete generally between 100 ms to 1,000 ms.

Now although we were able to get a solution working for our specific setup and needs, your application may require different configuration values. Hopefully this explanation will guide your experimentation with finding appropriate values that work for your application. Your can configure the VnSensor code to use your custom values by calling the methods VnSensor_setResponseTimeoutMs and VnSensor_setRetransmitDelayMs.