What's new
Van's Air Force

Don't miss anything! Register now for full access to the definitive RV support community.

Possible AD for certain NAVWORX ADS-B Units

I've also seen, on another board, posts by someone (probably the same guy) who says his wife worked in some unspecified capacity for Navworx at some unspecified point in past, and who may or more likely may not have the slightest clue what's going on. So far those posts have not included anything that would indicate either he or his ex-employee wife have any information that the rest of us don't have, which is to say... they're essentially clueless too.

Ain't the Internet grand? I guess we all watch and wait to see what happens next. I hope they work it out.
 
Does anyone see the hypocrisy here?

FAA and Dynon are putting non-TSO D10a in Part 23 aircraft and the world hasn't ended. Navworx puts a non TSO GPS in an EXPERIMENTAL airplane and the FAA acts like we will see 747s crashing into GA aircraft daily.

I certainly can't see any consistency here, but that is probably an unrealistic expectation from me.

Kudos to Dynon for their efforts by the way. Hopefully they don't get steamrolled in a similar way at some point.
 
Hypocrisy.... yep, a perfect synonym for POLITICS!

I wonder how the FAA would respond if the general public were somehow made aware, (and understood), the magnitude of reduction in safety actions like this cause.
 
Last edited:
Does anyone see the hypocrisy here?

FAA and Dynon are putting non-TSO D10a in Part 23 aircraft and the world hasn't ended. Navworx puts a non TSO GPS in an EXPERIMENTAL airplane and the FAA acts like we will see 747s crashing into GA aircraft daily.

I certainly can't see any consistency here, but that is probably an unrealistic expectation from me.

Kudos to Dynon for their efforts by the way. Hopefully they don't get steamrolled in a similar way at some point.

Not quite the same.
1. Ultimately, the FAA wants to get rid of radar and use ADSB-out to keep the airliners safe. Airline safety is way more important to the FAA, than having a small plane crash due to loss of attitude info.
2. Perhaps more important, Dynon has worked hand-in-hand with the FAA (and EAA) to make this happen. Not saying this happened with NavWorx, but an open spirt of cooperation seems to work better with the FAA than an advisarial relationship.
 
Anyone have any idea of the accuracy/inaccuracy of the TSO'd GPS chip vs. the non-TSO'd GPS chips. Are we talking a few inches, a few feet, a hundred feet or a mile. My iPhone shows my position sitting in the kitchen within 10 feet as shown on the Google map.

Will the FAA come clean and discuss this issue, which appears to be the main issue in a response?
 
The issue is not so much the accuracy when everything is working, but rather the ability to detect that the satellites being used to calculate the position are all working properly and thus the calculated position is accurate. This is the System Integrity Level (SIL) that is causing heartburn for Navworx. There are a lot of technical details involved, beyond just how accurately located a plane is when everything is going right.

I've seen my position jump a few times using my iPad. Usually it is something momentary, or sometimes they are conducting GPS tests. The cheaper receivers don't examine or report any problems with the data being received.
 
Does anyone see the hypocrisy here?

FAA and Dynon are putting non-TSO D10a in Part 23 aircraft and the world hasn't ended. Navworx puts a non TSO GPS in an EXPERIMENTAL airplane and the FAA acts like we will see 747s crashing into GA aircraft daily.

Big difference. The FAA is not using the D10A's output to separate traffic. I frankly don't have a problem with the FAA being conservative on this. The output of these units will, some day, be the sole method of aircraft separation. I don't want a midair because some guy decided to use a cheap part. I could care less if he falls out the sky for the same reason. While I don't believe in regulating victimeless crimes, that does not apply to ADS-b equipment.

Larry
 
2. Perhaps more important, Dynon has worked hand-in-hand with the FAA (and EAA) to make this happen. Not saying this happened with NavWorx, but an open spirt of cooperation seems to work better with the FAA than an advisarial relationship.

