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 the fixed and nominally
> known sample rate.) Of course the slave computer could use
> its own time, but that will add another level of jitter.
>
> As a minimum, I suggest that each packet include as a 32-bit
> integer the number of seconds since the Unix epoch,
> according to the master computer's system clock. So much
> the better if you include a number of milliseconds as a
> second number, or combine both into a double.
>
> Never mind about jitter; the receiving program would need to
> know that jitter in the time values will exist, and behave
> accordingly.
>
> Together with the block number, these approaches will
> suffice very nicely for JT65, anyway. They will work better
> and more reliably than having the slave computer use its own
> system clock.
OK. This is what it looks like under Windows:
int lir_get_epoch_seconds(void)
{
// Here we have to add a calendar to add the number
// of seconds from todays (year, month, day) to Jan 1 1970.
// The epoch time is needed for moon position computations.
SYSTEMTIME tim;
GetLocalTime(&tim);
return 3600.*tim.wHour+60.*tim.wMinute+tim.wSecond;
}
I can put the number of seconds since the Unix epoch if
someone supplies the code needed in Windows. (It is needed
anyway to make moon computations correct under Windows)
Would it not be more convenient to supply an integer with
the number of milliseconds since midnight? The accuracy
(jitter) might be a few ms and that should allow averaging
to find the sync tone provided that each station has
adequate stability and a correction for his own part of
the doppler shift.
> Please let me know when a broadcast-enabled Linrad version
> is available for testing with MAP65. And if you have some
> example code for use by the receiving program -- or, say, a
> stand-alone "dummy" receiving program that can receive
> broadcast packets, I would be happy to see the code!
Pretty soon, but I will await further comments on the way
it will be implemented. You already talked me into adding
a time stamp. I can see that it should have less time jitter
than the time stamp you can add from the system clock in
MAP65.
The time stamp will not necessarily be the time at which the
samples arrive for each block however. The SDR-14 for example
sends 8192 bytes and all 8 network packages from one read will
then have the same time stamp. (Of course this can be corrected
at a later stage.)
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)
73
Leif
#############################################################
This message is sent to you because you are subscribed to
the mailing list <linrad@antennspecialisten.se>.
To unsubscribe, E-mail to: <[EMAIL PROTECTED]>
To switch to the DIGEST mode, E-mail to <[EMAIL PROTECTED]>
To switch to the INDEX mode, E-mail to <[EMAIL PROTECTED]>
Send administrative queries to <[EMAIL PROTECTED]>
