gpsd-dev
[Top][All Lists]
Advanced

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

Re: [gpsd-dev] ✘NMEA_MAX


From: Eric S. Raymond
Subject: Re: [gpsd-dev] ✘NMEA_MAX
Date: Mon, 28 Mar 2016 21:06:38 -0400
User-agent: Mutt/1.5.23 (2014-03-12)

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.

> > So, basically, you can plug in both ports and GPS should figure out
> > which is NMEA and which is RTCM2 on its own.  At worst, you might
> > have to tell the RTCM2 port the baud rate with stty, but pribably you
> > won't need to do that.
> 
> 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.

> 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.

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.
-- 
                <a href="http://www.catb.org/~esr/";>Eric S. Raymond</a>

Attachment: signature.asc
Description: Digital signature


reply via email to

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