Bandwidth requirements for SBP messages is highly dependent on user settings, as well as the number of satellites and signals tracked. In some cases, the amount of bandwidth required can overcome the available bandwidth on a UART connection.
Swift receivers allow the user to change the messages output and output rate. Both have impacts on bandwidth requirements. Additionally, as more satellites and signals come online, some Swift Navigation Binary Protocol (SBP) messages will either increase in size or increase in output rate. For example, each GPS satellite tracked will result in an additional MSG_EPHEMERIS_GPS SBP message every thirty seconds, and each signal adds 17 bytes to each MSG_OBS message. This could present an issue where the UART0 or UART1 connections becomes saturated, resulting in data loss.
This article will present examples of some of the messages affected, how to identify UART saturation, techniques to mitigate the issue, and procedure to change the baud rate.
SBP version 2.4.7 was used for the publication of this article. For more information on SBP, including message structure, types, and sizes, please refer to the specification here: Swift Binary Protocol
UART Settings and Baud Rate
Universal Asynchronous Receiver/Transmitter is a popular protocol for communication between two systems. It allows full duplex transmission of data on only two lines, eliminating an extra line for a clock. System A transmits to system B on one line, and vice versa for the second line. While flow control signals can be added for reliability, they won’t be covered here.
Because a clock is not used to synchronize transmissions, both systems must be configured to identical settings to be able to communicate. In the case of the Piksi Multi, the default settings are as follows:
For the purposes of UART, where only two symbols are used for transmission (0 and 1), the baud rate is equivalent to the bit rate. When a system has data ready to send, it will send one start bit, followed by data bits, an optional parity bit, and stop bits. The start and stop bits allow the systems to signals the beginning and end of the frame. Parity provides simple error checking.
Using the Piksi Multi settings, one start bit is followed by eight data bits, and one stop bit. An illustration of two frames of data is shown below. The yellow section represent time in between frames with no data. These quiescent sections can be length from zero to infinite bit lengths, depending on when the system has data to send.
It’s possible that the Piksi can be configured to overwhelm the set baud rate. When the channel is completely utilized, protocol bits (start and stop bit) will utilize about 20% of the bandwidth (2 bits out of 10 for each frame). This allows for (baud rate) * 80% for user data (in this case, SBP messages). For the default settings, this results in 115200 * 80% = 92160 bits/sec.
Sustained overutilization will result in overflowing the UART buffers, and corruption or loss of data. To prevent this, a higher baud rate must be utilized.
SBP Dynamic Message Sizes
As additional satellites are added to constellations, several SBP messages will either increase in size, or output rate. The dynamic nature of SBP allows the messages to be compact, however, it may present an issue when if a UART is operating near the bandwidth limits.
This section is not meant to describe every possible message type in detail, only to provide examples of how sizes can change. For the full details, please refer to the SBP reference (link in the overview).
In addition to satellite and signals, other factors include the user selected output rate for navigation and observation messages, as well as the user selected messages to output.
We’ll explore a couple of scenarios here.
- 10Hz navigation lat/long output
- 1 Hz observation output
- 1 Hz observation from base station
- 5 GPS
- 5 GLO
- 1 BDS
- 5 GAL
- 2 signals per satellite
- Add one satellite per constellation
- Increase navigation output to 20 Hz
- Increase observation output to 10 Hz
- Enable IMU messages @ 100 Hz
In the table below, the message categories are a set of SBP message types. For example, the Navigation category includes MSG_POS_LLH, MSG_GPS_TIME and others. For simplification, the bandwidth cost of each message is not listed here, but the details can be found in the SBP specification. At the bottom of the section are the message types selected for each category.
When exceeding the bandwidth available, a “Dropping Data” error will be presented:
*Messages included in each category:
Navigation - MSG_GPS_TIME, MSG_UTC_TIME, MSG_DOPS, MSG_POS_ECEF, MSG_POS_LLH, MSG_BASELINE_ECEF, MSG_BASELINE_NED, MSG_VEL_ECEF, MSG_VEL_NED, MSG_AGE_CORRECTIONS
Observations - MSG_OBS (Rover), MSG_OBS (Base), MSG_BASE_POS_LLH, MSG_BASE_POS_ECEF, MSG_EPHEMERIS_GPS, MSG_EPHEMERIS_GAL, MSG_EPHEMERIS_BDS, MSG_EPHEMERIS_GLO, GLO_BIASES
Acquisition/Tracking - MSG_MEASUREMENT_STATE
IMU/Mag - MSG_IMU_RAW, MSG_IMU_AUX, MSG_MAG_RAW
How to Change Baud Rate
Baud rates are configurable on UART0 and UART1 to support the needs of the user. As described above, a baud rate must be selected to accommodate the expected bandwidth required by the user configured messages. The Piksi Multi supports the following rates:
The computer or system connected to the Piksi Multi must be set to the same baud rate. Note that the USB/serial adapter included with the Piksi Multi supports up to 230400.
Baud rate can be configured on any connection to the Piksi Multi (Ethernet, USB, UART). If the baud rate is changed via UART for the current connection, then the connection must be re-established with the new baud rate.
Follow the instructions here to connect the Swift console to the Piksi Multi: https://support.swiftnav.com/support/solutions/articles/44001907903-swift-console-user-s-guide
- Under the settings tab, select “baudrate” under uart0 or uart1 (depending on which you would like to configure).
- On the right side, select the new baud rate
- Any connections to the modified UART will drop. Reconnect with the new baud rate.
sbp2report will provide the following breakdown on an SBP recording. The latest sbp2report can be found here.