What's new
Van's Air Force

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

uAvionix replacement for Navworx EXP

I think I'm good to go

I installed the uAvionix replacement for the Navworx EXP with the Skyfyx GPS. Plugged into the Navworx harness, configured with the echoUAT app, checked the GRT Sport SX settings and all went well. Flew around BNA today for about an hour and displayed traffic on the GRT and Foreflight. Got a performance report back from the FAA with nothing in the RED, so I guess I passed. I did get some intermittent ghost traffic with my N number displayed.
 
I received the corrected replacement wire harness, installed it and flew yesterday.

With the initially supplied harness my ads-b performance report indicated all good (zero failures) except in 2 categories:
Baro Alt 100% failure
Mode 3A 100% failure

The new ads-b performance report indicates all good except:
Baro Alt 1.44% failure

The FAA ads-b performance report comes with the advisory:

Be advised that flight operations occurring at the fringe of ADS-B ground station coverage (refer to the FAA ADS-B Coverage Map) can cause intermittent signal losses with aircraft avionics. This condition may generate various false failure indications (red flag for Percent Failure - PF and/or Maximum Consecutive Failure - MCF flag) within a Public ADS-B Performance Report (PAPR). Such failures will vary depending on the duration of the flight in this condition. If you receive a PAPR with suspected false failure indications, please email [email protected] and request that your avionics performance be manually reviewed prior to taking maintenance action. Please attach the PAPR file and include (PAPR Review Request) in the subject line of the reply email to help expedite a response.

Recipients of Performance Reports flagged red for Air-on-Ground issues are advised to contact their repair shop and/or avionics manufacturer(s) for guidance on appropriate corrective action.


Perhaps the small percentage of Baro Alt failures we are seeing is related to ads-b coverage and not the installed device?
 
I wanted to comment on my Uavionix experience. I too replaced a Navworx ADS600B (that worked beautifully). I installed the Uavionix Echo and GPS SkyFY-EXT with no problem. I ran the GPS into port 2 at 115200 and output the same port to the GRT HX at 115200 as well. I am using the "sniffer" for the squawk and baro altitude information. I use the GRT filter that only displays traffic plus/minus 1500 feet. I passed the FAA inflight test the first try with no issues noted.

All seemed well except that I am experiencing the frequent intermittent traffic problem that others have noted. For example, this morning outbound traffic from my airport as I was arriving. This traffic was displayed normally for a while on the EFIS and IPad and then disappeared from the screens. The traffic was in visual sight and passed safely to the side but this is not acceptable. Surely some software changes can fix this (I hope.) I am going to call Uavionix next week. I did note that the problem is for both ground supplied info and the 978 or 1090 received traffic. Another friend with an RV-7A has experienced the same issues.

If this is not corrected, I will be looking for another "in" solution. I do not have confidence in the traffic display at this point.
 
I flew from Payson AZ to Carefree AZ yesterday morning. I have the Echo and Skyfx using the sniffer for alt/trnsp code displayed on Foreflight. After installation I passed the test flying just outside the PHX class B. As for yesterday's flight I failed due to loss of PA.

Payson is well below the radar environment until reaching 7 or 8 thousand MSL.with a 5000' elevation.

After takeoff, nearby traffic was shown to be 8500' feet above me until about a minute or two elapsed and some air carrier induced a transponder reply after which the traffic was then shown at it's actual altitude (+2000' when I was level at 6500') Until the first non radar transponder reply the Echo used 0 as our altitude instead of the GPS altitude resulting in the bogus traffic reference.

I suspect that the FAA will tolerate no failures in the every day environment . I will give Uavionx the benefit of the doubt and see what they come up with as a fix most likely a hard wired altimeter source.

Don Bodnar
 
..snip...

I suspect that the FAA will tolerate no failures in the every day environment . I will give Uavionx the benefit of the doubt and see what they come up with as a fix most likely a hard wired altimeter source.

Don Bodnar

I've noticed at times the traffic shown through my AF4500 shows relative altitude of targets while Foreflight is showing MSL, which leads me to believe - as others have stated - that retrieving pressure altitude by monitoring the transponder isn't adequate.

I would be happy if the Uavionix box accepted a hardwired altitude but used the transponder monitor to obtain the squawk code. This and more target filtering would make it a great solution.
 
How does an altitude encoder sniffer pull altitude out of a Mode C transponder that is outside ATC coverage and not being interrogated?

The WAAS gps position requirement is not an altitude source in any way, is it?

Won't the Skybeacon have the same issue? How would software be updated for either Uavionix device?

I wanted to be an early Skybeacon adopter, but something has long bothered me about being in ADS-B coverage while entering and exiting radar coverage. It seems a fail-filled cludge on UAT 978 only systems.

