A Satellite Navigation and Global Positioing Systems forum. Sat Nav Banter

If this is your first visit, be sure to check out the FAQ by clicking the link above. You may have to register before you can post: click the register link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below.

Go Back   Home » Sat Nav Banter forum » GPS and Sat Nav Newsgroups » sci.geo.satellite-nav (Global Satellite Navigation)
Site Map Home Register Authors List Search Today's Posts Mark Forums Read Web Partners

sci.geo.satellite-nav (Global Satellite Navigation) (sci.geo.satellite-nav) Discussion of global navigation satellite systems (GNSS). Topics include the technical aspects of GNSS operation, user experiences in the use of GNSS, information regarding GNSS products and discussion of GNSS policy (such as GPS selective availability).

Tags: , , , , , , ,

The NOG - AFSPC Media Telecon for IIR-20M (svn 49, prn 01) problem



 
 
Thread Tools Display Modes
  #1  
Old June 22nd 09, 11:40 PM posted to sci.geo.satellite-nav
Mike Jr
external usenet poster
 
Posts: 60
Default The NOG - AFSPC Media Telecon for IIR-20M (svn 49, prn 01) problem

Here is another take on Friday's meeting.

http://blogs.agi.com/navigationAccuracy/

"Question: How is the fix for this problem modeled? Is it a constant
bias or something else?

Answer: (Madden) The fix effectively moved the antenna phase center
for the satellite to 150 meters behind the satellite.

Question: What navigation parameters are being changed to implement
this fix?

Answer: (Thomas Powell, Aerospace) The ephemeris phase center value
(later determined to be the Tgd value) and the clock offset values are
being modified to allow user's receiver to get a correct URE for this
satellite."

With an elevation dependent error, I wonder how this is supposed to
work. Anybody?

BTW, AFSpace is on Twitter. http://twitter.com/afspace

--Mike Jr
  #2  
Old June 23rd 09, 02:31 AM posted to sci.geo.satellite-nav
HIPAR
external usenet poster
 
Posts: 114
Default The NOG - AFSPC Media Telecon for IIR-20M (svn 49, prn 01)problem

On Jun 22, 7:40*pm, Mike Jr wrote:
Here is another take on Friday's meeting.

http://blogs.agi.com/navigationAccuracy/

"Question: How is the fix for this problem modeled? *Is it a constant
bias or something else?

Answer: (Madden) The fix effectively moved the antenna phase center
for the satellite to 150 meters behind the satellite.

Question: What navigation parameters are being changed to implement
this fix?

Answer: (Thomas Powell, Aerospace) The ephemeris phase center value
(later determined to be the Tgd value) and the clock offset values are
being modified to allow user's receiver to get a correct URE for this
satellite."

With an elevation dependent error, I wonder how this is supposed to
work. *Anybody?

BTW, AFSpace is on Twitter.http://twitter.com/afspace

--Mike Jr


This is how I originally envisioned the problem:

The signal beamwidth is designed to be somewhat larger than the disk
of the earth. The beam axis is nadir from the phase center. Ideally,
at any point at a spherical surface at radius R from the antenna array
phase center, the signal time should be the same. Somehow, connecting
the L5 transmitter affected the beam forming network causing an off
nadir signal time delta. An observer sees the edges of the beam
pattern as the satellite rises and sets. This is where the signal time
is approaching worst error.

That's why I took a wild guess in an earlier comment thinking they
might attempt to modify the ionospheric delay parameters for this
satellite because that delay is elevation dependent.

After reading the explanation at GPS World magazine:

I get the impression that my origional mental conception was
incorrect. The signal time is equal as it should be but, due to some
time/phase delay in the antenna network, it's wrong. The user
receiver calculates the range based upon actual transmitted satellite
ephemeris but matches it to an signal time exhibiting an erroneous
orbital radius thereby causing a distortion in the apparent geometry.
However, I'm also having a problem visualizing details about how that
happens.

If it's basically a timing induced problem, adjusting the satellite
clock offset parameters and tweaking the ephemeris might fix it.

This problem and its solution needs a more detailed explanation from
those who performed the analysis.

--- CHAS
  #3  
