NavSpark

Decoding GNSS Streams Made Simple (5/29/2026)

Cross-Platform GNSS Console Tool gnss_tool (5/29/2026)

Windows & Linux Board Manager Support (7/15/2015)

I2C Improvement (7/15/2015)

GNSS Radar (6/20/2015)

NS-RAW Firmware Update (1/17/2015)

SUP800F User Data R/W Support and the Internal Data Logging 1MByte SPI Flash (11/8/2014)

SD Card Library for Adapter Board (6/17/2014)

NS-RAW Firmware Update with SD-Card Logging Feature (5/24/2014)

Decoding GNSS Streams Made Simple

Posted by Alex Lin on 5/29/2026

If you've ever tried to debug a GNSS receiver, you know the pain. The serial port spits out a noisy mixture of protocols — SkyTraq Binary frames here, NMEA sentences there, RTCM 3 correction messages interleaved in between — and most off-the-shelf tools can only handle one format at a time. You end up bouncing between three different decoders, or worse, writing your own from scratch.

We built skytraq-parser-api to fix that. It's a single open-source command-line tool that parses NMEA 0183, RTCM 3.3, and SkyTraq Binary Raw Measurement messages — all from the same stream, in real time, with checksum verification and colour-coded output. The source code is available on GitHub under the MIT licence:

github.com/SkyTraqGit/skytraq-parser-api

---

What it decodes

The parser auto-syncs on three protocol headers simultaneously — 0xA0 0xA1 for SkyTraq Binary, 0xD3 for RTCM 3, and $ / ! for NMEA — so you can feed it any captured log or live serial stream without telling it what to expect.

NMEA 0183 (and SkyTraq $PSTI)

Standard sentences — GGA, GLL, GSA, GSV, RMC, VTG, ZDA, THS, HDT — are all decoded with field-by-field interpretation. On top of that, the parser handles SkyTraq's proprietary $PSTI family, which is where the interesting RTK and security data lives:

• PSTI 030 — Recommended Minimum 3D GNSS data with RTK status and ENU velocity
• PSTI 032 / PSTI 035 — RTK baseline data (static and moving-base rover)
• PSTI 033 — RTK raw measurement monitoring (cycle slips)
• PSTI 013 — OSNMA status (Galileo authentication)
• PSTI 015 — AJAS general status (anti-jam / anti-spoof), with yellow warnings on spoofing detection
• PSTI 005, 012 — event-triggered timestamps and authenticated ephemeris

RTCM 3.3

If you're working with base stations, NTRIP casters, or RTK correction streams, the parser covers the full set of message types you actually see in the wild:

• Station / antenna metadata — 1005, 1033
• Ephemerides — 1019 (GPS), 1020 (GLONASS), 1041 (NavIC), 1042 (BeiDou), 1046 (Galileo)
• Code-phase biases — 1230 (GLONASS L1/L2)
• MSM4 / MSM7 observations for every constellation — GPS (1074/1077), GLONASS (1084/1087), Galileo (1094/1097), SBAS (1104/1107), QZSS (1114/1117), BeiDou (1124/1127), NavIC (1134/1137)

Each frame's CRC-24Q is verified, and mismatches are flagged in red so you can spot link errors instantly.

SkyTraq Binary — Raw Measurements (AN0039)

This is what sets the tool apart from generic GNSS parsers. The full AN0039 Raw Measurement Data Extension is supported, which means you can decode the low-level outputs that PVT-only tools throw away:

ID	Message
0xB1	GPS Ephemeris Data
0xDC	Measurement Time
0xDD	Raw Measurements (pseudorange, carrier phase, Doppler, CN0)
0xDE	SV and Channel Status
0xDF	Navigation State
0xE0	GPS Subframe Data
0xE1	GLONASS String
0xE2 / 0xE3	BeiDou2 D1 / D2 Subframe
0xE5	Extended Raw Measurement v1
0xE6	General Subframe Data
0xE7	GNSS SV and Channel Status
0xE8	GNSS SV Elevation / Azimuth
0xE9	Time Stamp Message

