[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Questions about decoding subframe messages (ublox F9P)

From: Curtis Olson
Subject: Re: Questions about decoding subframe messages (ublox F9P)
Date: Wed, 27 May 2020 12:01:41 -0500

On Tue, May 26, 2020 at 10:45 PM Gary E. Miller <address@hidden> wrote:
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:

-- a/subframe.c
+++ b/subframe.c
@@ -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);
     if (preamble == 0x8b) {
         /* somehow missed an inversion */
         preamble ^= 0xff;

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.


Curtis Olson
University of Minnesota, Aerospace Engineering and Mechanics, UAS Lab

reply via email to

[Prev in Thread] Current Thread [Next in Thread]