gpsd-dev
[Top][All Lists]
Advanced

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

Re: [gpsd-dev] ✘NMEA_MAX


From: Gary E. Miller
Subject: Re: [gpsd-dev] ✘NMEA_MAX
Date: Mon, 28 Mar 2016 18:34:07 -0700

Yo Eric!

On Mon, 28 Mar 2016 21:06:38 -0400
"Eric S. Raymond" <address@hidden> wrote:

> Gary E. Miller <address@hidden>:
> > > Shouldn't be a big deal.  The way I set things up, RTCM2 and
> > > RTCM3 are just additional packet types that the packet sniffer
> > > can recognize (though it took some contortions to make this work
> > > for RTCM2 because it's bit-stream with 30-bit words, not
> > > byte-oriented - you have to run a separate state machine to sync
> > > to the packet boundaries).  
> > 
> > Luckily this GPS is RTCM 3 and 3.1  
> 
> Oh, good.  I'm not at all worried about *that* working - 3/3.1 is just
> another packet type in nicely framed bytes, not the weird bit-stream
> thing 2.1 is.

Hmm, I see RTCM 3.1 is now called RTCM Standard 10403.1.

There is a 'not for redistribution' copy here: 
    http://docslide.us/documents/rtcm-31.html

Only 98 pages of light reading.  :-)

> > Cool.  It also looks like I'll need to send some config string to
> > enable the RTCM output from the base GPS.  
> 
> The best way to handle that, if you can, is to identify some packet
> unique ro the device, use that as the trigger for the driver, and
> then switch RTCM3 on with the config string shippee to the device
> when that type is recognized.

I have the trigger string: $PSTI, I just do not know what to send to
turn on RTCM 3.1, yet.  I have a request into Skytraq: address@hidden

Hopefully someone that reads English is there tonight.

> > And in another twist.  cm accuracy mean lat/lon use 7 digits after
> > the deciaml point, not 6.  I'll dive in to find where that is
> > getting truncated.  With luck it will not break too many
> > regressions...  
> 
> Uh oh. This'll be interesting.

Yeah, the rabbit hole just got deeper.  Check out this test code, 
patterned after do_lat_lon() in driver_nmea0183.c:

    #include <stdio.h>
    #include <stdlib.h>
    #include <math.h>

    int main() {

            double d, m, lat;

            lat = atof( "12118.8470591" );
            m = 100.0 * modf(lat / 100.0, &d);
            lat = d + m / 60.0;

        printf( "%f\n", lat);
    }


Care to guess the output?

    ~ $ ./a.out
    121.314118


modf() and atof() are double precision, which should allow 15.95 decimal
digits.  So the problem is not basic to internal representation, there
is a problem somewhere in the srting conversion.  Likely that printf()
%f defaults to %.6f

> Being able to handle centimeter accuracy is a big enough deal that if
> you have to rebuild a skajillion tests I won't actually mind that
> much.

Better get ready!

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

Attachment: pgp83gxPCee9O.pgp
Description: OpenPGP digital signature


reply via email to

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