[Top][All Lists]

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

Re: [gpsd-users] Communicating NMEA to gpsd as if my software was a GPS

From: Gary E. Miller
Subject: Re: [gpsd-users] Communicating NMEA to gpsd as if my software was a GPS device
Date: Wed, 4 Sep 2019 11:37:59 -0700

Yo Ellon!

On Wed, 4 Sep 2019 10:34:58 +0200
Ellon Paiva <address@hidden> wrote:

> I'm working in a project where some clients are already configured to 
> get localization data from gpsd. I'm in charge of creating a piece of 
> software that would communicate with gpsd as if it was a GPS device,
> so these clients would be able to get this information from the same
> gpsd client interface, and in a frequency slightly higher than 1Hz.

Easy, except the "slightly higher than 1Hz" part.

> Based on gpsd manual pages, it was decided my "GPS device" would 
> communicate to gpsd through UDP or TCP feed using NMEA sentences.

Those work.  You may want to verify how well things work on a
network interruption.  Did you look at gps2udp and gpsfake?

> The 
> sentences are:
>   * GGA for time, lat, lon
>   * ZDA for date, as gpsd expects the date to be informed to be able
> to use GGA
>   * GST for error ellipses
>   * VTG for linear speed

Good, so far.

>   * OHPR for attitude, acceleration and angular speed

Proprietary, not well tested.

You prolly also want GSV so gpsd can compute some more error estimates.
The GS values are not well standardized.

> This would translate into the following objects being sent to gpsd 
> clients as json reports:
>   * TPV
>   * ATT
>   * GST

Yup.  Plus an option SKY if you enable GSV.

> So at the end I want something like this:
>                               GGA
> +-------------------------+  ZDA   +------+  TPV   +--------------+
> | my simulated GPS device | -----> | gpsd | -----> | gpsd clients |
> +-------------------------+  GST   +------+  GST   +--------------+
>                               VTG             ATT
>                               OHPR

Looks good.

> I have a first implementation of this idea, but I'm facing some
> problems which I would like to discuss. For information, I'm using
> gpsd-3.17 installed from Fedora 29 default repositories. I'm
> attaching some log files to help understand the problems.

That is old.  If you ever need a fix you need to be on 3.19 or git head.

Your logs are "interesting".  Rt first glance your GST and GGA are not
even close to standard NMEA.  If such simple things are wrong the
bit rot must go very deep.

>  1. The time in the GST reports seems to be off and floating with
>     relation to the time in the TPV reports,


> which seems to be
> according with the data sent. Does anyone know why I have this
> behavior?

Crappy GNSS receiver firmware.  Well, maybe not crappy, as the
standard does not say that the times must be monotonic and increasing.

> 2. It seems that OHPR is not being properly parsed as a
> NMEA sentence by gpsd (there is no ATT output for gpsd clients).

That is because it is NOT and NMEA sentence.  It is proprietary, and
thus poorly documented and not standardized.

> I
> tried to follow logic used by the state machine decode the sentence
> but it proved to be very hard...

Then you looked in the wrong place.  dirver_nmea0183.c does not
contain a state machine.  You were likely looking at packet.c.  Ignore
packet.c for now.  Look at the function processOHPR() in driver_nmea0183.c

Just the start of many changes that may be needed for your sentences that
look like, but are not NMEA 0183.

> Anyone could confirm this parse bug
> or tell me what am I doing wrong?

Not a parse bug.  A decode

Also, I see you are hitting a known TSIP bug in 3.17.  You need to get
off 3.17.

>  3. man gpsd tells that VTG is supported, but when I looked at the
> code of gpsd-3.17 it seems that it was not (I found a
>     {"VTG", 0,__ false, NULL},______ /* ignore Velocity Track made Good */

I see it supported in git head.

>     line on driver_nmea0183.c), although there are other parts of the
>     code that mention VTG. So, is VTG supported on this version or
> not? and if it is, how can I get it to be used to generate json
> reports? 4. In general, what would be a good set of NMEA messages to
> pass all the information I need to gpsd?

Since I do not know your needs, I can only make the guesses as above.

Getting off 3.17 is your first step.

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: pgpb5gehA2xWZ.pgp
Description: OpenPGP digital signature

reply via email to

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