Timing over low bandwidth channels
If you can indeed track a 1W signal from ~ Colorado, there might indeed be
some timing use for the system.
I have a start at understanding how much data you can get through a channel.
There is a tradeoff between data rate and error rate and it depends on the
signal/noise ratio.
Is there a similar sort of high level picture about sending timing info? I'm
not even sure what the units are.
--
These are my opinions, not necessarily my employer's. I hate spam.
In message 20101209105031.6104C80003B@ip-64-139-1-69.sjc.megapath.net, Hal Murray writes:
Is there a similar sort of high level picture about sending timing info? I'm
not even sure what the units are.
Basically with timing you only send one bit: "now"
The most precise way to send that bit is to use a very long PRNG
spreading code, and identify the correlator output peak using
statistical estimation on the slopes up to the peak.
DCF77 sends a 512 bit PRNG every second and in hand-run testes I have
been able to determine the peak of the correlation with precision which
is 100-500 times better than the second to second jitter on the 1200km
propagation.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
phk@FreeBSD.ORG | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
Hi
... and for a very low power system, there's no reason to stick with a "short" 512 bit data set, or a "fast" 1 second rep rate.
If the signal is a "only at night" sort of thing (as I'm guessing it is over that path), all you really might do is a couple of time transfers a night. A code that marked 10 minute slots would do the trick. Make it nice and long so you don't loose precision.
Bob
On Dec 9, 2010, at 5:55 AM, Poul-Henning Kamp wrote:
In message 20101209105031.6104C80003B@ip-64-139-1-69.sjc.megapath.net, Hal Murray writes:
Is there a similar sort of high level picture about sending timing info? I'm
not even sure what the units are.
Basically with timing you only send one bit: "now"
The most precise way to send that bit is to use a very long PRNG
spreading code, and identify the correlator output peak using
statistical estimation on the slopes up to the peak.
DCF77 sends a 512 bit PRNG every second and in hand-run testes I have
been able to determine the peak of the correlation with precision which
is 100-500 times better than the second to second jitter on the 1200km
propagation.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
phk@FreeBSD.ORG | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
Hal Murray wrote:
If you can indeed track a 1W signal from ~ Colorado, there might indeed be
some timing use for the system.
I have a start at understanding how much data you can get through a channel.
There is a tradeoff between data rate and error rate and it depends on the
signal/noise ratio.
That's the Shannon bound.. (or Shannon-Hartley)..
C = B*log2(1+S/N)
You can get pretty darn close (hundredths of a dB) to this limit with
coding.
Is there a similar sort of high level picture about sending timing info? I'm
not even sure what the units are.
That's a bit trickier to conceptualize... In the data bit case, you can
work at the "one bit" scale.. and say something about the probability
that the bit is wrong. ANd, you can combine multiple bits and drive the
probability of an error over all those bits combined down.
But for "time" or "frequency" it's a bit trickier. You have to specify
the time scale over which you're interested (I suppose that relates to
the bandwidth in the Shannon formula). But more to the point, in
digital communications there's a clear "two-state" thing..either the bit
is correct or it's not. Time/Frequency has "degrees of wrongness"
On 12/09/2010 03:16 PM, jimlux wrote:
Hal Murray wrote:
If you can indeed track a 1W signal from ~ Colorado, there might
indeed be
some timing use for the system.
I have a start at understanding how much data you can get through a
channel. There is a tradeoff between data rate and error rate and it
depends on the signal/noise ratio.
That's the Shannon bound.. (or Shannon-Hartley)..
C = B*log2(1+S/N)
You can get pretty darn close (hundredths of a dB) to this limit with
coding.
Is there a similar sort of high level picture about sending timing
info? I'm not even sure what the units are.
That's a bit trickier to conceptualize... In the data bit case, you can
work at the "one bit" scale.. and say something about the probability
that the bit is wrong. ANd, you can combine multiple bits and drive the
probability of an error over all those bits combined down.
But for "time" or "frequency" it's a bit trickier. You have to specify
the time scale over which you're interested (I suppose that relates to
the bandwidth in the Shannon formula). But more to the point, in digital
communications there's a clear "two-state" thing..either the bit is
correct or it's not. Time/Frequency has "degrees of wrongness"
Which is the reason you look a bit wider on Shannon's work and not use
the oversimplified model of above. Shannon's article(s) cover both
analog and digital transmissions. The bandwidth you use for your signal
will be the bandwidth you toss into the formula, where spread spectrum
helps to confuse the issue. The time and frequency reception is not all
that strange. The analysis is done fairly deeply for GPS, where a 40 W
transmission provides timing for 1/3 of the earth surface area some
26000 km away or so.
Cheers,
Magnus