Bookmark this page: Add RINEX fundamental to Yahoo MyWeb Add RINEX fundamental to Google Bookmarks Add RINEX fundamental to Windows Live Add RINEX fundamental to Del.icio.us Digg RINEX fundamental! Add RINEX fundamental to Netscape
  •  
  • Subject
  • Author
  • Date
If you were  Registered and logged in, you could reply and use other advanced thread options
Posted by Justin on June 13, 2009, 11:18 am


So I'm working with a RINEX (v 2.11) observation file, have read the
file specification, and I seem to be missing something fundamental
somewhere.

I was doing a basic sanity check: calculating the approximate position
of the CORS antenna using its own C1 pseudorange values.

Using known ephemerides from the same time period and existing code, I
can calculate satellite positions for time of transmission which agree
with .sp3 records.

So the way I figure it, for each satellite:

C1 - (true distance from sat to receiver) approx (receiver clock
offset)

I know I'm neglecting lots of things here, (ionosphere, sat clock
offset, etc) but these should add cumulative noise which should be
well under 100m per satellite. Here's a sample of what I do see
(these are records from the same epoch):


C1: 20677980.187; D: 20726453.793; C1-D: -48473.606
C1: 24068372.685; D: 23978504.420; C1-D: 89868.265
C1: 23870644.581; D: 23707541.548; C1-D: 163103.033
C1: 23625163.959; D: 23527541.923; C1-D: 97622.036

where D is the expected range given the sat position and base station
location, C1 is the C/A pseudorange from the RINEX file, and C1-D is
the difference of the two values, which should be (roughly) the
receiver clock offset if I'm understanding things correctly.

I've tried a few different base stations, in case this particular one
is spewing insane data, but to no avail. Interestingly, the C1-D
value is consistently around +=160,000m, which is suspiciously close
to the 1 ms C/A signal length.

So, in short, I'm about 95% sure I'm just doing something stupid or
misunderstanding how the RINEX file presents data, but I sure can't
figure out where I'm going wrong. Can anyone point me in the right
direction?

Thanks,
-J

Posted by Tim Springer on June 14, 2009, 5:25 pm




> So I'm working with a RINEX (v 2.11) observation file, have read the
> file specification, and I seem to be missing something fundamental
> somewhere.
> I was doing a basic sanity check: calculating the approximate position
> of the CORS antenna using its own C1 pseudorange values.
> Using known ephemerides from the same time period and existing code, I
> can calculate satellite positions for time of transmission which agree
> with .sp3 records.
> So the way I figure it, for each satellite:
> C1 - (true distance from sat to receiver) approx (receiver clock
> offset)
> I know I'm neglecting lots of things here, (ionosphere, sat clock
> offset, etc) but these should add cumulative noise which should be
> well under 100m per satellite. Here's a sample of what I do see
> (these are records from the same epoch):
> C1: 20677980.187; D: 20726453.793; C1-D: -48473.606
> C1: 24068372.685; D: 23978504.420; C1-D: 89868.265
> C1: 23870644.581; D: 23707541.548; C1-D: 163103.033
> C1: 23625163.959; D: 23527541.923; C1-D: 97622.036
> where D is the expected range given the sat position and base station
> location, C1 is the C/A pseudorange from the RINEX file, and C1-D is
> the difference of the two values, which should be (roughly) the
> receiver clock offset if I'm understanding things correctly.
> I've tried a few different base stations, in case this particular one
> is spewing insane data, but to no avail. Interestingly, the C1-D
> value is consistently around +=160,000m, which is suspiciously close
> to the 1 ms C/A signal length.
> So, in short, I'm about 95% sure I'm just doing something stupid or
> misunderstanding how the RINEX file presents data, but I sure can't
> figure out where I'm going wrong. Can anyone point me in the right
> direction?
> Thanks,
> -J

Justin,

You should really not neglect the satellite clock offset! So the equation
you should "solve" is:
C1 = D - Clight * SatClk + Clight * StaClk

Where:
Clight = the velocity of light (roughly 300000000 m/s).
SatClk = is the satellite clock offset (also given in the SP3 file)