From my observations, Bob is right on here. The Navworx fiasco is squarely upon their shoulders, not the FAA's. The Dynon cases are examples that the FAA is being at least moderately cooperative in working with vendors to allow flexibility.

Larry
 
Navworx may have had a valid argument, or at least part of a valid argument, but they poked the bear. You don't ever poke the bear. Nothing good comes from poking the bear.
 
Anyone have any idea of the accuracy/inaccuracy of the TSO'd GPS chip vs. the non-TSO'd GPS chips. Are we talking a few inches, a few feet, a hundred feet or a mile. My iPhone shows my position sitting in the kitchen within 10 feet as shown on the Google map.

Will the FAA come clean and discuss this issue, which appears to be the main issue in a response?

The FAA requires that there is engineering data to support just about everything. The TSO process is a method to provide them specifications and specific data about the device.

I have a non-TSO'd, non-certified GPS in my aircraft that is more accurate and faster response time than my certified GPS which has a TSO. With that said, even though it may be a better GPS, I can't use it for IFR operations. The FARs state that a TSO C146c GPS device is needed for all phases of an IFR flight (terminal, enroute, and approach) if it is the sole navigation device.

The issue with a non TSO certified products is that they are unknown to the FAA. So it's more of an unknown accuracy versus it's less accurate situation.
 
Mess

I think this whole thing is a huge mess that spiraled out of control.

The FAA claims that the Navworx units need to broadcast a SIL = 0 but AC 20-165 section 3.3.3.3 states that installations that derive their SIL from GNSS position sources compliant with any revision of TSO-C145 should set SIL = 3.

https://www.faa.gov/documentLibrary/media/Advisory_Circular/AC_20-165B.pdf

According to Navworx's compliance matrix, all the units in question use a NexNav-mini from Aspen as the internal WAAS GPS source.

http://www.navworx.com/documents/ADS600BGPSMatrixRedacted-Copy.pdf

The NexNav-mini is certified to TSO-C145c Class Beta 1.

http://aspennexnav.com/wp-content/uploads/2016/04/NexNav-mini-Product-Sheet.pdf

So unless Navworx is not really using this internal GPS, I don't know why the FAA would require them to broadcast a SIL=0.

It really sounds like this whole thing got personal and spun out of control. I really hope Navworx and the FAA office can both act professionally and work together to come to a reasonable conclusion.
 
Sorry about that....didn't know if they allowed guests access.
Here is a couple of comments. It appears to all boil down to a certification issue, which I understand is very expensive.
...
All I can say is that NavWorx had a number of consultants involved in the certification effort. But for the most part, they studied the FAA guidance and proceeded as instructed by that guidance. As best I can tell, the problems started when the "normal thing" at the FAA office was above and beyond what was in the guidance. The alternative (which is a theory I do not like, but must acknowledge as a possibility) is that a competitor influenced the FAA, and once that ball was rolling, it couldn't stop.


Another:

The conversations often went something like this...

NavWorx provides data that is at-least compliant with the regulation.

FAA: This is not what we expect.
NavWorx: Okay, what would you like?
FAA: It is not our place to tell industry how to comply with regulations.

It would not surprise me in the slightest if this was going on. From my involvement on the engineering side of aviation, it's astounding to me how much otherwise-acceptable stuff (drawings, reports, parts, etc.) gets hung up because of minor paperwork issues and/or "this doesn't fit the usual mold of how we do things". I once had three FAA reps arguing for weeks about whether we could release two versions of a bushing on the same drawing, because one was a standard repair bushing and the other was a new production bushing--but the FAA approval form only allows you to pick one category.

This is why certifying engines/airplanes/avionics/parts is expensive, and why the recently-released Part 23 overhaul isn't going to really do anything for GA costs. The issue isn't designing or building something that complies with the applicable regulations. Rather, it's showing the FAA that you comply with them in the way the FAA wants to be shown.

And that doesn't even get into producing the items in the FAA Way :rolleyes:

That's not to say that I imagine NavWorx is blameless in the situation. I know that in a small town (like the aviation community) you don't mouth-off to the cops, even if you're right. That isn't going to play well for you in the short term or the long. I can easily imagine certain people at NavWorx electing to say certain things to their FAA representatives that I might have chosen not to say.
That certainly doesn't help.
 
Called the Feds

I don't know if anyone noticed the contact info for the FAA in Fortworth listed at the bottom of Navworx letter. I decided to shoot them an email. 5 min. Later they replied and invited me to call and discuss the situation with Navworx. I did. Call lasted almost an hour. According to the FAA, they want this resolved without removing all the boxes. I told him that I had 3 boxes in my shop that I was afraid were heading for the dumpster. He told me not to get rid of anything because he believed there would be some solution. Also , to be clear, this has nothing to do with accuracy. As someone mentioned earlier, it is about detecting bad satellite data. I brought up the rumor that Dynon was using the same gps. He said that he did not know because Navworx has never let them look inside their box. They asked if I would let them look at one of mine. All I know right now is that the Feds wanted to talk and Navworx won't. Fishy.
 
Good on you, Zlinman. I like your pro-active get to the bottom of things approach with an open mind towards either side's story. I find your conversation with the FAA refreshing after 3 months of gloom and doom.

I hope this does get sorted out well. I like NavWorx and have one new in the box ready to go for my personal RV. Meanwhile I have purchased two FreeFlight RANGRs for two other installs (Husky and Cessna 140) after I waived off the originally intended TSO'd Navworx boxes.

Jim
 
.... Also , to be clear, this has nothing to do with accuracy. As someone mentioned earlier, it is about detecting bad satellite data....

Does anyone know what happens if the unit does not properly detect / handle bad data? Would it calculate a bad position and send it out to other users, or would it simply not send anything? Or choke / need some sort of reset/reboot? Apparently it's a serious concern, but it would be interesting to know the potential consequences of the deficiency.
 
Good on you, Zlinman. I like your pro-active get to the bottom of things approach with an open mind towards either side's story. I find your conversation with the FAA refreshing after 3 months of gloom and doom.

I hope this does get sorted out well. I like NavWorx and have one new in the box ready to go for my personal RV. Meanwhile I have purchased two FreeFlight RANGRs for two other installs (Husky and Cessna 140) after I waived off the originally intended TSO'd Navworx boxes.

Jim

I had same experience talking with Michael at FAA, am cautiously hopeful this matter will be resolved.
 
Just an observation on my part - -

Since I fly very often, and have had the EXP along with the IFly app on a 10" IPad pro, I will say I have to assume the info sent Wi-Fi to the Ipad is the same as sent out on the 'out' portion. On my IPad, the depiction always seems to be very stable and accurate. When I cross over a highway or such, it shows me exactly at that position. Could it be off 100', maybe, but the value I place on the info is very high. I believe some of the recent accidents near an airport could have been prevented if they had this unit or similar. I always know where to look for traffic, and if it is close ( say under a mile ), I can usually find it. I know I way more often would not have seen it without this device. I feel it is another valuable aid toward safety. I do not want to go without it now.
 
Zlinman,
The FAA put out this AD without having one in possession and looking inside?????
Now they want to borrow one from you. GOOD GRIEF!! We are in more trouble
than I thought.
 
Last edited:
Does anyone know what happens if the unit does not properly detect / handle bad data? Would it calculate a bad position and send it out to other users, or would it simply not send anything? Or choke / need some sort of reset/reboot? Apparently it's a serious concern, but it would be interesting to know the potential consequences of the deficiency.


My understanding is that there are 3 states your GPS can be in:

1. The GPS is producing data within the accuracy specs.
2. The GPS is producing data outside the accuracy specs and it knows it. So it will report poor accuracy when it reports it's location.
3. The GPS is producing data outside the accuracy specs and it has no idea that it is doing that.

Now 2. is not really the biggest worry. In that state controllers can just give you larger separation. If it doesn't happen to often that really shouldn't impact safety.