If you're building a PPP engine, validating an RTK fix, training an interference detector, or just curious what your receiver is actually measuring, these are the messages you want.

---

Getting started

The tool is cross-platform — Linux and Windows (via MSYS2 UCRT64) — and depends only on a C compiler and make.

Build on Linux

git clone https://github.com/SkyTraqGit/skytraq-parser-api.git
cd skytraq-parser-api
make

Build on Windows (MSYS2 UCRT64)

pacman -S --needed make mingw-w64-ucrt-x86_64-gcc
git clone https://github.com/SkyTraqGit/skytraq-parser-api.git
cd skytraq-parser-api
make

If you'd rather skip the build, every push triggers GitHub Actions to produce Linux and Windows binaries — grab them from the Actions tab.

---

Using it

The CLI is deliberately small. There are really only two modes: read from a file, or read from a serial port.

gnss_parser [OPTIONS]

  -h               Show help.
  -i <filename>    Read from a file instead of a serial port.
  -p <port>        Serial port (e.g. COM3 or /dev/ttyUSB0).
  -b <baudrate>    Baud rate (default: 115200).
  -a               ASCII-only output (for legacy terminals).

Parse a captured log

gnss_parser -i mylog.bin

Live capture from a SkyTraq receiver

On Linux:

gnss_parser -p /dev/ttyUSB0 -b 115200

On Windows:

gnss_parser -p COM3 -b 115200

The output is colour-coded so you can read a mixed stream at a glance:

Colour	Meaning
Cyan	SkyTraq Binary message
Green	NMEA / $PSTI sentence
Magenta	RTCM 3 message
White	Plain ASCII pass-through
Red	Checksum / CRC error
Yellow	Security warning (PSTI 015 spoofing)

---

Why we open-sourced it

GNSS protocol documentation is dense, the bit-packing is unforgiving, and most engineers reinvent the same decoder every time they start a new project. Releasing this tool under MIT means you can drop it straight into your debugging workflow, fork the decoders into your own application, or use the source as a reference when you're reading the RTCM 10403.3 standard at 2 AM and the bit-fields stop making sense.

The code is organised so each protocol lives in its own file (skytraq.c, nmea.c, rtcm3.c) with a shared BitReader API in util.c — easy to lift out a single decoder if that's all you need.

Pull requests are welcome. If you decode a new message type, add a quick test frame in the PR description and we'll merge it.

---

Get it

• Source: github.com/SkyTraqGit/skytraq-parser-api
• Pre-built binaries: GitHub Actions artifacts
• Licence: MIT

Whether you're integrating a SkyTraq receiver, troubleshooting an RTK setup, or just want a clean way to inspect what's coming out of a GNSS module's UART, give it a try — and let us know what you'd like to see decoded next.

Cross-Platform GNSS Console Tool gnss_tool

Posted by Alex Lin on 5/29/2026

If you have ever tried to test a setting on a SkyTraq module by flipping through AN0037, looking up the Message ID, looking up the field order, looking up the byte order, hand-calculating the checksum in a hex editor, and then typing 22 bytes one at a time into a serial terminal — this article is for you.

We are open-sourcing a lightweight command-line tool, gnss_tool, on GitHub. It wraps roughly 50 of the most commonly used messages from AN0037 v1.4.69 so you can configure parameters in plain values. The tool takes care of encoding, checksum, and response parsing for you.

---

Why this tool?

AN0037 is the SkyTraq receiver binary-protocol document. It covers everything from firmware version queries, position update rate, NMEA Talker ID, SBAS/QZSS, all the way to the 0x64 sub-ID family of control messages. The document itself is thorough — but to actually send one message you need to:

1. Look up the right Message ID and field definitions in the document
2. Know how many bytes each field is, and whether it is big- or little-endian
3. Hand-assemble the packet: 0xA0 0xA1 (start) + payload length + payload + checksum + 0x0D 0x0A (end)
4. Compute the checksum with XOR
5. Send it over the serial port
6. Parse the response — was it ACK (0x83)? NACK (0x84)? A query response?