After that your residuals should be rather similar and reflect the station
clock.

However, an other important correction term is the travel time correction.
Here a brief explanation of that. The GPS receiver collects the data
simultaneously at some given epoch. However, given the different distances
the signals have to travel the left the satellites at different times. So in
principle one has to compute the position of the satellite at the epoch the
signal left the satellite. But to compute the travel time one needs to know
the position of the satellite in the first place. So one has to iterate this
or make a approximation (e.g. typically done using a Taylor expansion).
Given the distance of the GPS satellites the travel time around 0.06 to 0.08
seconds. The velocity of the GPS satellites is about 3000 m/s. So the effect
of this term is at the few hunderd meter level (max).

Have fun!
Tim
http://gnss.servolux.nl



Posted by Justin on June 16, 2009, 7:47 am


Tim,

I had time of transmission compensation correct; the big piece I was
missing was the satellite clock offset. Things look much more sane
now.

I spent no end of time looking for that problem...thanks for your
help!

-J



wrote:
-9fca-c1d3320d62f9@o5g2000prh.googlegroups.com...
> > So I'm working with a RINEX (v 2.11) observation file, have read the
> > file specification, and I seem to be missing something fundamental
> > somewhere.
> > I was doing a basic sanity check: calculating the approximate position
> > of the CORS antenna using its own C1 pseudorange values.
> > Using known ephemerides from the same time period and existing code, I
> > can calculate satellite positions for time of transmission which agree
> > with .sp3 records.
> > So the way I figure it, for each satellite:
> > C1 - (true distance from sat to receiver) approx (receiver clock
> > offset)
> > I know I'm neglecting lots of things here, (ionosphere, sat clock
> > offset, etc) but these should add cumulative noise which should be
> > well under 100m per satellite. =A0Here's a sample of what I do see
> > (these are records from the same epoch):
> > C1: =A020677980.187; D: =A020726453.793; C1-D: =A0-48473.606
> > C1: =A024068372.685; D: =A023978504.420; C1-D: =A0 89868.265
> > C1: =A023870644.581; D: =A023707541.548; C1-D: =A0163103.033
> > C1: =A023625163.959; D: =A023527541.923; C1-D: =A0 97622.036
> > where D is the expected range given the sat position and base station
> > location, C1 is the C/A pseudorange from the RINEX file, and C1-D is
> > the difference of the two values, which should be (roughly) the
> > receiver clock offset if I'm understanding things correctly.
> > I've tried a few different base stations, in case this particular one
> > is spewing insane data, but to no avail. =A0Interestingly, the C1-D
> > value is consistently around +=3D160,000m, which is suspiciously close
> > to the 1 ms C/A signal length.
> > So, in short, I'm about 95% sure I'm just doing something stupid or
> > misunderstanding how the RINEX file presents data, but I sure can't
> > figure out where I'm going wrong. =A0Can anyone point me in the right
> > direction?
> > Thanks,
> > =A0-J
> Justin,
> You should really not neglect the satellite clock offset! So the equation
> you should "solve" is:
> C1 =3D D - Clight * SatClk + Clight * StaClk
> Where:
> Clight =3D the velocity of light (roughly 300000000 m/s).
> SatClk =3D is the satellite clock offset (also given in the SP3 file)
> After that your residuals should be rather similar and reflect the statio=
n
> clock.
> However, an other important correction term is the travel time correction=
.
> Here a brief explanation of that. The GPS receiver collects the data
> simultaneously at some given epoch. However, given the different distance=
s
> the signals have to travel the left the satellites at different times. So=
in
> principle one has to compute the position of the satellite at the epoch t=
he
> signal left the satellite. But to compute the travel time one needs to kn=
ow
> the position of the satellite in the first place. So one has to iterate t=
his
> or make a approximation (e.g. typically done using a Taylor expansion).
> Given the distance of the GPS satellites the travel time around 0.06 to 0=
.08
> seconds. The velocity of the GPS satellites is about 3000 m/s. So the eff=
ect
> of this term is at the few hunderd meter level (max).
> Have fun!
> Timhttp://gnss.servolux.nl