3. is what is really worrisome. Everybody things they know where they are but they don't. Now by definition there is no realtime measurement you can do within the GPS to figure that out. If you could you would just use that measurement to downgrade the data quality and you are back to case 2. So the probability of 3. is established by analysis of the design etc... That analysis is complex and expensive and has little to do with the cost of producing the hardware of the GPS... . That's why you can easily get a more accurate GPS for cheaper if you don't need the analysis for 3.

Oliver
 
Since the Aspen Nex Nav Mini is the GPS that all of the 600 series Navworx units ( Including the EXP) have and since the the FAA originally certified them for TSO according to Navworx. They actually have a file on the site that indicates the acceptable RCXX level testing for the SIL . This and the other measurable parameters as for horiz and vertical distances NACp, NACv, NIC, are all being reported back as within the TSO limits. I don't think accuracy is the problem. Not sure about what happens if position source goes "bad" and I guess that can happen to any GPS.

I think the problem is that the FAA wants ALL TSOd units to report a SIL of 3 if it is TSO d and report a 0 if it is not. Here's where the "Meeting Performance Standards" gets pushed to the rear. It may meet performance of the TSO but if not certified it is not recognized as an official law abiding position reporting source. Therefore being mandated to report SIL as 0 you don't get TSI B as per the FAA guidelines of Jan 2016 .

There seems to be a lot of unsupported information out there, and a lot that only Navworx can support, as well as the above two paragraphs! It will be interesting to see how the EXP units come out of this and if they are targeting the Meeting performance rule in all this.
 
I think the problem is that the FAA wants ALL TSOd units to report a SIL of 3 if it is TSO d and report a 0 if it is not. Here's where the "Meeting Performance Standards" gets pushed to the rear. It may meet performance of the TSO but if not certified it is not recognized as an official law abiding position reporting source. Therefore being mandated to report SIL as 0 you don't get TSI B as per the FAA guidelines of Jan 2016 .

If this is the case, then my Garmin GPS20A should also subject to a similar action by the FAA, since it is not TSO'd, yet the supporting hardware/software is configured for the equivalent of SIL=3. Therefore, I respectfully disagree with your theory.
 
Is that GPS 20A used only with 1090 ES Xponder or can it also support UAT equipment? Seems that the UAT equipment does not have all the capacity to transmit the same data string that the ES equipment does which may be part of the issue. Not sure.

Following copied from somewhere:

extended squitter technology allows your aircraft to automatically transmit more accurate and useful traffic surveillance data ? including aircraft flight ID, position, altitude, velocity, climb/descent and heading information ? to those tracking and controlling aircraft movements in ATC airspace. The extended squitter format can accommodate significantly more data elements than the basic Mode S transponder signal, so ADS-B system users are able to track each airplane?s flight path with much greater precision, accuracy and situational awareness.
 
Is that GPS 20A used only with 1090 ES Xponder or can it also support UAT equipment? Seems that the UAT equipment does not have all the capacity to transmit the same data string that the ES equipment does which may be part of the issue. Not sure.

Following copied from somewhere:

extended squitter technology allows your aircraft to automatically transmit more accurate and useful traffic surveillance data — including aircraft flight ID, position, altitude, velocity, climb/descent and heading information — to those tracking and controlling aircraft movements in ATC airspace. The extended squitter format can accommodate significantly more data elements than the basic Mode S transponder signal, so ADS-B system users are able to track each airplane’s flight path with much greater precision, accuracy and situational awareness.

