DEV Community: UAV GNSS

mosaic-X5 vs u-blox F9P for ArduPilot: what you actually get for the extra cost

UAV GNSS — Mon, 05 Oct 2026 01:32:51 +0000

We're UAV GNSS, a Septentrio receiver maker — we build HB-series receivers around Septentrio silicon. "Is a mosaic-X5 worth it over an F9P?" is the comparison ArduPilot builders bring to us most often, so here's an honest breakdown, including the cases where the F9P is the right answer.

Where they're the same

Both are multi-band (L1/L2) GNSS receivers that produce RTK-fixed centimetre positions. Both speak standard interfaces: NMEA out for position, RTCM v3 in for corrections, and a raw-log protocol you can record and post-process (UBX on u-blox, SBF on Septentrio). ArduPilot supports both natively.

For a low-dynamics airframe with a clean sky view and a healthy NTRIP link, an F9P does the job at a fraction of the cost. That is not a knock on it — it's the correct answer for a large share of builds.

Where they actually differ

Axis	u-blox ZED-F9P class	Septentrio mosaic-X5 class
Native navigation rate	~10–20 Hz	up to 100 Hz
In-band interference suppression	~25 dB class, usually unpublished	AIM+ ≈ 40–60 dB
Multipath mitigation	basic	APME+
Dual-antenna GNSS heading	no (single antenna)	yes (mosaic-H / mosaic-G5 P3H class)
Navigation-message authentication	none	OSNMA-ready (Galileo)
Free cm-class corrections, no base	no	Galileo HAS

Update rate, and why "native" matters

F9P-class modules typically publish a navigation solution at 10–20 Hz. mosaic-X5 computes solutions at up to 100 Hz, and each epoch is derived directly from the GNSS measurements instead of being interpolated between them.

For a slow tractor that difference is invisible. For a fast airframe, or for a control loop that wants fresh data every cycle, it's the difference between steering on a current position and steering on an extrapolation. It also changes what your logs look like when you analyse drops — we walk through SBF fix-quality and RTK-drop forensics in this guide.

Interference immunity is where the money actually goes

AIM+ suppresses roughly 40–60 dB of in-band interference. Consumer modules sit in the ~25 dB class and frequently publish no figure at all. Near power lines, electric fences, 4G/5G sites — or anyone deliberately jamming — that gap decides whether you hold RTK fixed or never see it lock.

Symptoms that you are interference-limited rather than correction-limited:

the fix drops to float at the same physical location every pass;
SNR fades on satellites at a specific azimuth rather than a specific elevation;
the receiver loses lock near pylons, electric fences or mobile masts;
correction age stays low and steady while the fix still degrades.

AIM+ runs continuously and needs no configuration. If your build works on a farm, near infrastructure, or anywhere you don't control the RF environment, this is usually the real reason to step up.

Heading without a magnetometer

A single-antenna build has no direct heading — the autopilot fuses GPS velocity and the compass, and the compass is usually the weak link: motor currents, steel frames and fences bend the local field by 5–30°, and a bad heading steers the EKF into the wrong row.

A mosaic receiver with two antenna inputs measures carrier-phase heading across a physical baseline, so it is immune to magnetic interference and doesn't drift. In ArduPilot you wire the second antenna to a second UART and enable a second GPS rather than swapping the receiver.

Interfaces — and one myth worth killing

mosaic-X5 exposes UART (LVTTL, 3.3 V), USB, SPI and I²C. It does not have native CAN or J1939 — and no Septentrio chip does. CAN is a carrier- or box-level feature, driven by the carrier's own processor and transceiver. If you need a machine bus, pick a box that provides it or add a transceiver/gateway; don't buy a bare module expecting native CAN.

Parameter starting points

ArduPilot (GPS_TYPE=9 selects the Septentrio driver):

Parameter	Value	Meaning
`GPS_TYPE`	9	Septentrio (SBF)
`GPS_BAUD_RATE`	9	115200 baud
`GPS_RATE_MS`	100	10 Hz update (lower = faster, if your link supports it)

Keep GPS_AUTO_CONFIG=1 so the receiver is configured on every boot. For dual-antenna heading, enable the second receiver on the secondary port (GPS2_TYPE=9).

PX4:

Parameter	Value	Meaning
`GPS_1_GNSS_ID`	1	Septentrio
`GPS_1_PROTOCOL`	14	Septentrio SBF / NMEA

Where it lands

F9P — low-dynamics, clean RF, budget-sensitive. Correct choice, and we'll say so.
mosaic-X5 — when a dropped fix costs a mission, a pass or a flight: high dynamics, contested RF, or you need heading, navigation-message authentication, or free HAS corrections with no base.

Wiring diagrams, full parameter tables and an SBF log analyzer with RTK-drop forensics are in our integration guide: github.com/uavgnss6-bot/septentrio-gnss-integration-guide. Receiver lineup and AIM+ details: uav-gnss.com/product-category/gnss-receiver/ and uav-gnss.com/aim-resilient-gnss/.

Which failure hurts you more today — losing RTK in a noisy spot, or not having enough update rate? That answer usually decides it.

Ionospheric scintillation: the GNSS failure that arrives after sunset

UAV GNSS — Thu, 24 Sep 2026 03:10:40 +0000

Ionospheric scintillation: the GNSS failure that arrives after sunset

It is 20:40 at a site 15° from the equator — Brazil, Nigeria, India, Singapore, northern Australia all behave the same way. The RTK fix that held 1 cm all afternoon starts wandering. Then it drops to float. Then a couple of satellites disappear entirely. Tomorrow morning everything will be perfect again.

Nothing has changed in the hardware, the corrections or the sky view. What changed is the ionosphere. If your deployments include low-latitude sites, this is one of the few GNSS error sources that is predictable in its rhythm and unpredictable in its timing — and it is worth knowing how it works before it shows up in a customer's log.

The signal path goes through a charged layer

GNSS signals travel roughly 20,000 km to reach the antenna, and for most of that journey there is nothing in the way. The last 1,000 km are the exception. The ionosphere — the charged layer between about 100 km and 1,000 km altitude — refracts and diffracts the signal, which produces both a delay and a distortion.

When the ionised particles are smoothly distributed, a receiver can model their effect on the signal. The trouble starts when the ionosphere becomes irregular: local fluctuations in electron density distort the phase and amplitude of the signal. That is ionospheric scintillation, and it is usually described with two indices:

S4 — the amplitude scintillation index;
σφ (sigma-phi) — the phase scintillation index.

Figure 1 — S4 and σφ through a scintillation event. The usual "strong" thresholds are S4 > 0.6 and σφ > 0.3. Image courtesy of Septentrio.

Where and when scintillation happens

Scintillation events are most frequent and most intense near the geomagnetic equator, with a weaker occurrence at the poles. They are also documented at mid-latitudes — Western Europe and the United States included — so this is not exclusively a tropical problem.

Timing is driven by the sun. Solar activity follows an 11-year cycle measured by sunspot count: around solar maximum, frequent solar flares release bursts of high-energy protons and X-rays that interact with the atmosphere, and scintillation events become more common. On top of the solar cycle there is a strong daily pattern — sunset triggers a sharp increase in ionospheric activity that can last for hours. That daily pattern is why scintillation so often looks like a "the fix degrades in the evening" bug rather than an environmental one.

Figure 2 — Distribution of high-S4 scintillation events: densest in the equatorial band, weaker at mid and high latitudes. Image courtesy of Septentrio.

Figure 3 — S4 recorded by a static PolaRxS receiver in Brazil (22°S) over 24 hours: activity climbs after sunset and stays elevated for hours. Image courtesy of Septentrio.

What it does to a GNSS solution

For a standard GNSS receiver the failure escalates in stages:

Scintillation severity	What the receiver does
Mild	Position accuracy degrades by several metres
Stronger	Cycle slips — the carrier-phase measurement jumps, and RTK has to recover ambiguity
Extreme	Complete loss of signal lock; even ordinary radio communication is disturbed in the same window

Because the corruption is in the signal itself, not in the satellite geometry, adding constellations does not fix it — the affected measurements have to be identified and excluded, or handled with a receiver that is designed for it.

How IONO+ handles it

Septentrio developed IONO+ as a direct result of working on projects in Brazil, one of the countries most affected by scintillation. Receivers with IONO+ keep tracking satellites under conditions that disrupt a standard receiver, and they identify scintillation events so their effect on position accuracy can be limited. In the static test below, the algorithm correctly identified the scintillation-affected signals and removed them from the position computation.