For someone who only does this occasionally, looking up the document alone easily takes 10 minutes. gnss_tool removes that entire workflow: you only write the field values in the command line; the tool handles the rest.

It is also cross-platform — the same source builds with a single make on both Linux and Windows MSYS2 UCRT64.

---

Feature overview

The tool supports seven command-line options:

Option	Purpose
-h MessageID	Show the field definitions for a message (offline, no port needed)
-c MessageID Field2 Field3 ...	Send a Set / Configure command; report ACK / NACK / Timeout
-q MessageID Field2 Field3 ...	Send a Query command; auto-decode every field of the response
-o filename	Save the raw response frame from a query to a file
-i filename	Batch-execute commands from a script file
-p port	Specify the serial port (/dev/ttyUSB0, COM28, etc.)
-b baudrate	Specify baud rate; default 115200; arbitrary values supported
-t timeout	Response wait time; default 3000 ms

Numeric arguments accept three forms and can be mixed:

• Decimal: 123
• Hex, C-style: 0x7B
• Hex, suffix: 7Bh

Messages with a Sub-ID use the ID/SubID form, for example 100/23, 0x64/0x17, or 64h/17h.

---

Build and install

Linux

git clone https://github.com/SkyTraqGit/skytraq-cmd-api.git
cd skytraq-cmd-api
make

Standard glibc is all you need. Arbitrary baud rates on Linux are supported via the termios2 / BOTHER ioctl.

Windows (MSYS2 UCRT64)

From an MSYS2 UCRT64 shell:

pacman -S --needed mingw-w64-ucrt-x86_64-gcc make
git clone https://github.com/SkyTraqGit/skytraq-cmd-api.git
cd skytraq-cmd-api
make

This produces gnss_tool.exe, which can be run from a regular Windows command prompt. For a fully static, redistributable .exe, add LDFLAGS="-static":

make LDFLAGS="-static"

If you just want the binary without building from source, grab gnss_tool-v1.0.0-linux-x86_64.tar.gz or gnss_tool-v1.0.0-windows-x86_64.zip from the repo's Releases page.

---

Four operating modes in practice

The examples below assume the module is on /dev/ttyUSB0 (Linux) or COM28 (Windows) at 115200 baud.

Mode 1 — Look up a field table (-h)

No port required; this is just a reference lookup. For example, to see what fields message 0x09 (Configure Position Update Rate) takes:

$ ./gnss_tool -h 0x09
Message 0x09 — Configure Position Update Rate
  Field 1: Message ID            (1 byte)   = 0x09 (auto)
  Field 2: Rate                  (1 byte)   Hz, 1/2/4/5/8/10/20/25/40/50
  Field 3: Attributes            (1 byte)   0=Update to SRAM, 1=Update to SRAM+FLASH

This maps directly to the field table in §5.20 of AN0037. Running it before you connect is a handy sanity check on what values you need to supply.

Mode 2 — Set / Configure (-c)

Set the position update rate to 10 Hz and write to flash so the setting survives a power cycle:

$ ./gnss_tool -p /dev/ttyUSB0 -c 0x09 10 1
Opened /dev/ttyUSB0 @ 115200 baud  (timeout 3000 ms)
Sent: A0 A1 00 03 09 0A 01 02 0D 0A
Response: ACK (Message ID = 0x09)

Notice that the command line only contains 10 1 — that is, Field 2 (Rate=10) and Field 3 (Attributes=1, Update to SRAM+FLASH) from the AN0037 table. Field 1 (the Message ID itself) is added automatically, and the checksum 0x02 is computed for you.

If the firmware refuses the setting (for example, the receiver does not support 10 Hz), the response is NACK:

Response: NACK (Message ID = 0x09)

If the module does not respond at all (cable loose, wrong baud rate, no power), you will see Timeout.

Mode 3 — Query (-q)

Query the firmware software version (Message 0x02, Sub-Type 1 = software version):

$ ./gnss_tool -p /dev/ttyUSB0 -q 0x02 1
Sent: A0 A1 00 02 02 01 03 0D 0A
Response: ACK + Software Version (Message ID = 0x80)
  Software Type     : 1 (System)
  Kernel Version    : 0.0.50
  ODM Version       : 0.5.115
  Revision          : 14.10.22