That would be a question for Garmin. It is designed to be used as a position source for their ES transponders when installed in an experimental aircraft (and I've read about others using it for non-Garmin transponders.) I *think* it outputs ADSB+ protocol on one serial line, and NMEA on the other, so theoretically it could be used by an UAT that accepts those flavors over rs232 for external position data .
 
Last edited:
Since the Aspen Nex Nav Mini is the GPS that all of the 600 series Navworx units ( Including the EXP) have and since the the FAA originally certified them for TSO according to Navworx.

Do you have any evidence that the NexNav Mini is inside the EXP? The NexNav mini is about $2,500 and the EXP was $700 originally.

I think the problem is that the FAA wants ALL TSOd units to report a SIL of 3 if it is TSO d and report a 0 if it is not.

The AD in discussion here says that the issue is that the 600 units were originally TSO'd with a SIL=0 and then a software change moved that to SIL=3. So the FAA accepted a TSO with a SIL=0 and is now saying a SIL=3 is inappropriate. They don't seem to have an issue with a TSO'd unit with a SIL=0. If the only performance allowed by the TSO was SIL=3, we wouldn't transmit SIL because we could assume all units were 3. The whole reason SIL exists is because it is acceptable to manufacture units under TSO that have various levels of integrity. There's actually a TSO (C199) that defines a GPS which is SIL=1.
 
Do you have any evidence that the NexNav Mini is inside the EXP? The NexNav mini is about $2,500 and the EXP was $700 originally.

......

Could this be a "what to call it" issue?

Is it an actual NexNav Mini system inside it, or simply the same GPS chip being used?

GPS chips are cheap - see your cell phone :) - but a tested, certified system component would not be.
 
Zlinman,
The FAA put out this AD without having one in possession and looking inside?????
Now they want to borrow one from you. GOOD GRIEF!! We are in more trouble
than I thought.

Another way to look at this is: how do they possibly bless it when they don't even know what is inside it.
 
To paraphrase something from a fairly large bill enacted by congress in the middle of the night a few years ago:

"You have to certify the unit before we can look inside. Then we will tell you what you have to do (and spend) to fix it."
 
I'm not a huge fan of the FAA, but let's be fair. Apparently NavWorx made an internal change to their box, and when the FAA went to the factory to look at it, they were not allowed in. This is just asking for trouble.

While I'm writing, let me again register a complaint: the NavWorx installations that use the Transmon device to sniff out squawk code and pressure altitude from the transponder are clearly not in compliance with the FARs. I think both the FAA and NavWorx got so involved with little details that they 'didn't see the forest for the trees'.
 
What FAR?? Would like to read it.

It's actually very simple. Although you only need ADSB-out in certain airspace, FAR 91.225 says that if it's installed, you must operate it all the time. And FAR 91.227 says when it's operating, it has to send out pressure altitude. But the transponder needs to have your mode C transponder 'pinged' by ATC in order for the Transmon to pick up PA. There's lots of airspace where that doesn't happen. In particular, my home airport (LVK) is inside the SFO mode C veil, so ADSB-out will be required from the ground up. But there's no radar service below about 1000' agl (LVK is in a valley), so Transmon devices will have no PA info until reaching that height.
 
Do you have any evidence that the NexNav Mini is inside the EXP? The NexNav mini is about $2,500 and the EXP was $700 originally.



The AD in discussion here says that the issue is that the 600 units were originally TSO'd with a SIL=0 and then a software change moved that to SIL=3. So the FAA accepted a TSO with a SIL=0 and is now saying a SIL=3 is inappropriate. They don't seem to have an issue with a TSO'd unit with a SIL=0. If the only performance allowed by the TSO was SIL=3, we wouldn't transmit SIL because we could assume all units were 3. The whole reason SIL exists is because it is acceptable to manufacture units under TSO that have various levels of integrity. There's actually a TSO (C199) that defines a GPS which is SIL=1.

Jordan, not sure whats inside my EXP unit other than what I've read from Navworx. And that could be some of the problem, maybe not so much with the EXP model but the other two certified 600 models. Not really interested in taking the cover off right now because it works to well!! I'll let it play out for now.

If those two certified models were TSO d as SIL 0 that may be some of the problem. Not sure why you would want to do that especially if it meets the higher levels. I know what my EXP model is SIL and SDA programed for since it is printed on the FAA report back. And can see that the unit reports back as 100% compliant position. Interesting that The AC No. 20-165B is not the rule but expected to be followed to the letter says that a noncertified position source must report both values as 0.
 
