Yo Curtis!
Hi Gary!
2 hours, and zero results is bad. Have you upgraded any F9P firmware yet?
For the ublox9 unit I have here, I didn't touch the firmware myself (but it did go through another set of hands before it landed on my desk so .... ?)
gpsd is reporting: FWVER=HPG 1.11,PROTVER=27.10,MOD=ZED-F9P
> I see the driver_ubx.c code, and see that it does something with
> RXM-SFRB messages (not in ublox8/9) but doesn't specifically handle
> the RXM-SFRBX message.
Good luck. GPS only may not be too bad.
So a quick report from the trenches on adding SFRBX support to the gpsd driver_ubx.c:
It was pretty easy to jump into driver_ubx.c and naively copy and adapt the SFRB handling code -> SFRBX and pass the subframe words to gpsd_interpret_subframe(). The SFRB vs SFRBX message structure is a bit different, but not too hard to look through the ublox9 docs and update the code to pick out the right bytes and validate the message length.
<I'm skipping past the 4-5 hours where I went in circles poking through bit streams and tearing my hair out, just to find my way to the easy solution>
From there I can pass the words[10] to gpsd_interpret_subframe()
So, sadly, the data always failed the preamble test. However, I did some digging and dusted off my hex->bin skills and discovered that gpsd_interpret_subframe_raw() does the preamble check correctly for the ublox subframe data.) In my own code here, I "fixed" the preamble check in gpsd_interpret_subframe() to work "correctly" as per the raw version of the function. If this preamble check had worked with some other brand receiver, that other receiver must be doing some pre-munging of word[0] (or it never actually worked?)
It appears the ublox reciever does the parity checking and bit inversions internally and then drops the 6 parity bits from each word before it is passed in the SFRBX message ... so those extra bits are not part of the subframe message.
Anyway, after all of this I now am actually getting SUBFRAME messages out of gpspipe -w
I would be excited except I have no idea if the decoded orbital parameter values are plausible. (Sadly my degree was in csci and somehow I ended up with a job in aerospace ... so I can grok bits and hex and find my way around C code, but orbital equations not so much.)
Is there interest in my code changes to support UBX-RXM-SFRBX? The updates to driver_ubx.c are super straight forward, and then there is the one change to the preamble check in subframe.c that we would have to arm wrestle over which way is right:
@@ -173,7 +173,7 @@ gps_mask_t gpsd_interpret_subframe(struct gps_device_t *session,
tSVID, words[0], words[1], words[2], words[3], words[4],
words[5], words[6], words[7], words[8], words[9]);
- preamble = (uint8_t)((words[0] >> 16) & 0x0FF);
+ preamble = (uint8_t)((words[0] >> 22) & 0xFF);
/* somehow missed an inversion */
Again, the only way I can make sense of the existing check is (a) it doesn't really work, or (b) the receiver it works with is doing some pre-parsing/reduction (by shifting away 8 of the original bits for some reason) of the "telemetry word" (TLM) which is the first word of the subframe message.
Let me know and I can generate a merge request (or easier) send you a git diff -c? Or I can just carry the changes here locally and probably be happy enough ... presuming I've put the values in a form that are actually getting decoded correctly.
Thanks,
Curt.