Figure 4 — Height computed by a static PolaRxS receiver during scintillation: standard positioning (blue) versus scintillation-improved positioning (green). Image courtesy of Septentrio.

The second half of the design is about baseline logistics. With standard RTK you normally need a reference station network to interpolate the ionospheric delay and compensate for it at the rover. With IONO+ the ionospheric delay is estimated inside the receiver, so no network is required: a single reference station at a baseline of up to 40 km is enough, and up to 80 km while the ionosphere is quiet. For integrators working in equatorial regions, that is often the difference between "RTK needs a dense CORS network we do not have" and "one base station on the site".

Practical checklist for low-latitude deployments

Log the evidence, not just the symptom. Record C/N0 per band and the receiver's interference/scintillation indicators alongside the position log. A dusk-onset pattern is the signature.
Test at the right hour. A site that passes commissioning at 14:00 may fail at 20:00. Plan an evening test during solar maximum.
Check the correction architecture. If the site relies on network RTK interpolation, confirm what happens when the ionosphere is disturbed — this is where a receiver-side estimate changes the requirement.
Expect cycle slips, not just accuracy loss. Design the recovery path: how fast does your RTK engine re-converge, and what does the autopilot or controller do in the meantime?
Pick receivers on capability, not constellation count. Multi-frequency tracking, robust tracking loops and scintillation handling matter more at these latitudes than one extra constellation.

Hardware that ships with this capability

IONO+ is receiver behaviour, not a service. It is part of the Septentrio feature set on the modules and receivers used in drones, robotics and reference stations:

Septentrio mosaic-X5 module — multi-frequency, all-constellation core for integrators that need raw observables;
HBEV322 / HBEV322H compact RTK GNSS receiver — mosaic-G5 P3H with dual-antenna heading;
HB52H / HB52 ultralight RTK module — few-gram mosaic-G5 for mass-limited platforms;
HB10 dual-antenna RTK receiver — AsteRx-m3 Pro+ where attitude is needed as well as position;
HB62 rugged GNSS reference station — a turnkey base for a shared correction source, including the 40–80 km baseline cases above.

If you want to work out whether scintillation is what you are seeing, the practical next step is a log review: send us a capture with the C/N0 and position stream and we will read it with you — request a quote or get in touch.

Sources: Septentrio technical note on ionospheric scintillation and IONO+; S4 observations from V. V. Sreeja et al., J. Space Weather Space Clim. 1 (2011); CIGALA project data (Brazil); Septentrio product documentation.

Debugging RTK GNSS integration: ports, baud rates and protocol direction (ArduPilot / PX4)

UAV GNSS — Mon, 21 Sep 2026 01:34:14 +0000

We build Septentrio-powered GNSS receivers at UAV GNSS — so the message "I wired it up, the port is open, and the autopilot still says no fix" is the one we get most often. In our experience it is almost never the receiver. It is a port, baud, or protocol-direction mismatch, and all three look identical from the outside.

Here is the checklist we walk integrators through, plus a small script that tells you which of those failure modes you are actually in instead of guessing.

1. Count the serial ports before you plan the build

The port count is a property of the receiver, not of the connector you plug in. Counted from the official interface maps:

Receiver	GNSS engine	Serial ports	Other links
HB10	AsteRx-m3 Pro+	3x UART (LVTTL, 115200 bps - 4 Mbps)	USB-C, microSD, 1PPS out, EVENT in
HB59	AsteRx-m3 Pro+	3x UART (LVTTL)	100M Ethernet, USB-C, microSD, 1PPS, EVENT
HB6 / HB6 Pro	mosaic-X5	2x UART	USB (4G on Pro)
EV322 / HB51 / HB52	mosaic-G5	2x UART (TTL) + I2C	PPS, EVENT
HB3 (machine-control box)	AsteRx-m3 Pro+	SER M12	CAN (PWR) M12 x2, Ethernet M12, 4G LTE, UHF, WiFi/BT

Two things worth internalising immediately:

