Got my first RAIM alert while flying a GPS approach... how?
Peter R.
(Northeast US), the GPS message annunciator started blinking. Upon
answering it I discovered that the RAIM alert was going off and that the
GPS approach mode had been disabled.
Fortunately, I was just practicing the GPS approach on an excellent VFR
day so there was no need to go missed (this was not a GPS overlay
approach so switching to a ground-based nav approach would have required
getting vectored after declaring a missed approach).
The GPS is a Bendix/King KLN94 with a current IFR subscription and
antenna mounted on the top of the aircraft.
I just read the applicable AIM section about RAIM alerts, but I am still
curious about what happened. Is it likely that cloud buildup prevented
a few satellite signals from reaching the antenna? What is a common
cause of RAIM alerts?
Additionally, for those of you who fly GPS approaches, do you use the
GPS to predict RAIM at your FAF well in advance of arriving at the
approach? I never thought of using the PREDICT feature of the GPS until
this experience, but now I see the logic if the PREDICT feature is
relatively accurate.
--
Peter R.
----== Posted via Newsfeed.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeed.com The #1 Newsgroup Service in the World! >100,000 Newsgroups
---= 19 East/West-Coast Specialized Servers - Total Privacy via Encryption =---
Ron Lee
1) Satellite failure causing a ranging error. If that happened I
should hear about it next week. It is a rare event but not unheard
of.
2) Lack of satellites in proper position to be able to detect a
satellite failure (the purpose of RAIM). If you do not have
baro-aiding then it is more likely.
Check the RAIM availability tomorrow around the same time
using your PREDICT function to see if you have RAIM availability.
Do this for about 20 minutes plus or minus the time you experienced
the event.
Ron Lee
Ron Lee
http://www.avionicswest.com/pilotsupplies/raimkln94.htm
Ron Lee
PS. What time did this occur?
Ron Lee
outage.
http://www.airservices.gov.au/brief/raim_nz.htm
Ron Lee
karl gruber
receiver that King uses in it's KLN94.
Garmin hasn't used that weak receiver since their first generation GPS155
almost a decade ago.
Garmin's fix was the 12 channel parallel receiver as used in the GPS155XL,
430 530 and all their recent handhelds. Note that with enough prodding
Garmin exchanged 155's for 155XL for free because the 8 channel receiver
lost lock so regularily. Usually after a procedure turn or holding pattern.
The 12 channel receiver not only sees more satellites, but is a much better
design and locks with authority.
King has been completely left in the dust wrt GPS. All their good engineers
left to form Garmin and their recent technology advances have been through
acquisition.
The new UPSAT GNX80 has a 15 channel parallel receiver, probably with yet
better specs. Garmin has some work to do to catch up with UPSAT's new unit.
Karl
curator of N185KG
C J Campbell
"karl gruber" <skywagon1...@msn.com> wrote in message
news:b7t8sl$4a2q8$1...@ID-161519.news.dfncis.de...
|
| The new UPSAT GNX80 has a 15 channel parallel receiver, probably with yet
| better specs. Garmin has some work to do to catch up with UPSAT's new
unit.
|
I'll say! That is an awesome unit. I have been playing with the one in
Mike's office (you have got to stop in and see this). This thing is not just
an incremental improvement in GPS units, it is a whole new generation. Hook
it up the MX20 MFD with JeppView and you have capability that is unequaled
anywhere. Put two GNX80's in the airplane with an MX20 MFD and you have dual
radios, dual navigation radios, dual GPS, dual transponders, dual
glideslopes, etc. When you near the approach the actual approach plate pops
up onto the MFD automatically, while a profile terrain view runs along the
bottom of the screen and pertinent information appears in a column on the
left.
Though it seems a bit pricey at $11,000 a unit, you are replacing a lot of
other equipment with it. A dual GNX80 with MX20 MFD installation will run
you less than $40,000 installed. A comparable Garmin suite could easily run
$70,000. A comparable King suite.... (but don't make me laugh).
Peter R.
> Here is a good description of the RAIM prediction:
>
> http://www.avionicswest.com/pilotsupplies/raimkln94.htm
Good information.
> PS. What time did this occur?
Last Friday, April 18th, somewhere between 18:45 and 19:10 local
(Eastern US Daylight time).
Jon Parmet
> Ron Lee wrote:
>
> > Here is a good description of the RAIM prediction:
> >
> > http://www.avionicswest.com/pilotsupplies/raimkln94.htm
>
> Good information.
>
> > PS. What time did this occur?
>
> Last Friday, April 18th, somewhere between 18:45 and 19:10 local
> (Eastern US Daylight time).
>
>
>
> --
> Peter R.
Assumptions:
1. All times below are GMT, so if my math is correct (+4 hours once we
go on DST) we're looking for something around the 18th @ 22:45 -> 19th
@ 23:10
2. All outage DTGs expressed as YYYYMMDDhhmm
3. I have an airfield entry for "SYRACUSE HAMILTON CO MUNI" at
N37593005W101444662 .
4. PRN 22 OTS
5. Algorithm checks RAIM w/baro aiding, if either of the following
conditions exist:
- Protection Level busts the Alert Limit (.3NM for NPA)
- < 5 satellites are in view (not enough for unaided RAIM)
I ran a 48-Hour prediction beginning on the 18th at 00:00, which
produced 3 RAIM outages (NPA):
# <Start Time> <End Time>
200304180310 200304180315
200304180520 200304180535
200304190516 200304190530
This assumed a 5-degree mask angle. Changing the mask angle to 7.5
degrees produced the following output:
200304180303 200304180321
200304180511 200304180535
200304182132 200304182142
200304190300 200304190317
200304190507 200304190530
200304192128 200304192138
Assuming PRN 22 is not OTS, no outages are produced for a 5-degree
mask angle and the same set of outages are produced as immediately
shown above for a 7.5 degree mask angle. So.... that region currectly
has geometry issues (Reason #2 in Ron's post). It appears to be an
edge of coverage issue with PRN 22 playing a role.
If the location I ran it for isn't where you were flying into but you
can send me lat/lon coords, I can re-run the prediction with yours.
It's not going to make that much (maybe a few minutes if there's any
edge of coverage between the locations at that time, but certainly not
hours) of a difference in start and/or end time(s), if the two
airfields are close to each other.
However, there were/are RAIM holes up in that area. Here's a run for
today:
w/5.0 degree mask angle:
200304210507 200304210522
200304220503 200304220518
w/7.5 degree mask angle:
200304210132 200304210137
200304210255 200304210309
200304210459 200304210522
200304212120 200304212130
200304220128 200304220133
200304220252 200304220305
200304220455 200304220518
200304222116 200304222126
Don't know if that helped or not...
K, time to get back to work ;)
Regards,
Jon
Peter R.
>
> If the location I ran it for isn't where you were flying into but you
> can send me lat/lon coords, I can re-run the prediction with yours.
> It's not going to make that much (maybe a few minutes if there's any
> edge of coverage between the locations at that time, but certainly not
> hours) of a difference in start and/or end time(s), if the two
> airfields are close to each other.
Thanks for the work, Jon, but you did not have the correct airport. Sorry
for the ambiguity. Here is the correct airport:
Syracuse Hancock International Airport
FAA Identifier: KSYR
Lat/Long:
43-06-40.273N / 076-06-22.718W
43-06.67122N / 076-06.37863W
43.1111869 / -76.1063106
(estimated)
Elevation: 421 ft. / 128.3 m (surveyed)
Variation: 13W (2000)
From city: 4 miles NE of SYRACUSE, NY
If you could please rerun your calculation on this airport, I would be very
much interested in it. Secondly, how are you doing this? Do you have a
pc-based utility or is there a calculator on the web somewhere?
Ron Lee
>5. Algorithm checks RAIM w/baro aiding, if either of the following
>conditions exist:
>
>- Protection Level busts the Alert Limit (.3NM for NPA)
>- < 5 satellites are in view (not enough for unaided RAIM)
Jon, when you run it again for the reported airport, clarify if the
RAIM "outage" is due to a protection limit condition or <5 satellites.
If baro-aiding applies to this user then the outage periods should be
minimal.
Ron Lee
Jon Parmet
> Jon Parmet (j...@parmetpc.volpe.dot.gov) wrote:
>
> >
> > If the location I ran it for isn't where you were flying into but you
> > can send me lat/lon coords, I can re-run the prediction with yours.
> > It's not going to make that much (maybe a few minutes if there's any
> > edge of coverage between the locations at that time, but certainly not
> > hours) of a difference in start and/or end time(s), if the two
> > airfields are close to each other.
>
>
> Thanks for the work, Jon, but you did not have the correct airport. Sorry
> for the ambiguity. Here is the correct airport:
>
> Syracuse Hancock International Airport
> FAA Identifier: KSYR
> Lat/Long:
> 43-06-40.273N / 076-06-22.718W
> 43-06.67122N / 076-06.37863W
> 43.1111869 / -76.1063106
> (estimated)
> Elevation: 421 ft. / 128.3 m (surveyed)
> Variation: 13W (2000)
> From city: 4 miles NE of SYRACUSE, NY
Ok, I found KSYR in the DAFIF file. The lat/lon is far enough away
from the other location, that it actually could shift the outage time
(hopefully closer to the time you experienced the outage ;)
> If you could please rerun your calculation on this airport, I would be very
> much interested in it.
Been flat out at work but I'll try to run it tomorrow.
> Secondly, how are you doing this? Do you have a
> pc-based utility or is there a calculator on the web somewhere?
This is Windows-free zone ;)
Actually, we do have a PC tool that has some graphical displays, but
we use it mostly for R&D scenarios (SA On/Off, taking GPS birds OTS,
adding in GEOs for additional ranging sources, RAIM/FD only, RAIM/FDE,
WAAS, LAAS, EGNOS, Galileo, etc.).
The program I ran is the same one we developed for the Air Force (FAA)
to drive M-series NOTAMs into USNS (aeronautical advisories to FSSes).
The operationally deployed solutions are all Unix-based (AIX ,
Solaris).
There's work in progress to get this (NPA a.k.a. LNAV) and eventually
other info (LNAV/VNAV, LPV, etc.) out onto the web. In support of the
CAPSTONE project, predicted availability information will be
represented graphically and placed on a web server for pilots up in
the Alaska region to access. This should be available in a couple of
months.
It's just a first cut and will be for En-Route down to LNAV only
(145/146 receivers, RAIM/FDE) and for a predefined grid points and
airfield locations. LNAV availability is so good up there, the
displays should be fairly boring. But it'll provide a good basis for
further work such as adding other regions w/in the NAS, calculating
user-defined routes. Graphical representation of this type of
information is clearly where all needs to go. Not to the exclusion of
text-based solutions, but this stuff just lends itself to so well to
being overlayed on a map (perhaps overlayed with weather info?)...
I've got a URL at work I'll post up. The main screen is a portal to a
bunch of sites people are already quite familiar with. It doesn't have
any of the 145/146 prediction stuff integrated in yet, but it's got
some other things I think folks on here might find interesting.
Regards,
Jon
> --
> Peter R.
Jon Parmet
Lemme take a look at that, Ron. That's down in the code, but it
shouldn't be a problem sticking some print statments in a couple of
places.
Regards,
Jon
Casey Webster
news:f0701dba.03042...@posting.google.com...
> Peter R. <prgr...@twcny.rrOMITX.com> wrote in message
news:<MPG.190e07a2...@text-west.newsfeeds.com>...
> > Jon Parmet (j...@parmetpc.volpe.dot.gov) wrote:
> >
> > Secondly, how are you doing this? Do you have a
> > pc-based utility or is there a calculator on the web somewhere?
>
> This is Windows-free zone ;)
>
> Actually, we do have a PC tool that has some graphical displays, but
> we use it mostly for R&D scenarios (SA On/Off, taking GPS birds OTS,
> adding in GEOs for additional ranging sources, RAIM/FD only, RAIM/FDE,
> WAAS, LAAS, EGNOS, Galileo, etc.).
>
> The program I ran is the same one we developed for the Air Force (FAA)
> to drive M-series NOTAMs into USNS (aeronautical advisories to FSSes).
> The operationally deployed solutions are all Unix-based (AIX ,
> Solaris).
>
is the software private stuff, or available for public consumption? among
other things, i've got an rs/6000 sitting around the apartment and the
software sounds pretty interesting.
TThierry
> If baro-aiding applies to this user then the outage periods should be
> minimal.
Sorry, but what is baro-aiding?
--
TThierry
Pour me repondre par email : remplacez l'_antisp@m_ par @.
To mail me back, replace my _antisp@m_ by @.
ICQ 113505533
Dave Butler
>
> Ron Lee <ronlee...@pcisys.net> wrote:
>
> > If baro-aiding applies to this user then the outage periods should be
> > minimal.
>
> Sorry, but what is baro-aiding?
Barometric pressure altitude is included in the navigation
solution.
The position is over-determined (more equations than
unknowns) but imprecise (there is error in the time
measurements). The additional equations are used to average
out the errors. Baro-aiding adds one more equation.
Usually the output of the altitude encoder is fed to the
GPS, which includes the altitude information in the
solution.
Jon Parmet
>
> is the software private stuff, or available for public consumption? among
> other things, i've got an rs/6000 sitting around the apartment and the
> software sounds pretty interesting.
I'll ask around and get back to you on this.
Regards,
Jon
Jon Parmet
> Peter R. <prgr...@twcny.rrOMITX.com> wrote in message news:<MPG.190e07a2...@text-west.newsfeeds.com>...
> > Jon Parmet (j...@parmetpc.volpe.dot.gov) wrote:
> >
> > Syracuse Hancock International Airport
> > FAA Identifier: KSYR
> > Lat/Long:
> > 43-06-40.273N / 076-06-22.718W
> > 43-06.67122N / 076-06.37863W
> > 43.1111869 / -76.1063106
> > (estimated)
> > Elevation: 421 ft. / 128.3 m (surveyed)
> > Variation: 13W (2000)
> > From city: 4 miles NE of SYRACUSE, NY
>
> Ok, I found KSYR in the DAFIF file. The lat/lon is far enough away
> from the other location, that it actually could shift the outage time
> (hopefully closer to the time you experienced the outage ;)
KSYR => N43064027W076062272W012500421
The outage shifted by about 20 minutes... in the other direction
(later).
200304180325 200304180336
This was for 7.5 degree mask angle. 5.0 produced no outage.
I didn't have a lot of time to investigate things, so it's not clear
to me whether what you experienced was/is even predictable or not.
Some print statements showed that it did not enter into that routine
during the outage time (either yours or the one predicted here). There
were, however, several instances where Baro was being called at other
timesteps during the day.
It would seem that the way the constellation is current optimized,
your neck of the woods is one of those places where you can experience
< 5 in view for periods of time or poor enough geometry.
> I've got a URL at work I'll post up. The main screen is a portal to a
> bunch of sites people are already quite familiar with. It doesn't have
> any of the 145/146 prediction stuff integrated in yet, but it's got
> some other things I think folks on here might find interesting.
Ok, here's the linkage:
1. https://register.naimes.nas.faa.gov
Once you're reigstered, the portal can be found at:
2. https://cdm.naimes.atcscc.faa.gov
I'd be interested to know what people think of NAIMES. It's still
being stood up, so screens may change. A flight planning tool is in
the works, but I can't remember the date for it to go live...
Regards,
Jon
Casey Webster
"Jon Parmet" <j...@parmetpc.volpe.dot.gov> wrote in message
news:f0701dba.03042...@posting.google.com...
thanks, i'll be watching here or you can take the -nospam- out of me email
and contact me that way.
TThierry
> Barometric pressure altitude is included in the navigation
> solution.
>
> The position is over-determined (more equations than
> unknowns) but imprecise (there is error in the time
> measurements). The additional equations are used to average
> out the errors. Baro-aiding adds one more equation.
>
> Usually the output of the altitude encoder is fed to the
> GPS, which includes the altitude information in the
> solution.
Thank you.
--
TThierry
http://flyinfrance.free.fr
Peter R.
<snip>
> It would seem that the way the constellation is current optimized,
> your neck of the woods is one of those places where you can experience
> < 5 in view for periods of time or poor enough geometry.
Jon, thank you for taking time out of your busy schedule to investigate
this for me. Very interesting results.
I have registered with the web site you provided and will take some time
to poke around and "play" with the various tools.
--
Peter
Jon Parmet
> Jon Parmet wrote:
>
> <snip>
> > It would seem that the way the constellation is current optimized,
> > your neck of the woods is one of those places where you can experience
> > < 5 in view for periods of time or poor enough geometry.
>
> Jon, thank you for taking time out of your busy schedule to investigate
> this for me. Very interesting results.
No problem, Pete. I'm not sure why you got the RAIM alert at that
time. It could have been due to something else, such as not having the
same set of satellites in view (blocked, interfered with, antenna
issues, receiver problems) although one wouldn't expect a certified
box/install to be behaving like this.
What I can do is to look at which satellites are in view and try
taking different ones out of the Visible Set, to see if I can generate
an outage at/around that time. If I am able to reproduce the alert by
this method, it then brings into question why your receiver either
isn't 'seeing' a supposedly healthy bird, or if something else is
going on with respect to how it's factoring in that bird (deweighting,
for example) in the protection level calculation part of the RAIM. I'd
be interested to know if you get any more alerts, predicted and/or
actual.
> I have registered with the web site you provided and will take some time
> to poke around and "play" with the various tools.
>
> --
> Peter
You'll find some GPS related pages in there (interference reporting,
for example). The OIS link contains a subset of what is displayed on a
big screen at the Command Center down in Herndon. Has some nice stuff
like Ground Stops, significant events like accidents. One of the
things the NAIMES program is planning to stand up is AISR which will
contain a flight planning tool that'll tie into all the various NAS
data sources.
Regards,
Jon
TThierry
> This assumed a 5-degree mask angle. Changing the mask angle to 7.5
> degrees produced the following output:
>
> 200304180303 200304180321
> 200304180511 200304180535
> 200304182132 200304182142
>
> 200304190300 200304190317
> 200304190507 200304190530
> 200304192128 200304192138
>
>
> Assuming PRN 22 is not OTS, no outages are produced for a 5-degree
> mask angle and the same set of outages are produced as immediately
> shown above for a 7.5 degree mask angle. So.... that region currectly
> has geometry issues (Reason #2 in Ron's post). It appears to be an
> edge of coverage issue with PRN 22 playing a role.
Could you explain what you call a 5 degree mask angle and PRN22?
--
TThierry
To mail me back, replace my _antisp@m_ by @.
Ron Lee
satellites above five degree elevation (angular distance above your
local horizon).
PRN 22 (satellite designation) may have been unavailable thus not
contributing to RAIM availability.
Ron Lee
Jon Parmet
> Jon Parmet <j...@parmetpc.volpe.dot.gov> wrote:
>
> > This assumed a 5-degree mask angle. Changing the mask angle to 7.5
> > degrees produced the following output:
> >
> > 200304180303 200304180321
> > 200304180511 200304180535
> > 200304182132 200304182142
> >
> > 200304190300 200304190317
> > 200304190507 200304190530
> > 200304192128 200304192138
> >
> >
> > Assuming PRN 22 is not OTS, no outages are produced for a 5-degree
> > mask angle and the same set of outages are produced as immediately
> > shown above for a 7.5 degree mask angle. So.... that region currectly
> > has geometry issues (Reason #2 in Ron's post). It appears to be an
> > edge of coverage issue with PRN 22 playing a role.
>
> Could you explain what you call a 5 degree mask angle and PRN22?
The mask angle is an elevation angle (horizon being 0 degrees) below
which the satellite will not be considered 'visible' (and thus not
used in the navigation solution) even though the receiver can track
it. Older receivers used 7.5 which is why I ran it for both 7.5 and 5
degrees. As you start going to elevation angles lower than 5,
multipath becomes an issue.
Unique PRN numbers are assigned (as are SV numbers) to each satellite
at commissioning time. Both PRN and SV numbers will appear in a NANU
when a satellite is taken out of service (scheduled or unscheduled
outage). Only the PRN number is indicated in the corresponding NOTAM,
though. I beleive most receivers that support "de-selecting" a bird
for the purposes of doing the prediction, expect the PRN number to be
referenced.
Sometimes a bird isn't actually taken OTS (Schriever sets it
unhealthy) at the exact time specified in the NANU/NOTAM. Sometimes
the NANU/NOTAM is cancelled prior to its start time (perhaps they've
rescheduled a maintenance operation) or prior to its end time
(unscheduled outage had an end time of UFN and the problem was fixed
or perhaps a maintenance operation was completed ahead of the
scheduled end time).
The important thing is to (if the receiver doesn't already do this
automatically) "re-select" it after your done with the prediction, so
it can be used in flight should it actually be healthy at the time. In
real-time, the receiver will use the 'health bit' being broadcast by
the bird to determine if it's actually gone OTS.
HTH.
Regards,
Jon
TThierry
> Unique PRN numbers are assigned (as are SV numbers) to each satellite
> at commissioning time.
So PRN 22 was the name of one of the satellite which should have been
"visible" when the alert occured?
Thank you anyhow to all contributors for this VERY interesting thread
and the information provided. I wish all pilots who rely solely on their
GPS for their navigation even if they have no RAIM function could read
it.
--
TThierry
http://flyinfrance.free.fr
To mail me back, replace my _antisp@m_ by @.
ICQ 113505533
Jon Parmet
> Jon Parmet <j...@parmetpc.volpe.dot.gov> wrote:
>
> > Unique PRN numbers are assigned (as are SV numbers) to each satellite
> > at commissioning time.
>
> So PRN 22 was the name of one of the satellite which should have been
> "visible" when the alert occured?
PRN 22 was OTS at the time (Check Ron's post). What I did was to
fabricate an example, making PRN 22 available just to see if it made a
difference or not to the outage. It was a Q&D test that looked at the
end result (outage times).
I'll run it later this week, printing out exactly which satellites are
visibile (healthy or not) at each timestep. This will go somewhat
further down in the weeds, so to speak, to see when PRN 22 was
visible.
There seem to be some edge of coverage things happening given the
outage at:
200304180310 200304180315
5 minutes is the minimum outage time established by the FAA for
whether a NOTAM is issued or not. Notice how on the next day (19th)
there was no outage predicted around that time. What I suspect is
happening is one or more satellites are rising/setting above/below the
mask angle.
What will be interesting, however, is what was happening at the time
Peter experienced the alert. He mentioned that it occured sometime
between 18:45-19:10. One thing I forgot to ask about was if the
alert was flagged for the entire 25 minutes or not. If the alert
lasted < 5 minutes, then that's the answer right there.
The prediction tool I use goes down to 1 minute resolution internally,
so that's as low in the weeds as I can go right now as far as outage
times are concerned. I don't know if the receiver's prediction
function has a granularity finer than 1 minute, so it wouldn't predict
a really short duration outage that it would catch in real-time.
Some of the rationale behind this is most likely a practicality issue.
Since a pilot can easily slide his/her approach time one way or the
other, flying ahead/behind predicted short duration outages. If one is
flagged during the approach and you only have a 129 box, FD (Fault
Detection) doesn't know which satellite caused the RAIM alert, so you
have to do a go around. If you've got a 145/146 box, FDE (Fault
Detection and Exclusion) is desgined to remove the bad satellite from
the nav solution on the fly (so to speak ;) so you can maintain
continuity during the approach and get to those restrooms and vending
machines at the FBO quicker ;)
I'll print out the protection level as well as the per-satellite
elevation angle for each timestep. This should give us a little more
insight into what's happening through time.
Regards,
Jon
Peter R.
> One thing I forgot to ask about was if the
> alert was flagged for the entire 25 minutes or not. If the alert
> lasted < 5 minutes, then that's the answer right there.
From the time I received the alert until the time I landed was about 5
minutes (since it was a clear VFR day and I had a complete visual on the
runway when I looked out, I opted to continue with the approach), so I
cannot say how long the alert would have lasted in its entirety.
I did try twice during the approach to go to the RAIM prediction page of
the GPS to see if doing so would reset the alert, but it did not.
--
Peter
TThierry
> PRN 22 was OTS at the time (Check Ron's post)
I saw that, but don't know what it means: out of service?
--
TThierry, PPL
Jon Parmet
> Jon Parmet <j...@parmetpc.volpe.dot.gov> wrote:
>
> > PRN 22 was OTS at the time (Check Ron's post)
>
> I saw that, but don't know what it means: out of service?
Temporarily unavailable for comment ;), as opposed to de-commissioned
which is when they are permanently taken out of service (orbits are
boosted at end-of-life).
The satellites are generally taken out of service:
- for scheduled maintenance (bounded start/end times)
- when a problem (anomaly) is detected (usually UFN. start time may be
WIE)
The health bit is set to a value which the receiver decodes along with
other information broadcast on the signal. It uses the value of the
bit (byte actually) to determine whether or not that satellite can be
used for ranging. So the satellite will still be transmitting
(hopefully ;), it just can't be used (trusted) for navigation/timing
services until the health status comes good again.
TThierry
> Temporarily unavailable for comment ;), as opposed to de-commissioned
> which is when they are permanently taken out of service (orbits are
> boosted at end-of-life).
>
> The satellites are generally taken out of service:
>
> - for scheduled maintenance (bounded start/end times)
> - when a problem (anomaly) is detected (usually UFN. start time may be
> WIE)
>
> The health bit is set to a value which the receiver decodes along with
> other information broadcast on the signal. It uses the value of the
> bit (byte actually) to determine whether or not that satellite can be
> used for ranging. So the satellite will still be transmitting
> (hopefully ;), it just can't be used (trusted) for navigation/timing
> services until the health status comes good again.
Thanks. When you add a langage problem to a technical one, understanding
is not so easy. Was not, should I say, thanks to your explanations.
Jon Parmet
> Jon Parmet <j...@parmetpc.volpe.dot.gov> wrote:
>
> > Temporarily unavailable for comment ;), as opposed to de-commissioned
> > which is when they are permanently taken out of service (orbits are
> > boosted at end-of-life).
> >
> > The satellites are generally taken out of service:
> >
> > - for scheduled maintenance (bounded start/end times)
> > - when a problem (anomaly) is detected (usually UFN. start time may be
> > WIE)
> >
> > The health bit is set to a value which the receiver decodes along with
> > other information broadcast on the signal. It uses the value of the
> > bit (byte actually) to determine whether or not that satellite can be
> > used for ranging. So the satellite will still be transmitting
> > (hopefully ;), it just can't be used (trusted) for navigation/timing
> > services until the health status comes good again.
>
> Thanks.
Beaucoup :)
> When you add a langage problem to a technical one, understanding
> is not so easy. Was not, should I say, thanks to your explanations.
Not a problem. You should have seen me in the back woods of Augsburg
try to ask the whereabouts of food ;)
Peter Duniho
> Not a problem. You should have seen me in the back woods of Augsburg
> try to ask the whereabouts of food ;)
No need. We've seen you right here trying to say "you're welcome". :)
Peter R.
LOL! I caught that, too.
--
Peter R.
Only had three years of French in High School.
TThierry
> Not a problem. You should have seen me in the back woods of Augsburg
> try to ask the whereabouts of food ;)
Must have managed this better than you pretend, since you didn't starve
to death. :o)