GPS World -- How Many? 32: SVN23/PRN32 to be Set to Healthy
Sam Wormley
http://sidt.gpsworld.com/gpssidt/content/printContentPopup.jsp?id=490027
Feb 7, 2008
GPS World
The U.S. military announced earlier this week that GPS satellite
SVN23, transmitting L-band code as PRN32, will be set to usable
status on Feb. 19.
This is notable for a couple of reasons, but namely because it is the
first time that the PRN32 designation will be used by an operational,
healthy GPS satellite.
GPS receivers initially were built to accommodate up to 31 satellite
signals, and a PRN designated with the number 32 can't be tracked by
some manufacturers' devices that look for PRNs numbered 0 through 31.
The U.S. Air Force began testing the PRN32 designation late in 2006
-- while SVN23/PRN32 was set to unhealthy and not included in the
operational GPS constellation almanac, some all-in-view GNSS tracking
stations received the L-band signal.
As of January 2007, SVN23 has been broadcasting but set to unhealthy
and not included in the almanac. Nevertheless, a number of civilian
users have reported being able to track PRN32 since then.
The setting of satellite SVN23/PRN32 to healthy is also notable
because in GPS satellite terms, it's coming back from the dead, or at
least from decommissioning. It is the first Block IIA satellite,
launched on Nov. 26, 1990, and initially decommissioned on Feb.13,
2004, after more than 13 years of service. Apparently the U.S. Air
Force reactivated it at some point and set it to broadcast a
non-standard code that could not be tracked by standard GPS
receivers. However, on Dec. 2, 2006, it started to transmit the
standard PRN32 code as part of the Air Force's initial test.
Bruce
"Sam Wormley" <swor...@mchsi.com> wrote in message
news:61Sqj.20775$9j6.20717@attbi_s22...
I just downloaded and installed the latest Trimble Planning software
(http://www.trimble.com/planningsoftware_ts.asp) and the latest almanac.
The software only shows up to PRN 31. I cant tell what the currency of the
almanac is though, it does appear to show PRN 32, but it looks like there
may be a flag, 'ff', that perhaps means that it is out of service.
Haven't yet seen PRN 32 on my GPSmap60CSx.
BTW I have been occasionaly seeing PRN 33, which is an EGNOS sat somewhere
off the west coast of Africa.
Bruce
"Bruce" <nu...@null.com> wrote in message
news:%V2rj.44400$m6.1...@newsfe18.lga...
' 0'. Now PRN 32 shows up in the Trimble planning software. According to
that I should be able to see PRN 32, but no joy so far. I'm looking at
firmware updates.
Bruce
save my station settings so when I restarted Trimble it was at the wrong
station. The correct station shows PRN 32 coming into view starting at 6 PM
EST. I also checked my firmware version and it is up to date.
Sam Wormley
:-)
news.giganews.com
Would you happen to know if the firmware in common handhelds
like Garmin 60/70 would be able to see #32?
"Sam Wormley" <swor...@mchsi.com> wrote in message news:61Sqj.20775$9j6.20717@attbi_s22...
Bruce
"news.giganews.com" <richard...@nessnet.spam.com> wrote in message
news:u-qdnYlD5vOY_DPa...@giganews.com...
9:30 PM EST Washington DC area, I got PRN 32 on my GPSmap60CSx. It is
really far north. I got WAAS PRN 51 at the same time but no dgps on PRN 32.
Jon
> "news.giganews.com" <richard.nod...@nessnet.spam.com> wrote in message
>
[...]
> >> Feb 7, 2008
> >> GPS World
>
> >> The U.S. military announced earlier this week that GPS satellite
> >> SVN23, transmitting L-band code as PRN32, will be set to usable
> >> status on Feb. 19.
> >> As of January 2007, SVN23 has been broadcasting but set to unhealthy
> >> and not included in the almanac. Nevertheless, a number of civilian
> >> users have reported being able to track PRN32 since then.
> 9:30 PM EST Washington DC area, I got PRN 32 on my GPSmap60CSx. It is
> really far north. I got WAAS PRN 51 at the same time but no dgps on PRN 32.
Not surprising as it would appear that PRN32 is currently set
unhealthy:
******** Week 442 almanac for PRN-32 ********
ID: 32
Health: 063
Eccentricity: 0.1402425766E-001
Time of Applicability(s): 147456.0000
Orbital Inclination(rad): 0.9708557129
Rate of Right Ascen(r/s): -0.8036295185E-008
SQRT(A) (m 1/2): 5154.639648
Right Ascen at Week(rad): 0.2849555850E+001
Argument of Perigee(rad): -1.321666718
Mean Anom(rad): -0.1152807951E+001
Af0(s): 0.2260208130E-003
Af1(s/s): 0.1091393642E-010
week: 442
Regards,
Jon
Sam Wormley
> Sam,
>
> Would you happen to know if the firmware in common handhelds
> like Garmin 60/70 would be able to see #32?
>
>
At 3:32 UTC Feb 10, 2008 -- No sign of PRN 32 on
any of these:
Trimble Pro XRS TerraSync 2.20
Trimble GeoXT TerraSync 2.21
Trimble GeoEx 3
Sam Wormley
I'll try again when the status bit is set healthy.
Dan Anderson
[snip]
> 9:30 PM EST Washington DC area, I got PRN 32 on my GPSmap60CSx. It is
> really far north. I got WAAS PRN 51 at the same time but no dgps on PRN 32.
I've noticed PRN 32 displayed at various times of day on the
satellite screen of a Garmin GPSmap 76Cx (SiRF III chipset).
I haven't payed attention to how often but I first noticed
it last Spring.
The indicator was on top of the "N" for North where there
are no GPS satellites and it didn't move as time passed
so it couldn't have been in "orbit" as far as the receiver
was concerned.
It'll be interesting to see how many receivers will actually
track/use it.
--
Dan
(Email: dan at domain below )
(www.gpsmap.net)
Tom
> At 3:32 UTC Feb 10, 2008 -- No sign of PRN 32 on
> any of these:
>
> Trimble Pro XRS TerraSync 2.20
> Trimble GeoXT TerraSync 2.21
> Trimble GeoEx 3
Garmin Colorado seems to be of the same quality :)
(no sign of PRN 32), but 60CSx shows the "32" at the
far north (it looks as "geostationary" over the Pole).
--
Tom
pat_...@yahoo.com
GPS World says "GPS receivers initially were built to accommodate up
to 31 satellite
signals, and a PRN designated with the number 32 can't be tracked
by
some manufacturers' devices that look for PRNs numbered 0 through
31."
This may or may not be a true statement, but either way, it's not
obvious why a manufacturer would design for a PRN range of 0 to 31.
IS-GPS-200D ( http://www.navcen.uscg.gov/gps/geninfo/IS-GPS-200D.pdf
), Table 3-I on pgs. 7-8, shows PRNs from 1 to 37.
For the semi-codeless receivers, the same document, para. 3.3.2.2, pg.
25, says:
"The X2i sequences are generated by first producing an X2 sequence and
then delaying it by a selected integer
number of chips, i, ranging from 1 to 37. Each of the X2i sequences is
then modulo-2 added to the X1 sequence
thereby producing up to 37 unique P(t) sequences."
Note that neither Table 3-I nor para. 3.3.2.2 lists or defines a PRN
0.
Excluding PRNs 33-37, the manufacturer should have expected a range of
1-32 (assuming that ancestor versions of this document said
essentially the same thing).
On the topic of which receivers can and cannot acquire/track PRN 32,
here are a few IGS messages:
http://igscb.jpl.nasa.gov/mail/igsmail/2006/msg00232.html
http://igscb.jpl.nasa.gov/mail/igsmail/2006/msg00234.html
The second IGS mail links to this GPS World article:
http://www.gpsworld.com/gpsworld/article/articleDetail.jsp?id=393807
PRN32 was last used by SVN32. It used that code until January 28,
1993, when its code was switched to PRN01.
which says:
"PRN32 was last used by SVN32. It used that code until January 28,
1993, when its code was switched to PRN01."
According to the USNO ( ftp://tycho.usno.navy.mil/pub/gps/gpsb2.txt )
SVN32 was launched on 22 Nov 1992 and became usable on 11 Dec 1992.
Thus PRN 32 was being broadcast for about 7 weeks. Apparently user
problems were the motivation to stop transmitting PRN 32 back in early
1993. But the problem seems to have been caused by some manufacturers
not complying with system documentation.
Dale DePriest
pat_...@yahoo.com wrote:
> On Feb 10, 7:29 pm, "Tom" <gps...@net.hr> wrote:
> GPS World says "GPS receivers initially were built to accommodate up
> to 31 satellite
> signals, and a PRN designated with the number 32 can't be tracked
> by
> some manufacturers' devices that look for PRNs numbered 0 through
> 31."
>
> This may or may not be a true statement, but either way, it's not
> obvious why a manufacturer would design for a PRN range of 0 to 31.
It may not be obvious to you but there are only 5 bits in the message to
track PRN so the obvious values are 0 to 31 since this is all you can do
with 5 bits. Isn't that pretty obvious? Now the question is what to do
with the 0 since 0 to 31 is really 32 numbers. At one time it was
thought that 0 might be used to mark bad satellites but it is clear now
that 0 should be mapped to 32 but that may not have been obvious 5 years
ago. Hindsight is always 20/20.
at any rate the receiver needs to map the value of 0 to 32 just like it
already maps the number 33 and above. But it is likely that receivers
that support WAAS and its siblings will do the mapping for 32 but not
guaranteed.
Dale
--
_ _ Dale DePriest
/`) _ // http://users.cwnet.com/dalede
o/_/ (_(_X_(` For GPS and GPS/PDAs
Marty Ryba
news:13r3nf3...@corp.supernews.com...
> pat_...@yahoo.com wrote:
>> This may or may not be a true statement, but either way, it's not
>> obvious why a manufacturer would design for a PRN range of 0 to 31.
>
> It may not be obvious to you but there are only 5 bits in the message to
> track PRN so the obvious values are 0 to 31 since this is all you can do
> with 5 bits. Isn't that pretty obvious? Now the question is what to do
> with the 0 since 0 to 31 is really 32 numbers. At one time it was thought
> that 0 might be used to mark bad satellites but it is clear now that 0
> should be mapped to 32 but that may not have been obvious 5 years ago.
> Hindsight is always 20/20.
Dale, what message are you referring to as containing only 5 bits to track
PRN? There's nothing I can think of off the top of my head in the IS-GPS-200
Navigation Data Message. In fact, one of the faults in the legacy NDM is
there is *nothing* in the ephemeris stream from a satellite that indicates
what PRN it is. It makes it easy for me to "clone" a satellite for some of
my pseudolite work (ref. my ION GNSS 2006 paper).
Marty Ryba
martin (dot) ryba (at) verizon (dot) net
Tim Springer
satellite memory to store the PRN code. Do not forget that these satellites were designed in the 1970's and memory was a very
sparse. This is also why we have the GPS "leap weeks". Only 10 bits were available to store the GPS week. Meaning the weeks run
from GPS week 0 to GPS week 1023. Currently we are in GPS week 1465 but the satellites actually transmit 442 (1465-1023). As an
end-user you do not see this since the receiver takes care of it.....
Cheers,
Tim
http://gnss.servolux.nl
"Marty Ryba" <martin.ry...@verizon.net> schrieb im Newsbeitrag news:gmssj.2255$YL3.157@trndny05...
Dale DePriest
available on board. In addition I believe many implementations of GPS
receivers, particularly early ones, only allowed 5 bits for this data
since it was enough.
However, I was actually thinking about the almanac which does store the
ID (usually representing the PRN) and the health data. I had
mis-remembered the content of this field as it is actually 6 bits and
can contain earth based data beyond that from the satellites. Sorry for
the confusion on my part. But because of the onboard implementations
mentioned earlier the 32 vs. 0 is still a reasonable error to worry about.
I am reminded of the Mathematician that went to pick up his friend the
programmer at the airport. They went to get the luggage and the
programmer indicated that he had 2 bags and 1 was missing. The
Mathematician said, but I see 2 bags. The programmer look and said see,
0, 1 ... 2 is missing.
Dale
--
Jon
> >news:gmssj.2255$YL3.157@trndny05...
> >> "Dale DePriest" <D...@gpsinformation.het> wrote in message
> >>news:13r3nf3...@corp.supernews.com...
> >>> pat_n...@yahoo.com wrote:
> >>>> This may or may not be a true statement, but either way, it's not
> >>>> obvious why a manufacturer would design for a PRN range of 0 to 31.
>
> >>> It may not be obvious to you but there are only 5 bits in the message
> >>> to track PRN so the obvious values are 0 to 31 since this is all you
> >>> can do with 5 bits. Isn't that pretty obvious? Now the question is
> >>> what to do with the 0 since 0 to 31 is really 32 numbers. At one time
> >>> it was thought that 0 might be used to mark bad satellites but it is
> >>> clear now that 0 should be mapped to 32 but that may not have been
> >>> obvious 5 years ago. Hindsight is always 20/20.
>
> >> Dale, what message are you referring to as containing only 5 bits to
> >> track PRN? There's nothing I can think of off the top of my head in
> >> the IS-GPS-200 Navigation Data Message. In fact, one of the faults in
> >> the legacy NDM is there is *nothing* in the ephemeris stream from a
> >> satellite that indicates what PRN it is. It makes it easy for me to
> >> "clone" a satellite for some of my pseudolite work (ref. my ION GNSS
> >> 2006 paper).
>
> >> Marty Ryba
> >> martin (dot) ryba (at) verizon (dot) net
>
> --
> _ _ Dale DePriest
> /`) _ // http://users.cwnet.com/dalede
> o/_/ (_(_X_(` For GPS and GPS/PDAs
Here's a link to an open memorandum that was issued to the GPS user
community over a year ago:
<http://www.navcen.uscg.gov/gps/geninfo/50SW_GPSW_letter.pdf>
Regards,
Jon