Hi Leif and all,
- I would want a timestamp in there somewhere. It might be derived
from block_no, but why not make it explicit ?
I do not see what it would be good for. Why do you want the clock
from the master while there is another one in the slave?
Surely I could add this, but there is
Hi JDB and all,
> A general point: in virtually all communications protocols the
> (descriptive) header comes before the data block, since the receiver
> usually needs to decode the header to be sure what to do with the
> data. This also makes it possible to vary the length of the data
> block
Hi Joe and all,
> I agree that a timestamp will be useful. For what I am
> thinking about, very high precision and high accuracy are
> not required. JT65 wants to know the UTC of a data block to
> within a second or so. (Relative timing among successive
> blocks is of course maintained by t
The newcomer who wants to write his own software does not have
to know anything about the header, he can just use the 1024
bytes of data and ignore whatever has been appended. Having a
header which has to be properly decoded in order to extract
the data builds a threshold that makes it more diffic
Leif and all,
Would you agree on milliseconds since midnight? From JDB I
learned that a double with seconds since Unix epoch
would be a bad idea since conversion may be difficult on
non-PC platforms. (It is the internal time format within
Linrad however)
Yes, milliseconds since UTC wou
Leif and all,
Would you agree on milliseconds since midnight? From JDB I
learned that a double with seconds since Unix epoch would be a bad
idea since conversion may be difficult on non-PC platforms. (It is
the internal time format within
Linrad however)
Yes, milliseconds since UTC wou
Hi again,
> WAV is an example of a file format where *everyone* added their own
> custom headers/chunks, without any planning. As a result, no program
> can read all existing WAV files; WAV is considered an example how
> *not* to do a file format.
And still we have to use it.
> Would you c