It's actually very simple. Although you only need ADSB-out in certain airspace, FAR 91.225 says that if it's installed, you must operate it all the time. And FAR 91.227 says when it's operating, it has to send out pressure altitude. But the transponder needs to have your mode C transponder 'pinged' by ATC in order for the Transmon to pick up PA. There's lots of airspace where that doesn't happen. In particular, my home airport (LVK) is inside the SFO mode C veil, so ADSB-out will be required from the ground up. But there's no radar service below about 1000' agl (LVK is in a valley), so Transmon devices will have no PA info until reaching that height.

I was under the impression that the initiation of an ADS-B out transmission packet required a ping from ATC. As opposed to an asynchronous mode where the ADS-B out transmission is made at an interval. Yes/No??
 
Last edited:
I was under the impression that the initiation of an ADS-B out transmission packet required a ping from ATC. As opposed to an asynchronous mode where the ADS-B out transmission is made at an interval. Yes/No??

Absolutely not. My TT-22 sends out messages on the ground at LVK, as it is required to do. But there are no radar pings, my old mode C transponder never transmitted until about 1200' agl, when it could 'see' radar. If it was otherwise ADSB would be useless for collision avoidance in non radar areas.
 
Absolutely not. My TT-22 sends out messages on the ground at LVK, as it is required to do. But there are no radar pings, my old mode C transponder never transmitted until about 1200' agl, when it could 'see' radar. If it was otherwise ADSB would be useless for collision avoidance in non radar areas.

So Bob does the UAT equipment work the same as you describe above , or is it dependent on a ATC sweep from the radar? I would think those UATs connected to the xponder via rs232 would have altitude and code embedded anytime it was powered. I know all info that is returned to me is usually 800 ft AGL or higher for me. That I'm sure is ground station signal. I never thought about those aspects of ADSB signal but I'm sure someone has.
 
The NavWorx UAT transmitter sends a position packet once per second. I got this directly from Bill at NavWorx. No, I don't know anything else about the current status of the AD.
 
So Bob does the UAT equipment work the same as you describe above , or is it dependent on a ATC sweep from the radar? I would think those UATs connected to the xponder via rs232 would have altitude and code embedded anytime it was powered. I know all info that is returned to me is usually 800 ft AGL or higher for me. That I'm sure is ground station signal. I never thought about those aspects of ADSB signal but I'm sure someone has.

Yes, UATs transmit without radar pings. They have to. Remember 2020 is just the first phase for the FAA. Ultimately they want to get rid of radar, which is expensive for them. Replacing radar with ADSB would not work, if ADSB itself needed a radar ping to transmit.
Yes, an RS232 connection directly sees the squawk code and pressure altitude coming into the transponder, regardless of whether or not the transponder is transmitting. There's no issue there, as far as I can see.
What I do not know is what a transmon equipped NavWorx does if it stops getting PA data, e.g., as a plane descends into LVK. If it simply kept transmitting the last known data, that's a recipe for disaster. Hopefully it times out and transmits no PA data. While not in compliance with 91.227, that's better than sending false data.
 
Last edited:
My EXP UAT gets altitude encoder data directly from the altimeter via serial connection. As far as I can tell, only the quawk code comes from my GTX327. I would think the transmon equipped UAT's should be wired the same way and no issue would exist for altitude data. Squawk code is a different issue..... The point about phasing out radar coverage in the future also begs the question about how a transmon dependent UAT will work in the future. Bottom line is that it wont be able to. What happens to transponders on that day? Without radar, there will be nothing to interrogate them.... How will we set a squawk code, and even further, why would we need to?
 
Last edited:
When the Radar sites are decommissioned, what safeguards are built into the system to prevent someone from transmitting a signal on 978 MHZ with the proper protocol and fake Lat / Lon / altitude?
 