Old June 23rd 09, 03:13 AM posted to sci.geo.satellite-nav
Mike Jr
external usenet poster
 
Posts: 60
Default The NOG - AFSPC Media Telecon for IIR-20M (svn 49, prn 01)problem

On Jun 22, 10:31*pm, HIPAR wrote:
On Jun 22, 7:40*pm, Mike Jr wrote:



Here is another take on Friday's meeting.


http://blogs.agi.com/navigationAccuracy/


"Question: How is the fix for this problem modeled? *Is it a constant
bias or something else?


Answer: (Madden) The fix effectively moved the antenna phase center
for the satellite to 150 meters behind the satellite.


Question: What navigation parameters are being changed to implement
this fix?


Answer: (Thomas Powell, Aerospace) The ephemeris phase center value
(later determined to be the Tgd value) and the clock offset values are
being modified to allow user's receiver to get a correct URE for this
satellite."


With an elevation dependent error, I wonder how this is supposed to
work. *Anybody?


BTW, AFSpace is on Twitter.http://twitter.com/afspace


--Mike Jr


This is how I originally envisioned the problem:

The signal beamwidth is designed to be somewhat larger than the disk
of the earth. *The beam axis is nadir from the phase center. *Ideally,
at any point at a spherical surface at radius R from the antenna array
phase center, the signal time should be the same. *Somehow, connecting
the L5 transmitter affected the beam forming network causing an off
nadir signal time delta. *An observer sees the edges of the beam
pattern as the satellite rises and sets. This is where the signal time
is approaching worst error.

That's why I took a wild guess in an earlier comment thinking they
might attempt to modify the ionospheric delay parameters for this
satellite because that delay is elevation dependent.

After reading the explanation at GPS World magazine:

I get the impression that my origional mental conception was
incorrect. *The signal time is equal as it should be but, due to some
time/phase delay in the antenna network, *it's wrong. The user
receiver calculates the range based upon actual transmitted satellite
ephemeris but matches it to an signal time exhibiting an erroneous
orbital radius thereby causing a distortion in the apparent geometry.
However, I'm also having a problem visualizing details about how that
happens.

If it's basically a timing induced problem, adjusting the satellite
clock offset parameters and tweaking the ephemeris might fix it.


I really don't know what is going on either. One hypothesis is that
the problem is in the shape of the PRN signal. The atomic clock
strikes and the PRN signal is generated. If the shape of that signal
is distorted then the receiver wouldn't lock in correctly. But if
that is the problem, I don't see how fiddling with the clock offset
and ephemeris will help. Oh well, why speculate? Somebody at
Aerospace must know. They have the data and are paid to know how to
analyze it. I still don't see why it should take them till October to
publish the results.


This problem and its solution needs a more detailed explanation

from
those who performed the analysis.


I couldn't agree more. If I was paying for GPS I would sure want to
know. Hey, wait a minute. I am a tax payer ....


--- *CHAS


  #4  
Old June 23rd 09, 11:57 AM posted to sci.geo.satellite-nav
T Driver
external usenet poster
 
Posts: 64
Default The NOG - AFSPC Media Telecon for IIR-20M (svn 49, prn 01)problem

On Jun 22, 11:13*pm, Mike Jr wrote:
On Jun 22, 10:31*pm, HIPAR wrote:

On Jun 22, 7:40*pm, Mike Jr wrote:


Here is another take on Friday's meeting.


http://blogs.agi.com/navigationAccuracy/


"Question: How is the fix for this problem modeled? *Is it a constant
bias or something else?


Answer: (Madden) The fix effectively moved the antenna phase center
for the satellite to 150 meters behind the satellite.


Question: What navigation parameters are being changed to implement
this fix?


Answer: (Thomas Powell, Aerospace) The ephemeris phase center value
(later determined to be the Tgd value) and the clock offset values are
being modified to allow user's receiver to get a correct URE for this
satellite."


With an elevation dependent error, I wonder how this is supposed to
work. *Anybody?


BTW, AFSpace is on Twitter.http://twitter.com/afspace


--Mike Jr


This is how I originally envisioned the problem:


The signal beamwidth is designed to be somewhat larger than the disk
of the earth. *The beam axis is nadir from the phase center. *Ideally,
at any point at a spherical surface at radius R from the antenna array
phase center, the signal time should be the same. *Somehow, connecting
the L5 transmitter affected the beam forming network causing an off
nadir signal time delta. *An observer sees the edges of the beam
pattern as the satellite rises and sets. This is where the signal time
is approaching worst error.


That's why I took a wild guess in an earlier comment thinking they
might attempt to modify the ionospheric delay parameters for this
satellite because that delay is elevation dependent.


After reading the explanation at GPS World magazine:


I get the impression that my origional mental conception was
incorrect. *The signal time is equal as it should be but, due to some
time/phase delay in the antenna network, *it's wrong. The user
receiver calculates the range based upon actual transmitted satellite
ephemeris but matches it to an signal time exhibiting an erroneous
orbital radius thereby causing a distortion in the apparent geometry.
However, I'm also having a problem visualizing details about how that
happens.


* If it's basically a timing induced problem, adjusting the satellite
* clock offset parameters and tweaking the ephemeris might fix it.

I really don't know what is going on either. *One hypothesis is that
the problem is in the shape of the PRN signal. *The atomic clock
strikes and the PRN signal is generated. *If the shape of that signal
is distorted then the receiver wouldn't lock in correctly. *But if
that is the problem, I don't see how fiddling with the clock offset
and ephemeris will help. *Oh well, why speculate? *Somebody at
Aerospace must know. *They have the data and are paid to know how to
analyze it. *I still don't see why it should take them till October to
publish the results.

*
* This problem and its solution needs a more detailed explanation
from
* those who performed the analysis.

I couldn't agree more. *If I was paying for GPS I would sure want to
know. *Hey, wait a minute. *I am a tax payer ....



--- *CHAS


I have a question into AFPSC asking just that. The respondents on the
telecon weren't very clear. I'll post on the Nog when I hear
something.
Ted Driver, The Nog
  #5  
Old June 24th 09, 12:46 AM posted to sci.geo.satellite-nav
Mike Jr
external usenet poster
 
Posts: 60
Default The NOG - AFSPC Media Telecon for IIR-20M (svn 49, prn 01)problem

On Jun 23, 7:57*am, T Driver wrote:
On Jun 22, 11:13*pm, Mike Jr wrote:



On Jun 22, 10:31*pm, HIPAR wrote:


On Jun 22, 7:40*pm, Mike Jr wrote:


Here is another take on Friday's meeting.


http://blogs.agi.com/navigationAccuracy/


"Question: How is the fix for this problem modeled? *Is it a constant
bias or something else?


Answer: (Madden) The fix effectively moved the antenna phase center
for the satellite to 150 meters behind the satellite.


Question: What navigation parameters are being changed to implement
this fix?


Answer: (Thomas Powell, Aerospace) The ephemeris phase center value
(later determined to be the Tgd value) and the clock offset values are
being modified to allow user's receiver to get a correct URE for this
satellite."


With an elevation dependent error, I wonder how this is supposed to
work. *Anybody?


BTW, AFSpace is on Twitter.http://twitter.com/afspace


--Mike Jr


This is how I originally envisioned the problem:


The signal beamwidth is designed to be somewhat larger than the disk
of the earth. *The beam axis is nadir from the phase center. *Ideally,
at any point at a spherical surface at radius R from the antenna array
phase center, the signal time should be the same. *Somehow, connecting
the L5 transmitter affected the beam forming network causing an off
nadir signal time delta. *An observer sees the edges of the beam
pattern as the satellite rises and sets. This is where the signal time
is approaching worst error.


That's why I took a wild guess in an earlier comment thinking they
might attempt to modify the ionospheric delay parameters for this
satellite because that delay is elevation dependent.


After reading the explanation at GPS World magazine:


I get the impression that my origional mental conception was
incorrect. *The signal time is equal as it should be but, due to some
time/phase delay in the antenna network, *it's wrong. The user
receiver calculates the range based upon actual transmitted satellite
ephemeris but matches it to an signal time exhibiting an erroneous
orbital radius thereby causing a distortion in the apparent geometry.
However, I'm also having a problem visualizing details about how that
happens.


