[Top][All Lists]

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

Re: [gpsd-dev] Newbie questions on gpsd_json discrepancies

From: Gary E. Miller
Subject: Re: [gpsd-dev] Newbie questions on gpsd_json discrepancies
Date: Thu, 13 Sep 2018 13:49:20 -0700

Yo Peter!

On Thu, 13 Sep 2018 19:41:45 +0000 (GMT)
Peter Liu <address@hidden> wrote:

>> I can't find what you are talking about. Can you specify the file, and
>> line number, that you are looking at?
> The following lines in gpsd_json.c (gpsd-release-3.17) output ISO8601
> for time fields for these 3 objects:
> line 152 (TPV)
> line 240 (GST)
> line 272 (SKY)

Yup, those are ISO8601.

Also, the code for ATT shows it never outputs a time.

> The following tables in pgsd_json man page
> (

That comes from: gpsd_json.xml

> Table 1 (TPV) : ISO8601 format

That agrees with the code.

> Table 2 (SKY): ISO8601 format

That called ISO8601 a number.  Fixed.

> Table 4 (GST): "Seconds since Unix epoch, UTC. May have a fractional
> part of up to .001sec precision."

Good catch, it is wrong.  Fixed.

> Table 5 (ATT): "Seconds since Unix epoch, UTC. May have a fractional
> part of up to .001sec precision."

Good catch, A{TT never outputs time.  Yet.

Since you are thinking of adding a time stamp, I changed this to ISO8601
to allow for the future option.

Fixes pushed to git head.  I'm not sure how long it takes the website
to update, but the man page (gpsd_json.1) is not better.

> Actually, I am creating a driver for an Inertial Navigation System
> (INS) but only outputting pitch/roll/yaw at about 10Hz instead of 100
> Hz. I think having its own timestamp is more accurate and efficient.

Yes, if you have one.

>> Yes, nice to have, but coming from where? Does your INS supply a
>> timestamp?
> Yes. I am working on a commercial INS (VectorNav VN-xxx series) and a
> military INS from Honeywell. All the messages are timestamped.


> If not from a GPS, then where is the time from?
> The times are kept by internal clock of INS and sync to the GPS time,
> of course. The timestamps of the pitch-roll-yaw measurements might be
> more frequent than GPS fix times.

Makes sense, you certainly want the time in ATT then.

> If there are no surrounding messages, what is the best way
> to provide time references?

Lost me?  You said the time is in your INS messages?

> Also, be careful, getting data at 10Hz over a serial connection is
> non-trivial.
> We are using RS422 at 38.4 kbps. I think the baud rate can support
> close to 200Hz if we only select one data message type.

38.4kbps is cutting things pretty close.  Be sure your INS does not
send other stuff now and then.

>> Adding time to the the client side is about the same level of effort
>> as adding time to the server side: not much effort.
> Agree.

You'll also need to add time to struct attitude_t in gps.h.

>> Better not to wait until you think it is done as there will be
>> feedback for you to apply.
> I will work on it. I will not submit the drivers.

Disappointing.  You benefit from the work of others.  Not to 
reciprocate is unfair.

> My goals is to
> update the server and client to actually handle the ATT timestamp and
> to make sure the documentation is consistent.

We'll continue to help with that part.  And any parts.

> However, I need
> management approval to submit anything. I will update status.

Of course.  Just remind your management how much they have benefited
from the work of others on this.  Time to give back a little.

Then, with luck, some others will take you work and improve upon it.

That is how the virtuous circle of FOSS is supposed to work.

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

reply via email to

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