It seems allowable with the posts about only testing inside a solid ADS-B and Radar coverage area. Does a 1090-ES installation totally avoid this cludge?
 
How does an altitude encoder sniffer pull altitude out of a Mode C transponder that is outside ATC coverage and not being interrogated?

The WAAS gps position requirement is not an altitude source in any way, is it?

Won't the Skybeacon have the same issue? How would software be updated for either Uavionix device?

I wanted to be an early Skybeacon adopter, but something has long bothered me about being in ADS-B coverage while entering and exiting radar coverage. It seems a fail-filled cludge on UAT 978 only systems.

It seems allowable with the posts about only testing inside a solid ADS-B and Radar coverage area. Does a 1090-ES installation totally avoid this cludge?

I have long asked the same question (your first one). Best answer I got was that the UAT would send gps altitude (along with a code that identified it as such) when barometric altitude was not available, and apparently they had some FAA approval for this.
For your last question, mode S-ES transponders are designed to periodically send out ADSB info, even in the absence of any ‘ping’ - just like UATs do. Of course they must be fed altitude, gps, etc., but it has to be hardwired as there’s no other signal to ‘sniff’.
Edit: all the cluge you refer to for UATs can be avoided in the same way: hardwire the data inputs instead of relying on transponder sniffers.
 
Last edited:
Seems like certified Navworx boxes using their transmon device will have all these same problems, and the Garmin GDL-82 will have them too.

Same for the soon-to-be-certified Skybeacon.
 
I had this problem when I was using the TransmonSPE with the Navworx. Resolved this issue by hard wiring the encoder to a serial in port.
 
Maybe UAvonic is listening.
I also think the P altitude would be more reliable if it was hard wired. The problem I see is that the ECHO begins transmitting UAT out before it has a transponder sweep. ( ie during Takeoff). With that missing data you can get a P Altitude MCF in the report even if it is on the order of seconds. Maybe software could hold that UAT signal until it received the first P altitude data point AND the first GPS position source data point. That might improve the report results in some cases.
The other comment I like better is that if the ECHO com Rx port 1 could be configured for say an Icarus Pressure Altitude input and used for input of an encoder or other Serial device and then use the sniffer for only the Mode and Sq code. I change altitude a whole lot more than I change SQ code! In my case the Com 2 port Rx is used for the EXT antenna.
Maybe they can fix this minor reporting problem with a software change rather that an AD !! Although the FAA don't seem to be concerned with the reporting. The Balance of the device seems to work well as advertised.
 
I've noticed at times the traffic shown through my AF4500 shows relative altitude of targets while Foreflight is showing MSL,.

This is pretty much as it has to be. I see the same comparing traffic data on my GRT and iPad/WingX. The ADSB data is MSL. The EFIS knows its altitude, so it can calculate the difference. But the iPad WingX doesn?t know the plane?s barometric altitude (it does know gps altitude) so it displays MSL.
 
I have long asked the same question (your first one). Best answer I got was that the UAT would send gps altitude (along with a code that identified it as such) when barometric altitude was not available, and apparently they had some FAA approval for this.
For your last question, mode S-ES transponders are designed to periodically send out ADSB info, even in the absence of any ?ping? - just like UATs do. Of course they must be fed altitude, gps, etc., but it has to be hardwired as there?s no other signal to ?sniff?.
Edit: all the cluge you refer to for UATs can be avoided in the same way: hardwire the data inputs instead of relying on transponder sniffers.

The problem is that the uAvionics system only has one serial port available for inputs. It would require two inputs to get both transponder squawk code, and altitude encoder information.

If you have a GNS-330 transponder (like I have) you can wire its serial output to the one serial input on the uAvionics system. The GNS-330 transponder outputs both the squawk code and alt encoder data. A GNS-327 will not do this (only the squawk code data).
 
I had this problem when I was using the TransmonSPE with the Navworx. Resolved this issue by hard wiring the encoder to a serial in port.

I also had PA failures with the NW transmon and Exp unit until I hard wired the encoder and Sq directly into the EXP.
 
Much better FAA ADS-B report this time

Uavionix support talked me through adjusting the threshold for the Echo to detect my transponder's encoded altitude. After doing so, I did another test flight out of KAEG and this time got no Baro Alt errors on the FAA report.

I did get a NACv Ave. of 1.2 (Min 1 and Max 2), but that was the only anomaly and is within the accepted range.

I found Ryan (the Uavionix support agent) to be responsive, clear, and helpful on the Baro Alt issue. I'll stay tuned here to hear what develops with the other issues mentioned in this thread.

We're based at KAEG, so we're flying in and out of there already.... Our test flight was the only flight of a several day period, so I don't think other errors could have made it into the report. Thanks for the ideas...I'll report back here if I hear from Uavionix support.