* If it's basically a timing induced problem, adjusting the satellite
* clock offset parameters and tweaking the ephemeris might fix it.


I really don't know what is going on either. *One hypothesis is that
the problem is in the shape of the PRN signal. *The atomic clock
strikes and the PRN signal is generated. *If the shape of that signal
is distorted then the receiver wouldn't lock in correctly. *But if
that is the problem, I don't see how fiddling with the clock offset
and ephemeris will help. *Oh well, why speculate? *Somebody at
Aerospace must know. *They have the data and are paid to know how to
analyze it. *I still don't see why it should take them till October to
publish the results.


*
* This problem and its solution needs a more detailed explanation
from
* those who performed the analysis.


I couldn't agree more. *If I was paying for GPS I would sure want to
know. *Hey, wait a minute. *I am a tax payer ....


--- *CHAS


I have a question into AFPSC asking just that. *The respondents on the
telecon weren't very clear. *I'll post on the Nog when I hear
something.
Ted Driver, The Nog


Ted,
You go guy.

I have been thinking (always a dangerous proposition). Consider the
case of two GPS users, one seeing SVN49 at an elevation of 20 degrees
and the second at an elevation of 90 degrees. Hey, it's a big
planet. The user at 20 degrees will see little or no additional error
in his/hers pseudo range measurement. The second user at 90 degrees
will see a huge error.

Both users see the same signal. Can someone explain to me how you
adjust the signal so that both users see a "correct" signal? IT
CANNOT BE DONE.

Let us assume for the sake of argument that you can monkey with the
signal so that both user 1 and user 2 see a pseudo range with a four
to eight meter error. The current constellation average (sans
receiver error) is under a meter, probably close to 3/4 meter. Why on
earth would you want to introduce a bird with this kind of error into
the constellation?

Would the FAA appreciate having airplanes on automatic approach to a
runway be off by four meters? Can the telco folks accept that kind of
clock error? Can the war fighters dropping a 500 lbs small diameter
bomb be off by eight meters? Give me a break.

SVN49 saved the L5 signal. The wing should declare victory and walk
away. They should either never mark SVN49 as healthy or they should
turn off Carrier and leave P(Y) and M code for use by the military/
intel user community.

I hope that the Aerospace engineers and executives fully realize that
their professional reputations are on the line. Have the courage (and
the enlightened self interest) to do the right thing.

--Mike Jr
  #6  
Old June 24th 09, 02:00 AM posted to sci.geo.satellite-nav
Marty Ryba
external usenet poster
 
Posts: 29
Default The NOG - AFSPC Media Telecon for IIR-20M (svn 49, prn 01) problem

"Mike Jr" wrote in message
...
I have been thinking (always a dangerous proposition). Consider the
case of two GPS users, one seeing SVN49 at an elevation of 20 degrees
and the second at an elevation of 90 degrees. Hey, it's a big
planet. The user at 20 degrees will see little or no additional error
in his/hers pseudo range measurement. The second user at 90 degrees
will see a huge error.


Both users see the same signal. Can someone explain to me how you
adjust the signal so that both users see a "correct" signal? IT
CANNOT BE DONE.


Let us assume for the sake of argument that you can monkey with the
signal so that both user 1 and user 2 see a pseudo range with a four
to eight meter error. The current constellation average (sans
receiver error) is under a meter, probably close to 3/4 meter. Why on
earth would you want to introduce a bird with this kind of error into
the constellation?


I was going to hold off commenting, as I don't know the specifics, and as
clearly some good experts didn't anticipate this problem it can be dangerous
to guess.

