Sorry, the emails are not getting through my company’s filter. Using different email address and try again. > It looks like the "time" fields in all objects are intended to be in
> ISO8601. The descriptions for both GST and ATT objects stated Epoch
> time instead. Both the source code and the example for GST object
> actually use ISO8601. Are Table 4 and Table 5 incorrect?
> 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.
>The AIS stuff is a dark corner of gpsd. Checking gpsd_json.c I see that
>you are correct, there is no time in the ATT JSON. You can infer the
>time from surrounding messages. 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. I don’t want to force it to output GPS fixes just to get the timestamp. If there are no surrounding messages, what is the best way to provide time references?
> Although I added a sensor timestamp in the
> attitude struct and updated the JSON output, the client side never
> expects it and is unable to accept any ATT object because of the
> extra "time" field.
>Do you really need yet another time stamp? If so, not too hard to
>add it.
See answer above. 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. 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. If I submit the fixes to support optional “time” in ATT object, what is the process to get them released publicly?
Thanks. Peter Liu
|