This application note provides an overview of the requirements associated with data transfer and storage.
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.
The total amount of data that will be transferred or stored can be determined using the following information:
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:
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
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:
The above items are important to note when using ASCII logs. Below is an example of an ASCII-formatted BESTVELA log:
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.
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:
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.
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:
The total BESTVEL log size, after totaling the fifth column in the table above, is therefore:
3 𝑠𝑦𝑛𝑐 𝑏𝑦𝑡𝑒𝑠 + 25 𝑏𝑦𝑡𝑒 ℎ𝑒𝑎𝑑𝑒𝑟 + 44 𝑏𝑦𝑡𝑒𝑠 (𝑓𝑖𝑒𝑙𝑑𝑠 2 𝑡𝑜 9) + 4 𝑏𝑦𝑡𝑒 𝐶𝑅𝐶 = 76 𝑏𝑦𝑡𝑒𝑠 𝑡𝑜𝑡𝑎𝑙
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:
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.
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.
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.
There are two main factors involved with determining throughput:
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.
This must be taken into account when determining 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.
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.
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.
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.
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 data link must support a baud rate high enough to transmit the required correction data. 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 𝑏𝑦𝑡𝑒𝑠 𝑡𝑜𝑡𝑎𝑙
𝟐𝟕𝟎 𝒃𝒚𝒕𝒆𝒔 × 𝟏𝟎 𝒃𝒊𝒕𝒔 𝒕𝒓𝒂𝒏𝒔𝒎𝒊𝒕𝒕𝒆𝒅 𝒑𝒆𝒓 𝒃𝒚𝒕𝒆 = 𝟐𝟕𝟎𝟎 𝒃𝒑𝒔
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.
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.
Instead, data can be collected from the receiver and stored for post-processing later on.
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:
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.