Re: [time-nuts] Trimble Mini-T Timing Glitches
Bob, this is quite an unorthodox description of how GPS works.
You probably want to rephrase that before it gets ripped to shreds.
Leo
From: Bob kb8tq kb8tq@n1k.org
GPS extracts time and location by locking on to various codes in the transmissions.
One of them happens to run at about a 1 KHz clock rate. A slip on that part of the
process gives you a (modulo) 1 ms clock jump. Certain types of interference may
“help” the receiver make these sorts of mistakes.
Hi
I’d freely admit it is very much the “Cliff notes” version of what is
happening.
Bob
On Nov 30, 2017, at 4:31 PM, Leo Bodnar leo@leobodnar.com wrote:
Bob, this is quite an unorthodox description of how GPS works.
You probably want to rephrase that before it gets ripped to shreds.
Leo
From: Bob kb8tq kb8tq@n1k.org
GPS extracts time and location by locking on to various codes in the transmissions.
One of them happens to run at about a 1 KHz clock rate. A slip on that part of the
process gives you a (modulo) 1 ms clock jump. Certain types of interference may
“help” the receiver make these sorts of mistakes.
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.
Leo,
About GPS and 1 ms...
- Bob's version:
Bob's succinct description is fine. There is often a 1 ms loop in GPS receiver firmware (you can see this in the spec for some timing receivers). It is not impossible that off-by-1 errors would occur at this level.
- Book version:
Fundamentals of Global Positioning System Receivers: A Software Approach
CHAPTER FIVE
GPS C/A Code Signal Structure
The C/A code is a bi-phase modulated signal with a chip rate of 1.023 MHz.
Therefore, the null-to-null bandwidth of the main lobe of the spectrum is 2.046
MHz. Each chip is about 977.5 ns (1/1.023 MHz) long. The transmitting bandwidth
of the GPS satellite in the L1 frequency is approximately 20 MHz to
accommodate the P code signal; therefore, the C/A code transmitted contains
the main lobe and several sidelobes. The total code period contains 1,023 chips.
With a chip rate of 1.023 MHz, 1,023 chips last 1 ms; therefore, the C/A code
is 1 ms long. This code repeats itself every millisecond. The spectrum of a C/A
code is shown in Figure 5.2.
In order to find the beginning of a C/A code in the received signal only a
very limited data record is needed such as 1 ms. If there is no Doppler effect
on the received signal, then one millisecond of data contains all the 1,023 chips.
Different C/A codes are used for different satellites. The C/A code belongs to
the family of Gold codes,(5) which will be discussed in the next section.
Figure 5.3 shows the GPS data format. The first row shows a C/A code with
1,023 chips; the total length is 1 ms. The second row shows a navigation data
bit that has a data rate of 50 Hz; thus, a data bit is 20 ms long and contains
20 C/A codes. Thirty data bits make a word that is 600 ms long as shown in
the third row. Ten words make a subframe that is 6 seconds long as shown in
row four. The fifth row shows a page that is 30 seconds long and contains 5
subframes. Twenty-five pages make a complete data set that is 12.5 minutes
long as shown in the sixth row. The 25 pages of data can be referred to as a
superframe.
- Tom's haiku version:
atomic clocks fly
coded signals drop from space
position is time
/tvb
----- Original Message -----
From: "Bob kb8tq" kb8tq@n1k.org
To: "Discussion of precise time and frequency measurement" time-nuts@febo.com
Sent: Thursday, November 30, 2017 2:14 PM
Subject: Re: [time-nuts] Trimble Mini-T Timing Glitches
Hi
I’d freely admit it is very much the “Cliff notes” version of what is
happening.
Bob
On Nov 30, 2017, at 4:31 PM, Leo Bodnar leo@leobodnar.com wrote:
Bob, this is quite an unorthodox description of how GPS works.
You probably want to rephrase that before it gets ripped to shreds.
Leo
From: Bob kb8tq kb8tq@n1k.org
GPS extracts time and location by locking on to various codes in the transmissions.
One of them happens to run at about a 1 KHz clock rate. A slip on that part of the
process gives you a (modulo) 1 ms clock jump. Certain types of interference may
“help” the receiver make these sorts of mistakes.
On Thu, 30 Nov 2017 21:31:54 +0000
Leo Bodnar leo@leobodnar.com wrote:
From: Bob kb8tq kb8tq@n1k.org
GPS extracts time and location by locking on to various codes in the transmissions.
One of them happens to run at about a 1 KHz clock rate. A slip on that part of the
process gives you a (modulo) 1 ms clock jump. Certain types of interference may
“help” the receiver make these sorts of mistakes.
Bob, this is quite an unorthodox description of how GPS works.
You probably want to rephrase that before it gets ripped to shreds.
Actually, that's a pretty accurate, two sentence description.
It wouldnt be possible to build a GPS receiver using this, but
it's ok for the purpose.
On Thu, 30 Nov 2017 23:05:55 +0000
Leo Bodnar leo@leobodnar.com wrote:
I can't see how randomly selected 1ms of data can contain unambiguously detectable start of C/A code.
If NAV data bit phase flip occurred within this 1ms of data then correlation search will most probably fail.
Yes, the probability of this is only 5% (assuming equal number of 1s and 0s in NAV message) but still not zero.
Perhaps the quote should have added "carefully chosen 1ms of data"
The C/A code repeates every 1ms. The decoder cannot tell the repetitions
themselves appart at all. To solve this ambiguity, the decoder has to wait
for the flip caused by the tranmitted data, that happens exactly at those
1ms boundaries. As you noted, they happen only every 20ms (50baud data).
So, if you take these bit flips into account, there is now a 20ms ambiguity.
To resolve this, one has to wait for a start of frame (Preamble of the TLM
in GPS-speak), which then gives an 6s amibiguitiy, but as the data frame
contains the current time, the ambiguity can be completely resolved.
Now, depending on how the decoder is organized, it is totally possible,
that the decoder jumps by 1ms. Why doesn't this cause a loss of correltation?
Because most modern receivers use multiple C/A code-blocks for corrlation.
Correlation times of 10ms or 20ms are pretty normal, 100ms are not unheard of.
Thus, when using such long correlation times, slipping by 1ms will only cause
a slight degradation of C/N0 but it will still sufficiently high.
And also the data will decode correctly, because it's just a 5% (or -1.45dB)
loss of signal assuming 20ms correlation time[1].
I've encountered modern receivers (aka not older than 5 years), that slip
by 1ms under certain conditions.
At the minimum, one would typically select 2ms of sampled data when they are doing a correlation search and then
they are guaranteed a full PRN sequence somewhere in there.
2ms is actually a pretty bad choice. If the bit flip happens within
those 2ms, then the correlation output, if perfectly matched, will
be exactly zero (assuming no noise). You have to use either 1ms
correlation times, for aquisition, or a more sophisticated method.
Section 5.8 "signal acquisition" in Kaplan and Hegarty's book[2]
contains a few common techniques with good explanations.
Attila Kinali
[1] ok, it's actually more like 10%/1.91dB loss, because the
signal during that flipped 1ms is multiplied by -1 instead of +1, so it
causes twice the amount of signal los than uncorrelated signal
[2] "Understanding GPS - Principles and Applications", 2nd ed
by Kaplan and Hegarthy, 2006
--
<JaberWorky> The bad part of Zurich is where the degenerates
throw DARK chocolate at you.
On 11/30/17 1:31 PM, Leo Bodnar wrote:
Bob, this is quite an unorthodox description of how GPS works.
You probably want to rephrase that before it gets ripped to shreds.
Leo
From: Bob kb8tq kb8tq@n1k.org
GPS extracts time and location by locking on to various codes in the transmissions.
One of them happens to run at about a 1 KHz clock rate. A slip on that part of the
process gives you a (modulo) 1 ms clock jump. Certain types of interference may
“help” the receiver make these sorts of mistakes.
I thought it was fairly accurate - the primary thing from which you get
your time reference is the C/A code epoch, which is a 1 millisecond sort
of thing. The Nav message is on top of that at 50 bps, but "GPS time"
is reckoned in "weeks and milliseconds of week" (e.g. that's what you
get out of a variety of small Novatel single board receivers).
So a lot of receivers have a basic "cycle" that runs at the epoch rate.
To generate a 1pps, you take your current nav solution to figure out how
far from the "epoch time for spacecraft #N" the "top of the second" is
at, and then jam that into a counter of some sort that delays the epoch
timing signal some number of clock ticks until the 1pps gets generated.
I suppose you could have some fancy system that takes the 1kHz ticks
from ALL currently tracked satellites, and forms some sort of average to
generate the 1pps signal.
But it's easier to take the "PN epoch sync" line, delay it by some
number of processor clocks, and generate the 1pps. Pick the strongest
signal, since the epoch sync is probably "best".
It's also likely that the "epoch sync" is latched by the processor clock
- hence hanging bridges, etc.
And all sorts of implementation idiosyncracies could confuse the "1pps
logic" into putting the wrong delay count in.
BTW, it could well be a multimillisecond delay from "epoch sync" to
"1pps" For the purposes of illustration, let's say the range to the SV
can vary by +/- 10,000km - that's 30 milliseconds light time.
So I could be tracking SV1 at the horizon, calculate my delay, and then
hiccup and now track SV2, directly overhead, but use the delay from SV1
(until the next 1pps cycle comes around).