1) It is a corporate fed helical phased array transmitter. What that means
in slightly less jargon is there is a series of waveguides (corporate fed)
that feed the elements of the antenna. Each phased array element is a loaded
helix (what gives you RHCP). Both the waveguides and the helices themselves
have frequency-dependent group and phase delay characteristics. Tuning them
up is somewhat of an art as opposed to pure science. What appears to have
happened is that the change in impedence coming from having the L5 payload
attached (instead of a terminator) messed up the input into the feed
network, causing substantial VSWR going into the network (they're lucky they
didn't get compaction in there). That means the phases going into arms of
the feed network got out of whack in a frequency-dependent way. You know,
you spec everything to be 50 Ohms or whatever, but sometimes things go wrong
even if they meet the spec to within tolerance. Re the art comment...I'm
sure no one has a validated EM-sim of this beast; it's just too knarly.

2) I'm sure they're wishing they had a far field antenna cut on this puppy;
I imagine it's pretty ugly (hell, the nominal ones are pretty ugly; this
will be double ugly). I'd be curious to take some high-gain traces of the
signal across the sky and see if there's extra scatter in the received C/N0
values, like what you get with mutlipath but in this case even at high
angles (and why you'd want a dish to block out the multipath). I've got the
right antenna and feeds available, but I am not an academic so I can't just
spend company or Government money satisfying my curiosity.

3) Net/net, what that means is the group delay varies as a function of
elevation (off axis angle from the satellite antenna maps into elevation
angle of the satellite as seen by the receiver). That's why the code/carrier
measurements were messed up. It's essentially *not* the same signal...it
comes from a different combination of the signals emanating from the 12 or
so elements. Since several meters is multiple wavelengths, that's why I
figure the antenna pattern is likely awful. They must have tuned some things
to get the phase behavior good enough to get any useful pattern though; I
don't know if they can perform per-element group delay measurements though
(likely very tricky).