Edit: Uavionix support just checked in on my ticket, and we're starting a conversation. Re the ForeFlight display, their comment was "Your observations regarding traffic separation are correct. When the ownship data from echoUAT doesn?t containg a valid pressure altitude ForeFlight will display the traffic using the geometric altitude. Based on your performance report I would expect that behavior." So it sounds like an issue w/ my setup/equipment/configuration.
 
Doug, please explain "adjusting threshold"

for the encoded altitude --- I do not find that in the install manual.

Thanks,

Ron (former AEG tenant/instructor -- really miss Albuquerque)
 
I installed the uAvionix replacement for the Navworx EXP with the Skyfyx GPS. Plugged into the Navworx harness, configured with the echoUAT app, checked the GRT Sport SX settings and all went well. Flew around BNA today for about an hour and displayed traffic on the GRT and Foreflight. Got a performance report back from the FAA with nothing in the RED, so I guess I passed. I did get some intermittent ghost traffic with my N number displayed.

Steve, GRT filters ownship based on the N-Number and ICAO being entered into the GRT settings. Please double check the Transponder settings inside the GRT for this. MGL and AFS are much the same, please confirm you have your N-Number (CallSign) entered, including the N.

We've also had a few report of FlyQ ghosting as well. Be sure to go to Setting and to the bottom and tap "Ignore Callsign" and enter your N-Number. Filtering of the Ownship is really a function of the EFB or display device.
 
I received the corrected replacement wire harness, installed it and flew yesterday.

With the initially supplied harness my ads-b performance report indicated all good (zero failures) except in 2 categories:
Baro Alt 100% failure
Mode 3A 100% failure

The new ads-b performance report indicates all good except:
Baro Alt 1.44% failure

The FAA ads-b performance report comes with the advisory:

Be advised that flight operations occurring at the fringe of ADS-B ground station coverage (refer to the FAA ADS-B Coverage Map) can cause intermittent signal losses with aircraft avionics. This condition may generate various false failure indications (red flag for Percent Failure - PF and/or Maximum Consecutive Failure - MCF flag) within a Public ADS-B Performance Report (PAPR). Such failures will vary depending on the duration of the flight in this condition. If you receive a PAPR with suspected false failure indications, please email [email protected] and request that your avionics performance be manually reviewed prior to taking maintenance action. Please attach the PAPR file and include (PAPR Review Request) in the subject line of the reply email to help expedite a response.

Recipients of Performance Reports flagged red for Air-on-Ground issues are advised to contact their repair shop and/or avionics manufacturer(s) for guidance on appropriate corrective action.


Perhaps the small percentage of Baro Alt failures we are seeing is related to ads-b coverage and not the installed device?

Keep in mind that the Test Report is designed for a test flight inside a Mode C veil, Class B or Class C airspace. It's not intended to test in uncontrolled areas outside these. The test compares ADS-B and Radar from the secondary Radar and many times at low alts, and distances the system cannot detect a transponder at lower alts. I fly in the DFW area and it takes a few hundred feet AGL before my transponder is interrogated. The test system needs data from the ADS-B device as well as from the Transponder as well.

One other thing to consider is the ADS-B system specs a Baro Tolerance of 125' error. So it could also be that the Altitude encode needs some adjustment.
 
Keep in mind that the Test Report is designed for a test flight inside a Mode C veil, Class B or Class C airspace. It's not intended to test in uncontrolled areas outside these. The test compares ADS-B and Radar from the secondary Radar and many times at low alts, and distances the system cannot detect a transponder at lower alts. I fly in the DFW area and it takes a few hundred feet AGL before my transponder is interrogated. The test system needs data from the ADS-B device as well as from the Transponder as well.

One other thing to consider is the ADS-B system specs a Baro Tolerance of 125' error. So it could also be that the Altitude encode needs some adjustment.

Ok
So is a baro alt failure outside of these areas something the FAA allows?
 
Is the harness from Dallas Avionics a plug and play for the - B boxes or just the EXP boxes?

AFAIK it's only for the EXP boxes. but I found it wasn't hard to get it working - I had to push some pins out of the existing Navworx harness and push them into the connector for the supplied harness - power, ground, and the ADSB out wire. Then I had to reconfigure the serial port in my AF-4500 for a higher baud rate. I'm not totally happy about the echouat getting altitude info from the transponder monitor, but perhaps there will be a solution for that at some point.
 
To Don's point I have seen this in bench testing this week.


A friend of mine and I are in process of programming a filter box that I'll be putting inline with the Echo to filter the traffic based on some parameters. I noticed that sometimes traffic was depicted in MSL altitude, and I wasn't sure what the heck was going on until I realized that since it wasn't getting baro alt, it was referencing all traffic to 0' as ownship altitude. So, in our filter I had him program it so that if baro alt was missing, it used GPS alt as ownship alt, so that my traffic would display properly. It's these kind of mickey mouse things that I think will drive Uavionix customers crazy over time, if they don't get to working through these issues.

