PRN133 ranging now useable for SoL, at non precision approach level

[macpacheco]

Since PRN133 was set healthy for WAAS corrections, its ranging was
kept at NM (Not Monitored) level, preventing its use for safety of
life applications, however in the last few days, its ranging improved
to UDRE 50 meters, which allows it to contribute for non precision
approaches.

With this improvement now all 3 WAAS satellites have ranging useable
for navigation. The other two WAAS satellites usually work at UDRE 7.5
meters which allows it to contribute even to precision approaches.

In contrast, GPS satellites normally operate at 3 meters UDRE, the
best accuracy WAAS allows any ranging source to achieve.

PRN133 has been performing at UDRE of 50 with some degradation to 150.

This is most useful in South America since PRN133 has the best view of
South America of all GEOs, and with a WAAS compatible receiver capable
of tracking two SBAS GEOs, you would effectively get two extra GPS
satellites.

Marcelo Pacheco

[Alan Browne]

On 2011-10-30 16:44 , macpacheco wrote:
> Since PRN133 was set healthy for WAAS corrections, its ranging was
> kept at NM (Not Monitored) level, preventing its use for safety of
> life applications, however in the last few days, its ranging improved
> to UDRE 50 meters, which allows it to contribute for non precision
> approaches.
>
> With this improvement now all 3 WAAS satellites have ranging useable
> for navigation. The other two WAAS satellites usually work at UDRE 7.5
> meters which allows it to contribute even to precision approaches.
>
> In contrast, GPS satellites normally operate at 3 meters UDRE, the
> best accuracy WAAS allows any ranging source to achieve.
>
> PRN133 has been performing at UDRE of 50 with some degradation to 150.
>
> This is most useful in South America since PRN133 has the best view of
> South America of all GEOs, and with a WAAS compatible receiver capable
> of tracking two SBAS GEOs, you would effectively get two extra GPS
> satellites.

I suppose at least you can use 133 for integrity information for the
rest of the satellites - at least those visible and monitored in N.A.

But the WAAS differential correction would not be applied in S.A. and
the range error from 133 would pollute GPS-only nav solutions in any
case - fine for terminals and en-route only.

--
gmail originated posts filtered due to spam.

[HIPAR]

On Oct 30, 4:44*pm, macpacheco > wrote:

NASA JPL operates a Global Differential GPS system with worldwide
coverage. They claim 10cm performance.

http://www.gdgps.net/

'The NASA Global Differential GPS (GDGPS) System is a complete, highly
accurate, and extremely robust real-time GPS monitoring and
augmentation system'.

I believe the John Deere Starfire commercial service is based upon the
NASA system.

Why can't airplanes use it ?

--- CHAS

[macpacheco]

On Oct 30, 10:08*pm, HIPAR > wrote:
> On Oct 30, 4:44*pm, macpacheco > wrote:
>
> NASA JPL operates a Global Differential GPS system with worldwide
> coverage. *They claim 10cm performance.
>
> http://www.gdgps.net/
>
> 'The NASA Global Differential GPS (GDGPS) System is a complete, highly
> accurate, and extremely robust real-time GPS monitoring and
> augmentation system'.
>
> I believe the John Deere Starfire commercial service is based upon the
> NASA system.
>
> Why can't airplanes use it ?
>
> --- *CHAS

- 10 cm performance in real time kinematic or post processing ?

- 10 cm performance at what confidence level ? SBAS confidence levels
are 99.99% - 99.99999% performance, instead of the usual 50-95%.

- Any system with that kind of performance today HAS to use semi
codeless at the end user level (L2 band). The FAA/ICAO/EASA has this
ARNS paranoia mentality that considers any usage of signals outside
ARNS protected bands a BIG no-no for end user equipment. While I don't
agree, I understand that decision within their paranoia mentality.
That's because the biggest bottleneck in SBAS performance today is
IONO corrections that must be applied on a grid basis, SoL end users
can't use semi codeless for autonomous IONO corrections. SBAS iono
grids are broadcast on a 5x5 degree spacing, and their calculation is
extremely dependent on station density.

- Finally, end user receivers are not required to have extensive multi
path rejection, that's the second biggest error factor in SBAS.

- If SBAS end users were allowed to use semi codeless today, and L2C /
L5 as it became healthy for IONO corrections, the current VPL/HPL
(vertical/horizontal protection level) that range from 15-50 meters
today, would go down to 5-20 meters easily, but that's 5 meters at
99.999% level (or better), which easily means measured performance
would be sub-meter. Add extensive multi path rejection requirement and
UDRE would come down from 3 meters to 1.5 meters easily. With
protection levels in the 2-10 meters range. UDRE level includes a
multi path error budget for end user equipment. A smarter approach
would have been to exclude receiver errors from UDRE levels, and
determine receiver errors (including multipath) at equipment
certification time, and have the end user equipment add its own error
to the UDRE levels, providing for a more competitive landscape for
equipments with better multi path rejection (would be able to achieve
LPV200 approaches under scenarios that are forbidden today, and could
even provide a basis for CAT II approaches today).

Theoretically if you plug in SBAS corrections into an end user
receiver that uses the starfire logic, you should get half meter
performance or better. The difference is due to the absence of carrier
phase information in the SBAS data stream.

SBAS uses a 250bps data stream, if you remove the IONO grid from that
data stream, you take 80% of the data away, which would allow for a
five fold increase in clock/ephemeris updates. Or you could easily add
carrier phase information and still increase the update rate. LAAS has
carrier phase information for instance.

