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

SVN49 Issue



 
 
Thread Tools Display Modes
  #1  
Old June 25th 09, 11:14 AM posted to sci.geo.satellite-nav,alt.satellite.gps
Tim Springer[_2_]
external usenet poster
 
Posts: 30
Default SVN49 Issue

Read the article I wrote on the SVN 49 issue. It is out on the Inside GNSS
"frontpage" (http://insidegnss.com) now and will be included in the
July/August printed version

The article nicely shows and explains what is being done and why that works
(for "ordinary" users).

For the direct link to the article visit my blog at:
http://gnss.servolux.nl/gnss_blog.html

Tim


Ads
  #2  
Old June 25th 09, 12:34 PM posted to sci.geo.satellite-nav,alt.satellite.gps
Mike Jr
external usenet poster
 
Posts: 60
Default SVN49 Issue

On Jun 25, 6:14*am, "Tim Springer"
wrote:
Read the article I wrote on the SVN 49 issue. It is out on the Inside GNSS
"frontpage" (http://insidegnss.com) now and will be included in the
July/August printed version

The article nicely shows and explains what is being done and why that works
(for "ordinary" users).

For the direct link to the article visit my blog at:http://gnss.servolux.nl/gnss_blog.html

Tim


"The tweaking of the satellite broadcast ephemerides and time is
designed to reduce the pseudorange error to within the specifications
for GPS Standard Positioning Service and Precise Positioning Service."

That ain't no .75 meters!

More later when I have time.

--Mike Jr
  #3  
Old June 26th 09, 02:06 AM posted to sci.geo.satellite-nav,alt.satellite.gps
Mike Jr
external usenet poster
 
Posts: 60
Default SVN49 Issue

On Jun 25, 7:34*am, Mike Jr wrote:
On Jun 25, 6:14*am, "Tim Springer"
wrote:

Read the article I wrote on the SVN 49 issue. It is out on the Inside GNSS
"frontpage" (http://insidegnss.com) now and will be included in the
July/August printed version


The article nicely shows and explains what is being done and why that works
(for "ordinary" users).


For the direct link to the article visit my blog at:http://gnss.servolux.nl/gnss_blog.html


Tim


"The tweaking of the satellite broadcast ephemerides and time is
designed to reduce the pseudorange error to within the specifications
for GPS Standard Positioning Service and Precise Positioning Service."

That ain't no .75 meters!

More later when I have time.

--Mike Jr


Tim,
The specification for the GPS Standard Positioning Service is 100
meters.

Some very smart and hardworking people have managed to get the
Unexplained Range Error down to .75 meters. It is this level of
service that people have come to expect and rely on from GPS. Now the
wing wants to throw this brick, the "worst performing block IIA in the
constellation", at the users and try to hide behind a 100 meter
requirement that was long ago left in the dust bins.

The wing is looking for political cover. Lets examine just some of
the consequences.
1. DOT wants to use GPS for real time tracking of railroad train
positions. Just imagine a future crash because someone thought the on
coming train was on the other track.

2. DOT needs to land airplanes.

3. The end users, DOT/DoD/Intel/RTK are going to have to adjust their
equipment to ignore this bad bird. What is that going to cost?

3. The wing's perceived incompetence in managing the GPS constellation
is only stoking the fires for Galileo. Galileo is on the ropes
because their business model doesn't make sense ("We are going to
charge you for precise positioning. What? GPS gives you .75 meter URE
for free. Curse those Americans!") But now they can point to the
wing's handling of SVN049 and say, "See. You need us".

4. The Obama administration would love to take GPS away from the
military and give it to DOT. "Under DOT we can play nice with the
Europeans!". This would be a disaster for the DoD/Intel community who
need a military GPS.

I don't think the wing has thought this through.

Man, that block IIF sure better shine when it gets launched. BTW, how
can Boeing launch eight IIF satellites in 2010 when it takes about six
months to bring the first in a new block online?

These are interesting times.

--Mike Jr
  #4  
Old June 26th 09, 03:21 AM posted to sci.geo.satellite-nav,alt.satellite.gps
Marty Ryba
external usenet poster
 
Posts: 29
Default SVN49 Issue

"Mike Jr" wrote in message
...
Tim,
The specification for the GPS Standard Positioning Service is 100
meters.

That's the SA-on value...I believe it is essentially 6 meters URE. I think
the SPS generally tells you navigation performance over the constellation,
not per-satellite ranging errors.

Some very smart and hardworking people have managed to get the
Unexplained Range Error down to .75 meters. It is this level of
service that people have come to expect and rely on from GPS. Now the
wing wants to throw this brick, the "worst performing block IIA in the
constellation", at the users and try to hide behind a 100 meter
requirement that was long ago left in the dust bins.


Calm down, Mike. First, it's a IIR(M), not a IIA. More importantly, if you
look at Tim's Figure 2, you should conclude that the average bias (error on
top of the standard noise) is the difference between his 4th-order fit
(dashed line) and the 150*(1 - cos(eta)) solid line. That error is about 0.6
meters peak. That means the typical RMS error will rise from something like
0.7 meters (typical IIR) to 0.8 meters if you RSS those two numbers; meaning
it should generally stay below 1.0 meters in real practice. So, it'll be
worse than most if not all the other IIR's (and IIR(M)'s), but better than
most of the IIA's.

Look at http://gps.afspc.af.mil/gpsoc/products/uclas_sisure.jpg to get a
sense of typical URE's.
-Marty


  #5  
Old June 26th 09, 08:10 AM posted to sci.geo.satellite-nav,alt.satellite.gps
Tim Springer[_2_]
external usenet poster
 
Posts: 30
Default SVN49 Issue



"Mike Jr" schrieb im Newsbeitrag
...
On Jun 25, 7:34 am, Mike Jr wrote:
On Jun 25, 6:14 am, "Tim Springer"
wrote:

Read the article I wrote on the SVN 49 issue. It is out on the Inside
GNSS
"frontpage" (http://insidegnss.com) now and will be included in the
July/August printed version


The article nicely shows and explains what is being done and why that
works
(for "ordinary" users).


For the direct link to the article visit my blog
at:http://gnss.servolux.nl/gnss_blog.html


Tim


"The tweaking of the satellite broadcast ephemerides and time is
designed to reduce the pseudorange error to within the specifications
for GPS Standard Positioning Service and Precise Positioning Service."

That ain't no .75 meters!

More later when I have time.

--Mike Jr


Tim,
The specification for the GPS Standard Positioning Service is 100
meters.

Some very smart and hardworking people have managed to get the
Unexplained Range Error down to .75 meters. It is this level of
service that people have come to expect and rely on from GPS. Now the
wing wants to throw this brick, the "worst performing block IIA in the
constellation", at the users and try to hide behind a 100 meter
requirement that was long ago left in the dust bins.

The wing is looking for political cover. Lets examine just some of
the consequences.
1. DOT wants to use GPS for real time tracking of railroad train
positions. Just imagine a future crash because someone thought the on
coming train was on the other track.

2. DOT needs to land airplanes.

3. The end users, DOT/DoD/Intel/RTK are going to have to adjust their
equipment to ignore this bad bird. What is that going to cost?

3. The wing's perceived incompetence in managing the GPS constellation
is only stoking the fires for Galileo. Galileo is on the ropes
because their business model doesn't make sense ("We are going to
charge you for precise positioning. What? GPS gives you .75 meter URE
for free. Curse those Americans!") But now they can point to the
wing's handling of SVN049 and say, "See. You need us".

4. The Obama administration would love to take GPS away from the
military and give it to DOT. "Under DOT we can play nice with the
Europeans!". This would be a disaster for the DoD/Intel community who
need a military GPS.

I don't think the wing has thought this through.

Man, that block IIF sure better shine when it gets launched. BTW, how
can Boeing launch eight IIF satellites in 2010 when it takes about six
months to bring the first in a new block online?

These are interesting times.

--Mike Jr


Mike,

First of all Marty is right. With this correction the GPS navigation
performance will stay close to its current level. So the correction is very
well suited for that, so no worries.

For landing airplanes and train tracking typically more advanced algorithms
are used and the phase measurements come into play. The SVN49 anomaly does
NOT impact the phase measurements and there all is fine. Only for some
special uses of the code care will have to be taken. So, yes, that requires
some work on the algorithm side but that is basically good for economy since
it generates/keeps jobs. Also, note that that only impacts the software on
the "server side". Typically for landing airplanes there is a service
provider ("server side") who computes accurate orbits and clocks and sends
those to the airplane, e.g., as corrections/improvements to the broadcast.
The airplane ("client side") uses this information to compute its position
in the normal way. For the "client side" no changes are needed since the
"server side" will handle it for him.

However, there are two issues I worry about:
1. Is this bias stable over time!? If not that would be a "killer"
2. Why do the Trimble receivers not see this bias? On one hand this
indicates that we may solve the problem by improving/changing the receiver
tracking loops. On the other hand it makes the bias receiver dependent which
would be "killer" as well.

So until October there is enough to be investigated.........

Your point that turning SVN49 to healthy with this bias will complicate
things is a very true statement and should be considered carefully!

Tim
http://gnss.servolux.nl



  #6  
Old June 26th 09, 08:45 AM posted to sci.geo.satellite-nav,alt.satellite.gps
claudegps
external usenet poster
 
Posts: 102
Default SVN49 Issue

On 26 Giu, 03:06, Mike Jr wrote:
On Jun 25, 7:34*am, Mike Jr wrote:



On Jun 25, 6:14*am, "Tim Springer"
wrote:


Read the article I wrote on the SVN 49 issue. It is out on the Inside GNSS
"frontpage" (http://insidegnss.com) now and will be included in the
July/August printed version


The article nicely shows and explains what is being done and why that works
(for "ordinary" users).


For the direct link to the article visit my blog at:http://gnss.servolux.nl/gnss_blog.html


Tim


"The tweaking of the satellite broadcast ephemerides and time is
designed to reduce the pseudorange error to within the specifications
for GPS Standard Positioning Service and Precise Positioning Service."


That ain't no .75 meters!


More later when I have time.


--Mike Jr


Tim,
*The specification for the GPS Standard Positioning Service is 100
meters.

Some very smart and hardworking people have managed to get the
Unexplained Range Error down to .75 meters. *It is this level of
service that people have come to expect and rely on from GPS. *Now the
wing wants to throw this brick, the "worst performing block IIA in the
constellation", at the users and try to hide behind a 100 meter
requirement that was long ago left in the dust bins.

The wing is looking for political cover. *Lets examine just some of
the consequences.
1. DOT wants to use GPS for real time tracking of railroad train
positions. *Just imagine a future crash because someone thought the on
coming train was on the other track.


And are they going to try to determine the track where the train is
using GPS L1-C/A code only?
I really hope they use something more reliable, independently from the
status of SVN49.
If for any reason a bird goes bad... you start crashing all the
trains?

2. DOT needs to land airplanes.


I really hope they are not going to land airplanes using GPS L1-CA
code only...

3. The end users, DOT/DoD/Intel/RTK are going to have to adjust their
equipment to ignore this bad bird. *What is that going to cost?


It's very easy, just a command on the serial port usually.
I you really want precision, you should be able to handle this
situation wthout any problems.
If you can't disable a satellite, then you sistem is really broken by
design.

3. The wing's perceived incompetence in managing the GPS constellation
is only stoking the fires for Galileo. *Galileo is on the ropes
because their business model doesn't make sense ("We are going to
charge you for precise positioning. *What? GPS gives you .75 meter URE
for free. *Curse those Americans!") *But now they can point to the
wing's handling of SVN049 and say, "See. *You need us".


I think you miss the point.
The target of SVN049 was another one. And the main target of that
mission was reached.

[cut]
  #7  
Old June 26th 09, 03:39 PM posted to sci.geo.satellite-nav,alt.satellite.gps
HIPAR
external usenet poster
 
Posts: 95
Default SVN49 Issue

On Jun 25, 6:14*am, "Tim Springer"
wrote:
Read the article I wrote on the SVN 49 issue. It is out on the Inside GNSS
"frontpage" (http://insidegnss.com) now and will be included in the
July/August printed version

The article nicely shows and explains what is being done and why that works
(for "ordinary" users).

For the direct link to the article visit my blog at:http://gnss.servolux.nl/gnss_blog.html

Tim


A satellite error less than a meter is significant for the Standard
Positioning Service (SPS) in that it's small enough to be swamped by
uncertainties introduced through ionospheric transit delays. Of
course, its more significant for two frequency systems that actually
attempt to measure the the delays.

Practically speaking, my SPS accuracy is typically 15 feet (4.6
meter) on the open water at the Chesapeake Bay (N 39 deg). That's
good enough to find a mark in poorest visual conditions. That's
really good enough for car navigators; my TomTom map database is often
less accurate than GPS. I'd also say its good enough for locating
trains also but I would hope the actual train movement is also
controlled by state-of-art signaling systems.

We know FAA operates WAAS for landing airplanes (SPS) and has
estaplished approach procedures for most North American airports.

http://www.nstb.tc.faa.gov/RT_Vertic...ctionLevel.htm

I'd hope the conventional Instrument Landing System (ILS) is retained
as a cross check. ILS has served us for over 50 years.

I haven't noticed any important improvement in horizontal accuracy
with WAAS. Perhaps vertical accuracy is improved but I haven't
studied that. A major criticism of NAVSTAR is an inability to convey
real time information about individual satellite health. WAAS
attempts to solve this problem by immediately instructing receivers
to ignore out of tolerance satellites when the Ground Segment detects
a problem. Every satellite now receives continuous monitoring through
an expanded ground network so malfunctions are quickly detected.

The Air Force cannot 'Tap Dance' around accuracy degradation by hiding
behind self imposed easy to meet specifications. They might retain
technical control but they have lost political control. The world will
not buy that act.

--- CHAS
  #8  
Old June 27th 09, 01:14 PM posted to sci.geo.satellite-nav,alt.satellite.gps
Kevin Horton[_2_]
external usenet poster
 
Posts: 1
Default SVN49 Issue

On Jun 26, 10:39 am, HIPAR wrote:

We know FAA operates WAAS for landing airplanes (SPS) and has

estaplished approach procedures for most North American airports.
http://www.nstb.tc.faa.gov/RT_Vertic...ctionLevel.htm

WAAS does not have the required accuracy to safely provide guidance
all
the way to landing. The current WAAS instrument approaches have
approach
minima of 200 ft, or higher, above the airport elevation. Once
reaching
the approach minima, the crew must be able to see the runway and/or
approach lights, take over control of the aircraft, and land it
manually
using the human eye for guidance.

The list of WAAS approaches, with approach minima for each approach,
can
be found on the FAA site:

http://www.faa.gov/about/office_org/...s_offices/ato/
service_units/techops/navservices/gnss/approaches/media/LPVs_060409
(ALL).xls
--
Kevin Horton
Ottawa, Canada
 




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 02:45 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.
Credit Consolidation - Myspace Layouts - Cheat Codes - Anime Episodes - Credit Consolidation