The intermittent traffic is also one I've experienced, where the airplanes show up, then disappear, and then show up...but at the same time, traffic 50 miles away is showing up rock solid stable. Or, sometimes all the traffic becomes intermittent. This could be due to the non-filtering as well, as once they split the batches of traffic up, different EFIS systems or even ipad apps may handle things differently.

And while I was glad to hear that GRT gives the option to filter traffic, I think that should not be an expected function of the EFIS. The reason being that if you are overloading the RS232 interface with dozens of unnecessary traffic targets, you are bound to miss some. I want to miss the far ones, NOT the near ones. RS232 even at 115,200 baud, can only handle so many planes at a time. At 38,400 baud, my system can't handle even nearly as many as 115,200. So they need to build a system that prefilters.
I had reliable traffic on NavWorX, so I know it's possible. It's all just a different programming paradigm.

We'll have to see how it goes.
 
plug and play or more

This comment is important, because I have had customers call the main office and order the EXP kit... replacement. They either don't make it clear that they have a 600B, or we forget to ask. The 600B customers will have to re-pin as mentioned. Some owners have complained to me, because they never did their original wiring and are not willing to go back and have the new box wired at the shop that did the original. From the re-pin comment, I think customers should see it is not a hard task. Nevertheless, we don't want unhappy customers and will cancel any orders if asked. With a smile.
see below:
{{{{AFAIK it's only for the EXP boxes. but I found it wasn't hard to get it working - I had to push some pins out of the existing Navworx harness and push them into the connector for the supplied harness - power, ground, and the ADSB out wire. Then I had to reconfigure the serial port in my AF-4500 for a higher baud rate. I'm not totally happy about the echouat getting altitude info from the transponder monitor, but perhaps there will be a solution for that at some point.}}}}}
__________________
 
Do you have the wiring diagram available so one can see what re-pinning is required to get a comfort level with the task prior to ordering the kit?
 
Question for TimO

Tim,
Not being that computer literate, I need to ask: How fast do USB and WiFi run? I have a Skyradar D2 that outputs on these two. I cannot recall any pre-filtering in the Skyradar (could be wrong) and I haven?t noticed any missing traffic on the GRT (filtered to +/- 3000?) or the iPad/WingX (filtering off), although in all honesty I don?t pay that much attention to the iPad. And the Bay Area is pretty busy.
 
download

I recommend any potential buyer download the install document at uAvionix. I think it surprises most, how easy it is to wire. Also, download the configuration app on your iPhone or Android to see what is involved.
 
How fast do USB and WiFi run? I have a Skyradar D2 that outputs on these two.

Hi Bob,

The WiFi I can't say for sure on the Echo UAT, because I'm not sure if it's sourced from the same serial internally or not, but in general at least from things like the old NavWorX wifi dongle, it is simply RS232 fed to a wifi adapter, so you can run the serial feed at whatever port speed you want. I think the NavWorX default was 115,200 baud. My guess would be that they run 115,200 baud serial into a serial to wifi chip onboard the Echo UAT, and it's probably running at about that speed. I think the USB interfaces in many systems are probably doing the same serial to USB, if they get it that way. This is all just a guess, because other than some systems that can use wifi, so many things rely on RS232 hard wired connections. That will change over time, but as you know, EFIS systems are a long-term purchase, so in my case it won't be changing any time soon.
 
Ok
So is a baro alt failure outside of these areas something the FAA allows?

They don't monitor performance for outside ADS-B Rule Airspaces. It's technically not a failure if outside of ADS-B Rule Airspace. If your Transponder was not in range of ATC or SSR, albeit too low or to far from, they would not have a Mode C or S to compare against, thus causing a failure as well. That is why it is critical to be tested in the proper airspace where ADS-B is required to meet a performance. The ADS-B spec permits using GPS Alt in Baro is absent, which is what the EchoUAT does. It's only a failure if inside the 91.227 rule airspace. I hope this helps some...
 
I recommend any potential buyer download the install document at uAvionix. I think it surprises most, how easy it is to wire. Also, download the configuration app on your iPhone or Android to see what is involved.

So if we hard wire it to a 330 instead of relying on the wifi we will be rid of the
altitude problem?
 
Is the harness from Dallas Avionics a plug and play for the - B boxes or just the EXP boxes?

the Plug and Play harness built for Dallas Avionics is specific to the ADS600EXP model as it uses a DB-9 serial plug. The 600-B model has far more optional scenarios to predict a standardized patch harness.

Ultimately there are only 6-wires on the EchoUAT to connect from that NavWorx plug. We'd only be using 4-5 wires in most cases from the 32 pin serial plug.

1-Ground
2-Power
3-Com1-TX
4-Com1-RX
5-Com2-TX
6-Com2-RX
 
So if we hard wire it to a 330 instead of relying on the wifi we will be rid of the
altitude problem?

Yes, the 330 will send the Pressure Alt and Squawk via serial, unlike the 327. most transponders like the Sandia, Trig, SL70, 330's, and many more actually send both Press Alt and Squawk via serial. The GTX-327 just does not support this.
 
So what are you guys saying... I have GTX-327 in my RV-12 and was planning UAVIONIX ECHO-ATU-20 just sniffing the xponder instead of hard wire connection. I fly mostly in MODE C local.

This still a good plan?
 
Last edited:
327s here also

I have two planes with 327 xpdr and EchoUAT and I am pleased with the system. If you have an issue with the "sniffer" contact support and find out how to adjust the sniffer threshold.
 
Ron, the threshold adjustment is not in the install manual, but Uavionix support walked me through it. I signed up and filed a ticket online, and they got back to me within a day on this. They asked me some questions and tailored their guidance based on my answers.

And yes, AEG is a great place!

Cheers,
Doug

for the encoded altitude --- I do not find that in the install manual.

Thanks,

Ron (former AEG tenant/instructor -- really miss Albuquerque)
 
the Plug and Play harness built for Dallas Avionics is specific to the ADS600EXP model as it uses a DB-9 serial plug. The 600-B model has far more optional scenarios to predict a standardized patch harness.

Ultimately there are only 6-wires on the EchoUAT to connect from that NavWorx plug. We'd only be using 4-5 wires in most cases from the 32 pin serial plug.

1-Ground
2-Power
3-Com1-TX
4-Com1-RX
5-Com2-TX
6-Com2-RX

Shane:

I have an EXP Navworx in my plane and I just unpacked my Echo UAT today. Regarding the included plug and play harness, I received a pig tail harness with a connector that plugs into the Echo unit. Shouldn’t there be another connector at the other end or is this the extent of plug and play harness? Maybe I didn’t receive the right harness?

EDIT: It turns out they didn’t send me the right kit. DA is sending out the replacement now.

I’m getting cold feet regarding the disappearing nearby traffic. This would be a deal breaker for me. Are there any plans to address this?
 
Last edited:
The intermittent traffic is also one I've experienced, where the airplanes show up, then disappear, and then show up...but at the same time, traffic 50 miles away is showing up rock solid stable. Or, sometimes all the traffic becomes intermittent. This could be due to the non-filtering as well, as once they split the batches of traffic up, different EFIS systems or even ipad apps may handle things differently.

And while I was glad to hear that GRT gives the option to filter traffic, I think that should not be an expected function of the EFIS. The reason being that if you are overloading the RS232 interface with dozens of unnecessary traffic targets, you are bound to miss some. I want to miss the far ones, NOT the near ones. RS232 even at 115,200 baud, can only handle so many planes at a time. At 38,400 baud, my system can't handle even nearly as many as 115,200. So they need to build a system that prefilters.
I had reliable traffic on NavWorX, so I know it's possible. It's all just a different programming paradigm.

We'll have to see how it goes.

I use FlyQ with my EXP box and it has a filtering function which I have turned on. Everything functions great with the Navworx unit..no disappearing traffic. Is it reasonable for me to expect the same performance with the Echo unit?
 
More updates on my NavWorX replacement with EchoUAT

The past few days I've had a few flights with the Echo UAT and am starting to see a trend. I'm curious as to how it is for other people as well.

With the Echo I'm seeing lots and lots of times that traffic randomly comes and goes. I see it on the ipad and there may be a bunch of planes on the north side of a class Bravo area, then a minute later those flash out and maybe there will just be a couple of random targets but a few seconds later there are a large group on the south side of a class Bravo. So it appears that traffic is very intermittent.

Bench testing the unit with a "Ted" stubby antenna, I find that a stratux unit (I have a Seattle Avionics Merlin), has quite a bit better reception range, but that's just a side note.

One thing that I've been plagued with much more often than with the NavWorX is with ghost traffic in my location. I am used to a ghost callout for "traffic" maybe once every month or two, when flying around class B areas, but I now get ghost traffic multiple times on some flights. Yesterday I probably had ghost alerts 6-8 times in less than an hour.

Based on the above, I'm thinking that there is not nearly the processing/filtering being done that the NavWorX did. As you may have noticed from a previous post, another RV builder and I have been working to build a filter/converter box for the GDL90 data coming out of the Echo. Right now the output isn't in GDL90 format, but it would be easy to do so. But in the process of logging GDL90 data, and feeding it in, processing it, and outputting it, we are finding multiple things that can easily be improved in software.

Here's a rundown of a few off the top of my head:

Coasting: By using a short-term table of nearby targets, sorted by distance, and coasted, we are able to greatly reduce the blinking out of these targets. You keep track of Vertical speed, speed, altitude, and track of the targets, and when they disappear, if they were in your table (we keep track of 31 nearby targets), you use their previous reports to generate traffic output that would continue their previous trajectory. We have it set to a user definable setting so you can receive projected traffic positions for an extra 15-30 seconds after it blinks out on the UAT. If it pops back up, the position updates and everything syncs back up, as each target is tracked by Mode S code.

With the sorting by distance, I only send to my EFIS a max of 31 targets, and they are only the 31 nearest ones that are heard. If a new one pops up, it displaces the furthest one from the list. This coasting really makes the system much more useable since you don't constantly lose and regain targets.

Ghosting improvements: By keeping track of ownship track/speed/altitude and comparing it to any targets within a certain very close range (a few hundred feet), you can look at that targets track/speed/altitude and if the parameters closely match yours, and the position is within a couple hundred feet, you can blow it away and eliminate the ghosting.

COM Port Speed matching: One nice thing about doing this by a post processing box is that I was finally able to use my GTX wire connection for the UAT. If you remember in previous posts, I said that one of the pains of the box is since the ports aren't asynchronous, you can't have a 9600 baud transponder connection, and a 38,400 baud EFIS GDL90 connection on COM1 TX/RX, and you are fairly locked into using 115,200 baud on COM2 with the SkyFYX GPS, so that eliminates using a 38,400 baud EFIS on that port. But, by post processing it, it made it possible to push the GDL90 at 115,200 baud to this box, process it and filter it, and then output it at 38,400 baud, allowing the box to be integrated into COM2. That frees up COM1 for use at 9600 baud with the transponder. Once I did that, my squawk code was able to change immediately when I tested it. Before this, I tried in-flight quickly entering 1234 and noticed that the UAT did not receive the update. This was on climb-out, and I didn't wait a long time to see if it would finally get the squawk, as it was not my assigned code, but it did illustrate that you may have a delay in switching squawk codes by the monitor function.

Max Intruders: Another nice feature is being able to limit the output a little to not clutter the screen with too many intruders. I can user configure a setting to display any number from 1-31 of intruders. Once you get near the top of that range, you can make your EFIS so messy that as I was flying around MSP airspace, you could barely read the airport info or airspace info within the class B area with as much traffic as their was. Having a way to limit counts is a great thing...having it sorted by distance is crucial then though.

Distance filter: Rather than just pick up traffic from whatever the default distance is, I have a user-defined variable for setting the maximum target distance, so it does not pass on or display anyone further out than that. This keeps down the unnecessary processing of the other targets, because if someone is over 100nm away, you really don't need to know about them.

Anyway, this is just a little of what I've bee working on and finding, but I'm curious as to how common this ghosting is for others using the Echo, and how much disappearing traffic you have. Those things should be fixable as Uavionix puts more time into developing the software, so hopefully if you are having issues, you can see those things improve down the road.
 
Last edited:
Yes, the 330 will send the Pressure Alt and Squawk via serial, unlike the 327. most transponders like the Sandia, Trig, SL70, 330's, and many more actually send both Press Alt and Squawk via serial. The GTX-327 just does not support this.

Shane, I take it that the GTX 330 ( not upgraded to ES and or older software) can be serial connected to the ECHO via COM 1 and with that the ECHO will use the P altitude and Squawk code from the RS232 com rather that the transponder output sniffer. I believe the manual shows a separate set up for the 330. Am I understanding you correctly? I am beginning to see some GTX330 on the classified now for less that 1K.
 
GTX330 and EchoUAT

Shane, I take it that the GTX 330 ( not upgraded to ES and or older software) can be serial connected to the ECHO via COM 1 and with that the ECHO will use the P altitude and Squawk code from the RS232 com rather that the transponder output sniffer. I believe the manual shows a separate set up for the 330. Am I understanding you correctly? I am beginning to see some GTX330 on the classified now for less that 1K.

This is the setup that I have installed in my RV-7A, replacing the Navworx EXP unit. It tested out OK by the FAA test site. But the original harness, that was supposed to be compatible with the EXP air frame wiring, had to be changed. Instead of the EchoUAT COM2 going to pin #3 of the DB-9, it had to be moved to Pin #1. Then follow the EchoUAT setup process for the GTX330 transponder.

I too am seeing erratic traffic with the EchoUAT system. It doesn't perform like the Navworx 600EXP unit. Yes I see traffic, but sometimes traffic within a mile doesn't appear, or suddenly disappears. Not liking it at all. Definitely not a reliable traffic indicator, especially when compared to the Navworx EXP unit...

I'll be testing out a freeflight Lite system this weekend. It too has the GDL90 serial interface to outside devices. I'd like to see how this unit compares to the uAvionics EchoUAT unit....
 
Shane, I take it that the GTX 330 ( not upgraded to ES and or older software) can be serial connected to the ECHO via COM 1 and with that the ECHO will use the P altitude and Squawk code from the RS232 com rather that the transponder output sniffer. I believe the manual shows a separate set up for the 330. Am I understanding you correctly? I am beginning to see some GTX330 on the classified now for less that 1K.

Yes, the GTX330 will pass the Squawk and Pressure Altitude to the EchoUAT over the serial wire. We've set many customers up successfully with this.

For others concerned with low % fails on reports:
Keep in mind that the ADS-B spec supports a device sending GPS altitude if Pressure Alt is not available for a period of time. There seems to be a lot of concern about low % of fails outside of Rule Airspace... defined as below.

Please understand that the required performance marks on these reports are specifically noted for these airspaces due and are not reasonable for tests outside the "Rule Airspace", or at least within very close proximity to it. Here is a basic analogy... Its like paying for 10mb internet service in your home using a WiFi router, then walking 200+ feet away from your house and expecting the full 10mb service speed... it simply won't happen. You've increased the distance outside the intended zone and put many variables, buildings (Terrain and Altitude) into the mix.

Under the rule, ADS-B Out performance is only required to operate to the performance report levels in:

1. Class A, B, and C airspace.
2. Class E airspace within the 48 contiguous states and the District of Columbia at and above 10,000 feet MSL, excluding the airspace at and below 2,500 feet above the surface.
3. Class E airspace at and above 3,000 feet MSL over the Gulf of Mexico from the coastline of the United States out to 12 nautical miles.
4. Around those airports identified in 14 CFR part 91, Appendix D.

If you look at your performance reports on the beginning page, you'll see Duration, Mod and Rule. The time in the Rule field is your amount of time in Rule Airspace. This should technically be a majority of your flight to ensure performance marks are hit.

I hope this clears up a little confusion.
 
Yes, the GTX330 will pass the Squawk and Pressure Altitude to the EchoUAT over the serial wire. We've set many customers up successfully with this.

For others concerned with low % fails on reports:
Keep in mind that the ADS-B spec supports a device sending GPS altitude if Pressure Alt is not available for a period of time. There seems to be a lot of concern about low % of fails outside of Rule Airspace... defined as below.

Please understand that the required performance marks on these reports are specifically noted for these airspaces due and are not reasonable for tests outside the "Rule Airspace", or at least within very close proximity to it. Here is a basic analogy... Its like paying for 10mb internet service in your home using a WiFi router, then walking 200+ feet away from your house and expecting the full 10mb service speed... it simply won't happen. You've increased the distance outside the intended zone and put many variables, buildings (Terrain and Altitude) into the mix.

Under the rule, ADS-B Out performance is only required to operate to the performance report levels in:

1. Class A, B, and C airspace.
2. Class E airspace within the 48 contiguous states and the District of Columbia at and above 10,000 feet MSL, excluding the airspace at and below 2,500 feet above the surface.
3. Class E airspace at and above 3,000 feet MSL over the Gulf of Mexico from the coastline of the United States out to 12 nautical miles.
4. Around those airports identified in 14 CFR part 91, Appendix D.

If you look at your performance reports on the beginning page, you'll see Duration, Mod and Rule. The time in the Rule field is your amount of time in Rule Airspace. This should technically be a majority of your flight to ensure performance marks are hit.

I hope this clears up a little confusion.

Shane,

Could you also comment on the traffic issues that are being seen. I was IFR at 6000' when traffic within 2 miles and within 900' Alt, suddenly disappeared, and only re-appeared after it had gone past me.

Others have commented on this site that the GDL90 output stream needs to be prioritized and filtered prior to being outputted from the UAT.

Does your UAT do any filtering? Is there any way in the setup to limit the number of targets, especially those that are outside the 15 mile active area?
 
I too am seeing erratic traffic with the EchoUAT system. It doesn't perform like the Navworx 600EXP unit. Yes I see traffic, but sometimes traffic within a mile doesn't appear, or suddenly disappears.

Please know that we are looking into these reports of above noted traffic behavior with great seriousness. There could be a number of factors at play here based on Location, Antennas, GPS, EFIS and EFBs... We are working with a few pilots that have reported this and we are performing numerous tests and test flights this weekend to isolate the problem for a fix.

Anyone with a video of this behavior is welcome to send it to me at [email protected] and we can use these to help determine a pattern. Please know that we are taking this very serious and will have an update very soon.
 
Phase II

Dallas Avionics has provided a large number of former Navworx owners the Echo solution from uAvionix. I have fielded about 125 phone calls for tech support since this began. I feel we are moving into phase two where pilots/builders are doing the setup and configuration for a number of connected EFIS systems. They range from GRT to AFS and others including portable pads via WIFI. It might be valuable to start a thread to share settings. I am putting this out to the Vans community to see if they agree. Input is welcome. As a side note, I pulled the EXP box from my RV yesterday. Last Thursday I had to fly to Las Vegas to program a park service tactical radio. It had me wondering just what was contained in the data stream from a given UAT. My uAvionix Echo unit is going in today and I will do a compliance flight test after. I suspect that the ICAO code entered in any UAT is just about all that is broadcast. (in terms of identity) When I was chief pilot for Capstone Phase II, certain operators did not trust the FAA and changed settings to avoid broadcasting their true altitude. Enforcement history has shown this was not necessary. But, I digress. The Vans community has proven to be a valuable resource to builders and even those with other types of planes. Kudos to Doug and don't forget those 2018 donations for support!
 
I just got back from my first flight using the echouat/skyfx combination in place of the Navworks 600B box.

My experience matches what previous poster have seen:

  • Targets disappearing and reappearing
  • Targets appearing many miles away/at much higher altitude
  • Targets appearing twice on top of themselves

Better filtering/prioritization of targets would definitely help these problems.
I was flying in an area where there was only one ADSB tower and I would lose contact with it in turns, etc., which corresponded to targets disappearing. Other targets, presumably 1090ES ones, remained throughout.

The ghosting/shadowing of targets only seemed to show up when there was an ADSB tower that was available, so presumably this could be because the target was being seen on both UAT and 1090ES.

I got NEXRAD wx through the flight similarly to how the Navworx box used to.

So in summary, a bit more filtering of targets would make the performance of this solution more than satisfactory.
 
Time will tell

Interesting to read about target behavior. We were promised dual band receive on the Navworx, and so most of us are used to single frequency input. That and data link to ground station propagation (line of sight and relatively high frequency @978mhz) will have some effect. I will be curious to see how things play out since uAvionix is looking closely at these reports as well. My compliance flight with the Echo set a personal record for me yesterday. Total time airborne (or above stall speed minus 10) was 16 minutes. I got an error free compliance report back in less than five minutes after putting my email and N number in the form. And I live a hundred miles from the nearest class B. Full disclosure: we do have a ground station on the field. And I got a discreet squawk in the pattern by request. But it sure was fast and easy. I spent way more time removing the Navworx box than putting in the Echo. Small and light are the key words here. Happy RV owner today.
 
I made the swap yesterday and performed two flights.

I too saw disappearing and reappearing targets, ghosting of targets, and I had 2, 100% failures on my reports.

I had the same 2 performance failures on each of my flights: ?Baro Alt? and ?Mode 3A?.

I am using a GTX-327 and FlyQ on an iPad Mini for my ADS-B. I?m also seeing the red ADS-B battery low indicator flash on my FlyQ. This is a minor issue but still, not right.

I will notify uAvionix of all this.

It seems like we are all experiencing the same sort of issues which is actually a good thing for troubleshooting. I know that uAvionix is working hard on this and I?m hopeful for a solution very soon.

Installation was pretty easy and I can?t believe how small the boxes are.
 
I had 2, 100% failures on my reports.

I had the same 2 performance failures on each of my flights: ?Baro Alt? and ?Mode 3A?.

I am using a GTX-327 and FlyQ on an iPad Mini for my ADS-B. I?m also seeing the red ADS-B battery low indicator flash on my FlyQ. This is a minor issue but still, not right.

Sounds like you have the original wiring harness that was wired incorrectly. I had the same failures initially. You need to request they send a corrected wiring harness or swap one of the wires yourself. This is what they advised me:
If you are using our provided plug and play harness it may have shipped with an incorrect pinout for the 327. If you?d like to resolve it yourself pin 3 on the DB9 needs moved to pin 1 which requires some soldering.
 
"Fails to generate a report"

I have made 3 flights with my new install and FAA reports "failed to generate a report". I used the monitor function on my phone and saw the pressure altitude and code. I also received traffic on my AFS, but it blinked in and out, and I get ghosting, which I see on my iFly740.

Tomorrow I will install another unit, borrowed from a hangar neighbor, that did generate a clean report, from the FAA (but still had the traffic issue).

Ron
 
MGL

Anyone flying with an MGL Voyager, Odyssey, or IEFiS? I am getting traffic on my IPAD but am not seeing anything on the EFIS. I have my Garmin 430W for position source and only need one wire going to the Efis according to the diagram. Also have not been able to generate a FAA report, but have not flown inside a Class B or C airspace.
 
After my flight today I asked for and got a FAA report.
No failures for a 30 min flight just outside the Denver Class B.
 
Back
Top