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