APN-067 Rev A
Data Transfer and Bandwidth
This application note provides an overview of the requirements associated with data transfer and storage.
1 Overview
In many applications, it is necessary to determine the bandwidth required for transferring data from a receiver, or to
determine the amount of memory required to store the data, so that the appropriate equipment and settings can be
selected.
The amount of bandwidth required will be determined by the amount, size, and rate that data is being sent to or from
a receiver, and can depend on the limitations of hardware being used. The size and amount of data that will be
transferred or stored can be calculated using the documented log size of each message, as well as the frequency
(rate) of each message that is transferred.
The sections that follow will outline the considerations involved in determining the data throughput and storage
requirements for typical applications.
2 Considerations
2.1 Volume of Data
The total amount of data that will be transferred or stored can be determined using the following information:
• Size of each log that will be transferred
• Rate at which each log will be sent
• Complete list of logs to be sent or stored
• For logs that have variable sizes, such as RANGE, it is necessary to know the model and channel
configuration of the receiver. For example, an OEMV-2 receiver capable of tracking GPS and GLONASS
satellites will have more channels available compared to an OEMV-1 receiver capable of tracking GPS only.
2.1.1 Log Size
The size of a specific log or message can be found by referring to the appropriate Firmware Reference Manual for
the receiver used. NovAtel product manuals can be found by going to the NovAtel website using the following link:
http://www.novatel.com/support/firmware-software-and-manuals/product-manuals-and-doc-updates/
It is important to make note of the format of logs that will be requested, as the same log can have a different total
size depending on the format. To reduce the amount of data logged, it is recommended to use binary formatting.
The format used to output each log will depend on how the log is requested. A “B” appended to the message name
will indicate binary, while an appended “A” will indicate ASCII. No “A” or “B” appended to the message name
will indicate abbreviated ASCII, which is not typically used for data that will be transferred or stored. For example,
to request the BESTPOS log in abbreviated ASCII, ASCII, and binary formats respectively, the commands will be
similar to the following:
LOG COM1 BESTPOS ONTIME 1
LOG COM1 BESTPOSA ONTIME 1
LOG COM1 BESTPOSB ONTIME 1
Page | 1 July 2, 2014
2.1.1.1 ASCII Logs
All ASCII formatted logs or commands will have variable length depending on the amount of data and formats. It is
recommended, whenever possible, to use the binary version to minimize the amount of data being sent.
In cases where it is necessary to log the ASCII version of a message, there are some items to note:
1. The start of each message is indicated by “#”.
2. All fields will be separated by a comma except for after the last field in the header, which is followed by a
semicolon, and after the last data field.
3. The last data field will be followed by a ‘*’, the 32-bit CRC, a carriage return, and line feed.
4. Any ASCII strings in the message will be surrounded by double quotation marks.
The above items are important to note when using ASCII logs. Below is an example of an ASCII-formatted
BESTVELA log:
#BESTVELA,COM1,0,46.0,FINESTEERING,1642,160721.000,00000020,827b,6302;
SOL_COMPUTED,DOPPLER_VELOCITY,0.150,0.000,0.0161,189.304443,-0.0042,0.0*976f0082
Using the message definition and basic characteristics of ASCII-formatted logs, it is possible to determine an
approximate size of an ASCII log. If an application requires the use of ASCII-formatted logs, it may be necessary to
collect some sample messages to estimate the expected log size in that particular scenario.
2.1.1.2 NMEA Logs
The NMEA (National Marine Electronics Association) has defined the format for several GNSS data logs otherwise
known as ‘sentences’. NMEA sentences are used in many applications and are similar to ASCII formatted logs.
Because these messages follow a defined standard, the format will be the same regardless of the type of GNSS
receiver used. For this reason, NMEA logs are required for many users when integrating a NovAtel receiver with
other third party equipment.
The length of each sentence can vary slightly due to fields that have variable width or that can be null or empty if no
information is available. Each field of a message, however, will have a defined maximum width. This makes it
possible to find the maximum size of the message, even though the size of some fields may vary.
As an example, the below string is a sample GPGGA message that contains position information from a receiver:
$GPGGA,213130.00,5107.0068,N,11402.3321,W,9,09,0.8,1064.35,M,-16.90,M,02,0133*68
This example NMEA GPGGA string has a total of 80 ASCII characters including the ‘$’ at the start, the comma
separating each field, as well as the ‘*’ and CRC at the end.
Refer to Section 3.3.59 NMEA Standard Logs in the OEM6 Family Firmware Reference Manual
, Rev 1, for more
information on NMEA logs.
2.1.1.3 Binary Logs
All NovAtel logs that are sent in binary format will have a binary header that is 25 bytes long, as well as three sync
bytes and a 32-bit CRC at the end. These bytes will need to be included when calculating the total log size.
Using the BESTVEL log as an example, here is the log size from the message definition in the
OEM6 Family
Firmware Reference Manual, Rev 1, page 296:
Page | 2 July 2, 2014
The total BESTVEL log size, after totaling the fifth column in the table above, is therefore:
3 𝑠𝑦𝑛𝑐 𝑏𝑦𝑡𝑒𝑠 + 25 𝑏𝑦𝑡𝑒 ℎ𝑒𝑎𝑑𝑒𝑟 + 44 𝑏𝑦𝑡𝑒𝑠
(
𝑓𝑖𝑒𝑙𝑑𝑠 2 𝑡𝑜 9
)
+ 4 𝑏𝑦𝑡𝑒 𝐶𝑅𝐶 = 76 𝑏𝑦𝑡𝑒𝑠 𝑡𝑜𝑡𝑎𝑙
2.1.1.4 Variable Length Logs
Many logs will not have a fixed length, even when output in binary format. The size of the log will often depend on
the number of satellites actively being tracked by the receiver, the characteristics of the receiver hardware, or both.
Consider the RANGE log, for example, which will contain a record for each measurement currently available. The
number of records will depend on the number of satellites currently being tracked, as well as the number of channels
used to track those satellites (ie: GPS L1 or GPS L1&L2).
The RANGE log is defined in the following table, taken from the OEM6 Family Firmware Reference Manual
, Rev
1, page 448:
Page | 3 July 2, 2014
The size of a RANGEB log can be determined using a calculation similar to the one shown below, using the
example of an OEMV-3 receiver tracking 10 GPS and 7 GLONASS satellites, and using 2 channels to track each
satellite (L1 + L2, or G1 + G2):
𝑁𝑢𝑚𝑏𝑒𝑟 𝑜𝑓 𝑆𝑎𝑡𝑒𝑙𝑙𝑖𝑡𝑒𝑠 𝑇𝑟𝑎𝑐𝑘𝑒𝑑 = 17
𝑁𝑢𝑚𝑏𝑒𝑟 𝑜𝑓 𝐶ℎ𝑎𝑛𝑛𝑒𝑙𝑠 𝑈𝑠𝑒𝑑 𝑡𝑜 𝑇𝑟𝑎𝑐𝑘 𝐸𝑎𝑐ℎ 𝑆𝑎𝑡𝑒𝑙𝑙𝑖𝑡𝑒 = 2
𝑁𝑢𝑚𝑏𝑒𝑟 𝑜𝑓 𝑂𝑏𝑠𝑒𝑟𝑣𝑎𝑡𝑖𝑜𝑛𝑠 = 17 × 2 = 34
𝑆𝑖𝑧𝑒 𝑜𝑓 𝐸𝑎𝑐ℎ 𝑂𝑏𝑠𝑒𝑟𝑣𝑎𝑡𝑖𝑜𝑛 (𝑓𝑖𝑒𝑙𝑑𝑠 3 − 12) = 44 𝐵𝑦𝑡𝑒𝑠
𝟑 𝑠𝑦𝑛𝑐 𝑏𝑦𝑡𝑒𝑠 + 𝟐𝟓 𝑏𝑦𝑡𝑒 ℎ𝑒𝑎𝑑𝑒𝑟 + 𝟒 𝑏𝑦𝑡𝑒𝑠
(
𝑓𝑖𝑒𝑙𝑑 2
)
+ (𝟑𝟒 × 𝟒𝟒 𝑏𝑦𝑡𝑒𝑠) + 𝟒 𝑏𝑦𝑡𝑒 𝐶𝑅𝐶 = 𝟏𝟓𝟑𝟐 𝒃𝒚𝒕𝒆𝒔 𝒕𝒐𝒕𝒂𝒍
The above RANGEB example illustrates how the amount of data output from the receiver for one message can
depend on the channel configuration of the receiver and the number of satellites being tracked.
2.1.2 Frequency of Log Output
After the size of a particular log is determined, as well as for all other logs that will be collected, it is important to
make note of the rate at which each log will be output.
Page | 4 July 2, 2014
For example, requesting a log at a rate of 10 Hz (10 logs per second) will result in ten times the amount of data
being output on the port compared to a rate of 1 Hz (1 log per second). This is a very important consideration when
determining throughput of a system and will be discussed in more detail in the next section.
2.2 Throughput
There are two main factors involved with determining throughput:
1. Baud rate available and port settings
2. Total amount of data to be transferred
It is best to use the highest baud rate possible when transferring data, however the highest rate available can be
limited by hardware restrictions and also the type of connection (ie: serial vs USB).
The serial ports available on OEMV and OEM6 family receivers support baud rates up to 230400 bps or 921600
bps, depending on the port. When using a serial connection, it is recommended to use a baud rate of at least 115200
bps, or higher, depending on the hardware used. Typical PC hardware will not support rates over 115200 bps and
special hardware may be required.
In some applications, it is necessary to collect certain logs at very high rates (ie: 20 Hz or higher) in addition to other
messages. This is particularly true for NovAtel SPAN users who need to log high-rate INS data, many times at 100-
200 Hz. When this is required, it is best to use a USB connection which will support a much higher baud rate
(maximum 12 Mbps in many cases).
Question: What baud rate is required to transfer 20 Hz RANGEB logs when the receiver is tracking, on average, 17
dual-frequency satellites?
Answer: Using the total RANGEB size previously calculated for 17 dual-frequency satellites, it is possible to
determine the amount of data that will be sent per second and therefore the required baud rate.
Default port settings allow transmission of 10 bits/byte. This includes 8 data bits, 1 stop bit, and 1 framing bit. This
must be taken into account when determining the required baud rate.
𝑆𝑖𝑧𝑒 𝑜𝑓 𝑜𝑛𝑒 𝑅𝐴𝑁𝐺𝐸𝐵 𝑙𝑜𝑔 𝑤𝑖𝑡ℎ 17 𝑠𝑎𝑡𝑒𝑙𝑙𝑖𝑡𝑒𝑠 (𝐿1 & 𝐿2 𝑜𝑟 𝐺1 & 𝐺2) = 1532 𝑏𝑦𝑡𝑒𝑠 𝑡𝑜𝑡𝑎𝑙
𝑁𝑢𝑚𝑏𝑒𝑟 𝑜𝑓 𝑅𝐴𝑁𝐺𝐸𝐵 𝑙𝑜𝑔𝑠 𝑡ℎ𝑎𝑡 𝑤𝑖𝑙𝑙 𝑏𝑒 𝑠𝑒𝑛𝑡 𝑝𝑒𝑟 𝑠𝑒𝑐𝑜𝑛𝑑 = 20
𝟐𝟎 𝑅𝐴𝑁𝐺𝐸𝐵 𝑙𝑜𝑔𝑠 𝑝𝑒𝑟 𝑠𝑒𝑐𝑜𝑛𝑑 × 𝟏𝟓𝟑𝟐 𝑏𝑦𝑡𝑒𝑠 𝑝𝑒𝑟 𝑙𝑜𝑔 = 𝟑𝟎𝟔𝟒𝟎 𝑏𝑦𝑡𝑒𝑠 𝑜𝑓 𝑑𝑎𝑡𝑎 𝑝𝑒𝑟 𝑠𝑒𝑐𝑜𝑛𝑑
𝟑𝟎𝟔𝟒𝟎 𝑏𝑦𝑡𝑒𝑠 𝑜𝑓 𝑑𝑎𝑡𝑎 𝑝𝑒𝑟 𝑠𝑒𝑐𝑜𝑛𝑑 × 𝟏𝟎 𝑏𝑖𝑡𝑠 𝑡𝑟𝑎𝑛𝑠𝑚𝑖𝑡𝑡𝑒𝑑 𝑝𝑒𝑟 𝑏𝑦𝑡𝑒 = 𝟑𝟎𝟔𝟒𝟎𝟎 𝒃𝒑𝒔
Even a baud rate of 230400 bps will result in frequent buffer overruns in this case, since 306400 bits will be sent per
second. The total data output per second for 20 Hz RANGEB logs, assuming 17 dual frequency satellites, will
therefore require a baud rate of at least 921600 bps.
In the case of the RANGE log, required for many applications and post-processing, it is also possible to log a
compressed version – RANGECMP. Logging the RANGECMPB (binary format) instead of RANGEB can greatly
reduce the amount of data and is beneficial when throughput is limited.
Page | 5 July 2, 2014
The size of a RANGECMPB log collected from an OEMV-3 receiver tracking 10 GPS and 7 GLONASS satellites,
and using 2 channels to track each satellite (L1 + L2, or G1 + G2), can be found using the following calculation:
𝑁𝑢𝑚𝑏𝑒𝑟 𝑜𝑓 𝑆𝑎𝑡𝑒𝑙𝑙𝑖𝑡𝑒𝑠 𝑇𝑟𝑎𝑐𝑘𝑒𝑑 = 17
𝑁𝑢𝑚𝑏𝑒𝑟 𝑜𝑓 𝐶ℎ𝑎𝑛𝑛𝑒𝑙𝑠 𝑈𝑠𝑒𝑑 𝑡𝑜 𝑇𝑟𝑎𝑐𝑘 𝐸𝑎𝑐ℎ 𝑆𝑎𝑡𝑒𝑙𝑙𝑖𝑡𝑒 = 2
𝑁𝑢𝑚𝑏𝑒𝑟 𝑜𝑓 𝑂𝑏𝑠𝑒𝑟𝑣𝑎𝑡𝑖𝑜𝑛𝑠 = 17 × 2 = 34
𝑆𝑖𝑧𝑒 𝑜𝑓 𝐸𝑎𝑐ℎ 𝑂𝑏𝑠𝑒𝑟𝑣𝑎𝑡𝑖𝑜𝑛 (𝑓𝑖𝑒𝑙𝑑𝑠 3 − 12) = 24 𝐵𝑦𝑡𝑒𝑠
𝟑 𝑠𝑦𝑛𝑐 𝑏𝑦𝑡𝑒𝑠 + 𝟐𝟓 𝑏𝑦𝑡𝑒 ℎ𝑒𝑎𝑑𝑒𝑟 + 𝟒 𝑏𝑦𝑡𝑒𝑠
(
𝑓𝑖𝑒𝑙𝑑 2
)
+ (𝟑𝟒 × 𝟐𝟒 𝑏𝑦𝑡𝑒𝑠) + 𝟒 𝑏𝑦𝑡𝑒 𝐶𝑅𝐶 = 𝟖𝟓𝟐 𝒃𝒚𝒕𝒆𝒔 𝒕𝒐𝒕𝒂𝒍
The resulting size of the RANGECMPB log is significantly smaller than a RANGEB log with the same number of
observations – a difference of 680 bytes of data.
Although the difference may not be important in terms of storage, the reduced log size may be required after taking
into account throughput restrictions such as baud rate and total number of logs periodically output on the port.
2.3 Data Storage
The amount of memory or data storage available can be a very important factor when choosing hardware for a
particular application.
Using the example of RANGECMPB logs, as above, it is possible to determine the maximum amount of data
collected over a specific period of time. Note that after the data has been transmitted, the extra two bits mentioned
in the previous section (1 stop bit, 1 framing bit) are stripped off and only the raw data bits are stored in memory.
In the example below, we will consider an OEMV-3G receiver that is tracking the maximum number of satellites –
14 GPS and 12 GLONASS – on dual frequencies. This means that, assuming the “worst case scenario” where all
channels are tracking at all times, there will be 52 records per RANGCMPB message:
𝟑 𝑠𝑦𝑛𝑐 𝑏𝑦𝑡𝑒𝑠 + 𝟐𝟓 𝑏𝑦𝑡𝑒 ℎ𝑒𝑎𝑑𝑒𝑟 + 𝟒 𝑏𝑦𝑡𝑒𝑠
(
𝑓𝑖𝑒𝑙𝑑 2
)
+ (𝟓𝟐 × 𝟐𝟒 𝑏𝑦𝑡𝑒𝑠) + 𝟒 𝑏𝑦𝑡𝑒 𝐶𝑅𝐶 = 𝟏𝟐𝟖𝟒 𝒃𝒚𝒕𝒆𝒔 𝒕𝒐𝒕𝒂𝒍
For RANGECMPB data collected over a 24 hour period with a 1 Hz logging rate, and assuming the maximum
number of satellites are tracked at all times, the maximum amount of data storage that will be required is as follows:
𝟖𝟔𝟒𝟎𝟎 𝑠𝑒𝑐𝑜𝑛𝑑𝑠 𝑝𝑒𝑟 𝑑𝑎𝑦 × 𝟏𝟐𝟖𝟒 𝑏𝑦𝑡𝑒𝑠 𝑝𝑒𝑟 𝑅𝐴𝑁𝐺𝐸𝐶𝑀𝑃𝐵 𝑙𝑜𝑔 = 𝟏𝟏𝟎, 𝟗𝟑𝟕, 𝟔𝟎𝟎 𝒃𝒚𝒕𝒆𝒔
To collect 1 Hz RANGECMPB logs alone, a maximum of about 110 MB (megabyte) of memory will be required to
store the data.
Page | 6 July 2, 2014
In most applications it is necessary to record more than one type of message from the receiver and the size of all of
the logs together will need to be considered to determine the amount of throughput and data storage required. The
next section will discuss the data requirements for some common applications.
3 Applications
3.1 Transfer of RTK corrections
In this section we will consider a typical RTK base/rover setup where dual frequency GPS and GLONASS
corrections must be transmitted from the base station to the rover. The size of the corrections that
must be transmitted will need to be determined in order to design the RTK system appropriately.
Specifically, the size of data and throughput required will be important when selecting the equipment
that will be used as the data link between receivers (ie: radios, cell modems, etc.). The data link must
support a baud rate high enough to transmit the required correction data.
Question: What baud rate is required to transfer dual frequency, GPS and GLONASS RTCA corrections
containing data for 17 satellites from a base station to a rover?
Answer: For dual frequency GPS+GLONASS RTK using RTCA corrections, the recommended logs are
RTCAOBS2 and RTCAREF. RTCAREF messages will be sent once every ten seconds, and RTCAOBS2 will be
sent once per second (1 Hz).
The RTCAOBS2 log has a variable length and can be a maximum of 255 bytes long. The number of bits
contained in an RTCAOBS2 message is [128 + (108 x N)], where N is the number of satellite record
entries transmitted.
𝑁𝑢𝑚𝑏𝑒𝑟 𝑜𝑓 𝑏𝑖𝑡𝑠 𝑖𝑛 𝑅𝑇𝐶𝐴𝑂𝐵𝑆2 𝑚𝑒𝑠𝑠𝑎𝑔𝑒 = 128 + (108 × 𝑁)
𝑁 = 𝑁𝑢𝑚𝑏𝑒𝑟 𝑜𝑓 𝑠𝑎𝑡𝑒𝑙𝑙𝑖𝑡𝑒𝑠 = 17
𝟏𝟐𝟖 +
(
𝟏𝟎𝟖 × 𝟏𝟕
)
= 𝟏𝟗𝟔𝟒 𝒃𝒊𝒕𝒔 𝒕𝒐𝒕𝒂𝒍
𝟏𝟗𝟔𝟒 𝒃𝒊𝒕𝒔 ÷ 𝟖 = 𝟐𝟒𝟔 𝒃𝒚𝒕𝒆𝒔
The RTCAREF log has a fixed length of 192 bits, or 24 bytes. To determine the baud rate required, we
will consider the case when both an RTCAOBS2 and an RTCAREF message are sent during the same
second, as will occur once every 10 seconds.
𝑆𝑖𝑧𝑒 𝑜𝑓 𝑅𝑇𝐶𝐴𝑂𝐵𝑆2 = 246 𝑏𝑦𝑡𝑒𝑠
𝑆𝑖𝑧𝑒 𝑜𝑓 𝑅𝑇𝐶𝐴𝑅𝐸𝐹 = 24 𝑏𝑦𝑡𝑒𝑠
246 + 24 = 270 𝑏𝑦𝑡𝑒𝑠 𝑡𝑜𝑡𝑎𝑙
𝟐𝟕𝟎 𝒃𝒚𝒕𝒆𝒔 × 𝟏𝟎 𝒃𝒊𝒕𝒔 𝒕𝒓𝒂𝒏𝒔𝒎𝒊𝒕𝒕𝒆𝒅 𝒑𝒆𝒓 𝒃𝒚𝒕𝒆 = 𝟐𝟕𝟎𝟎 𝒃𝒑𝒔
Page | 7 July 2, 2014
In this example the default serial port baud rate of 9600 bps will be sufficient to transfer the required
RTCA messages. It is recommended, however, that a baud rate of at least 19200 bps is used for basic
RTK applications. Common RTK radios will typically support baud rates up to 19200 bps.
3.2 Storage of Data at a Remote Station
For many applications, it is not necessary to analyze or display data from a receiver in real time. Instead, data can
be collected from the receiver and stored for post-processing later on. It is important to determine how much data is
required from the receiver, and over what length of time, to best select the type and size of memory card or data
logging device to use for storing the collected data.
As an example, a surveyor may require very high precision for a particular survey but environmental factors such as
remote location, terrain, or even cellular coverage may prevent the use of a radio or cellular data link that is
commonly used for RTK. In a situation like this, a real-time base and rover setup is not practical so post-processing
software, such as Waypoint, can be used.
If data collection is required purely for post-processing, the receiver can be setup and configured at a remote
location to log data to a memory card or storage device. The user can then return to the receiver and retrieve the
collected data at a later time.
Question: For a 24-hour survey, what size of memory card is required to store the logs necessary for
post-processing with Waypoint’s GrafNav software? Data will be collected using an OEMV-3 receiver
that is tracking GPS and Glonass on dual frequencies.
Answer: To satisfy the requirements for GrafNav post-processing, the following logs will be collected
from the receiver:
RANGECMPB (1 Hz)
RAWEPHEMB
BESTPOSB (1 Hz)
IONUTCB
GLOEPHEMERISB
GLOCLOCKB
Many of the logs in the list above, such as RAWEPHEMB and GLOEPHEMERISB, are asynchronous and
will only be collected when new information is downloaded from a satellite. These logs can be
requested using the “ONCHANGED” or “ONNEW” trigger. The ephemeris logs can be expected to be
output approximately once every two hours for each satellite. Since the number of these logs that will
be output depends on the number of satellites tracked throughout the entire data collection, it is
difficult to determine the exact number of logs, and therefore size of data, that will be saved to file. It is
possible, however, to estimate the expected file size based on a sample 24 hr dataset.
For this example, a 24-hour dataset was collected from a ProPak-V3 receiver that was tracking dual
frequency GPS and GLONASS. The “ONCHANGED” trigger was used for all asynchronous logs. The
resulting data file had the following characteristics:
Log Summary
Page | 8 July 2, 2014
Number of Logs
Name of Message
86400
BESTPOSB
23
IONUTCB
86400
RANGECMPB
205
RAWEPHEMB
18
GLOCLOCKB
425
GLOEPHEMERISB
173471 logs total, 84485788 bytes
Based on the size of the example dataset shown above, 80.5 MB, it is possible to estimate the amount of data that
will be stored over other lengths of time. As an example, if data collection was 12 hours instead of 24, the expected
file size is about 40 MB.
For DL-V3 receivers, commonly used for remote stations, the typical size of CF card that is used for storing data is 2
GB. When collecting data that contains the same list of logs as above, about 24 days worth of data can be collected
before the CF card will be full.
4 Contact Information
If you require further information regarding the topics covered in this application note, please contact:
NovAtel Customer Service
1120 – 68 Ave. N.E.
Calgary, Alberta, Canada, T2E 8S5
Phone: 1-800-NOVATEL (in Canada or the U.S.) or +1-403-295-4500
Fax: 403-295-4501
E-mail: support@novatel.ca
Website: www.novatel.com
Page | 9 July 2, 2014