Finally, SBAS ephemeris/clock updates accuracy would improve
significantly if all SBAS systems use each other's pseudoranging, in
WAAS cases that would mean at least using three strategically selected
MSAS stations and four strategically selected EGNOS stations, allowing
for almost worldwide ephemeris/clock coverage. Today satellites flying
over the Indian Ocean get Not Monitored flags in WAAS, while
satellites over the south pacific get NM flags on EGNOS. EGNOS fares a
little better due to having one station in South Africa and one in
French Guyana (South America very close to the equator line).

If all SBAS systems used 100% of each other reference stations, they
would be able to provide worldwide clock/ephemeris updates (all
satellites) at UDRE 3 for all satellites north of 30S latitude and
mostly UDRE 3 for satellites south of that line.

Marcelo Pacheco

[Alan Browne]

On 2011-10-30 20:08 , HIPAR wrote:
> On Oct 30, 4:44 pm, > wrote:
>
> NASA JPL operates a Global Differential GPS system with worldwide
> coverage. They claim 10cm performance.
>
> http://www.gdgps.net/
>
> 'The NASA Global Differential GPS (GDGPS) System is a complete, highly
> accurate, and extremely robust real-time GPS monitoring and
> augmentation system'.
>
> I believe the John Deere Starfire commercial service is based upon the
> NASA system.
>
> Why can't airplanes use it ?

