Yo [email protected]!
On Mon, 25 May 2026 13:09:27 +0200
[email protected] wrote:
I'm new to this list, and have been using gpsd silently for 3-4 years
now. I'm using it with my U-Blox ZED-F9T time-focused GNSS receiver.
Welcome to our group!
While tracking crashes in my gpsd-prometheus-exporter instance, I
identified that gpsd (3.27.5) emits invalid JSON data for specific
subframes.
Can you please try git head? There are 250 patches in git head not in
3.27.5
I activated SFRBX reporting on my ublox receiver a while
ago, and since then my exporter reports decode errors about once
every (other) day. It crashes-on-error, so it's quite visible to me
when this happens.
Ouch. Errors from GNSS receivers are normal, best not to crash on
them....
Looking at my monitoring dashboards & log streams for gpsd and the
exporter, I can say that this issue definitely originates from gpsd
emitting invalid JSON messages, and it keeps the exporter
dysfunctional for around 10-15 minutes. Then the emission of invalid
messages vanish until they re-appears again, usually a day or two
later. It happened 6 times over the last 7 days.
Ouch.
Here are some JSON messages that were emitted by gpsd that triggered
a JSON decoder exception in the exporter:
I passed those 4 lines to jq, and they are well formed JSON. If jq
can read it and not crash, then your program should also be able to.
Your JSON is very odd, I see "gnssId": 254,, as well as 246, 250 and
252. Not legal values! The train has aalready left the track. No
point debugging anything beyond that as beyond that is totally
undefined.
From include/gps.h, here are the only legal gnssId values:
#define GNSSID_GPS 0
#define GNSSID_SBAS 1
#define GNSSID_GAL 2
#define GNSSID_BD 3
#define GNSSID_IMES 4
#define GNSSID_QZSS 5
#define GNSSID_GLO 6
#define GNSSID_IRNSS 7 // ZED-F9T
Can you provide the snippet of UBX that produces that JSON?
One can see that all messages are frameid 5 dataid 106 almanac data,
and both (d_)deltai and (d_)af0 have a value of nan, which raises the
decoder error (correctly).
Yes, NaN is not art of the JSON spec,. IMHO, any decoder should be able
to handdle NaN. jq just translates it to null. But none of the
Subframe
decoders should do that.
Normally, you should look for the subframe decoder for that gnssId, but
sine there is no gnssId 254, that is pointless.
I took a look at the code, and I think construction of these messages
happens in gpsd/gpsd_json.c, on around line 1220-1259,
You need to look much further back. Without a good gnssID there is
no way to know which values need encoding.
The first failure is incorrect gnssId. Always pay most attention to
the first failure.
I have some spare time at hand over the next days/weeks, so I will
try to analyze and fix this issue.
Great. If you intend to put real work into it then create a GitLab
issue for handling this.
If anyone has some input &
insights on this it would be great, since I'm not very experienced
with subframe-data and its processing details yet.
Few are. To make sense of it you need to keep 4 coordinate systems
in your head at the same time.
RGDS
GARY
---------------------------------------------------------------------------
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
[email protected] Tel:+1 541 382 8588
Veritas liberabit vos. -- Quid est veritas?
"If you can't measure it, you can't improve it." - Lord Kelvin
