gpsd-dev
[Top][All Lists]
Advanced

[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: Wed, 12 Sep 2018 13:37:59 -0700

Yo Peter!

On Tue, 11 Sep 2018 22:43:41 -0400
Peter Liu <address@hidden> wrote:

> Sorry, the emails are not getting through my company’s filter. Using
> different email address and try again.

You need to apply a blunt object to your email admin.

> > ISO8601 is just one of many epoch times.  can you clarify your
> > question?  
> According to table 4 and table 5 of the gpsd_json documentation, the
> “time” fields are in number of seconds since 1970. Other objects
> (e.g. TPV) stated the time fields are in ISO8601 format. The
> documentation is not up-to-date.

I can't find what you are talking about.  Can you specify the file, and
line number, that you are looking at?

> 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, nice to have, but coming from where?  Does your INS supply a
timestamp?

> I don’t want to force it to output GPS fixes just to get the
> timestamp.

If not from a GPS, then where is the time from?

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

Grab the time from the previous message that had a time.  Which is a
bit problematic if your GPS is at 1HZ and your INS is at 10Hz.

Also, be careful, getting data at 10Hz over a serial connection is
non-trivial.

> I added time stamps in ATT objects very easily on
> the server side. However it breaks the client API because it does not
> expect “time” in ATT objects even the documentation saids “time” is
> part of ATT objects.

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

> I really hope that the publicly available client
> libraries can support the optional “time” field so that I don’t have
> to provide modified client libraries to my customers.

When you have something working, send it here, with a bit of work we'll
get it into git head.

> If I submit the
> fixes to support optional “time” in ATT object,

Almost ALL fields in any of our JSON objects are optional.   A big
mistake people make is assuming their setup will always output the same
data.

> what is the process
> to get them released publicly?

Send this list a patch file as an attachment.  Git can make this
file for you: git format-patch

Better not to wait until you think it is done as there will be feedback
for you to apply.

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


reply via email to

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