First off it's proprietary - something WAAS/EGNOS avoid. Airlines are
loathe to add equipment and pay operating fees for it. (Not to mention
that JD would have to build (or have an avionics firm design, build and
certify) airborne Starfire receivers.

Secondly, Starfire receivers are L1+L2. More expensive than L1
receivers. L1+L2(codeless) phase comparisons provide for a lot of local
PR correction due to ionospheric delays. The data downloaded by
Starfire is thus limited to non-iono effects (ephemeris error, clock error).

So, an aviation certified L1/L2 antenna would be needed as well (I don't
know if any exist but surely a military antenna could be put through the
paces for DO-160D and whichever TSO applies to GPS antennas,
appropriately modified to cover L2 reception).

It doesn't provide (I assume) integrity signals - though likely it could
with little additional effort.

Aparently Starfire also uses the WAAS ephemeris/clock data even if it is
not as accurate as Starfire's own eph/clk data.

Finally, there may be various forms of liability issues both on the part
of JD and the national airspace services.

--
gmail originated posts filtered due to spam.

[macpacheco]

On Oct 31, 11:56*am, Alan Browne >
wrote:
> On 2011-10-30 20:08 , HIPAR wrote:
>
> > On Oct 30, 4:44 pm, > *wrote:
>
> > NASA JPL operates a Global Differential GPS system with worldwide
> > coverage. *They claim 10cm performance.
>
> >http://www.gdgps.net/
>
> > 'The NASA Global Differential GPS (GDGPS) System is a complete, highly
> > accurate, and extremely robust real-time GPS monitoring and
> > augmentation system'.
>
> > I believe the John Deere Starfire commercial service is based upon the
> > NASA system.
>
> > Why can't airplanes use it ?
>
> First off it's proprietary - something WAAS/EGNOS avoid. *Airlines are
> loathe to add equipment and pay operating fees for it. *(Not to mention
> that JD would have to build (or have an avionics firm design, build and
> certify) airborne Starfire receivers.
>
> Secondly, Starfire receivers are L1+L2. *More expensive than L1
> receivers. *L1+L2(codeless) phase comparisons provide for a lot of local
> PR correction due to ionospheric delays. *The data downloaded by
> Starfire is thus limited to non-iono effects (ephemeris error, clock error).
>
> So, an aviation certified L1/L2 antenna would be needed as well (I don't
> know if any exist but surely a military antenna could be put through the
> paces for DO-160D and whichever TSO applies to GPS antennas,
> appropriately modified to cover L2 reception).
>
> It doesn't provide (I assume) integrity signals - though likely it could
> with little additional effort.
>
> Aparently Starfire also uses the WAAS ephemeris/clock data even if it is
> not as accurate as Starfire's own eph/clk data.
>
> Finally, there may be various forms of liability issues both on the part
> of JD and the national airspace services.
>
> --
> gmail originated posts filtered due to spam.

L2 isn't ARNS protected, so they are forbidden for aviation SBAS
receivers.
The only means for IONO corrections on SBAS receivers will be with L1/
L5, both in ARNS protected band, hence the importance of GPS L5
becoming operational for dual frequency SBAS (we might get Galileo
operational prior to GPS L5, and use Galileo dual frequency + GPS
single frequency for EGNOS).

[Alan Browne]

On 2011-11-01 02:34 , macpacheco wrote:
> On Oct 31, 11:56 am, Alan >
> wrote:
>> On 2011-10-30 20:08 , HIPAR wrote:
>>
>>> On Oct 30, 4:44 pm, > wrote:
>>
>>> NASA JPL operates a Global Differential GPS system with worldwide
>>> coverage. They claim 10cm performance.
>>
>>> http://www.gdgps.net/
>>
>>> 'The NASA Global Differential GPS (GDGPS) System is a complete, highly
>>> accurate, and extremely robust real-time GPS monitoring and
>>> augmentation system'.
>>
>>> I believe the John Deere Starfire commercial service is based upon the
>>> NASA system.
>>
>>> Why can't airplanes use it ?
>>
>> First off it's proprietary - something WAAS/EGNOS avoid. Airlines are
>> loathe to add equipment and pay operating fees for it. (Not to mention
>> that JD would have to build (or have an avionics firm design, build and
>> certify) airborne Starfire receivers.
>>
>> Secondly, Starfire receivers are L1+L2. More expensive than L1
>> receivers. L1+L2(codeless) phase comparisons provide for a lot of local
>> PR correction due to ionospheric delays. The data downloaded by
>> Starfire is thus limited to non-iono effects (ephemeris error, clock error).
>>
>> So, an aviation certified L1/L2 antenna would be needed as well (I don't
>> know if any exist but surely a military antenna could be put through the
>> paces for DO-160D and whichever TSO applies to GPS antennas,
>> appropriately modified to cover L2 reception).
>>
>> It doesn't provide (I assume) integrity signals - though likely it could
>> with little additional effort.
>>
>> Aparently Starfire also uses the WAAS ephemeris/clock data even if it is
>> not as accurate as Starfire's own eph/clk data.
>>
>> Finally, there may be various forms of liability issues both on the part
>> of JD and the national airspace services.
>>
>> --
>> gmail originated posts filtered due to spam.
>
> L2 isn't ARNS protected, so they are forbidden for aviation SBAS
> receivers.

I was just answering HIPAR's general question. The same list applies to
L5 use as well. Of course L5 birds are rare so it will be a long time
before there are enough for actual aviation use.

> The only means for IONO corrections on SBAS receivers will be with L1/
> L5, both in ARNS protected band, hence the importance of GPS L5
> becoming operational for dual frequency SBAS (we might get Galileo
> operational prior to GPS L5, and use Galileo dual frequency + GPS
> single frequency for EGNOS).

L5 isn't exactly usable yet with all of 2 sats in orbit. Will be a long
wait before any advance with any system. For simplicity sake (a good
thing in avionics) mixing GPS with EGNOS in a system won't be seen in
avionics for quite a while yet.

--
gmail originated posts filtered due to spam.

[Alan Browne]

On 2011-11-01 09:25 , Alan Browne wrote:
> On 2011-11-01 02:34 , macpacheco wrote:
>> On Oct 31, 11:56 am, Alan >
>> wrote:
>>> On 2011-10-30 20:08 , HIPAR wrote:
>>>
>>>> On Oct 30, 4:44 pm, > wrote:
>>>
>>>> NASA JPL operates a Global Differential GPS system with worldwide
>>>> coverage. They claim 10cm performance.
>>>
>>>> http://www.gdgps.net/
>>>
>>>> 'The NASA Global Differential GPS (GDGPS) System is a complete, highly
>>>> accurate, and extremely robust real-time GPS monitoring and
>>>> augmentation system'.
>>>
>>>> I believe the John Deere Starfire commercial service is based upon the
>>>> NASA system.
>>>
>>>> Why can't airplanes use it ?
>>>
>>> First off it's proprietary - something WAAS/EGNOS avoid. Airlines are
>>> loathe to add equipment and pay operating fees for it. (Not to mention
>>> that JD would have to build (or have an avionics firm design, build and
>>> certify) airborne Starfire receivers.
>>>
>>> Secondly, Starfire receivers are L1+L2. More expensive than L1
>>> receivers. L1+L2(codeless) phase comparisons provide for a lot of local
>>> PR correction due to ionospheric delays. The data downloaded by
>>> Starfire is thus limited to non-iono effects (ephemeris error, clock
>>> error).
>>>
>>> So, an aviation certified L1/L2 antenna would be needed as well (I don't
>>> know if any exist but surely a military antenna could be put through the
>>> paces for DO-160D and whichever TSO applies to GPS antennas,
>>> appropriately modified to cover L2 reception).
>>>
>>> It doesn't provide (I assume) integrity signals - though likely it could
>>> with little additional effort.
>>>
>>> Aparently Starfire also uses the WAAS ephemeris/clock data even if it is
>>> not as accurate as Starfire's own eph/clk data.
>>>
>>> Finally, there may be various forms of liability issues both on the part
>>> of JD and the national airspace services.
>>>
>>> --
>>> gmail originated posts filtered due to spam.
>>
>> L2 isn't ARNS protected, so they are forbidden for aviation SBAS
>> receivers.
>
> I was just answering HIPAR's general question. The same list applies to
> L5 use as well. Of course L5 birds are rare so it will be a long time
> before there are enough for actual aviation use.
>
>> The only means for IONO corrections on SBAS receivers will be with L1/
>> L5, both in ARNS protected band, hence the importance of GPS L5
>> becoming operational for dual frequency SBAS (we might get Galileo
>> operational prior to GPS L5, and use Galileo dual frequency + GPS
>> single frequency for EGNOS).
>
> L5 isn't exactly usable yet with all of 2 sats in orbit. Will be a long
> wait before any advance with any system. For simplicity sake (a good
> thing in avionics) mixing GPS with EGNOS in a system won't be seen in
..............
> avionics for quite a while yet.

Sorry - meant to say mixing GPS with Galileo.


--
gmail originated posts filtered due to spam.

[macpacheco]

On Nov 1, 1:18*pm, Alan Browne >
wrote:
> On 2011-11-01 09:25 , Alan Browne wrote:
>
>
>
>
>
>
>
> > On 2011-11-01 02:34 , macpacheco wrote:
> >> On Oct 31, 11:56 am, Alan >
> >> wrote:
> >>> On 2011-10-30 20:08 , HIPAR wrote:
>
> >>>> On Oct 30, 4:44 pm, > wrote:
>
> >>>> NASA JPL operates a Global Differential GPS system with worldwide
> >>>> coverage. They claim 10cm performance.
>
> >>>>http://www.gdgps.net/
>
> >>>> 'The NASA Global Differential GPS (GDGPS) System is a complete, highly
> >>>> accurate, and extremely robust real-time GPS monitoring and
> >>>> augmentation system'.
>
> >>>> I believe the John Deere Starfire commercial service is based upon the
> >>>> NASA system.
>
> >>>> Why can't airplanes use it ?
>
> >>> First off it's proprietary - something WAAS/EGNOS avoid. Airlines are
> >>> loathe to add equipment and pay operating fees for it. (Not to mention
> >>> that JD would have to build (or have an avionics firm design, build and
> >>> certify) airborne Starfire receivers.
>
> >>> Secondly, Starfire receivers are L1+L2. More expensive than L1
> >>> receivers. L1+L2(codeless) phase comparisons provide for a lot of local
> >>> PR correction due to ionospheric delays. The data downloaded by
> >>> Starfire is thus limited to non-iono effects (ephemeris error, clock
> >>> error).
>
> >>> So, an aviation certified L1/L2 antenna would be needed as well (I don't
> >>> know if any exist but surely a military antenna could be put through the
> >>> paces for DO-160D and whichever TSO applies to GPS antennas,
> >>> appropriately modified to cover L2 reception).
>
> >>> It doesn't provide (I assume) integrity signals - though likely it could
> >>> with little additional effort.
>
> >>> Aparently Starfire also uses the WAAS ephemeris/clock data even if it is
> >>> not as accurate as Starfire's own eph/clk data.
>
> >>> Finally, there may be various forms of liability issues both on the part
> >>> of JD and the national airspace services.
>
> >>> --
> >>> gmail originated posts filtered due to spam.
>
> >> L2 isn't ARNS protected, so they are forbidden for aviation SBAS
> >> receivers.
>
> > I was just answering HIPAR's general question. The same list applies to
> > L5 use as well. Of course L5 birds are rare so it will be a long time
> > before there are enough for actual aviation use.
>
> >> The only means for IONO corrections on SBAS receivers will be with L1/
> >> L5, both in ARNS protected band, hence the importance of GPS L5
> >> becoming operational for dual frequency SBAS (we might get Galileo
> >> operational prior to GPS L5, and use Galileo dual frequency + GPS
> >> single frequency for EGNOS).
>
> > L5 isn't exactly usable yet with all of 2 sats in orbit. Will be a long
> > wait before any advance with any system. For simplicity sake (a good
> > thing in avionics) mixing GPS with EGNOS in a system won't be seen in
>
> * * * * * * * * * * * * * * *..............
>
> > avionics for quite a while yet.
>
> Sorry - meant to say mixing GPS with Galileo.

The FAA stated that GPS L5 WAAS will only be allowed once GPS L5 is
FOC, so 22 GPS launches to go before we get there. This was reiterated
in the current issue of FAA Sat Nav News (issued in the last few
days).

One of the reasons is they will replace the whole thing, all reference
receivers will then work only with L1+L5, all current ground semi
codeless will go at once, so once they migrate to L5 for the ground
infrastructure, even GPS IIR-M will no longer be used for WAAS.

It will be a temporary big step backwards, cause we'll go from using
all operational GPS satellites to using only L5 capable satellites,
reducing from 29-31 operational satellites to 24 initially.

That's stupid in my opinion, but that's their prerogative, they should
include support for L2C for the ground receivers, using L2C for IIR-M
and L5 for IIF + III, that would keep 29+ birds usable at all times.
And Galileo + Glonass should be rolled into WAAS as well.

That's only for aviation, other receivers outside the FAA's authority
could even use semi codeless today with any SBAS.

As far as Galileo or Glonass support for WAAS, theres no word
whatsoever in adding WAAS support for that, but the ARAIM work (which
makes WAAS obsolete) would include multi constellation end user
support.

[HIPAR]

On Nov 1, 9:25*am, Alan Browne >
wrote:

....
>
> L5 isn't exactly usable yet with all of 2 sats in orbit. *Will be a long
> wait before any advance with any system. *For simplicity sake (a good
> thing in avionics) mixing GPS with EGNOS in a system won't be seen in
> avionics for quite a while yet.
>
> --

I couldn't agree more that we need simplicity .. too many
constellations transmitting signals that are compatible only by the
definition of not interfering with each other. My head would be
spinning if I were tasked to perform a trade study defining the next
generation of avionics. But the GNSS community thinks this kind of
diversity is great so those geniuses like Marcelo (just joking) can
sort it out.

Would it have been nice if Galileo L5 and NAVSTAR L5 shared a common
ICD? Would it have been nice if there were a common L1 modernized
signal. That would be 'bound' the problem.

Regarding WDGPS, I really don't understand who actually controls
access to the system. If NASA operates the core system, what kind of
agreement does the US government have with Deere allowing them
exclusive commercial marketing rights under the Starfire trademark?
NASA/JPL doesn't say much about that.

I looked over a few of the easier to read references concerning the
JPL system. This one addresses the expected performance for a GDGPS
corrected C/A code system:

http://www.gdgps.net/system-desc/papers/SiRF_SingleFreqCorr.pdf

Receiving L1 only, I'd say it might provide WAAS grade performance.
Getting back to simplicity, the need to receive the corrections from
another satellite system would complicate the actual operations.
Along with the other issues discussed, WAAS remains a more practical
system for airplanes.

--- CHAS

[Alan Browne]

On 2011-11-01 17:47 , HIPAR wrote:
> On Nov 1, 9:25 am, Alan >
> wrote:
>
> ...
>>
>> L5 isn't exactly usable yet with all of 2 sats in orbit. Will be a long
>> wait before any advance with any system. For simplicity sake (a good
>> thing in avionics) mixing GPS with EGNOS in a system won't be seen in
>> avionics for quite a while yet.
>>
>> --
>
> I couldn't agree more that we need simplicity .. too many
> constellations transmitting signals that are compatible only by the
> definition of not interfering with each other. My head would be
> spinning if I were tasked to perform a trade study defining the next
> generation of avionics. But the GNSS community thinks this kind of
> diversity is great so those geniuses like Marcelo (just joking) can
> sort it out.
>
> Would it have been nice if Galileo L5 and NAVSTAR L5 shared a common
> ICD? Would it have been nice if there were a common L1 modernized
> signal. That would be 'bound' the problem.

That wouldn't fly far - there are only so many viable gold codes -
though possibly many more on L5 with its longer code length.

> Regarding WDGPS, I really don't understand who actually controls
> access to the system. If NASA operates the core system, what kind of
> agreement does the US government have with Deere allowing them
> exclusive commercial marketing rights under the Starfire trademark?
> NASA/JPL doesn't say much about that.

No idea. But with the network of ground stations collecting the data
for GDGPS that data can be "sold" to J-D for further use. In that sense
JD depend on the network, but they package the data for Starfire (and to
finer resolution and accuracy than WAAS).

> I looked over a few of the easier to read references concerning the
> JPL system. This one addresses the expected performance for a GDGPS
> corrected C/A code system:
>
> http://www.gdgps.net/system-desc/papers/SiRF_SingleFreqCorr.pdf
>
> Receiving L1 only, I'd say it might provide WAAS grade performance.
> Getting back to simplicity, the need to receive the corrections from
> another satellite system would complicate the actual operations.
> Along with the other issues discussed, WAAS remains a more practical
> system for airplanes.

But EGNOS provides SBAS for both GPS and GLONASS...

--
gmail originated posts filtered due to spam.

[Ed M.[_2_]]

On Nov 1, 2:47*pm, HIPAR > wrote:
>
> Regarding *WDGPS, *I really don't understand who actually controls
> access to the system. *If NASA operates the core system, what kind of
> agreement does the US government have with Deere allowing them
> exclusive commercial marketing rights under the Starfire trademark?
> NASA/JPL doesn't say much about that.
>
> --- *CHAS

JPL alludes to commercial opportunities on their site, but don't give
specifics of licensing, fees, etc. Clicking on the "Customer Portal"
tab yields a certificate error message.

http://www.gdgps.net/system-desc/network.html

"The core of the GDGPS network is the NASA Global GPS Network (GGN), a
JPL-owned and operated network of roughly 70 geodetic-quality, dual
frequency receivers, distributed globally. Additional real-time sites
are contributed by a variety of U.S. and international partner
organizations. The result is the world's largest real-time GPS
tracking network, with more than 100 global sites (as of October
2006). All these sites stream their GPS measurements at 1 Hz to the
GDGPS Operation Centers (GOCs), where it is processed and analyzed in
real-time.

.. . . The GDGPS system is proud to count 4 national timing
laboratories among it contributing network partners. In particular,
the United States Naval Observatory (USNO) contributes two monitoring
sites driven by its Master Clock, allowing the GDGPS System to provide
its global users the most accurate real-time realization of USNO UTC.

.. . . We continue to expand our network, and welcome contributions
from interested organizations. We offer our network partners a variety
of benefits, including real-time positioning, timing, and
environmental monitoring, as well as data archiving and data
distribution through the NASA CDDIS facility."

http://www.gdgps.net/applications/index.html

"The GDGPS System produces differential corrections to the GPS
broadcast ephemeris with unparelleled accuracy and seamless global
validity. Various GDGPS technology components and data products are
being used by nearly all of the providers of premium global
differential corrections. The underlying software and algorithms are
being used by the FAA's Wide Area Augmentation System (WAAS), and its
Japanese counterpart, MSAS. "

http://www.gdgps.net/system-desc/references.html

Kevin Dixon, "StarFire: A Global SBAS for Sub-Decimeter Precise Point
Positioning," ION GNSS 2006, Fort Worth, TX, September 2006,
http://www.gdgps.net/system-desc/papers/starfire.pdf

"The central processing hubs are based upon a version of the Real Time
GIPSY (RTG) suite, originally developed by the Jet Propulsion
Laboratory for precise real time orbit and clock determination of
GNSS. This has been refined to optimize positioning accuracy of NavCom
developed GNSS hardware.

.. . . The StarFire correction stream consists of the RTG generated
GNSS precise orbit and clock values differenced with respect to the
GNSS broadcast ephemeris.

, , , The RTG code is the latest state of the art implementation from
NASA's Jet Propulsion Laboratory."

More on RTG:

http://gipsy.jpl.nasa.gov/igdg/system/od/index.html

Some older publications imply that JPL and NavCom (or John Deere --
think they were spun off once, then brought back) may have had a joint
venture at one time.

The world map in this 2004 paper shows roughly equal number of JPL and
NavCom reference stations (NavCom in green, the John Deere color):

http://www.gmat.unsw.edu.au/wang/jgps/v3n12/v3n12p19.pdf

This 2001 NavCom press release (reprinted in GPS World) describes a
joint venture:

http://www.navcomtech.com/News/PressReleases.cfm?id=8

[Ed M.[_2_]]

On Nov 1, 3:21*pm, Alan Browne >
wrote:
>
> That wouldn't fly far - there are only so many viable gold codes -
> though possibly many more on L5 with its longer code length.
>

There are actually around 500 balanced (roughly equal number of 0s and
1s) Gold codes in GPS, if you ignore the 2-tap mechanization shown in
the ICD. The 4-asterisk footnote was added to Tables 3-I and 3-II a
few years ago when the first list of expanded codes was published in
the ICD ( " **** The two-tap coder utilized here is only an example
implementation that generates a limited set of valid C/A codes.").

With zero Doppler difference between two PRNs, any pair of the 500 or
so balanced Gold codes would have the same peak cross-correlations.
The cross-correlation peak comes up a few dB at some Doppler
differences. Gold's 1967 papers showed that the zero-Doppler peak for
a 10-bit code is limited to 20*log(65/1023) of 20*log(63/1023), where
63 and 65 represent the excess of bit by bit agreements over
disagreements (or vice versa) between the two codes at a given time
offset. His papers also showed the probability of occurrence.

The log works out to about -24 dB. But user antenna gain, as well as
differences in satellite power, can bring the peak up more.

The bigger issue is that the broadcast ephemeris doesn't include the
PRN number. It's just assumed by the receiver that it's tracking the
one it wanted. But that's not a deficiency of the Gold codes, nor
really a deficiency of the original signal design, which is quite
elegant -- an awful lot of information packed into very few bits.

All just a quibble -- you're right that the newer signals with longer
codes will work better.

[HIPAR]

On Nov 1, 7:54*pm, "Ed M." > wrote:
> On Nov 1, 3:21*pm, Alan Browne >
> wrote:
>
>
>
> > That wouldn't fly far - there are only so many viable gold codes -
> > though possibly many more on L5 with its longer code length.
>
> There are actually around 500 balanced (roughly equal number of 0s and
> 1s) Gold codes in GPS, if you ignore the 2-tap mechanization shown in
> the ICD. *The 4-asterisk footnote was added to Tables 3-I and 3-II a
> few years ago when the first list of expanded codes was published in
> the ICD ( " **** The two-tap coder utilized here is only an example
> implementation that generates a limited set of valid C/A codes.").
>
> With zero Doppler difference between two PRNs, any pair of the 500 or
> so balanced Gold codes would have the same peak cross-correlations.
> The cross-correlation peak comes up a few dB at some Doppler
> differences. *Gold's 1967 papers showed that the zero-Doppler peak for
> a 10-bit code is limited to 20*log(65/1023) of 20*log(63/1023), where
> 63 and 65 represent the excess of bit by bit agreements over
> disagreements (or vice versa) between the two codes at a given time
> offset. *His papers also showed the probability of occurrence.
>
> The log works out to about -24 dB. *But user antenna gain, as well as
> differences in satellite power, can bring the peak up more.
>
> The bigger issue is that the broadcast ephemeris doesn't include the
> PRN number. *It's just assumed by the receiver that it's tracking the
> one it wanted. *But that's not a deficiency of the Gold codes, nor
> really a deficiency of the original signal design, which is quite
> elegant -- an awful lot of information packed into very few bits.
>
> All just a quibble -- you're right that the newer signals with longer
> codes will work better.


I suppose if cross correlation becomes a problem, it can be mitigated
by placing the conflicting satellites in antipodal positions.


Current L5 PRN assignments:

http://www.losangeles.af.mil/shared/media/document/AFD-070530-041.pdf

And L1 C/A:

http://www.losangeles.af.mil/shared/media/document/AFD-101124-042.pdf

Of course, 'modernized signal' would be the operative concept for a
universal open L1 signal conforming with a common ICD. Shame it will
never happen.

It's a 'minor miracle' that SBAS has been standardized.

http://www.elisanet.fi/master.navigator/img/SBAS_Coverage.jpg

--- CHAS

[macpacheco]

On Nov 1, 10:58*pm, HIPAR > wrote:
> On Nov 1, 7:54*pm, "Ed M." > wrote:
>
>
>
>
>
>
>
>
>
> > On Nov 1, 3:21*pm, Alan Browne >
> > wrote:
>
> > > That wouldn't fly far - there are only so many viable gold codes -
> > > though possibly many more on L5 with its longer code length.
>
> > There are actually around 500 balanced (roughly equal number of 0s and
> > 1s) Gold codes in GPS, if you ignore the 2-tap mechanization shown in
> > the ICD. *The 4-asterisk footnote was added to Tables 3-I and 3-II a
> > few years ago when the first list of expanded codes was published in
> > the ICD ( " **** The two-tap coder utilized here is only an example
> > implementation that generates a limited set of valid C/A codes.").
>
> > With zero Doppler difference between two PRNs, any pair of the 500 or
> > so balanced Gold codes would have the same peak cross-correlations.
> > The cross-correlation peak comes up a few dB at some Doppler
> > differences. *Gold's 1967 papers showed that the zero-Doppler peak for
> > a 10-bit code is limited to 20*log(65/1023) of 20*log(63/1023), where
> > 63 and 65 represent the excess of bit by bit agreements over
> > disagreements (or vice versa) between the two codes at a given time
> > offset. *His papers also showed the probability of occurrence.
>
> > The log works out to about -24 dB. *But user antenna gain, as well as
> > differences in satellite power, can bring the peak up more.
>
> > The bigger issue is that the broadcast ephemeris doesn't include the
> > PRN number. *It's just assumed by the receiver that it's tracking the
> > one it wanted. *But that's not a deficiency of the Gold codes, nor
> > really a deficiency of the original signal design, which is quite
> > elegant -- an awful lot of information packed into very few bits.
>
> > All just a quibble -- you're right that the newer signals with longer
> > codes will work better.
>
> I suppose if cross correlation becomes a problem, it can be mitigated
> by placing the conflicting satellites in antipodal positions.
>
> Current L5 PRN assignments:
>
> http://www.losangeles.af.mil/shared/media/document/AFD-070530-041.pdf
>
> And L1 C/A:
>
> http://www.losangeles.af.mil/shared/media/document/AFD-101124-042.pdf
>
> Of course, *'modernized signal' would be the operative concept for a
> universal open L1 signal conforming with a common ICD. *Shame it will
> never happen.
>
> It's a 'minor miracle' that SBAS has been standardized.
>
> http://www.elisanet.fi/master.navigator/img/SBAS_Coverage.jpg
>
> --- *CHAS

One interesting question, military and L5 signals both use a 10 mega
chip/sec signal, clearly better for jamming tolerance and ability to
acquire a signal under challenging conditions, but does 50 10 mega
chip/sec signals being received at the same band perform better than
50 1 mega chip/sec signals ?

As far as the common ICD, I believe this will take 20-30 years, and
will happen when L1 C/A gets retired and replaced by a brand new
signal, perhaps a 10 mega chip/sec signal, broadcast by all GPS
satellites (one can hope...).

Also there has been talk about a signal in the 5GHz band, maybe one
day we could have a sane, normalized signal there too. A 5GHz signal
would improve IONO corrections hugely, due to the multi GHz jump in
frequency.

SBAS has a common ICD due to FAA having no proprietary interest in the
signal, quite on the opposite, by making SBAS signal structure a
worldwide standard benefits the early manufacturers (Americans) to
come to market, and due to the obvious requirement that an American
aircraft needs to be able to fly elsewhere in the world and use the
other SBAS systems, much like ILS/VOR/NDB/DME allow that today and
vice-versa. The requirements for revision control, documentation and
testing of software onboard aircraft navigation systems is 100%
assinine and extremely expensive. Talk about burying yourself in
paperwork.

But are the ICD differences between GPS/Galileo and QZSS that big ? It
seems to me that the differences are 100% software stuff, nothing to
do with acquiring and tracking the signal, just in the higher level
functions, like a few ifs in the higher level software of a receiver.
I have not read those ICDs, I'm really asking.

Marcelo Pacheco

[Alan Browne]

On 2011-11-01 19:54 , Ed M. wrote:
> On Nov 1, 3:21 pm, Alan >
> wrote:
>>
>> That wouldn't fly far - there are only so many viable gold codes -
>> though possibly many more on L5 with its longer code length.
>>
>
> There are actually around 500 balanced (roughly equal number of 0s and

To avoid x-correlation there are only 35 or so. Don't recall the
correct number.

--
gmail originated posts filtered due to spam.

[Terje Mathisen]

Alan Browne wrote:
> On 2011-11-01 19:54 , Ed M. wrote:
>> On Nov 1, 3:21 pm, Alan >
>> wrote:
>>>
>>> That wouldn't fly far - there are only so many viable gold codes -
>>> though possibly many more on L5 with its longer code length.
>>>
>>
>> There are actually around 500 balanced (roughly equal number of 0s and
>
> To avoid x-correlation there are only 35 or so. Don't recall the correct
> number.

I have read a white paper which stated that the number of available Gold
codes was (afair) in the 60-70 range.

For randomly generated 1023-bit codes we should expect collisions around
32 (sqrt(1024)), but since the codes can be selected by hand, they can
get away with approximately twice as many without having problems with
cross-correlation, with or without doppler corrections.

Several people have noted that you could theoretically get twice as many
sats if you set them up in pairs on opposite side of the globe, but
since there's no explicit sat nr in the transmitted msg, this won't work
with any currently deployed gps receivers.

(In theory, as long as the pairs were not exactly opposite, you should
be able to determine which hemisphere was the correct one by looking at
the residual errors for each of them?)

Terje
--
- <Terje.Mathisen at tmsw.no>
"almost all programming can be viewed as an exercise in caching"

[Alan Browne]

On 2011-11-02 09:43 , Terje Mathisen wrote:
> Alan Browne wrote:
>> On 2011-11-01 19:54 , Ed M. wrote:
>>> On Nov 1, 3:21 pm, Alan >
>>> wrote:
>>>>
>>>> That wouldn't fly far - there are only so many viable gold codes -
>>>> though possibly many more on L5 with its longer code length.
>>>>
>>>
>>> There are actually around 500 balanced (roughly equal number of 0s and
>>
>> To avoid x-correlation there are only 35 or so. Don't recall the correct
>> number.
>
> I have read a white paper which stated that the number of available Gold
> codes was (afair) in the 60-70 range.

The number of "suitable codes" is 37. Again, x-correlation is the issue.

http://www.kowoma.de/en/gps/signals.htm as we discussed here some months
ago.

As I've stated in the past (and HIPAR states in this thread) one could
put satellites in opposition in the same plane and use the codes twice.

A quick scan (meaning I might have read it wrong) of ICD-200 data frames
doesn't appear to name the transmitting SV. - which would help
"unconfuse" the receiver (would need two almanacs per PRN). Acquisition
of PRN, eg: 23, would require knowledge of both almanacs and careful
attention to the ephemeris used if there is no other means of
identifying which is which. (Of course with reliable init position and
time, this would be unambiguous. For a cold start it wouldn't matter:
search a PRN and if it comes up it's one of the two). Problem is how to
store two almanacs per PRN, acquire and track without screwing up.
Could require an analysis of several satellite positions to
unambiguously select.

In brief, the PRN is the identifier for the satellite. (Almanac data
identifies the satellite for the data set (In the convoluted definition
of subframes 4 and 5 which carry a lot of almanac and other data ...
over a 12.5 minute cycle)).

http://www.navcen.uscg.gov/pubs/gps/icd200/ICD200Cw1234.pdf

--
gmail originated posts filtered due to spam.

[Ed M.[_2_]]

Up front, I apologize for nit-picking. I agree with all the posts
about modernized signals (L2C, L5, L1C). They have all been designed
to correct various problems experienced with C/A code.

Meanwhile, the number of C/A codes is being expanded to 209, or about
40% of the balanced C/A codes. Many or most of these may never
actually be broadcast, but they are defined.

From Spilker's paper in the Summer 1978 special issue of the ION
Journal (alias "Vol. I Red Book"):

Spilker, J. J., "SIGNAL STRUCTURE AND PERFORMANCE CHARACTERISTICS
(SPACE SEGMENT)", NAVIGATION, Vol. 25, No. 2, Summer 1978, pp.
121-146.
http://www.ion.org/search/view_abstract.cfm?jp=j&idno=680

"Thus the advantage of the Gold codes is not simply a low cross-
correlation between all members of the family but that there are a
large number of codes all of similar good properties.

.. . . Fig. 2-13 shows the cumulative probability of various cross-
correlation interference levels for the GPS C/A code for various
doppler shifts from fd = 0 to + 5 kHz. Note that the 4 kHz doppler
gives the worst cross-correlation sidelobe over this range; however,
the other doppler shifts give similar results. These cumulative
averages are formed by averaging results for alI 1023 of the Gold
codes of period 1023 in the GPS family. All possible code time offsets
are considered for each doppler offset and ail possible pairs of codes
in this family. . . .

Peak Cross-correlation (any doppler shift) -21.6 dB
Peak Cross-correlation (zero doppler) -23.8 dB
Probability of worst case or near worst case cross-correlation 0.25
"


Couldn't find a free on-line copy of that paper, but you can browse
the Vol. I "Blue Book" via Google Books:

Global positioning system: theory and applications, Volume 1, Bradford
W. Parkinson and James J. Spilker (eds.),
AIAA, 1996, ISBN: 156347106X, 9781563471063

http://books.google.com/books?id=lvI1a5J_4ewC

pg. 99: "The number of balanced Gold codes is . . . 513 . . . ."

pg. 102, Table 9

The table shows that the cross-correlation of any pair of Gold codes
is 1/1023 with probability 3/4, 63/1023 with probability 1/8, and
65/1023 with probability 1/8. Taking 20*Log10 of those values gives
worst case cross-correlation of -23.8 dB, and best case of -30 dB.

Again, these theoretical cross-correlation peaks are valid only for
zero Doppler. As Spilker notes in his 1978 ION paper, the worst case
Doppler raises that peak about 2.2 dB.


IS-GPS-200E shows C/A code generation in Figs. 3-8 through 3-10, and
Table 3-I.

http://www.gps.gov/technical/icwg/

http://www.gps.gov/technical/icwg/IS-GPS-200E.pdf

The table and Fig. 3-10 show a "2-tap" mechanization, in which 2
stages of the G2 shift register are tapped and added modulo 2 to the
output of the G1 register. Since the G2 register has 10 stages, there
are 45 ways ("10 choose 2") to do this.

Table 3-1 shows only 36 unique tap pairs. PRNs 34 and 37 are
identical on C/A code (though unique on P-Y code).

The reason is that the other 9 tap pairs produce unbalanced codes,
i.e., the number of 0s and 1s differ by more than 1. Note also that
the selection of a pair of stages is equivalent to a time delay of the
G2 sequence. The newly defined C/A codes are defined on the basis of
G2 time delay, so that information has been added to Table 3-I for
consistency.

C/A codes can easily be generated in a spreadsheet, which shows that
the other 9 2-tap codes are unbalanced.

IS-GPS-200E defines 173 new C/A codes, for a total of 209 unique ones,
or 210 total.

"6.3.6.1 Additional C/A-code PRN sequences. The PRN C/A-code is
described in Section 3.2.1.3 and 36 legacy C/A-code sequences are
assigned by SV-ID number in Table 3-I. An additional set of 173 C/A-
code PRN sequences are selected and assigned with PRN numbers in this
section as shown in Table 6-I. Among the 173 additional sequences; PRN
numbers 38 through 63 are reserved for future GPS SVs; PRN numbers 64
through 119 are reserved for future Ground Based Augmentation System
(GBAS) and other augmentation systems; PRN numbers 120 through 158 are
reserved for SBAS; and PRN numbers 159 through 210 are reserved for
other Global Navigation Satellite System (GNSS) applications."

This information will evntually migrate from Sec. 6 to Sec. 3.

The implication is that someone has gone through the tedious effort of
examining roughly 125,000 (513 choose 2) pairs of codes for
undesirable cross-correlation properties, and selected the 173 "best"
in some sense for the PRN expansion.