The tool decodes each byte of the 0x80 response according to the AN0037 field table and prints it in human-readable form.

Mode 4 — Batch script (-i)

Create an init.txt like this:

# Position rate 10 Hz, save to flash
-c 0x09 10 1

# Set NMEA Talker ID to GNSS (Field 2 = 2)
-c 0x4B 2 1

# Query the result
-q 0x02 1

Then run:

./gnss_tool -p /dev/ttyUSB0 -i init.txt

The tool executes each line in order (lines starting with # are comments; blank lines are skipped). This is well suited to production-line initialization, batch configuration, or regression testing.

---

Validating against AN0037

Does the tool produce correct packets? You can cross-check against the System Restart example on page 5 of AN0037. The byte sequence shown there is:

A0 A1 00 0F 01 01 07 D8 0B 0E 08 2E 03 09 C4 30 70 00 64 16 0D 0A

Sending the same command with gnss_tool (2008-11-14 08:46:03, lat=2500, lon=12400, alt=100):

$ ./gnss_tool -p /dev/ttyUSB0 -c 0x01 1 2008 11 14 8 46 3 2500 12400 100 2
Sent: A0 A1 00 0F 01 01 07 D8 0B 0E 08 2E 03 09 C4 30 70 00 64 16 0D 0A

Every byte matches, including the checksum 0x16.

---

Test without hardware — fake_gnss.py

The repo ships with a PTY-based receiver simulator written in Python, fake_gnss.py (Linux / macOS only). It creates a pair of virtual serial ports — gnss_tool connects to one end, and the script simulates ACK / NACK / query responses on the other. This lets you exercise the full CLI without a physical module.

# Terminal 1
python3 fake_gnss.py
# prints: /dev/pts/3

# Terminal 2
./gnss_tool -p /dev/pts/3 -q 0x02 1

There is also a run_tests.sh driver that runs 13 regression tests, covering every CLI mode end-to-end against the simulator.

---

Message database — ~50 known, others sent as raw bytes

The built-in message database covers:

• System control (0x01 System Restart, 0x02 Query Software Version, 0x03 Query CRC, ...)
• Serial / output configuration (0x05, 0x09 update rate, 0x0E, 0x4B NMEA Talker ID, ...)
• Power mode, DOP / CNR mask, position pinning
• SBAS / QZSS / SAEE
• The 0x64 sub-ID family (boot status, navigation mode, GPS time, datum, version extension)
• The 0x62 sub-ID family (including 0x62/0x05 with optional SouthPAN support)
• ACK / NACK

Messages outside this set can still be sent with -c / -q as raw bytes; the response is dumped in hex rather than decoded. To add proper decoding for a new message, you just add one entry in messages.c following the same pattern as the existing ones.

---

License

The project is released under the MIT License, Copyright © 2026 SkyTraq Technology, Inc. You are free to integrate it into commercial products or internal tools, as long as the copyright notice is preserved.

---

Wrap-up

The goal of this tool is to turn "send a command to the GNSS module" from a 10-minute job of doc-lookup + byte-counting + checksum-math into a single shell command. If you are working on SkyTraq module development, integration testing, or production-line configuration — or simply want to verify the examples in the document — clone it from GitHub and try it out.

Issues, pull requests, and corner-case reports are all welcome.

Windows & Linux Board Manager Support

Posted by Jason Lin on 7/15/2015

I2C Improvement

Posted by Oliver Huang on 7/15/2015

GNSS Radar

Posted by Oliver Huang on 6/20/2015

NS-RAW Firmware Update

Posted by Oliver Huang on 1/17/2015

SUP800F User Data R/W Support and the Internal Data Logging 1MByte SPI Flash

Posted by Jason Lin on 11/8/2014

SD Card Library for Adapter Board

Posted by Jason Lin on 6/17/2014

NS-RAW Firmware Update with SD-Card Logging Feature

Posted by Oliver Huang on 5/24/2014