On Thu, Aug 10, 2000 at 08:23:24AM +0200, Uwe Girlich wrote:
> It looks like in the protocol we have a 64 bit number which holds the number
> seconds * 100000, which is good for 5 fraction digits. But to interpret
> the lnglng overlaying 2 uint is an assumtion about the order of the 2 uint
> in the guint64. It will work on little-endian systems only.
>
> The first timestamp (ts.lnglng / 100000L) should be obviously the number of
> seconds (ctime() needs it so) but what is the second timestamp (ts.lng[0]).
> From the following lines (hours = ...) it should probably be the originally
> value ts.lnglng, because every following statement has its own division
> by 100000.
I'm suspicious of this; the Gryphon protocol is documented at
http://www.dgtech.com/gryphon/docs/html/GCprotocol/
and says, of the CMD_GET_TIME command the code in question dissects:
Response data length is four bytes.
TIME -- 8 bytes -- Timestamp, in units of .00001 sec. (Lower
four bytes correspond to Gryphon Data Frame timestamp, upper
four bytes add more significant bits.)
I suspect "Response data length is four bytes." is the result of cutting
and pasting without editing.
By "more significant bits" I'd assume they provided higher resolution;
given that elsewhere in the protocol time resolution is also .00001 sec,
though, I suspect it really means "larger range".
The sample output in the documentation for the "gryphrx" utility":
http://www.dgtech.com/gryphon/docs/html/utils/gryphrx.html
shows times with more than 32 bits of data, although they seem to show
that as part of the header time stamp, which is only 32 bits wide.
So I don't know what the heck is going on here - I'm CCing Steve
Limkemann of Dearborn Technology Group, to see if he can explain this.
> > (BTW, this indicates that we should provide "pntohll()" and "phtonll()"
> > routines, and tvbuff versions of them, at least on platforms where we
> > have "gint64" and "guint64".)
> That would at least clean the first mentioned problem.
I've checked that in.