4) Apparently, you can get most of the effect canceled by treating the
aperture as having a point source phase center 150 meters behind the bird
(Madden's comment). The quick fix would be "fine, just change Root-A".
Unfortunately, that screws up the mean motion calculation, and the
adjustment to delta-n required might exceed the ephemeris range.
Fortunately, to first order, changing the clock bias and/or Tgd can give you
pretty much the same result. I think part of the reason they're holding off
marking the SV healthy is they want to be sure this patch holds over time.

5) Regarding not using this bird (Mike's comment). The URE was already down
to 2.4 meters or so. According to Don Jewell's transcription of the same
telecon, the Wing/2SOPS said they're confident they'll get the URE down to a
meter or better by October.

Lastly, a more detailed technical explanation will likely end up in an
Aerospace report sometime. Whether a paper gets presented to ION or similar
depends on whether it can get past export control. Remember, this is not a
NASA science experiment. Pretty much everything the Air Force touches is
presumed to be a munition by ITAR rules. Presenting a technical paper is an
export of military-related technical data, and has to be reviewed carefully
before release. I'm sure Col Madden, Mr. Powell, and others in the telecon
had to go over what they were going to say with the Program Protection group
at the Wing (Art Fernandez and a few others I know) before they went public.


  #7  
Old June 24th 09, 10:01 AM posted to sci.geo.satellite-nav
claudegps
external usenet poster
 
Posts: 134
Default The NOG - AFSPC Media Telecon for IIR-20M (svn 49, prn 01)problem

On 24 Giu, 02:46, Mike Jr wrote:
[cut]
Both users see the same signal. *Can someone explain to me how you
adjust the signal so that both users see a "correct" signal? *IT
CANNOT BE DONE.


Are you sure?

Let us assume for the sake of argument that you can monkey with the
signal so that both user 1 and user 2 see a pseudo range with a four
to eight meter error. *The current constellation average (sans
receiver error) is under a meter, probably close to 3/4 meter. *Why on
earth would you want to introduce a bird with this kind of error into
the constellation?


Redundancy for example.

Would the FAA appreciate having airplanes on automatic approach to a
runway be off by four meters? Can the telco folks accept that kind of
clock error? *Can the war fighters dropping a 500 lbs small diameter
bomb be off by eight meters? *Give me a break.


If you have enough redundancy, you just discard the SV with higher
error.
If you need that SV for a solution, it means that without it you don't
have a fix.
And anyway... 8m of error on 1 SV does not mean 8m of error in the
final solution and you don't drop bombs with comman L1-C/A code
receiver... I think.
Moreover when you operate indoor with errors of 200m. Are you really
sure that having a 8m error would be such damage? If you prefer, you
can have no fix at all...

SVN49 saved the L5 signal. *The wing should declare victory and walk
away. *They should either never mark SVN49 as healthy or they should
turn off Carrier and leave P(Y) and M code for use by the military/
intel user community.

I hope that the Aerospace engineers and executives fully realize that
their professional reputations are on the line. *Have the courage (and
the enlightened self interest) to do the right thing.


I don't agree...
Everyone knows why that SV has problems and what the goal of the
mission was.
  #8  
Old June 24th 09, 02:42 PM posted to sci.geo.satellite-nav
HIPAR
external usenet poster
 
Posts: 114
Default The NOG - AFSPC Media Telecon for IIR-20M (svn 49, prn 01)problem

About a week ago, the Air Force stopped including PRN01 in the daily
constellation performance report. I 'spot checked' their report for
several weeks before this happened finding the reported PRN01
satellite error was consistently less than a meter. I don't know how
they calculate the error. It must be some kind of daily average but
one would hope the hour to hour error wouldn't fluctuate wildly from
the reported number.

The Air Force is proud to state the overall constellation satellite
error continuously improves and now is under a meter. It was
outperforming PRN30 which is in a nearly identical obit. Of course,
if PRN01 reverses that trend, I'd turn it off and designate the
satellite as as a spare for emergency reactivation. Otherwise, If the
'fix' doesn't cause problems for the phase tracking users, I'd have no
problem setting PRN01 healthy.

What's wrong .. the world wants to know. Although the Air Force
operates within a 'cult of secrecy', ITAR or not they are going to
feel pressure to explain this debacle; especially after that GAO
report questioning their competency to sustain the system.
Practically speaking, they lost absolute control when the system was
opened for civilian use with the demands of other entities
complicating their operations. I'm thinking they would be happier
just providing the military signals not having to worry about a hodge-
podge of civilian signals and interoperability/compatibility with
everyone else building competing 'superior' systems.

--- CHAS

  #9  
Old June 24th 09, 11:50 PM posted to sci.geo.satellite-nav
T Driver
external usenet poster
 
Posts: 64
Default The NOG - AFSPC Media Telecon for IIR-20M (svn 49, prn 01)problem


I have a question into AFPSC asking just that. *The respondents on the
telecon weren't very clear. *I'll post on the Nog when I hear
something.
Ted Driver, The Nog


I received a response from AFSPC: http://blogs.agi.com/navigationAccuracy/?p=208
Ted

  #10  
Old June 25th 09, 12:37 AM posted to sci.geo.satellite-nav
Mike Jr
external usenet poster
 
Posts: 60
Default The NOG - AFSPC Media Telecon for IIR-20M (svn 49, prn 01)problem

On Jun 23, 10:00*pm, "Marty Ryba"
wrote:
"Mike Jr" wrote in message

...

I have been thinking (always a dangerous proposition). *Consider the
case of two GPS users, one seeing SVN49 at an elevation of 20 degrees
and the second at an elevation of 90 degrees. *Hey, it's a big
planet. *The user at 20 degrees will see little or no additional error
in his/hers pseudo range measurement. *The second user at 90 degrees
will see a huge error.
Both users see the same signal. *Can someone explain to me how you
adjust the signal so that both users see a "correct" signal? *IT
CANNOT BE DONE.
Let us assume for the sake of argument that you can monkey with the
signal so that both user 1 and user 2 see a pseudo range with a four
to eight meter error. *The current constellation average (sans
receiver error) is under a meter, probably close to 3/4 meter. *Why on
earth would you want to introduce a bird with this kind of error into
the constellation?


I was going to hold off commenting, as I don't know the specifics, and as
clearly some good experts didn't anticipate this problem it can be dangerous
to guess.

1) It is a corporate fed helical phased array transmitter. What that means
in slightly less jargon is there is a series of waveguides (corporate fed)
that feed the elements of the antenna. Each phased array element is a loaded
helix (what gives you RHCP). Both the waveguides and the helices themselves
have frequency-dependent group and phase delay characteristics. Tuning them
up is somewhat of an art as opposed to pure science. What appears to have
happened is that the change in impedence coming from having the L5 payload
attached (instead of a terminator) messed up the input into the feed
network, causing substantial VSWR going into the network (they're lucky they
didn't get compaction in there). That means the phases going into arms of
the feed network got out of whack in a frequency-dependent way. You know,
you spec everything to be 50 Ohms or whatever, but sometimes things go wrong
even if they meet the spec to within tolerance. Re the art comment...I'm
sure no one has a validated EM-sim of this beast; it's just too knarly.

2) I'm sure they're wishing they had a far field antenna cut on this puppy;
I imagine it's pretty ugly (hell, the nominal ones are pretty ugly; this
will be double ugly). I'd be curious to take some high-gain traces of the
signal across the sky and see if there's extra scatter in the received C/N0
values, like what you get with mutlipath but in this case even at high
angles (and why you'd want a dish to block out the multipath). I've got the
right antenna and feeds available, but I am not an academic so I can't just
spend company or Government money satisfying my curiosity.

3) Net/net, what that means is the group delay varies as a function of
elevation (off axis angle from the satellite antenna maps into elevation
angle of the satellite as seen by the receiver). That's why the code/carrier
measurements were messed up. It's essentially *not* the same signal...it
comes from a different combination of the signals emanating from the 12 or
so elements. Since several meters is multiple wavelengths, that's why I
figure the antenna pattern is likely awful. They must have tuned some things
to get the phase behavior good enough to get any useful pattern though; I
don't know if they can perform per-element group delay measurements though
(likely very tricky).

