This is a community-wide initiative but the GitHub project and initial thoughts and ideas were created on GitHub by Michael George (K888). This is by no means the finished article. It is simply the product of a few hours work and is something of an in-depth brain dump.
After a number of questions and responses, I’ve written an additional document to provide insights into a number of key design decisions. I’ve referred to them as the “minutiae” but they have informed almost every decision. That’s not to say that the document below doesn’t contain any oversights!
All feedback is welcome. Feel free to contact me via Seabreeze (or e-mail if you have it) and I will get back to you when time allows.
A number of items will be required in the file header. These could include the following:
I have no doubt that other fields will be required and they can be added over time in a non-breaking manner.
A header frame definition should be implemented (not documented yet) so that smaller headers can be used, when desired. This would work in a similar way to the GNSS Frame definition below, referring to a published dictionary of valid data items. The header items that should be regarded as essential for ensuring forwards-compatibility are highlighted in bold. Endian can potentially have a default value (need to check if SiRF and u-blox are the same) and compression could have a default of zero. This leaves 4 absolutely essential header items to ensure forward + backward compatibility - frame identifier / size (2 bytes), checksum (2 bytes), version (4 bytes) and epoch (8 bytes) which total just 16 bytes.
If GNSS chipset manufacturer and GNSS chipset model are known (totaling 4 bytes) they should also be included so that fields such as SDOP and sAcc can be handled accordingly. This makes a minimal header containing only essential items a mere 20 bytes.
Results summaries have yet to be discussed in this document - e.g. best 2s, 10s, 500m, etc.
GNSS frame definitions will detail the content of the GNSS frames:
It should be noted that optimal byte alignment is retained for these frames because every item specification is exactly 4 bytes.
Multiple frame types can be included in a file using the open GNSS format (e.g. corresponding to NMEA sentence types). The numerical GNSS frame identifiers will be implicit within the file, simply based on the order of frame definitions.
This section illustrates how minimal SiRF and u-blox GNSS frames might be implemented. Summary:
It’s worth noting that byte offsets / alignments have been chosen to suit the underlying data types (e.g. 4 byte data types are aligned with 4-byte boundaries). Failure to align data types properly can lead to sub-optimal processing, depending on the CPU architecture.
| Offset | Type | Scaling | Name | Units | Description |
|---|---|---|---|---|---|
| 0 | u2 | - | id | - | Frame identifier and size |
| 2 | u2 | - | cksum | - | Checksum |
| 4 | u4 | 1 x 10-3 | ts | s | Timestamp - ms relative to the epoch |
| 8 | u4 | 1 x 10-7 | lat | deg | Latitude |
| 12 | u4 | 1 x 10-7 | lon | deg | Longitude |
| 16 | u2 | 1 x 10-2 | cog | deg | Course Over Ground |
| 18 | u2 | 1 x 10-2 | sog | m/s | Speed Over Ground |
| 20 | u1 | 1 x 10-2 | sdop | m/s | Speed Dilution of Precision |
| 21 | u1 | 2 x 10-1 | hdop | - | HDOP |
| 22 | u1 | - | sat | - | Number of SVs |
TOTAL = 23 bytes
Notes:
| Offset | Type | Scaling | Name | Units | Description |
|---|---|---|---|---|---|
| 0 | u2 | - | id | - | Frame identifier and size |
| 2 | u2 | - | cksum | - | Checksum |
| 4 | u4 | 1 x 10-3 | ts | s | Timestamp - ms relative to the epoch |
| 8 | u4 | 1 x 10-7 | lat | deg | Latitude |
| 12 | u4 | 1 x 10-7 | lon | deg | Longitude |
| 16 | u4 | 1 x 10-3 | cog | deg | Course Over Ground |
| 20 | u4 | 1 x 10-3 | sog | m/s | Speed Over Ground |
| 24 | u4 | 1 x 10-3 | sacc | m/s | Speed accuracy |
| 28 | u2 | 2 x 10-2 | hdop | - | HDOP |
| 30 | u1 | - | sat | - | Number of SVs |
TOTAL = 31 bytes
Notes:
Detailed GNSS frames can by exact copies of the binary payloads output by SiRF and u-blox chipsets.
The frame identifier and checksum are 4 bytes in total so the byte-alignment of SiRF / u-blox payloads will remain unchanged.
| Offset | Type | Scaling | Name | Units | Description |
|---|---|---|---|---|---|
| 0 | u2 | - | id | - | Frame identifier and size |
| 2 | u2 | - | cksum | - | Checksum |
| 4 | … | … | … | … | … |
Custom GNSS frames can be logged for development purposes and detailed analysis, simply adding data items to the minimal content.
Examples of more “unusual” data items which are not currently used for speed sailing:
Since additional fields are just a change to the GNSS frame definition, software reading the file can easily ignore “unusual” data items whilst parsing the data.
Frame identifiers can specify the frame type and frame size, packed into 2 bytes.
It should be noted that any given frame type will always have the same first 2 bytes (identifer + size):
File readers may wish to utilise the frame identifier and frame size to skip past frames that are of no interest / unsupported. This can be even be done without interpreting the detailed field specifications in the GNSS frame definition(s).
A simple checksum algorithm is desired with minimal processing overhead, yet effective error detection:
Fletcher’s checksum is well suited because of it’s simple implementation and low computational overheads.
This algorithm has the added benefit that existing C / Java / Python code used by UBX and OAO readers can be re-used.
The minimal GNS frame examples take the opportunity to save space by using 4 byte timestamps:
The first option isn’t particularly viable because existing SBP files can contain vast date ranges and therefore could not be converted to the open format.
The second option is suited to devices that are either likely to record continuously for in excess of 48 days, or software that converts SBP files to the open format. It would be very easy to implement in both the file writers and file readers.
In theory, consumer GPS units are limited to 1000 knots which is approximately 514.44 m/s.
FIT files store latitude and longitude in semicircles This is actually relatively pointless because standard precision GNSS chipsets output latitude and longitude as 4 byte integers with a scaling of 1 x 10-7. Converting the native output of the GNSS chip from degrees to semicircles may use the full 32-bit range but it does not add any precision!
Since semicircles are what are recorded in FIT files they should be perfectly preserved within the open format, using the dedicated semicircles data type.
High precision logging devices such as the u-blox NEO-M8P and ZED-F9P add the following items to record higher precision:
If a high precision device wishes to log data in the open format they simply need to specify these fields in the GNSS frame definition.
The SiRF files use 0xff in SDOP and VSDOP (aka SDOS and VSDOS) to indicate that value is unknown.
Some consideration needs to be given to these special cases so they are not confused with genuine values.
It is also worth mentioning that SDOP and sAcc are similar but subtly different. The header allows them to be distinguished using the GNSS chipset.