These UARTs are LVTTL (3.3 V logic) at the module. They are not RS-232, RS-422 or RS-485. Feeding a true RS-232 source straight in will not work and can damage the port — use the matching level shifter on the carrier board, or an external transceiver if you genuinely need RS-232.

There is no native CAN/J1939 on the GNSS chip. CAN exists at product level (the HB3 above); on modules it is an external gateway/transceiver job. If a datasheet skim told you otherwise, you were reading the box, not the chip.

2. One port per job — the three-stream rule

Serial links usually fail because two logical jobs were pushed onto one port. Budget a port per job:

Port	Job	Protocol	Typical rate
UART 1	Autopilot position/status	NMEA 0183 out	5-10 Hz
UART 2	Corrections in (+ optional NMEA mirror out)	RTCM v3 / CMR in	as broadcast
UART 3 (HB10/HB59)	Raw logging, ROS driver, radio	SBF out	1 Hz, up to 100 Hz bursts

At absolute minimum, keep corrections on their own port. On a single-port build you have to multiplex RTCM input and NMEA output on the same UART — and a misconfiguration there looks exactly like a dead correction source, so you will spend an afternoon replacing cables for a config problem.

Dual-port wiring example:

Septentrio receiver                Flight controller (Pixhawk class)
-------------------                ---------------------------------
UART1 TX  ---------------------->  GPS1 RX
UART1 RX  <----------------------  GPS1 TX
GND       -----------------------  GND
5V        -----------------------  5V (dedicated UART 5V, not the servo rail)

Septentrio receiver                NTRIP / telemetry link
-------------------                ----------------------
UART2 RX  <--- RTCM v3 corrections ---  radio or companion TX
UART2 TX  --- NMEA mirror (opt.)  --->  radio or companion RX

3. Baud rate: match exactly, and know the headroom

115200 bps is the safe default, and what the parameter tables below assume (GPS_BAUD_RATE=9 on ArduPilot, GPS_1_BAUD=115200 on PX4).
AsteRx-m3 Pro+ UARTs on HB10/HB59 support up to 4 Mbps. That headroom exists for raw multi-constellation SBF logging — full-band data will not fit in 115200.
Change baud on one side at a time and re-verify. Changing both ends blind is how two working ports become one broken link.
A baud mismatch typically shows as garbage or framing errors rather than a clean "no data" — which is exactly why it gets misdiagnosed as a dead receiver.

4. Protocol direction — the silent failure

This is the one that catches experienced people:

Protocol	Direction	Carries	Goes to
NMEA 0183	receiver -> autopilot	GGA/RMC position + status	GPS port
SBF	receiver -> logger/computer	PVTGeodetic, AttEuler, observables	SD card, ROS driver, post-processing
RTCM v2/v3	base -> rover (IN)	corrections	rover's correction port
CMR v2.0 / CMR+	base -> rover (IN)	corrections	rover's correction port

NMEA and SBF are outputs you enable. RTCM/CMR is an input the rover must be told to accept. A receiver happily streaming perfect NMEA while ignoring its RTCM input will sit in Single forever with a healthy-looking data link — no error, no warning, nothing in a log to point at.

5. A script that names the fault

Guessing is what costs the afternoon, so here is a small checker. It reads the port for a few seconds and classifies what it sees: no bytes at all, bytes but nothing valid, binary SBF only, or NMEA with fix type, satellite count and age of differential corrections parsed straight out of GGA (fields 6, 7 and 13).

#!/usr/bin/env python3
"""Prove what a GNSS receiver is actually sending on a serial port.

Usage:
    python gnss_stream_check.py /dev/ttyUSB0 115200
"""
import sys
import time


def parse_nmea(data: bytes) -> dict:
    """Pure parser: summarise an NMEA byte stream (no serial port needed)."""
    out = {"bytes": len(data), "lines": 0, "gga": 0, "rmc": 0,
           "fix": None, "sats": None, "age": None, "sbf_syncs": data.count(b"\xfa\xfa")}
    for raw in data.split(b"\n"):
        line = raw.strip()
        if not line.startswith(b"$"):
            continue
        out["lines"] += 1
        kind = line[3:6]
        if kind == b"GGA":
            out["gga"] += 1
            f = line.split(b",")
            if out["fix"] is None and len(f) > 13:
                try:
                    out["fix"] = int(f[6]) if f[6] else 0        # 0 none, 1 GPS, 2 DGPS, 4 RTK fixed, 5 RTK float
                    out["sats"] = int(f[7]) if f[7] else 0
                    out["age"] = float(f[13]) if f[13] else None  # age of differential corrections (s)
                except ValueError:
                    pass
        elif kind == b"RMC":
            out["rmc"] += 1
    return out