When the Radar sites are decommissioned, what safeguards are built into the system to prevent someone from transmitting a signal on 978 MHZ with the proper protocol and fake Lat / Lon / altitude?

Nothing. There's nothing to prevent that now. It would just confuse things. That's one of the vulnerabilities of ADSB - no effort was made to prevent spoofing.

As for Radar, 9/11 pretty much put to bed the idea of completely eliminating it.
 
What happens to transponders on that day? Without radar, there will be nothing to interrogate them.... How will we set a squawk code, and even further, why would we need to?

Don't worry, Big Brother I mean the FAA has thought about this. The backup to an ADSB failure will be TCAS (transponder based collision avoidance) which the airlines already have. So we'll be required to have transponders even after radar goes away, so airliners can see us in an ADSB failure. GA? The FAA doesn't really care.
 
I was under the impression that the initiation of an ADS-B out transmission packet required a ping from ATC. As opposed to an asynchronous mode where the ADS-B out transmission is made at an interval. Yes/No??

The 1090 ES (Extended Squitter) transponders will "squit" without an ATC radar contact.

If you?ve ever flown with a Mode S transponder, you?ve already done your fair share of ?squittering.? By definition, the word ?squitter? refers to a periodic burst or broadcast of aircraft-tracking data that is transmitted periodically by a Mode S transponder without interrogation from controller?s radar. Mode S ( which stands for mode ?select?) technology was first developed in the mid-1970s as a way of using existing ground-based secondary surveillance radar (or SSR) to track onboard transponders more precisely and more efficiently ? while reducing the number of interrogations required to identify and follow aircraft on the controller?s radar scope.

Good operation description from Garmin here -

http://www.garmin.com/us/intheair/ads-b/squit/
 
Nothing. There's nothing to prevent that now. It would just confuse things. That's one of the vulnerabilities of ADSB - no effort was made to prevent spoofing.

As for Radar, 9/11 pretty much put to bed the idea of completely eliminating it.

One of my brothers, retired Navy electronics specialist, worked on FAA radar systems through his employer after transition to civilian life. He said the system was very complex in that newer radar computers were layered on top of old. At the time he said original computers, based on first iMac platform, were still being used 20 years after introduction.

The system certainly was prone to failure, not often reported to public. I was working a trip from Boston one morning when advised by NY Center to proceed to a VOR in New Jersey and hold indefinitely. Ok. what's going on? Answer, we just lost all radar.

I called dispatch and advised and they responded land at PHL. I responded, descent through 35,000' of uncontrolled airspace? Not a good idea. How 'bout we just proceed west at 350 until we get to Cleveland airspace and reestablish radar contact. About then NY called and said they got it working, cleared as filed.

There will be ADS-B failures also. My guess radar will be around a long time, old as it is, as a back up.

The cost of all this might have gone long way to whole new radar system, we will never know.
 
When the Radar sites are decommissioned, what safeguards are built into the system to prevent someone from transmitting a signal on 978 MHZ with the proper protocol and fake Lat / Lon / altitude?
FWIW: The long range center radars (although maintained by the FAA they are owned and funded by the DOD) are not, have not nor has anybody even talked about them being decommissioned. Think NORAD and air defense. Now short range approach radars (maintained, owned and funded by the FAA) are a different animal.
:cool:
 
Last edited:
When the Radar sites are decommissioned, what safeguards are built into the system to prevent someone from transmitting a signal on 978 MHZ with the proper protocol and fake Lat / Lon / altitude?

Multilateration can be used to both back up certain ADS-B system failures, as well as provide detection of signals which originate from a different physical location than the payload indicates. Multiple ground stations or a ground station and a satellite can be used for multilateration.
 
My that was pretty much a waste of server space!!! About the only bit of knowledge there, and I already knew this, was that the FAA looks at all threads on the Vansairforce site. Remember the S in ADS B stands for surveillance.
 
Back
Top