| Author |
Message |
Jason Martin
Guest
|
 Posted:
Fri Apr 01, 2005 1:58 pm Post subject:
calculating pseudorange |
|
|
Hi there,
I am a student working on a project that deals with GPS and am trying to
understand how the pseudorange from the receiver to a satellite is
calculated. All of the explanations I have found have been fairly
vauge. What I do understand at this point is that (without taking in
clock and atomospheric errors) the receiver and satellite generate the
PRN at the same time and that by using cross-correlation, the time
difference between when the PRN was generated by the receiver and when
the PRN from the satellite was received can be determined. I also
understand that the PRN is 1023 bits long and is transmitted at
1.023MHz, which means that it is repeated every millisecond.
As an example, let's assume that there is a 3-bit "time" difference
between when the PRN was generated by the receiver and when the PRN was
received from the satellite. The corresponding time difference would
then be approximately 3 microseconds. If we multiply this by the speed
of light, we obtain 0.9km. This is, however, far from the distance to
the satellite (around 20,000km). Can anyone explain to me how the
"real" distance to the satellite is calculated, perhaps using my
example? Right now, I'm not interested in removing any errors, I just
want to understand how the complete pseudorange is calculated.
Thanks in advance!
Jason |
|
| Back to top |
|
 |
Sam Wormley
Guest
|
| Posted:
Sat Apr 02, 2005 4:59 am Post subject:
Re: calculating pseudorange |
|
|
Jason Martin wrote:
| Quote: | Hi there,
I am a student working on a project that deals with GPS and am trying to
understand how the pseudorange from the receiver to a satellite is
calculated. All of the explanations I have found have been fairly
vauge. What I do understand at this point is that (without taking in
clock and atomospheric errors) the receiver and satellite generate the
PRN at the same time and that by using cross-correlation, the time
difference between when the PRN was generated by the receiver and when
the PRN from the satellite was received can be determined. I also
understand that the PRN is 1023 bits long and is transmitted at
1.023MHz, which means that it is repeated every millisecond.
As an example, let's assume that there is a 3-bit "time" difference
between when the PRN was generated by the receiver and when the PRN was
received from the satellite. The corresponding time difference would
then be approximately 3 microseconds. If we multiply this by the speed
of light, we obtain 0.9km. This is, however, far from the distance to
the satellite (around 20,000km). Can anyone explain to me how the
"real" distance to the satellite is calculated, perhaps using my
example? Right now, I'm not interested in removing any errors, I just
want to understand how the complete pseudorange is calculated.
Thanks in advance!
Jason
|
Take a look at:
http://www.colorado.edu/geography/gcraft/notes/gps/gps.html
http://www.navcen.uscg.gov/pubs/gps/gpsuser/gpsuser.pdf
-Sam Wormley
http://edu-observatory.org/eo/books.html |
|
| Back to top |
|
|
John
Guest
|
| Posted:
Tue Apr 05, 2005 3:01 am Post subject:
Re: calculating pseudorange |
|
|
For an additional perspective, take a look at the raw data provided by
Trimble's SK II receiver. Their description of record 0x5a talks about
how to convert correlator output into a pseudorange.
http:/tr1.trimble.com/docushare/dsweb/Get/Document-9998/lassensk2man.pdf |
|
| Back to top |
|
|
Jason Martin
Guest
|
| Posted:
Mon Apr 11, 2005 8:55 am Post subject:
Re: calculating pseudorange |
|
|
John wrote:
| Quote: | For an additional perspective, take a look at the raw data provided by
Trimble's SK II receiver. Their description of record 0x5a talks about
how to convert correlator output into a pseudorange.
http:/tr1.trimble.com/docushare/dsweb/Get/Document-9998/lassensk2man.pdf
Thanks for your replies, |
I think that I understand now how the pseudorange to a satellite is
calculated to a certian point, but if someone could look over the
example below to see if I am explaining it right, I'd appreciate it very
much (I'm writing a report in which I need to summerize the pseudorange
calculation process).
As an example, the GPS receiver locks onto a Satellite and obtains
full-correlation by shifting the receiver PRN by 3 bits, which
translates to a distance of approximately 0.9km:
C/A-code chip length = ~300 meters * 3 = 0.9 km
However, the satellites orbit at 20,200km which means that there is a
big ambiguity here. This is because the length of the C/A-code is about
300km, which means the maximal range obtainable through correlation
alone is 300km. In order to calculate the "real" distance to the
satellite, we must know when this 300km-long C/A-code left the satellite
and when we received it. The receiver knows when we recieved the PRN but
in order to find out when the PRN left the satellite, we must use the
navigation message. The navigation message is synchronized with the PRN
code. It consists of 37500 bits that are evenly divided into 25,
1500-bit frames. Each frame consists of 5, 300-bit subframes. At the
beginning of each subframe, we can determine when it (the subframe) left
the satellite (TOW). This also means, that the receiver knows when each
"bit" of each subframe left the satellite. A bit of the navigation
message takes 20 milliseconds to transmit. This means that 20 C/A-codes
are transmitted in the same period of time. At this point we have an
unambiguous range of 6000km.
0.02 sec * 300,000km = 6000km
So, at this point, I'm not exactly sure what happens. I am also not
sure when the correlation factor of 0.9km comes into play? One
explination I found said that this comes into play once the distances to
4 satellites have been determined to with 300km, but I'd appreciate it
if anyone could tell me where to go from here.
Thanks!
Jason |
|
| Back to top |
|
|
Keith Sheppard
Guest
|
| Posted:
Mon Apr 11, 2005 9:34 am Post subject:
Re: calculating pseudorange |
|
|
My apologies for a slightly irrelevant response but I can't help feeling
that "pseudorange" needs an apostrophe to stop it looking like "an
artificial fruit of the citrus family".
Keith |
|
| Back to top |
|
|
Jason Martin
Guest
|
| Posted:
Mon Apr 11, 2005 9:41 am Post subject:
Re: calculating pseudorange |
|
|
Keith Sheppard wrote:
| Quote: | My apologies for a slightly irrelevant response but I can't help feeling
that "pseudorange" needs an apostrophe to stop it looking like "an
artificial fruit of the citrus family".
Keith
:).... you're probaly right! |
Jason |
|
| Back to top |
|
|
Jim Heckman
Guest
|
| Posted:
Tue Apr 12, 2005 2:37 am Post subject:
Re: calculating pseudorange |
|
|
On 11-Apr-2005, Jason Martin <jason.d.martin@informatik-uni-oldenburg.de>
wrote in message <425a3b68$0$21454$9b622d9e@news.freenet.de>:
| Quote: | Thanks for your replies,
I think that I understand now how the pseudorange to a satellite is
calculated to a certian point, but if someone could look over the
example below to see if I am explaining it right, I'd appreciate it very
much (I'm writing a report in which I need to summerize the pseudorange
calculation process).
As an example, the GPS receiver locks onto a Satellite and obtains
full-correlation by shifting the receiver PRN by 3 bits, which
translates to a distance of approximately 0.9km:
C/A-code chip length = ~300 meters * 3 = 0.9 km
However, the satellites orbit at 20,200km which means that there is a
big ambiguity here. This is because the length of the C/A-code is about
300km, which means the maximal range obtainable through correlation
alone is 300km. In order to calculate the "real" distance to the
satellite, we must know when this 300km-long C/A-code left the satellite
and when we received it. The receiver knows when we recieved the PRN but
in order to find out when the PRN left the satellite, we must use the
navigation message. The navigation message is synchronized with the PRN
code. It consists of 37500 bits that are evenly divided into 25,
1500-bit frames. Each frame consists of 5, 300-bit subframes. At the
beginning of each subframe, we can determine when it (the subframe) left
the satellite (TOW). This also means, that the receiver knows when each
"bit" of each subframe left the satellite. A bit of the navigation
message takes 20 milliseconds to transmit. This means that 20 C/A-codes
are transmitted in the same period of time. At this point we have an
unambiguous range of 6000km.
0.02 sec * 300,000km = 6000km
So, at this point, I'm not exactly sure what happens. I am also not
sure when the correlation factor of 0.9km comes into play? One
explination I found said that this comes into play once the distances to
4 satellites have been determined to with 300km, but I'd appreciate it
if anyone could tell me where to go from here.
Thanks!
|
Perhaps a better way to think of it is that a sat's pseudo-range
is the difference between the time of its transmission and the
time of its reception (multiplied by the speed of light if you
want to work in distance units instead of time units).
A receiver first slides its local PRN code generator around
until it locates the sat's signal; this tells it the
pseudo-range modulo the C/A code length of 1 ms ~ 300 km. Say,
as per your example, the receiver had to slide its generator by
3 code bits ~ 0.9 km; it then knows the pseudo-range is 0.9 km
or 300.9 km or 600.9 km or ... Next, the receiver performs "bit
sync" by looking for the data bit transitions in the signal;
this tells it the pseudo-range modulo the data bit length of 20
ms ~ 6000 km. For example, suppose the receiver finds the bit
transitions 7 C/A code lengths (out of a possible 0-19) ~ 2100
km away from where it started searching; now it knows the
pseudo-range is 2100.9 km or 8100.9 km or 14,100.9 km or ...
Finally, the receiver decodes the TOW to get the real
pseudo-range.
Of course, the pseudo-ranges don't really do much good until the
receiver has decoded the sats' ephemerides, which tell it where
they are. Then it can say, for example, "OK, sat 1 is located at
X1,Y1,Z1 and is 2345.6 km further away than sat 2, which is
located at X2,Y2,Z2, and 7654.3 km closer than sat 3, which is
located at X3,Y3,Z3, ...", so now it can figure out its own
position.
--
Jim Heckman |
|
| Back to top |
|
|
Guest
|
| Posted:
Tue Apr 12, 2005 7:32 am Post subject:
Re: calculating pseudorange |
|
|
On Mon, 11 Apr 2005 11:41:08 +0200, Jason Martin
<jason.d.martin@informatik-uni-oldenburg.de> wrote:
| Quote: | Keith Sheppard wrote:
My apologies for a slightly irrelevant response but I can't help feeling
that "pseudorange" needs an apostrophe to stop it looking like "an
artificial fruit of the citrus family".
Keith
:).... you're probaly right!
Jason
|
But only f he uses a hyphen, not an apostrophe. |
|
| Back to top |
|
|
Jason Martin
Guest
|
| Posted:
Wed Apr 13, 2005 1:50 pm Post subject:
Re: calculating pseudorange |
|
|
Jim Heckman wrote:
| Quote: | On 11-Apr-2005, Jason Martin <jason.d.martin@informatik-uni-oldenburg.de
wrote in message <425a3b68$0$21454$9b622d9e@news.freenet.de>:
Thanks for your replies,
I think that I understand now how the pseudorange to a satellite is
calculated to a certian point, but if someone could look over the
example below to see if I am explaining it right, I'd appreciate it very
much (I'm writing a report in which I need to summerize the pseudorange
calculation process).
As an example, the GPS receiver locks onto a Satellite and obtains
full-correlation by shifting the receiver PRN by 3 bits, which
translates to a distance of approximately 0.9km:
C/A-code chip length = ~300 meters * 3 = 0.9 km
However, the satellites orbit at 20,200km which means that there is a
big ambiguity here. This is because the length of the C/A-code is about
300km, which means the maximal range obtainable through correlation
alone is 300km. In order to calculate the "real" distance to the
satellite, we must know when this 300km-long C/A-code left the satellite
and when we received it. The receiver knows when we recieved the PRN but
in order to find out when the PRN left the satellite, we must use the
navigation message. The navigation message is synchronized with the PRN
code. It consists of 37500 bits that are evenly divided into 25,
1500-bit frames. Each frame consists of 5, 300-bit subframes. At the
beginning of each subframe, we can determine when it (the subframe) left
the satellite (TOW). This also means, that the receiver knows when each
"bit" of each subframe left the satellite. A bit of the navigation
message takes 20 milliseconds to transmit. This means that 20 C/A-codes
are transmitted in the same period of time. At this point we have an
unambiguous range of 6000km.
0.02 sec * 300,000km = 6000km
So, at this point, I'm not exactly sure what happens. I am also not
sure when the correlation factor of 0.9km comes into play? One
explination I found said that this comes into play once the distances to
4 satellites have been determined to with 300km, but I'd appreciate it
if anyone could tell me where to go from here.
Thanks!
Perhaps a better way to think of it is that a sat's pseudo-range
is the difference between the time of its transmission and the
time of its reception (multiplied by the speed of light if you
want to work in distance units instead of time units).
A receiver first slides its local PRN code generator around
until it locates the sat's signal; this tells it the
pseudo-range modulo the C/A code length of 1 ms ~ 300 km. Say,
as per your example, the receiver had to slide its generator by
3 code bits ~ 0.9 km; it then knows the pseudo-range is 0.9 km
or 300.9 km or 600.9 km or ... Next, the receiver performs "bit
sync" by looking for the data bit transitions in the signal;
this tells it the pseudo-range modulo the data bit length of 20
ms ~ 6000 km. For example, suppose the receiver finds the bit
transitions 7 C/A code lengths (out of a possible 0-19) ~ 2100
km away from where it started searching; now it knows the
pseudo-range is 2100.9 km or 8100.9 km or 14,100.9 km or ...
Finally, the receiver decodes the TOW to get the real
pseudo-range.
Of course, the pseudo-ranges don't really do much good until the
receiver has decoded the sats' ephemerides, which tell it where
they are. Then it can say, for example, "OK, sat 1 is located at
X1,Y1,Z1 and is 2345.6 km further away than sat 2, which is
located at X2,Y2,Z2, and 7654.3 km closer than sat 3, which is
located at X3,Y3,Z3, ...", so now it can figure out its own
position.
|
Hi Jim, thanks for your reply!
can you tell me a little bit more about how the TOW is used to get the
real pseudorange? For example, how the receiver decides wheather the
distance is 2100.9 or 8100.9 or 14,100.9 or.....
Thanks!!
Jason |
|
| Back to top |
|
|
Jim Heckman
Guest
|
| Posted:
Thu Apr 14, 2005 11:32 am Post subject:
Re: calculating pseudorange |
|
|
On 13-Apr-2005, Jason Martin <jason.d.martin@informatik-uni-oldenburg.de>
wrote in message <425d239c$0$21554$9b622d9e@news.freenet.de>:
| Quote: | Jim Heckman wrote:
|
[...]
| Quote: | Perhaps a better way to think of it is that a sat's pseudo-range
is the difference between the time of its transmission and the
time of its reception (multiplied by the speed of light if you
want to work in distance units instead of time units).
A receiver first slides its local PRN code generator around
until it locates the sat's signal; this tells it the
pseudo-range modulo the C/A code length of 1 ms ~ 300 km. Say,
as per your example, the receiver had to slide its generator by
3 code bits ~ 0.9 km; it then knows the pseudo-range is 0.9 km
or 300.9 km or 600.9 km or ... Next, the receiver performs "bit
sync" by looking for the data bit transitions in the signal;
this tells it the pseudo-range modulo the data bit length of 20
ms ~ 6000 km. For example, suppose the receiver finds the bit
transitions 7 C/A code lengths (out of a possible 0-19) ~ 2100
km away from where it started searching; now it knows the
pseudo-range is 2100.9 km or 8100.9 km or 14,100.9 km or ...
Finally, the receiver decodes the TOW to get the real
pseudo-range.
Of course, the pseudo-ranges don't really do much good until the
receiver has decoded the sats' ephemerides, which tell it where
they are. Then it can say, for example, "OK, sat 1 is located at
X1,Y1,Z1 and is 2345.6 km further away than sat 2, which is
located at X2,Y2,Z2, and 7654.3 km closer than sat 3, which is
located at X3,Y3,Z3, ...", so now it can figure out its own
position.
Hi Jim, thanks for your reply!
can you tell me a little bit more about how the TOW is used to get the
real pseudorange? For example, how the receiver decides wheather the
distance is 2100.9 or 8100.9 or 14,100.9 or.....
|
OK. After thinking more about it, I like the analogy that the
different stages of acquiring the pseudo-range are like
determining the digits on a digital clock, in reverse order. He
starts by sliding his local C/A PRN code around and finds the
sat 3 code chips away -- actually, let's say 3.5, since good
receivers can usually resolve to about a tenth of a chip. That's
3.5/~1000 of a msec, so the least significant figure of the
pseudo-range is 3.5 mcsec = 0.0035 msec, and the pseudo-range
itself is 0.0035 msec, or 1.00035 msec, or 2.0035 msec, or ...
Next, he searches for data bit transitions super-imposed on, and
aligned with, the C/A code. (I.e., data bit edges always occur
at the beginning of a 1-msec C/A code period, and data bits last
20 msec.) He finds the data bit edges at 7 msec, and now the
pseudo-range is known to be 7.0035 msec, or 27.0035 msec, or
47.0035 msec, or ... At this point, the data stream is just a
series of 0's and 1's, and he needs to figure out where he is in
it. He looks for the HandOver Word (HOW), a pattern which occurs
at the beginning of every subframe, i.e. every 6 sec, and finds
it at 2.46 seconds, so now he knows the pseudo-range is
2.4670035 sec, or 8.4670035 sec, or 14.4670035 sec, or ... If he
has a really good local clock, i.e. if he knows his clock is good to
within 3 sec, he now knows the exact pseudo-range. If he doesn't
trust his own clock that well, he has to decode the TOW, which
occurs in the data stream right after the HOW, and is in units
of 6 sec, the subframe length. (Actually, in practice, most
receivers don't trust the HOW until they find one with a TOW
right after it, then another HOW and TOW 6 seconds later, all
correctly parity checked -- since other data in the stream can
sometimes mimic the HOW pattern.) In our hypothetical case, he
finds the TOW to be, say Monday, 12:34:54 pm (must be a multiple
of 6 sec). He compares that with his local clock, which says
Monday, 12:39:03 pm -- off by 00:04:09. But he knows his
pseudo-range must be 2.4670035 sec, or ..., so he picks the
closest one to 00:04:09, i.e. 00:04:08.4670035. At this point,
most receivers reset their local clock to be the sat's transmit
time + ~80 msec, the average time of flight to a sat -- so they
can show the user a more accurate time right away -- and correct
the pseudo-range accordingly. Let's say our receiver does that,
so he corrects his local clock by 00:04:08.40 sec and his
pseudo-range to 67.0035 msec. Now, lather, rinse and repeat for
the other visible sats. Say he finds sat 2 to have a
pseudo-range of 78.9012 msec, sat 3 to have 89.0123 msec, etc.
He says, "Aha, from the ephemerides I know sat 1 is at position
X1,Y1,Z1, sat 2 at X2,Y2,Z2 and sat 3 at X3,Y3,Z3, and from the
pseudo-ranges I know that sat 1 is 78.9012 - 67.0035 = 11.8977
msec ~= 3569.10 km closer to me than sat 2 is, and 89.0123 -
67.0035 = 22.0088 msec ~= 6602.64 km closer than sat 3, so
I must be at position X,Y,Z! And since I now know my own
position, I know the exact time of flight from each sat, so I
can correct my first guesstimate of my local time from being sat
1 transmit time + 80 msec to sat 1 transmit time +, say,
70.1234 msec, good to ~0.0001 msec = 100 nsec.
--
Jim Heckman |
|
| Back to top |
|
|
Jason Martin
Guest
|
| Posted:
Thu Apr 14, 2005 4:07 pm Post subject:
Re: calculating pseudorange |
|
|
Jim Heckman wrote:
| Quote: | On 13-Apr-2005, Jason Martin <jason.d.martin@informatik-uni-oldenburg.de
wrote in message <425d239c$0$21554$9b622d9e@news.freenet.de>:
Jim Heckman wrote:
[...]
Perhaps a better way to think of it is that a sat's pseudo-range
is the difference between the time of its transmission and the
time of its reception (multiplied by the speed of light if you
want to work in distance units instead of time units).
A receiver first slides its local PRN code generator around
until it locates the sat's signal; this tells it the
pseudo-range modulo the C/A code length of 1 ms ~ 300 km. Say,
as per your example, the receiver had to slide its generator by
3 code bits ~ 0.9 km; it then knows the pseudo-range is 0.9 km
or 300.9 km or 600.9 km or ... Next, the receiver performs "bit
sync" by looking for the data bit transitions in the signal;
this tells it the pseudo-range modulo the data bit length of 20
ms ~ 6000 km. For example, suppose the receiver finds the bit
transitions 7 C/A code lengths (out of a possible 0-19) ~ 2100
km away from where it started searching; now it knows the
pseudo-range is 2100.9 km or 8100.9 km or 14,100.9 km or ...
Finally, the receiver decodes the TOW to get the real
pseudo-range.
Of course, the pseudo-ranges don't really do much good until the
receiver has decoded the sats' ephemerides, which tell it where
they are. Then it can say, for example, "OK, sat 1 is located at
X1,Y1,Z1 and is 2345.6 km further away than sat 2, which is
located at X2,Y2,Z2, and 7654.3 km closer than sat 3, which is
located at X3,Y3,Z3, ...", so now it can figure out its own
position.
Hi Jim, thanks for your reply!
can you tell me a little bit more about how the TOW is used to get the
real pseudorange? For example, how the receiver decides wheather the
distance is 2100.9 or 8100.9 or 14,100.9 or.....
OK. After thinking more about it, I like the analogy that the
different stages of acquiring the pseudo-range are like
determining the digits on a digital clock, in reverse order. He
starts by sliding his local C/A PRN code around and finds the
sat 3 code chips away -- actually, let's say 3.5, since good
receivers can usually resolve to about a tenth of a chip. That's
3.5/~1000 of a msec, so the least significant figure of the
pseudo-range is 3.5 mcsec = 0.0035 msec, and the pseudo-range
itself is 0.0035 msec, or 1.00035 msec, or 2.0035 msec, or ...
Next, he searches for data bit transitions super-imposed on, and
aligned with, the C/A code. (I.e., data bit edges always occur
at the beginning of a 1-msec C/A code period, and data bits last
20 msec.) He finds the data bit edges at 7 msec, and now the
pseudo-range is known to be 7.0035 msec, or 27.0035 msec, or
47.0035 msec, or ... At this point, the data stream is just a
series of 0's and 1's, and he needs to figure out where he is in
it. He looks for the HandOver Word (HOW), a pattern which occurs
at the beginning of every subframe, i.e. every 6 sec, and finds
it at 2.46 seconds, so now he knows the pseudo-range is
2.4670035 sec, or 8.4670035 sec, or 14.4670035 sec, or ... If he
has a really good local clock, i.e. if he knows his clock is good to
within 3 sec, he now knows the exact pseudo-range. If he doesn't
trust his own clock that well, he has to decode the TOW, which
occurs in the data stream right after the HOW, and is in units
of 6 sec, the subframe length. (Actually, in practice, most
receivers don't trust the HOW until they find one with a TOW
right after it, then another HOW and TOW 6 seconds later, all
correctly parity checked -- since other data in the stream can
sometimes mimic the HOW pattern.) In our hypothetical case, he
finds the TOW to be, say Monday, 12:34:54 pm (must be a multiple
of 6 sec). He compares that with his local clock, which says
Monday, 12:39:03 pm -- off by 00:04:09. But he knows his
pseudo-range must be 2.4670035 sec, or ..., so he picks the
closest one to 00:04:09, i.e. 00:04:08.4670035. At this point,
most receivers reset their local clock to be the sat's transmit
time + ~80 msec, the average time of flight to a sat -- so they
can show the user a more accurate time right away -- and correct
the pseudo-range accordingly. Let's say our receiver does that,
so he corrects his local clock by 00:04:08.40 sec and his
pseudo-range to 67.0035 msec. Now, lather, rinse and repeat for
the other visible sats. Say he finds sat 2 to have a
pseudo-range of 78.9012 msec, sat 3 to have 89.0123 msec, etc.
He says, "Aha, from the ephemerides I know sat 1 is at position
X1,Y1,Z1, sat 2 at X2,Y2,Z2 and sat 3 at X3,Y3,Z3, and from the
pseudo-ranges I know that sat 1 is 78.9012 - 67.0035 = 11.8977
msec ~= 3569.10 km closer to me than sat 2 is, and 89.0123 -
67.0035 = 22.0088 msec ~= 6602.64 km closer than sat 3, so
I must be at position X,Y,Z! And since I now know my own
position, I know the exact time of flight from each sat, so I
can correct my first guesstimate of my local time from being sat
1 transmit time + 80 msec to sat 1 transmit time +, say,
70.1234 msec, good to ~0.0001 msec = 100 nsec.
Wow Jim, thanks for the great explaination!! :) |
I understand the process much better now, however, if we assume that the
receiver and satellite clocks are exactly synchronized (or within +- 3
seconds), according to your method, we have possible pseudoranges of
2.670035 sec or 8.670035 sec or... . Even the first possibility
(2.670035 sec = ~801,000 km) goes way out of the possible distance range
-- or am I missing something totally obvious here? Forgetting a moment
about unsynchronized clocks, how do I get a resonable figure?
Using your method, however, I've thought of a different approach - each
TOW gives us the Z-count epoch at the edge of the next sub-frame. This
means that at any point in time, we know the time that the next
sub-frame will be transmitted. Therefore, if we count 2.670035 seconds
from our correlated PRN to the edge of the next subframe, then all we
have to do is subtract 2.670035 seconds from that time (the transmission
time of the next subframe) to get the time our PRN was transmitted.
This time minus the time that our reciever generated the idential PRN
multiplied by the speed of light will then give us the pseudorange
(including clock bias). Is that right or am I making it too complicated?
Thanks!
Jason |
|
| Back to top |
|
|
Jim Heckman
Guest
|
| Posted:
Sat Apr 16, 2005 11:26 am Post subject:
Re: calculating pseudorange |
|
|
On 14-Apr-2005, Jason Martin <jason.d.martin@informatik-uni-oldenburg.de>
wrote in message <425e9542$0$1991$9b622d9e@news.freenet.de>:
| Quote: | Jim Heckman wrote:
|
[...]
| Quote: | OK. After thinking more about it, I like the analogy that the
different stages of acquiring the pseudo-range are like
determining the digits on a digital clock, in reverse order. He
starts by sliding his local C/A PRN code around and finds the
sat 3 code chips away -- actually, let's say 3.5, since good
receivers can usually resolve to about a tenth of a chip. That's
3.5/~1000 of a msec, so the least significant figure of the
pseudo-range is 3.5 mcsec = 0.0035 msec, and the pseudo-range
itself is 0.0035 msec, or 1.00035 msec, or 2.0035 msec, or ...
Next, he searches for data bit transitions super-imposed on, and
aligned with, the C/A code. (I.e., data bit edges always occur
at the beginning of a 1-msec C/A code period, and data bits last
20 msec.) He finds the data bit edges at 7 msec, and now the
pseudo-range is known to be 7.0035 msec, or 27.0035 msec, or
47.0035 msec, or ... At this point, the data stream is just a
series of 0's and 1's, and he needs to figure out where he is in
it. He looks for the HandOver Word (HOW), a pattern which occurs
at the beginning of every subframe, i.e. every 6 sec, and finds
it at 2.46 seconds, so now he knows the pseudo-range is
2.4670035 sec, or 8.4670035 sec, or 14.4670035 sec, or ... If he
has a really good local clock, i.e. if he knows his clock is good to
within 3 sec, he now knows the exact pseudo-range. If he doesn't
trust his own clock that well, he has to decode the TOW, which
occurs in the data stream right after the HOW, and is in units
of 6 sec, the subframe length. (Actually, in practice, most
receivers don't trust the HOW until they find one with a TOW
right after it, then another HOW and TOW 6 seconds later, all
correctly parity checked -- since other data in the stream can
sometimes mimic the HOW pattern.) In our hypothetical case, he
finds the TOW to be, say Monday, 12:34:54 pm (must be a multiple
of 6 sec). He compares that with his local clock, which says
Monday, 12:39:03 pm -- off by 00:04:09. But he knows his
pseudo-range must be 2.4670035 sec, or ..., so he picks the
closest one to 00:04:09, i.e. 00:04:08.4670035. At this point,
most receivers reset their local clock to be the sat's transmit
time + ~80 msec, the average time of flight to a sat -- so they
can show the user a more accurate time right away -- and correct
the pseudo-range accordingly. Let's say our receiver does that,
so he corrects his local clock by 00:04:08.40 sec and his
pseudo-range to 67.0035 msec. Now, lather, rinse and repeat for
the other visible sats. Say he finds sat 2 to have a
pseudo-range of 78.9012 msec, sat 3 to have 89.0123 msec, etc.
He says, "Aha, from the ephemerides I know sat 1 is at position
X1,Y1,Z1, sat 2 at X2,Y2,Z2 and sat 3 at X3,Y3,Z3, and from the
pseudo-ranges I know that sat 1 is 78.9012 - 67.0035 = 11.8977
msec ~= 3569.10 km closer to me than sat 2 is, and 89.0123 -
67.0035 = 22.0088 msec ~= 6602.64 km closer than sat 3, so
I must be at position X,Y,Z! And since I now know my own
position, I know the exact time of flight from each sat, so I
can correct my first guesstimate of my local time from being sat
1 transmit time + 80 msec to sat 1 transmit time +, say,
70.1234 msec, good to ~0.0001 msec = 100 nsec.
Wow Jim, thanks for the great explaination!! :)
I understand the process much better now, however, if we assume that the
receiver and satellite clocks are exactly synchronized (or within +- 3
seconds), according to your method, we have possible pseudoranges of
2.[4]670035 sec or 8.[4]670035 sec or... . Even the first possibility
(2.[4]670035 sec = ~[740],000 km) goes way out of the possible distance
range
-- or am I missing something totally obvious here? Forgetting a moment
about unsynchronized clocks, how do I get a resonable figure?
|
Well, if the receiver and satellite clocks are *perfectly*
synchronized, then the receiver won't have found the sat's HOW
at 2.46 sec away from his local one. I was just using that as an
example. Instead he'll have found it at 0.06 or 0.08 sec,
corresponding to pseudo-ranges of 67.0035 or 87.0035 msec.
(I think those are both possible values for sat distances; it's
been a while since I worked as a GPS engineer and did this sort
of thing for a living.)
| Quote: | Using your method, however, I've thought of a different approach - each
TOW gives us the Z-count epoch at the edge of the next sub-frame. This
means that at any point in time, we know the time that the next
sub-frame will be transmitted. Therefore, if we count 2.670035 seconds
from our correlated PRN to the edge of the next subframe, then all we
have to do is subtract 2.670035 seconds from that time (the transmission
time of the next subframe) to get the time our PRN was transmitted.
This time minus the time that our reciever generated the idential PRN
multiplied by the speed of light will then give us the pseudorange
(including clock bias). Is that right or am I making it too complicated?
|
Yes, that's essentially just what I did. (I didn't check my
signs; I may have added when I should have subtracted here and
there, but you get the idea.) I just broke it out showing how at
each stage of the satellite acquisition you can narrow down the
possible pseudo-ranges. (Like I said, it's like finding each
digit of a digital readout, in reverse order of significance.)
Whereas your method just saves up all the info and does it all
in one fell swoop at the end.
You're welcome.
--
Jim Heckman |
|
| Back to top |
|
|
|
|
|
|
FAQ
Memberlist
Register
Profile
Log in to check your private messages
Log in