def read_port(port: str, baud: int, seconds: float) -> bytes:
    import serial  # pyserial, only needed for live capture
    ser = serial.Serial(port, baud, timeout=1)
    buf = b""
    t0 = time.time()
    while time.time() - t0 < seconds:
        buf += ser.read(4096)
    ser.close()
    return buf


FIX_NAMES = {0: "no fix", 1: "GPS (single)", 2: "DGPS", 4: "RTK fixed", 5: "RTK float"}


def report(r: dict) -> None:
    print(f"bytes={r['bytes']} lines={r['lines']} GGA={r['gga']} RMC={r['rmc']} "
          f"SBF_syncs={r['sbf_syncs']}")
    if r["bytes"] == 0:
        print("-> No bytes at all: TX/RX swapped, wrong port, baud mismatch, "
              "or receiver output disabled on this port.")
    elif r["lines"] == 0 and r["sbf_syncs"] == 0:
        print("-> Bytes but no valid NMEA or SBF: almost always a baud mismatch.")
    elif r["gga"] == 0 and r["sbf_syncs"] > 0:
        print("-> Binary SBF only on this port. Fine for logging, but the autopilot "
              "needs NMEA on its port.")
    if r["fix"] is not None:

        print(f"-> fix={r['fix']} ({FIX_NAMES.get(r['fix'], '?')}) sats={r['sats']} "
              f"correction_age={r['age']}s")
        if r["fix"] in (0, 1) and r["age"] in (None, 0.0):
            print("   Never RTK: corrections are not reaching the receiver "
                  "(check RTCM is wired IN, not OUT).")
        elif r["age"] is not None and r["age"] > 10:
            print("   Corrections are arriving but stale (>10 s): link/caster problem, "
                  "not receiver.")


if __name__ == "__main__":
    port = sys.argv[1] if len(sys.argv) > 1 else "/dev/ttyUSB0"
    baud = int(sys.argv[2]) if len(sys.argv) > 2 else 115200
    report(parse_nmea(read_port(port, baud, 5)))

The classifier has four outcomes. Exercised against synthetic NMEA and SBF streams, they print like this:

# healthy stream: GGA quality 4 = RTK fixed, fresh corrections
bytes=149 lines=2 GGA=1 RMC=1 SBF_syncs=0
-> fix=4 (RTK fixed) sats=18 correction_age=1.2s

# bytes arriving, but nothing valid -> baud mismatch
bytes=200 lines=0 GGA=0 RMC=0 SBF_syncs=0
-> Bytes but no valid NMEA or SBF: almost always a baud mismatch.

# receiver configured for raw logging only
bytes=56 lines=0 GGA=0 RMC=0 SBF_syncs=2
-> Binary SBF only on this port. Fine for logging, but the autopilot needs NMEA on its port.

# NMEA fine, but corrections never arrive
-> fix=1 (GPS (single)) sats=9 correction_age=None
   Never RTK: corrections are not reaching the receiver (check RTCM is wired IN, not OUT).

That last branch is the important one. NMEA GGA fix quality is 4 = RTK fixed, 5 = RTK float, 1 = single, 0 = no fix. And a correction_age above ~10 s means corrections are arriving but are stale — a link or caster problem, not a receiver problem. Two numbers, and the whole "is it the radio or the receiver" argument is over.

6. Autopilot parameters

ArduPilot:

Parameter	Value	Notes
`GPS_TYPE`	9	Septentrio
`GPS_BAUD_RATE`	9	115200
`GPS_RATE_MS`	100	10 Hz
`GPS_AUTO_CONFIG`	1	Receiver configured on every boot
`GPS2_TYPE` / `GPS2_BAUD_RATE`	9 / 9	Second receiver or dual-antenna heading

PX4:

Parameter	Value	Notes
`GPS_1_GNSS_ID`	1	Septentrio
`GPS_1_CONFIG`	TELEM2	Serial port
`GPS_1_BAUD`	115200	Must match receiver
`GPS_1_PROTOCOL`	14	Septentrio SBF/NMEA (autodetect usually works)

One driver per port. Do not point two autopilot drivers — or an autopilot plus a companion logging script — at the same UART. They fight over the stream and both look intermittent.

7. Fault isolation table

Symptom	Likely cause
No data at all	TX/RX swapped, wrong port, baud mismatch
Garbage / framing errors	Baud or protocol mismatch on that port
3D fix but never RTK Fixed	Corrections not arriving, or RTCM directed OUT instead of IN
Fixed -> float, recovers when you move	Multipath (canopy, buildings, vehicle body) — antenna placement
Fix lost near power lines, fences, 4G sites	In-band RF interference
Data dies at high output rate	Baud too low for the stream set — reduce blocks or raise baud
Two receivers conflict / intermittent position	Two drivers on one UART, or mismatched `GPS2_*`
Resets to defaults after power cycle	Configuration not stored as boot config

8. Why a perfectly configured port can still lose the fix

A port can be flawless and the fix still drops, because the receiver's front end is being desensitised. Power lines, electric fences, 4G/5G sites and deliberate jamming all put energy in band. AIM+ on our receivers rejects roughly 40-60 dB of in-band interference versus ~25 dB typical for consumer GNSS modules, and it runs continuously with no configuration.

The tell is the shape of the failure: if C/N0 sags across many satellites at once and the drop correlates with position rather than sky view, your link is fine and the RF environment is not. If only low-elevation satellites fade and it recovers as soon as you clear the trees, that is multipath — an antenna placement problem, not a receiver one.

The full port/baud/protocol guide plus an SBF log parser and a synthetic SBF generator (handy for testing a pipeline without driving to a field) live in the repo: septentrio-gnss-integration-guide.

More on the hardware: GNSS receivers | AIM+ resilient GNSS | integration guides

How do you allocate your ports? Do you keep corrections on a dedicated UART, or multiplex RTCM and NMEA on one link — and does your correction age stay steady through a whole pass?

Parsing Septentrio SBF logs in Python: fix-quality analysis and RTK drop forensics

UAV GNSS — Fri, 18 Sep 2026 02:33:11 +0000

If you build robots that depend on RTK, you eventually hit the moment where the fix drops from RTK Fixed to RTK Float and nothing on your ground station explains why. The autopilot log says "float". The correction source looks healthy. The sky is clear.

The answer is almost always in the receiver's raw log. If that receiver is a Septentrio, the raw log is SBF (Septentrio Binary Format) — and it is very parseable once you know where the traps are.

This walks through parsing SBF in Python and turning it into a fix-quality + drop-event report you can actually reason about. Fair disclosure up front: we're UAV GNSS, a Septentrio receiver maker, and everything below is what we built into a small open-source parser after our first version quietly produced wrong coordinates.

What SBF is, in 30 seconds

SBF is a binary block format. Each block is framed by a 0xFA 0xFA sync marker, followed by a header (block ID, block length, TOW, GPS week) and a payload, and closed by a CRC-16/X25 checksum. Two record types do most of the work for RTK forensics:

PVTGeodetic — position, plus the fix mode and the satellite count (NrSV)
AttEuler — roll / pitch / heading and their accuracies (relevant if you run dual-antenna heading)

The fix mode is a small integer, and it is the field you care about most:

MODE_MAP = {
    0: 'No GNSS',
    1: 'Single',
    2: 'Differential',
    3: 'RTK Float',
    4: 'RTK Fixed',
}

If you only extract one number from a receiver log all day, make it this one.

Three bugs that bite everyone writing an SBF parser

We rewrote ours after v1 emitted plausible-but-wrong latitude/longitude — the worst possible failure mode, because nothing crashes and your data looks fine.

1. Field offsets are not where you guess they are. In the PVTGeodetic payload we parse lat/lon/height at byte offsets 8 / 16 / 24, with mode at offset 6 and NrSV at 62. Pick wrong offsets and you still get numbers in a believable numeric range. Always sanity-check your first epoch against a known surveyed point or the receiver's own web interface readout before you trust a single row.

