gpsd-users
[Top][All Lists]
Advanced

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

Re: [gpsd-users] parsing NMEA PASHR record


From: Gary E. Miller
Subject: Re: [gpsd-users] parsing NMEA PASHR record
Date: Fri, 9 Feb 2018 10:10:53 -0800

Yo Roger!

On Fri, 9 Feb 2018 10:31:11 +0000
Roger Oberholtzer <address@hidden> wrote:

> Just an update on the PASHR parsing: we had no trouble doing the
> PASHR parsing. That part is easy. The problem we have is that PASHR
> records trigger a new report cycle.

Yeah, I struggling with similar while coding the new ECEF support.  Note
two things going on: one is when a report is triggered (REPORT_IS),
another when the current data is cleard (CLEAR_IS)

> Which is not what we want. In our
> systems, records like GGA arrive at 10 Hz, and PASHR at 25 Hz. This
> is by design.

Similar to the satellite reports being less frequent that PVT reports.

> Because of this, we have disabled PASHR parsing by gpsd
> and instead parse it our self via the raw NMEA stream we get from
> gpsd. We could of course pass our parsing code to you, but we would
> probably disable it anyway.

Even if we disable, someone else may find it useful.  I find for every
on person that speaks up, ten people silently have the same issue.

If you add a configure switch to enable/disable PASHR that might
be useful in git head.  Also, any standalone parsing code could at
least go in contrib/.

> In fact, the general way that gpsd
> determines report cycles is, in our opinion, rather draconian and not
> really suitable for many uses.

Yup, I've been fighting that too.  Ideas welcome.

If you want to try to tweak your copy, just look in the driver you
are using (driver_nmea0183) and look for REPORT_IS and CLEAR_IS.
Moving them around is easy.  The bad part is that no two GPS seem
to send the same NMEA in the same order...

One solution may be to send the report when a new time stamp is received,
before parsing the new data.  Others may not like the increased latency
that gives.

Another solution might be to dynamically watch the incoming sentences
and determine end of cycle in real time.  That would be my preferred
option, and could be implemented per driver.

Like everything else, it will not get fixed until someone gets mad
enough...

> So, it you want the PASHR parsing code, I can send you the diffs.
> Many systems will, I think, then have unexpected side effects.

Yeah, but worst case it can go in the code but conditioned out.  Then
the next guy that wants to play with it can.

> Still a happy gpsd user.

Cool!

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

Attachment: pgpPkhHTn1Kr4.pgp
Description: OpenPGP digital signature


reply via email to

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