All the satellites are at the same frequency, and they are CDMA (each
satellite has a different PN sequence on its signal)
What's the bandwidth of an individual satellite?
It may have been a different thread, but the Doppler shift is up to 2 KHz.
Even if you could tune to an individual satellite signal, you still have to
go through the whole GPS calculation in order to correct for Doppler.
--
These are my opinions, not necessarily my employer's. I hate spam.
-----Original Message-----
From: time-nuts-bounces@febo.com
[mailto:time-nuts-bounces@febo.com] On Behalf Of Hal Murray
Sent: Tuesday, November 11, 2008 10:10 AM
To: Discussion of precise time and frequency measurement
Subject: Re: [time-nuts] Checking the Frequency of a Rubidium
Oscillator
All the satellites are at the same frequency, and they are
CDMA (each
satellite has a different PN sequence on its signal)
What's the bandwidth of an individual satellite?
Megahertz (the 1 MHz C/A code + the 10MHz P/Y code)
It may have been a different thread, but the Doppler shift is
up to 2 KHz.
Even if you could tune to an individual satellite signal, you
still have to go through the whole GPS calculation in order
to correct for Doppler.
A GPS receiver actually solves for the state vector of the receiver (including the local clock error) using the raw observables from the tracking loop (code phase). The nav equations calculate (apparent) range and range rate from the known state vector of each satellite and the (estimated) state vector of the receiver. Range rate is the doppler.
The 1.xxx Megachip/second C/A code is 1023 bits long, so the classical approach is to step the receiver through all possible phases of the code, integrating at each one to see if it can detect the signal. If your integration time is, say, 10 milliseconds, it takes 10 seconds to step through them all. Once the signal is detected, the PN tracking loop tracks that signal.
If you have some a-priori knowledge of the expected code phase, that reduces your search space quite a bit.
You can also search for multiple codes at once with parallel receivers (really, parallel code tracking loops, because the RF receiver is usually just a single bit quantizer, and the same bits go to all loops), either acquiring different satellites in parallel, or speeding up the acquisition of a single satellite.
This is where the proprietary nature of each manufacturer really comes in, because time spent acquiring is time not deriving a nav fix, and in a energy sensitive design (which many GPS receivers are.. E.g. in cell phones or battery powered), time is of the essence.
For instance, if you know your approximate position and date/time, you can not bother trying to search for satellites that aren't above the horizon. If you've characterized your local oscillator properties, you might be able to do a more clever acquisition by modeling the drift.
If the cellular system can tell the receiver in the phone an approximate position and estimated range/range rate, it can greatly reduce the acquisition time. (in fact, most phones don't actually implement a full GPS receiver.. They use assistance from the cell site to acquire, and just return the raw observables, and the centralized system turns that into a position)
All very interesting stuff..
Jim
Hi Hal,
What's the bandwidth of an individual satellite?
the bandwidth is defined by the ~ 1 MHz "chipping" rate that
phase-modulates the carrier, so it's roughly 1 MHz to both sides of the
carrier (for the civilian signal). Search google images for "gps
spectrum" to see plots... :-)
Chris
On Tue, 2008-11-11 at 10:10 -0800, Hal Murray wrote:
All the satellites are at the same frequency, and they are CDMA (each
satellite has a different PN sequence on its signal)
What's the bandwidth of an individual satellite?
As said before. The carrier is chopped by a 1.023MHz PRN sequence on C/A
and a 10.23MHz chipping rate on P(Y).
--
Björn
On Tue, 2008-11-11 at 10:28 -0800, Lux, James P wrote:
A GPS receiver actually solves for the state vector of the receiver (including the local clock error) using the raw observables from the tracking loop (code phase). The nav equations calculate (apparent) range and range rate from the known state vector of each satellite and the (estimated) state vector of the receiver. Range rate is the doppler.
The 1.xxx Megachip/second C/A code is 1023 bits long, so the classical approach is to step the receiver through all possible phases of the code, integrating at each one to see if it can detect the signal. If your integration time is, say, 10 milliseconds, it takes 10 seconds to step through them all. Once the signal is detected, the PN tracking loop tracks that signal.
You also need to check different doppler bins. 500Hz bins are a classic
choice.
--
Björn
Björn Gabrielsson skrev:
On Tue, 2008-11-11 at 10:28 -0800, Lux, James P wrote:
A GPS receiver actually solves for the state vector of the receiver (including the local clock error) using the raw observables from the tracking loop (code phase). The nav equations calculate (apparent) range and range rate from the known state vector of each satellite and the (estimated) state vector of the receiver. Range rate is the doppler.
The 1.xxx Megachip/second C/A code is 1023 bits long, so the classical approach is to step the receiver through all possible phases of the code, integrating at each one to see if it can detect the signal. If your integration time is, say, 10 milliseconds, it takes 10 seconds to step through them all. Once the signal is detected, the PN tracking loop tracks that signal.
You also need to check different doppler bins. 500Hz bins are a classic
choice.
To elaborate on that. The C/A code is 1023 chips long, at 1,023
MChips/s which cause a cycle period of 1 ms. If you now consider
sampling at 1 ms, the sampling rate is 1 kHz giving the Nyquist
frequency of 500 Hz and thus 500 Hz doppler bins. For a earth bound GPS
receiver, as extreme as 6 kHz doppler offsets can be seen on the
carrier. The chipping rate shift is 1/1540 as low, so it can be almost
neglected in comparision.
The traditional search is a two-dimensional search in doppler bins +/-
6000 Hz in 500 Hz blocks and 0-1022 phase stages for each of 1-32 PRN
codes. a search space totaling of 818400 combinations taking 818,4 s for
a single integrator and 1/N for N integrators so roughly a minute or two
for a now classic receiver of 8 to 12 channels. A more efficient
algorithm is to sample the signal, FFT it and make the correlation in
the frequency domain. It will crank out the phase and correlation
amplitude for each PRN attempted with much less processing. This needs
ot be performed for each doppler bin, but is certainly worthwhile the
effort. Extending the search for all the WAAS/EGNOS sats is trivial and
worthwhile.
Once doppler bin and phase has been achieved for each PRN, picking the
top N correlations and initiate channels is a quick process. The
correlation phase can be initiated into the channel together with a
rought initial frequency guess from the doppler bin and phase locking is
quickly achieved in a traditional correlation channel. Data channel
phase locking is the next thing, but that hunt is quickly achieved. This
can be aided by having an existing total lock in which case even
fundamental things such as bit phase on pseudo-code has a very limitied
range between sats. A very rought idea of current position can give a
correct model of full subcode phase.
A sat based receiver must handle higher doppler offsets due to its
higher speed, but as long as the per channel mix-down carrier NCO can be
set wide enought, and that search patterns include the needed range, it
will not be much of a problem. Naturally, tracking PLLs needs to handle
the higher dynamics. As the orbit is fairly stable, orbit predictions
can be fed into loop for better performance as it allows tighter bandwidth.
The full benefit of code and carrier phase measurements should be used.
Also, considering L2C is becomming more and more common, it should also
be used. Preparation for L1C should also be done.
As for signal bandwidth, while the C/A chiping rate is 1,023 MChips/s,
we can expect a 2,046 MHz range between the first nulls offset from the
carrier. However, the traditional sats uses a full 20,46 MHz bandwidth
since it also transmitts the P(Y) code. Buliding a receiver that uses
the full bandwidth provides certain benefits, but standard off the shelf
chips usually stays within 2,046 MHz. The front end design is basically
the same thought, just 10 MHz higher bandwidth. For civilian receivers,
only code-less tracking receivers usually have that bandwidht.
Modern GPS signals extend to a 24 MHz bandwidth. It is especially the
M-code that mandates this shift. The M-code should be of no major
interest for civilian receivers.
Sorry for the short write-up, but there is certainly more to tell about
this.
Cheers,
Magnus
In message 491A210B.30401@rubidium.dyndns.org, Magnus Danielson writes:
Once doppler bin and phase has been achieved for each PRN, [...]
Just a footnote to say that as soon as you start receiving ephemerides
from the first sat, the search-space can be significantly reduced
if you care to do the, rather longhaired, trignometric math.
A sat based receiver must handle higher doppler offsets due to its
higher speed, [...]
While this is true for any non-geo-stationary satellite, it may not
be true for the project the initial poster talked about.
As I remember it, he said that the mission would be in an earth-following
orbit, ie: in the same orbit as the earth around the sun, but
trailing it by some distance.
Given that the distance in GPS terms is "vast" and furthermore that
the GPS orbits have a pretty steep angle relative to the earths
orbital path, I would expect the doppler offsets to be much smaller
than here on earth.
Obviously, getting a position fix will suck with the worst
DOP seen to date, but a frequency fix should not be out
of the question.
Obviously, the situation on the way to the final orbit is entirely
different, and there I would expect doppler to be totally out
of the lower end of the window.
Remember to figure out the relevant relativistic corrections.
Poul-Henning
--
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.
GEEZ,
After all this discussion, it sounds like he should consider 2 Cs space devices,
one main and a secondary.
Bill....WB6BNQ
Poul-Henning Kamp wrote:
In message 491A210B.30401@rubidium.dyndns.org, Magnus Danielson writes:
Once doppler bin and phase has been achieved for each PRN, [...]
Just a footnote to say that as soon as you start receiving ephemerides
from the first sat, the search-space can be significantly reduced
if you care to do the, rather longhaired, trignometric math.
A sat based receiver must handle higher doppler offsets due to its
higher speed, [...]
While this is true for any non-geo-stationary satellite, it may not
be true for the project the initial poster talked about.
As I remember it, he said that the mission would be in an earth-following
orbit, ie: in the same orbit as the earth around the sun, but
trailing it by some distance.
Given that the distance in GPS terms is "vast" and furthermore that
the GPS orbits have a pretty steep angle relative to the earths
orbital path, I would expect the doppler offsets to be much smaller
than here on earth.
Obviously, getting a position fix will suck with the worst
DOP seen to date, but a frequency fix should not be out
of the question.
Obviously, the situation on the way to the final orbit is entirely
different, and there I would expect doppler to be totally out
of the lower end of the window.
Remember to figure out the relevant relativistic corrections.
Poul-Henning
--
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.
Poul-Henning Kamp skrev:
In message 491A210B.30401@rubidium.dyndns.org, Magnus Danielson writes:
Once doppler bin and phase has been achieved for each PRN, [...]
Just a footnote to say that as soon as you start receiving ephemerides
from the first sat, the search-space can be significantly reduced
if you care to do the, rather longhaired, trignometric math.
True, but breaking into the code phase for each sat is nowdays fairly
quick, and after setting up the receive channels the rest is much more
parallelized. It is simply just quicker to do the code phase break in
and start tracking than receiving the ephemerides data from the first
sat. The time it takes for a calender to be received is fairly long.
A sat based receiver must handle higher doppler offsets due to its
higher speed, [...]
While this is true for any non-geo-stationary satellite, it may not
be true for the project the initial poster talked about.
As I remember it, he said that the mission would be in an earth-following
orbit, ie: in the same orbit as the earth around the sun, but
trailing it by some distance.
That was never clear in my mind. Ah well, if so then that part would not
need any specific modifications, not that they are particular hard.
However, which ever orbit we are discussing, the doppler aspect needs to
be studied.
Given that the distance in GPS terms is "vast" and furthermore that
the GPS orbits have a pretty steep angle relative to the earths
orbital path, I would expect the doppler offsets to be much smaller
than here on earth.
Another aspect to remember is that there is usually a earth bound
assumption used to bootstrap the position calculation. This would
naturally need to be adapted. Fortunately it can be adapted and tested
very easily if needed.
Obviously, getting a position fix will suck with the worst
DOP seen to date, but a frequency fix should not be out
of the question.
Obviously, the situation on the way to the final orbit is entirely
different, and there I would expect doppler to be totally out
of the lower end of the window.
Actually, you can expect both ends of the doppler spectrum. As long as
you are below the GPS sats, you will also see high positive dopplers as
you goes towards them and negative from those you are leaving behind. As
you go past them, all will show up on the negative side. However, those
closest to you will not be looking at you any more due to directivity of
the antenna array.
Remember to figure out the relevant relativistic corrections.
There are several relativistic corrections that needs to be considered.
Also, while the sat is in transit to its final orbit one can expect
these to be with a higher dynamic than a circular orbit. An elliptic
orbit would always need orbit-based relativistic correction for that
extra correctness.
The intended orbit and transit-orbit is certainly of great importance
for a number of key processing requirements. It is however not extremely
hard to handle it.
Cheers,
Magnus
WB6BNQ skrev:
GEEZ,
After all this discussion, it sounds like he should consider 2 Cs space devices,
one main and a secondary.
Actually, I would pick rubidium sources unless extreme stability and
offset is needed. The longer lifetime and less weight compared to Cs
devices would be a better fit. Another option would be to use an OCXO
and tune it over the telemetry channel which may prove sufficient if
telemetry is timely spaced such that worst case drifts can be
compensated out. The benefit in weight of such a solution is even
greater. Weight and power budget is much more limiting factor than any
of the labs we guys run.
Cheers,
Magnus