4) Apparently, you can get most of the effect canceled by treating the
aperture as having a point source phase center 150 meters behind the bird
(Madden's comment). The quick fix would be "fine, just change Root-A".
Unfortunately, that screws up the mean motion calculation, and the
adjustment to delta-n required might exceed the ephemeris range.
Fortunately, to first order, changing the clock bias and/or Tgd can give you
pretty much the same result. I think part of the reason they're holding off
marking the SV healthy is they want to be sure this patch holds over time..

5) Regarding not using this bird (Mike's comment). The URE was already down
to 2.4 meters or so. According to Don Jewell's transcription of the same
telecon, the Wing/2SOPS said they're confident they'll get the URE down to a
meter or better by October.

Lastly, a more detailed technical explanation will likely end up in an
Aerospace report sometime. Whether a paper gets presented to ION or similar
depends on whether it can get past export control. Remember, this is not a
NASA science experiment. Pretty much everything the Air Force touches is
presumed to be a munition by ITAR rules. Presenting a technical paper is an
export of military-related technical data, and has to be reviewed carefully
before release. I'm sure Col Madden, Mr. Powell, and others in the telecon
had to go over what they were going to say with the Program Protection group
at the Wing (Art Fernandez and a few others I know) before they went public.


Marty,
Thank you. I am not an RF Engineer but I have a background in
physics so I
followed most of it. I once knew some RF Engineers and they wouldn't
change an RF circuit without doing some bench tests. What is
engineering
coming to today? Now I am on the outside looking in and it is hard to
see from out
here.

If the constellation average pseudo range error is .75 meters, 2.4
meters is not
pretty, And is that 2.4 meters an average? Does it have a min and max
that
is elevation dependent? What is the variance to go along with that
average?

If you are going to change the clock bias and/or Tgd what will that do
to folks
trying to use GPS to figure out the ionospheric delay? What is 150
meters
in units of time? About 450 nanoseconds? What is that going to do to
users
that need precise time? What will that do to GPS system time?

If the antenna was on the ground I can see retuning it. But it's up
there.
I suppose that the phased array has firmware that can be reprogrammed.
Hmmm, Aerospace and/or ITT will be earning their money.

For now I am going to take a wait and see approach. All the cards are
yet to be placed on the table.

--Mike Jr
 




Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Forum Jump


All times are GMT. The time now is 11:53 PM.


Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2010, Jelsoft Enterprises Ltd.SEO by vBSEO 2.4.0
Copyright ©2004-2010 Sat Nav Banter, part of the NewsgroupBanter project.
The comments are property of their posters.
Nikon D5000 - Canon 500d - Breast Enlargement - Find jobs - Debt Help