Re: Questions about decoding subframe messages (ublox F9P)

[Gary E. Miller]

Yo Curtis!

On Fri, 22 May 2020 14:00:30 -0500
Curtis Olson <address@hidden> wrote:

> Thanks for the reply!  I'm still trying to figure out the lay of the
> land here in the gpsd world, so sorry if some of my questions are
> dumb.

There are a log of books on the subject.  Some of it still classified.

> $ ubxtool -V
> ubxtool: Version 3.19

Uh, oh.  Old version. released before the u-blox 9-series, so not useful
with the 9-series.  Get 3.20, or better yet, pull from git head.


> > Good luck with that, certainly the highway you the hard way.
> >  
> 
> We have an in-house developed loosely integrated kalman filter that
> we have been flying with for over a decade, but we would like to do a
> tightly integrated version.  We aren't trying to reinvent the wheel
> or improve the state of the art in accuracy, but instead, having our
> own in-house system tightly integrated system would lay the
> groundwork for us to be able to do other more interesting higher
> research projects going forward.

If a reinvented, then a wheel made in a completely different way.

> We are interested in exploring some
> different ideas of redundancy through software rather than
> replicating physical hardware. That is the theory anyway.

The trend for decades.

> > Where?
> Here is our main Github repository for our lab.  Many of our student
> projects are scattered all over and in their own personal
> repositories. For core lab work we are trying to become more
> organized as we go:
> 
>     https://github.com/UASLab

Thanks!  I'll check it out.

> > Without details no way to suggest options.
> My understanding was that orbital parameters come from the subframe
> messages,

Nope.  They come from ground stations that bounce lasers off the sats
as they fly by, then recompute the orbintal parameters.

One, of many, ways to get a copy of the almost current orbital parameters
is from the current ephemeris.  But thre are not the most current orbital
parameters and the ephermeris is not the only way to get them.

> and then the orbital parameters go into known equations to
> compute actual locations in ECEF?

Yes.  Except the "known" part.  GNSS receivers do many things that
are not "known" to the public.

  I know parts of the puzzle and am
> trying to get up to speed on other parts, and I'm sure there are
> things that have not even hit my radar screen yet.

I know this stuff, and I still get surprised, often.

>  Are there better
> ways to do this?

Of course.

> For whatever it's worth, my roll in this is to support our
> student projects.  So I am trying to plow through the difficult nuts
> and bolts of low level protocol decoding, communication, hardware
> connectivity, basic driver setup, etc.

Even then, the subject is hard.

> Otherwise you hand this to a
> student who's never seen a binary protocol before and they could
> struggle for a year just trying to get messages out of the gps.

Yup.

> Hopefully if I can work through all the tricky and fiddly (but not phd
> level) protocol and communication issues, then I can hand this off to
> a student to work on all their high level researchy stuff.

It is Phd level.  Did you read the pdf I mentioned last time?

> I stumbled on gpsd again today (I have used it a number of years ago
> but forgot about it when we moved towards plugging our gps's directly
> into arduino processors.)  But for this upcoming work, doing
> everything on a desktop with gpsd would be great if that saves us
> some headaches on the low level.

More popular to put it on a Raspberry Pi.  To do it right you need
megabytes of memory.

> > You don't.  Your gpsd is doing exactly what it needs to do as a
> > daemon. You effort will be as a client.  Look at the gpsd clients,
> > obviously influenced by your programming language of choice.
> 
> Dumb question.  So then is the subframe.c code being used by certain
> clients, not gpsd?  I didn't look too closely at the build system.

subframe.c is part of the daemon.  The fist step in converting the
raw 30 bit, including parity, words into JSON, that you see with the
gpspipe client.

> I see that gpsd is parsing the basic ublox binary messages to get the
> raw subframe bytes, but what I want to do is extract the satellite
> orbital information from those raw bytes ... subframe.c seems like
> code to do this, but it sounds like gpsd doesn't invoke that code,
> and I need a client instead?

Nope, ust look at the JSON with gpspipe.

> I definitely do not fully understand
> the architecture/ecosystem of gpsd.

No one does.

> I couldn't find any
> documentation on the subframe stuff within the gpsd ecosystem.

Nor do you need to know.  That part is done, use it as a blcok box.  It
could take you a year to learn what is done.

>  Is
> there a client you can suggest for me to try?

Try: gpspipe -w

> I'm happy with C or
> python, or do I need to be writing my own code and making libgps
> calls?  At this point, if I can just get the subframe data decode and
> spit out those numbers, I'll be super happy.  We have a student lined
> up for the summer to work on figuring out how to take this data and
> actually compute the satellite locations, and possibly start working
> on the tightly integrated kalman filter stuff.

Or just have him read the RTKLIB code.

>  (And I know there
> will be a lot of housekeeping work in the middle to manage all the
> information.)

Actually, not so much.  Take the current ephereris (orbital info)
crank it in a huge matrix with the RAWX measurements.  Compute a
best case fix using iteration.  Done.

Spend some time with: IS-GPS-200K.  A year should be enough time.

> This works and gives me "TPV" messages (I'll assume you won't call in
> an airstrike with this information!)

Look at the RAW messages, there is the orbital data.

> And then also the raw info (pseudorange, doppler, carrier phase)
> coming from the RXM-RAWX message:

Yup, that is what you want.  Except, psuedorange has already been
pre-processed with the ephmeris.  You may eventually want more raw than
that.

> It is my understanding that I still need the orbital parameters out
> of the RXM-SFRBX subframe messages to compute actual satellite
> positions accurately in order to feed our tight integration system,
> but ???


Yes, and no.  You need the ephemeris (orbital info), by you do not have to
get it from the subframes.

You can also get it here:

https://cddis.nasa.gov/Data_and_Derived_Products/GNSS/broadcast_ephemeris_data.html

> I can go ask more questions if it sounds like I'm way off
> track here.

Not off track, just gonna take a while to see individual trees in the forest.

> 
> Have you looked at RTKLIB?  Or some of the other "soft gnss" projects?
> > They take the raw + orbital and generate fixes.
> >  
> 
> I haven't dug into any of their code. I can try to poke around in
> their stuff as well if you think it could be useful.

They do what you want to do.  gpsd only gives you some of the pieces.

Here is a project that does what you want to do:

    https://sourceforge.net/projects/gnss-sdr/

RGDS
GARY
---------------------------------------------------------------------------
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
        address@hidden  Tel:+1 541 382 8588

            Veritas liberabit vos. -- Quid est veritas?
    "If you can't measure it, you can't improve it." - Lord Kelvin

pgpjKGihZuQO8.pgp
Description: OpenPGP digital signature