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: Peter Liu
Subject: Re: [gpsd-dev] Newbie questions on gpsd_json discrepancies
Date: Thu, 13 Sep 2018 19:41:45 +0000 (GMT)



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.
Roger.


> 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?
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)
The following tables in pgsd_json man page (http://www.catb.org/gpsd/gpsd_json.html):
Table 1 (TPV) : ISO8601 format
Table 2 (SKY): ISO8601 format
Table 4 (GST): "Seconds since Unix epoch, UTC. May have a fractional part of up to .001sec precision."
Table 5 (ATT): "Seconds since Unix epoch, UTC. May have a fractional part of up to .001sec precision."

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?
Yes. I am working on a commercial INS (VectorNav VN-xxx series) and a military INS from Honeywell. All the messages are timestamped.


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?
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.


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.
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.


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.
Agree.


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.
I will work on it. I will not submit the drivers. My goals is to update the server and client to actually handle the ATT timestamp and to make sure the documentation is consistent. However, I need management approval to submit anything. I will update status.


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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 851 bytes
Desc: OpenPGP digital signature
URL: <http://lists.nongnu.org/archive/html/gpsd-dev/attachments/20180912/940e0427/attachment.pgp>

------------------------------

Subject: Digest Footer

_______________________________________________
gpsd-dev mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/gpsd-dev


------------------------------

End of gpsd-dev Digest, Vol 84, Issue 3
***************************************

reply via email to

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