gpsd: scan all SKY frames for richest snapshot, use single-pass parse

[octalparrot]

Summary

The snmp/gpsd extend script returned 0/0 for satellites/satellites_used on a multi-constellation receiver (Quectel LC29H + gpsd 3.25, GPS+GLONASS+Galileo+BeiDou) on roughly 80% of polls. Investigation showed the receiver emits SKY frames in a repeating cycle:

SKY[0..3]  : len(satellites)=0, nSat=null, uSat=62   ← DOP-only summary
SKY[4]     : len=27, nSat=27, uSat=23                 ← GPS only
SKY[5]     : len=38                                    ← +GLONASS
SKY[6]     : len=48                                    ← +BeiDou
SKY[7]     : len=66
SKY[8]     : len=76, nSat=76, uSat=62                  ← FULL accumulated
SKY[9..12] : len=0 ... (cycle restarts)

Selecting a single SKY (whether the first via grep -m 1 or the last via tail -1) randomly hits the empty DOP-only frame most of the time. Both approaches were unreliable on multi-constellation hardware.

Changes

Rewrite the parse step as a single Python pass that:

• iterates the entire gpspipe buffer
• tracks the latest TPV frame (for mode/lat/lon/alt)
• tracks the richest SKY frame (highest accumulated satellite count, preferring len(satellites) and falling back to nSat/uSat)
• emits a pipe-delimited record consumed by bash to format the final JSON

This reduces subprocess invocations from 9 (one Python per metric) to 1 and is robust against partial / DOP-only frames.

Other changes:

• Bump LINES from 20 to 50 to guarantee at least one full constellation cycle is captured (LC29H cycles ~10 SKY frames).
• Tolerate missing keys via d.get(...) so partial frames no longer silently drop values via 2>/dev/null.
• Prefer uSat summary for satellites_used with per-sat used flag count as fallback for older gpsd builds that don't expose summary fields.

Reproduction

Before (10 consecutive runs on LC29H + gpsd 3.25):

sats=0/62
sats=0/62
sats=0/61
sats=0/62
sats=0/64
sats=0/64
sats=0/63
sats=0/60
... (visible always 0 because grep -m 1 SKY hit DOP-only frame)

After:

sats=75/65 mode=3 hdop=0.41
sats=75/66 mode=3 hdop=0.41
sats=75/66 mode=3 hdop=0.41
sats=75/66 mode=3 hdop=0.41
sats=75/65 mode=3 hdop=0.41
sats=75/64 mode=3 hdop=0.43
sats=75/64 mode=3 hdop=0.43
sats=75/65 mode=3 hdop=0.42
sats=75/64 mode=3 hdop=0.43
sats=75/65 mode=3 hdop=0.42

Test plan

• gpsd 3.25 + Quectel LC29H (GPS+GLONASS+Galileo+BeiDou) on Debian 13 Trixie aarch64: 10/10 stable readings, values agree with cgps -s
• LibreNMS gpsd application polls extend OID, RRD satellites/satellites_used populate correctly
• Single-receiver GPS fallback path (no nSat/uSat, populated satellites[]) returns the expected count
• Empty buffer / no-fix edge case (TPV mode=1) returns 0/0 instead of crashing

Note for downstream graph maxima

The LibreNMS-side gpsd.inc.php PHP module declares addDataset('satellites', 'GAUGE', 0, 40) and the same for satellites_used. Modern multi-constellation receivers routinely report 70–80+ satellites visible, exceeding this DS maximum and causing RRD to record Unknown (graphed as 0). A companion PR to librenms/librenms raising those maxima to 200 will be filed separately so this extend script's output is actually consumed correctly.

[VVelox]

Consider just converting this entirely to python or the like if you are already going this far?

[kanokc]

Tested this on a Unicore UM980 (multi-constellation GPS/GLONASS/Galileo/BeiDou
RTK receiver, via RTKBase) feeding gpsd 3.25 on a Raspberry Pi, polled by
LibreNMS — figured another receiver data point beyond the Quectel LC29H would help.

Confirms both the bug and the fix.

Before (current snmp/gpsd): the UM980 makes gpsd emit mostly partial
DOP-only SKY frames, so grep -m 1 "SKY" lands on one without a satellites
array → KeyError: 'satellites'; satellites / satellites_used come back empty
and the LibreNMS graph stays blank.

With this PR: stable, valid output across consecutive polls:

{"data":{"mode":"3","hdop":"0.7","vdop":"1.3","satellites":"42","satellites_used":"13"}, "error":"0", "version":"3.25"}
{"data":{"mode":"3","hdop":"0.7","vdop":"1.3","satellites":"42","satellites_used":"14"}, "error":"0", "version":"3.25"}
{"data":{"mode":"3","hdop":"0.8","vdop":"1.4","satellites":"43","satellites_used":"12"}, "error":"0", "version":"3.25"}
{"data":{"mode":"3","hdop":"0.7","vdop":"1.3","satellites":"43","satellites_used":"13"}, "error":"0", "version":"3.25"}

42–43 visible / 12–14 used, consistent run to run, graph populates. The single-pass
rewrite reads well too. LGTM on the UM980 👍

FWIW the same partial-SKY behaviour shows up on u-blox ZED-F9P multi-band
configs on recent gpsd, so this fix isn't limited to any one chip.