[linrad] Re: Network standards for SDR
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 a cost to it. The packages are sent out at maybe 1 kHz. The corresponding time resolution is 1 ms. There is an appreciable time jitter however and it is not obvious what time to put into a specific package. Presumably it should be the time when the first sample within the package was taken from the hardware. What would it be good for? It is not trivial to evaluate. 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. 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! -- Joe, K1JT # 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]
[linrad] Re: Network standards for SDR
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]
[linrad] Re: Network standards for SDR
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 would be OK. Maybe you should send BOTH this quantity AND a double with seconds since Unix epoch (which I would actually prefer). I don't see the conversion issue as a big deal; little-endian to big-endian copnversion is trivial, and doesn't nearly everybody use IEEE floating point these days? -- Joe # 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]
