gpsd-users
[Top][All Lists]
Advanced

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

Re: [gpsd-users] issues with u-blox m8l ADR


From: Gary E. Miller
Subject: Re: [gpsd-users] issues with u-blox m8l ADR
Date: Mon, 25 Apr 2016 10:34:13 -0700

Yo Jorick!

On Mon, 25 Apr 2016 09:52:52 +0200
Jorick Astrego <address@hidden> wrote:

> On 04/24/2016 06:36 PM, Gary E. Miller wrote:
> > Yo Jorick!
> >
> > On Sun, 24 Apr 2016 13:51:00 +0200
> > Jorick Astrego <address@hidden> wrote:  
> Yo Gary! :-)
> 
> >> The M8L supports the "UBX-NAV-HNR (0x01 0x37) High Rate Output of
> >> PVT Solution", but gpsd only outputs at the normal rate. I could
> >> add it to the code base but don't have a good feel on where all
> >> the places are I need to make changes. I added the message to
> >> driver_ubx.h but it feels a bit to easy ;-)  
> > Take a look at driver_ubx.c
> >
> > If you have the spec for that message send it to this list, plus
> > some output from the GPS that has the message in it.  Say maybe a
> > minute of raw data.  
> I have been looking at that and I guess I need to modify the 
> "ubx_msg_nav_sol" part?

If the messages are very similar, then adding some compatibility to 
that function mmay be fine.  But if data is in different places in
the packet best to make a copy for the new messages.
 
> Sending the spec and raw output is a bit of a problem as we got the 
> ProtocolSpec under NDA from u-blox. I will first have to contact them
> as it's not yet in the public domain :-(

And any derived data may also be restricted.  We can't take a patch
if it has any restrictions.  So beat on uBlox for us.
 
> >> The second problem we have is that gpsd has the fix as 2D. This
> >> way I cannot get the altitude that we need. 2D should be fine and
> >> there is an elevation output in the tracklog .... but not in the
> >> gpsd output. Any idea how I can get the elevation with the c++
> >> client?  
> > If it is only a 2D fix, then you are not supposed to use the
> > altitude.
> >
> > Some GPS output crazy data when the invalid flag is set.  
> 
> It is a valid 3d fix in my opinion, I will try what happens after I 
> modify the code below to MODE_3D as we really need the altitude for
> our project and from what I see from the elevation output it's nice
> and stable and very much more correct then the normal 3D gps altitude.

I have seen nice and stable altitude that is 2,000 feet wrong when the
fix is 3D.  People risk their drones, and maybe their live, on knowing
the altitude is rock solid.  You are certainly free to patch as you wish
but gpsd would not accept any patch that passes altitude on 2D.

>     from "driver_ubx.h"
> 
>       case UBX_MODE_GPSDR:    /* FIX-ME: DR-aided GPS may be valid 3D
> */ session->newdata.mode = MODE_2D;

If you can positively identify that condition, and back it up with
uBlox documentation then we would love that patch.

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

Attachment: pgpd9x9MePB6O.pgp
Description: OpenPGP digital signature


reply via email to

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