time-nuts@lists.febo.com

Discussion of precise time and frequency measurement

View all threads

Re: [time-nuts] Checking the Frequency of a Rubidium Oscillator

HM
Hal Murray
Tue, Nov 11, 2008 6:10 PM

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.

> 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.
LJ
Lux, James P
Tue, Nov 11, 2008 6:28 PM

-----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

> -----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
CV
Christian Vogel
Tue, Nov 11, 2008 6:29 PM

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
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
BG
Björn Gabrielsson
Tue, Nov 11, 2008 6:32 PM

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: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
BG
Björn Gabrielsson
Tue, Nov 11, 2008 6:37 PM

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

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
MD
Magnus Danielson
Wed, Nov 12, 2008 12:19 AM

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

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
PK
Poul-Henning Kamp
Wed, Nov 12, 2008 1:23 AM

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.

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.
W
WB6BNQ
Wed, Nov 12, 2008 1:59 AM

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.

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.
MD
Magnus Danielson
Wed, Nov 12, 2008 7:33 AM

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

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
MD
Magnus Danielson
Wed, Nov 12, 2008 7:40 AM

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

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