2. Resync at the byte level — never skip a fixed stride. If the sync marker doesn't match, scan forward byte by byte for the next 0xFA 0xFA instead of assuming an 8-byte block header and jumping. A dropped or partially-written block then self-heals instead of desynchronising the entire rest of the file.

3. Validate the CRC. SBF uses CRC-16/X25 (poly 0x1021 reflected, init 0xFFFF, xorout 0xFFFF):

def crc16_x25(data):
    crc = 0xFFFF
    for b in data:
        crc ^= b
        for _ in range(8):
            crc = (crc >> 1) ^ 0x8408 if crc & 1 else crc >> 1
    return crc ^ 0xFFFF

With CRC checking on, corrupt blocks are counted and dropped rather than parsed into your CSV. In our own tamper test, flipping one byte in a 30-record log dropped the parsed record count from 30 to 29 — exactly the behaviour you want from a forensics tool.

One more that is easy to forget: timestamps. SBF gives you GPS week + time-of-week in milliseconds. Converting that to UTC means applying the leap-second offset (UTC = GPS - 18 s, valid through 2026) — otherwise your drop events are timestamped 18 seconds off and won't line up with your flight-controller log.

The workflow

The parser lives in our integration guide repo, alongside a generator that produces synthetic SBF logs with valid CRCs so you can test without flying anything:

# dump a CSV: tow, wn, mode, nrsv, lat, lon, height[, roll, pitch, heading]
python3 sbf-parser.py log.sbf --check-crc --utc -o out.csv

# or skip the CSV and get the drop report straight to the console
python3 sbf-parser.py log.sbf --check-crc --utc --analyze

# synthetic test log with two embedded 3-second RTK float drops
python3 make-sample-sbf.py --drops 10,20

--analyze prints a fix-quality summary followed by every drop event, defined as a contiguous run of non-RTK-Fixed epochs following a fixed one:

Fix-quality summary (30 epochs):
  RTK Fixed     27  ( 90.0%)
  RTK Float      3  ( 10.0%)

Drop events (RTK Fixed -> degraded):
  #1  2026-08-27T01:46:15Z: RTK Fixed -> RTK Float for 3.0 s
      (NrSV at onset 12 -> min 6)

That mini-report is the whole point: duration tells you how severe the event was, onset satellite count vs minimum during the drop tells you whether satellites disappeared, and an unrecovered run gets flagged as still degraded at the end of the log instead of being silently truncated.

Reading a drop report like a diagnostician

Three completely different faults produce the same "it went to float" symptom on your GCS. The log separates them:

What the log shows	Most likely cause	What to change
`NrSV` collapses across many constellations, degrades in one specific location, recovers when you move away	RF interference desensitising the front end (power lines, electric fences, nearby 4G/5G sites)	Antenna placement first; then receiver front-end capability
`NrSV` stays high, fix degrades only under canopy or beside structures, recovers as soon as you clear them	Multipath — delayed reflections corrupting carrier-phase	Raise the antenna, add a proper ground plane, move it off motor/ESC wiring
`NrSV` is healthy but the fix degrades for a stretch and returns	Corrections were lost or stale (NTRIP dropout, radio link, cellular handover)	Log correction age; check the link, not the receiver

In practice you correlate three things on the same timeline: fix mode, satellite count, and correction age. Fix mode alone tells you that you lost it; the other two tell you why.

Why this matters for receiver choice

The third row in that table is a link problem, and no receiver on earth fixes it. But the first row is a hardware differentiator. Receivers differ enormously in how much in-band interference they tolerate before the front end is desensitised: consumer-grade modules typically manage on the order of 25 dB of suppression, while our AIM+ receivers are specified at 40–60 dB. Same sky, same corrections, same wiring — different outcome when you drive past a pylon or work under a transmission line.

You cannot see that difference in a datasheet comparison table. You can see it in an SBF drop report, which is why we instrument it.

If you want the written-up field guide for the satellite-count-collapse pattern, we keep one here: Satellite count drop and RTK fix loss — SBF analyzer guide, and the receiver range that logs this data is here.

Over to you

Do you capture raw SBF/UBX on your vehicles, or only the autopilot's fix-status field? And when you analyse a drop, what do you plot first — satellite count, C/N0, or correction age? Curious what patterns other people are chasing.