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've been told by a reputable source that this offer is based on a limited production of approximately 200 units. First come first serve. I ordered one this afternoon and was told it will ship Friday. Don't count on this offer being available for very long unless Uavionix decides to build more.

Flightlogic's post above (post #45) seems to indicate that is not the case. It appears that he represents Dallas Avionics in the Southwest region.

I too plan to wait this out for a bit to see how it all works out. I certainly don't want to be bit again.
 
Shane's Reply

"We put this package together with them based on an estimated 200 unit order. I personally would not wait to long, as there is a 12/31/17 deadline on the offer as well."

Great, the pressure is now on.
 
pressure is on

I don't think being cautious is a bad idea. For those who lost money, I would expect that. I will see that experimental customers are happy with their uAvionix products. Scott and I are committed to standing behind what Dallas Avionics distributes. It has been that way for many many years.
 
GPS Ant Adapter

I removed the EXP, and installed the UAvionix UAT & GPS source combo. I was provided an adapter to go from GPS antenna I had to smaller hookup on their GPS source. I was able to re-use the output TXP antenna from the EXP. Set it up, and flew. Requested report same afternoon I installed it. Come back perfect. SIL 3. I am using IFly thru Wi-Fi. I had 7 ground stations on a very recent flight. Seems to work exactly as advertised.

So the current NavWorx ADS600-EXP GPS ant input uses an SMA male type connection (the ant lead has female SMA connector). The ECHOUAT-KL5 combo GPS ant connector is a MCX type connection (Question: is it a male or female connector???). An adapter is required to make the current GPS ant input work. Is this the adapter you are referring too? If so, what is the part number?

Does it look like this? https://www.adafruit.com/product/1532

Or like this? https://www.pasternack.com/sma-female-mcx-jack-straight-adapter-pe9470-p.aspx?gclid=EAIaIQobChMIhpWs4fas1wIVg4izCh3HDAfSEAYYBCABEgJvofD_BwE

Or is like this? https://www.ebay.com/itm/SMA-Female-to-MCX-Male-Adapter-Connector-US-Stock-Fast-Shipping/111265515416?hash=item19e7f10798:g:lbsAAOxyOMdS5JJE
 
Last edited:
Certified to Experimental

If any Van's owner/builder got caught up in the certified UAT AD, and plans to purchase an experimental ADS-B, send me a PM. I have some ideas regarding the change over to experimental. Have a great week.
 
If any Van's owner/builder got caught up in the certified UAT AD, and plans to purchase an experimental ADS-B, send me a PM. I have some ideas regarding the change over to experimental. Have a great week.
Did you mean the certified Navworx AD?
Bob Cowan, RV&A 500 hrs
 
If you have the certified units (-0112 and -0113), they are not covered by the AD - only the -0012, -0013, and exp units. They are all subject to the lack of support and software upgrades though!
 
Anyone get a shipping notice from Dallas Avionics today for the Echo/Skyfix Navworx replacement package?

Thanks Don Bodnar
 
I ordered directly from Shawn at uAvionix and received my echoUAT bundle Thursday. Don't know when I will go through the agony on the remove and replace!

Bob Cowan, RV7A 500hours
 
Anyone know about the wiring for the -B models?

If you have the certified units (-0112 and -0113), they are not covered by the AD - only the -0012, -0013, and exp units. They are all subject to the lack of support and software upgrades though!

I was a very early adopter and have the Navworx ADS600-B (-0012) model. The offer talks about a pigtail for the ADS600-EXP models but says that we will have to re-wire for the ADS600-B. I am assuming that means I will have to make my own D-sub pigtail adapter. Has anyone done that or know if it is feasible/how difficult will the install for the ADS600-B models be? Same or different antenna connectors?

For that matter, would it be possible (and legal) to simply install the uAvionics Skyfyx GPS and connect it via Serial port to the ADS600B (like a panel mount WAAS GPS would be). Then the GPS source would be certified and I could keep using the ADS600B. (though with the deal they are offering it is probably worth it to just get rid of the ADS600 for the Echo's dual band and wifi capabilities alone...)
 
If the SkyFyx is already on the FAA approved position source list you can simply submit an AMOC like others already have.

If not (it wasn't there last time I checked), you will need to show that it meets the requirements for certification.

From what I can figure out, since the EXP's were called out by the FAA - they are in a tough spot.

I would check with the folks making the uAvionics offer to see how they are handling the AD resolution. I would not want to be in the same place again after spending even more money!
 
If the SkyFyx is already on the FAA approved position source list you can simply submit an AMOC like others already have.

If not (it wasn't there last time I checked), you will need to show that it meets the requirements for certification.

Yes, I have been wondering about why the SkyFyx is not on the list, and then I realized it is still experimental, and not TSO'd. Because of that, it wont make the official list.

Also, I answered my own question about weather it would even work with the ADS600-B models.... It appears not. Bob L. has mentioned that the ADS-600B will only accept ADSB+ format, while the SkyFyx outputs in NMEA format.

A similar solution would be the Garmin 20A GPS source (listed at $850 currently). It is also non TSO'd but 'performs to the standard'. It outputs in ADSB+ format an might be a candidate for a future AMOC but it looks to me like they are only accepting AMOCs for TSO'd position sources?? Meanining position sources like the SkyFyx and Garmin 20 can be used by experimental aircraft for any ADS-B unit EXCEPT the Navworx (because of the AD). I am guessing that there is no specific reason that we couldn't get an AMOC using the Garmin 20, its just that no one has done it yet because it still might not be approved.

Anyway, for me, out with the Navworx and in with Echo/SkyFyx.

I may still be able to get a few $ for the ADS600-B by selling it to a certified aircraft owner to be installed under an AMOC in an installation that already has a Garmin panel mount WAAS. There are still a ton of certified aircraft around that are going to have to equip in the next couple of years.
 
Dallas Avionics Ship Date

When I placed my order with Dallas Avionics I was told it would ship the 10th. I called today because my CC has not been charged and have not received a tracking number. I talked to Sydni at DA and she said that they had expected them in but have not. She said they are now due to arrive by the 30th.

Anyone get a shipping notice from Dallas Avionics today for the Echo/Skyfix Navworx replacement package?

Thanks Don Bodnar
 
Echo UTA "Sniffing"

Like most everyone looking at this post, I've gotten caught up with the NavWorx fiasco. I've got an RV6, just installed a Garmin GPS, King KT78 transponder. Installed the NavWorx just aft of the baggage compartment bulkhead and planned on installing the Echo in the same location. ADSB antenna located on the belly in a similar location. Transponder antenna located under the copilots feet. NavWorx's "Transmon" worked well at picking up the mode 3A and C squwaks. Anyone have any feed back on how well the Echo "sniffer" captures the squwaks?
 
My experience so far - -

Excellent. Got back perfect report first time. I was using the Navworx EXP, so reused my out antenna and GPS antenna. Simple and fast. Like receiving both 1090 & 978 in.
 
my experience

Anyone have any feed back on how well the Echo "sniffer" captures the squwaks?

As an early EchoUAT customer, I have found the "sniffer" works very well. Check for pressure altitude and squawk code on the Echo App to verify it is working. IF you have any issue, Tech Support can tell you how to change the transponder threshold so that it works better.

In my opinion, EchoUAT is a very well engineered product with great support via the Echo App and Tech Support.
 
TO JBPILOT --- Position Source

You mention you are using the NAVWORX GPS antenna --- what are you using for your position source? (my system is on order from Dallas)

Thanks,

Ron
 
Ron - - - -

I bought their GPS combo package. Two very small boxes that you can mount nearly anywhere. They provided an 'adapter' short wire to change from GPS antenna I had to their small snap in type connection. Out antenna had same type connector. Run ONE wire from one box to the other, and power and ground to both boxes, setup, go. Simple.
 
The combo package worked for me. I got the SKYFyx-EXT antenna and mounted it where the NW antenna was on a bracket under the canopy in back of the baggage compartment. I tested it on a long cross-country flight with some other RVs. It worked perfectly the first leg. On the second leg the wi-fi disconnected a couple of times. After I reset the CB it stayed put for the rest of the 1+50 flight. The performance report came back with no errors. I'm scratching my head over the disconnect and hoping that will not be an on-going problem.
 
Alan and others - -

My GPS antenna is on the shelf under the top cowl where the original XM antenna was designed to go. A short provided adapter cable allowed me to keep both antennas from previous setup. I have had NO issues so far. I had the Navworx unit operate for 2 years, and it worked well. I really now appreciate the dual input. I was not use to seeing jets far above me. So far - so good.
 
Fallback mode when flying below radar coverage

If flying below radar coverage, where there aren't interrogations, does the EchoUAT fall back on GPS altitude and broadcast out regularly (e.g. once per second) instead of relying on the sniffer? And is the fallback mode EchoUAT uses acceptable to the FAA for 2020 purposes? I sent in a support ticket a couple weeks ago with these questions but haven't heard back yet.

Thanks,
Doug

As an early EchoUAT customer, I have found the "sniffer" works very well. Check for pressure altitude and squawk code on the Echo App to verify it is working. IF you have any issue, Tech Support can tell you how to change the transponder threshold so that it works better.

In my opinion, EchoUAT is a very well engineered product with great support via the Echo App and Tech Support.
 
If flying below radar coverage, where there aren't interrogations, does the EchoUAT fall back on GPS altitude and broadcast out regularly (e.g. once per second) instead of relying on the sniffer? And is the fallback mode EchoUAT uses acceptable to the FAA for 2020 purposes? I sent in a support ticket a couple weeks ago with these questions but haven't heard back yet.

Thanks,
Doug

I sent in a similar request and got the following response
... When the pressure altitude is not available the echoUAT will send geometric altitude (GPS) as the primary altitude. The UAT message allows for the declaration of the type of altitude being transmitted. When pressure altitude becomes available again echoUAT will send pressure altitude automatically.

I hope this helps your understanding of the echoUAT behavior.

uAvionix Support
 
Unit received from Dallas Avionics

Just received my Echo package from Dallas Avionics. The installation will be a snap. Even included the UAT antenna adapter

20171207_182834%5B1%5D.jpg
 
Safe-Fly + EchoUAT reply when outside RADAR

Quote:
Originally Posted by NM Doug View Post
If flying below radar coverage, where there aren't interrogations, does the EchoUAT fall back on GPS altitude and broadcast out regularly (e.g. once per second) instead of relying on the sniffer? And is the fallback mode EchoUAT uses acceptable to the FAA for 2020 purposes? I sent in a support ticket a couple weeks ago with these questions but haven't heard back yet.

Thanks,
Doug
I sent in a similar request and got the following response
Quote:
... When the pressure altitude is not available the echoUAT will send geometric altitude (GPS) as the primary altitude. The UAT message allows for the declaration of the type of altitude being transmitted. When pressure altitude becomes available again echoUAT will send pressure altitude automatically.

I hope this helps your understanding of the echoUAT behavior.

This is the answer to PART of the issue: When outside the radar environment, and the transponder isn't being pinged, what transponder code is sent by the UAT device? If the UAT device isn't able to detect a transponder output, how does it know if the transponder code has been changed?

Just got off the phone with auAvionics tech. He stated that the UAT will transmit the last known transponder code under the above situation. A previous post stated (and uAvionics confirmed) that the GPS alt it sent with the encoder alt = 0. And there will not be any loss of weather or traffic as long as a ground station is within range. He didn't see any situation that would result in loosing traffic data.

Something else of interest: The FAA knows the manufacture of your ADS-B from it's transmissions. They will treat the ADS600-EXP transmissions as invalid after 1/11/18, and you will loose ground based broadcast of traffic data, AND probably get an official notification from the FAA.....
 
Last edited:
This is the answer to PART of the issue: When outside the radar environment, and the transponder isn't being pinged, what transponder code is sent by the UAT device? If the UAT device isn't able to detect a transponder output, how does it know if the transponder code has been changed?

In my case I intend to connect the serial from the GTX327 transponder to the ECHO UAT. I wish the ECHO unit could receive BOTH the serial data from an encoder and a transponder like the NAVWORX-EXP unit did.

It would also be nice if uAvionix published more documentation about how their unit handles cases where the transponder is not being interrogated.
 
my experience

I have an EchoUAT in both my RVs since last May. Have flown about 150 hours between the two RVs. I have a wired connection to my panel mounted GPS to get ADSB+ into EchoUAT and wired connection to my EFIS to get weather and traffic. I have found no need to connect to my transponder since the "sniffer" works so well. Just wanted to document my experience.

Your experience may vary.
 
Something else of interest: The FAA knows the manufacture of your ADS-B from it's transmissions. They will treat the ADS600-EXP transmissions as invalid after 1/11/18, and you will loose ground based broadcast of traffic data, AND probably get an official notification from the FAA.....

Fred,
I don't doubt that you may be correct, but,
If the FAA knows the manufacturer from the the data stream transmit, why do they ask who the manufacturer is when you submit a compliance report?
They should already know or they want to validate?
 
Fred,
I don't doubt that you may be correct, but,
If the FAA knows the manufacturer from the the data stream transmit, why do they ask who the manufacturer is when you submit a compliance report?
They should already know or they want to validate?

Dan,

When I talked to the uAvionics guy yesterday, he stated that he had been using his own (certified) aircraft to test various ADS-B devices. He stated that the FAA would query him every time he had a new (non-certified) device in his certified aircraft. The FAA wanted to know why he was using a non-certified ADS-B in a certified aircraft. He also stated that he had not previously told the FAA what he was using, but they knew it wasn't certified by it's transmission.

The uAvionics guy surmised that the FAA was able to recognize ADS-B RF transmission characteristics. Since the ADS600-EXP is a known device to the FAA, they will be able to identify its illegal use after 1/11/18....
 
Dan,

When I talked to the uAvionics guy yesterday, he stated that he had been using his own (certified) aircraft to test various ADS-B devices. He stated that the FAA would query him every time he had a new (non-certified) device in his certified aircraft. The FAA wanted to know why he was using a non-certified ADS-B in a certified aircraft. He also stated that he had not previously told the FAA what he was using, but they knew it wasn't certified by it's transmission.

The uAvionics guy surmised that the FAA was able to recognize ADS-B RF transmission characteristics. Since the ADS600-EXP is a known device to the FAA, they will be able to identify its illegal use after 1/11/18....

Thanks Fred, That's very interesting.
BTW, missed you & Turbo on the breakfast club in New England in Oct. You guys had already returned to Florida. Funny that everbody at breakfast were from Florida.
 
Flight test

Did a flight test after installing the Echo UAT, and upgrading the GNS430W to ADSB+. Tried to generate a report from the FAA website but got a message that the flight did not generate a report. Does the Garmin need anything else in the menu setup to use the RS232 out? I got traffic on my IPAD, a SW airlines at 29k and a UAL at 30K.
 
Did a flight test after installing the Echo UAT, and upgrading the GNS430W to ADSB+. Tried to generate a report from the FAA website but got a message that the flight did not generate a report. Does the Garmin need anything else in the menu setup to use the RS232 out? I got traffic on my IPAD, a SW airlines at 29k and a UAL at 30K.

Well, you had to run a wire from a 430W RS232-out port to the Echo. Whatever port that was needs to be configured in the Garmin setup menu for adsb+.
 
Our install: Baro Alt failure on FAA ADS-B report

Just swapped out our EXP box with the combo from Uavionix/Dallas. We were using the TransMonSPE with the EXP due to our older G320A transponder, so we are using the wireless transponder code and pressure alt detection on the Uavionix. We are also displaying traffic and Wx on our MGL Odyssey G2 EFIS (wired connection).

I took the airplane for a test flight after configuring - a couple of times on ForeFlight, a nearby target looked like it was displaying MSL instead of relative altitude for awhile, but then it corrected itself.

Possibly related: the FAA ADS-B report came back with a 60% fail rate for Baro Alt.

With the EXP, I hadn't had a similar problem on the ADS-B report. I've filed a ticket with Uavionix, asking what they suggest for troubleshooting.
 
Baro Errors

Just swapped out our EXP box with the combo from Uavionix/Dallas. We were using the TransMonSPE with the EXP due to our older G320A transponder, so we are using the wireless transponder code and pressure alt detection on the Uavionix. We are also displaying traffic and Wx on our MGL Odyssey G2 EFIS (wired connection).

I took the airplane for a test flight after configuring - a couple of times on ForeFlight, a nearby target looked like it was displaying MSL instead of relative altitude for awhile, but then it corrected itself.

Possibly related: the FAA ADS-B report came back with a 60% fail rate for Baro Alt.

With the EXP, I hadn't had a similar problem on the ADS-B report. I've filed a ticket with Uavionix, asking what they suggest for troubleshooting.

Where are you located relative to the closest RADAR facility? You MUST be INSIDE the RADAR environment when you power up the ADS-B (because of the FAA Measurement methods). See my previous posts on how to circumvent this problem....
 
Thanks for your suggestion, Fred -

I think we're in ABQ Approach radar from the moment we take off - if not, it would be within 15s or so. My FAA report's 60% Baro Alt failure rate totals ~25 minutes...

After takeoff (field elevation ~5300MSL), I climbed right up to 10.5k+, receiving 2-4 towers at least until reentering the pattern to land, according to ForeFlight. I stayed in an area I think is well covered by ABQ approach and/or center radar.

I saw your earlier posts on turning the ADS-B on later in the flight to test, but my ForeFlight behavior on indicating traffic altitude was odd, and my FAA reports on the EXP flying out of KAEG had been clean, so I'm not sure if the radar is the issue.



Where are you located relative to the closest RADAR facility? You MUST be INSIDE the RADAR environment when you power up the ADS-B (because of the FAA Measurement methods). See my previous posts on how to circumvent this problem....
 
Thanks for your suggestion, Fred -

I think we're in ABQ Approach radar from the moment we take off - if not, it would be within 15s or so. My FAA report's 60% Baro Alt failure rate totals ~25 minutes...

After takeoff (field elevation ~5300MSL), I climbed right up to 10.5k+, receiving 2-4 towers at least until reentering the pattern to land, according to ForeFlight. I stayed in an area I think is well covered by ABQ approach and/or center radar.

I saw your earlier posts on turning the ADS-B on later in the flight to test, but my ForeFlight behavior on indicating traffic altitude was odd, and my FAA reports on the EXP flying out of KAEG had been clean, so I'm not sure if the radar is the issue.

If you're located at E80 or even E98, then you're too far outside the RADAR environment to get a good performance report. You might get a good performance report if you were to fly to AEG with the ADS-B OFF, turn it ON before taking OFF again, then fly around KABQ, land at AEG and turn OFF the ADS-B, leaving it OFF while flying THE REST OF THE DAY..... (FAA performance errors are accumulated over a 24 hr period!).

Hope that helps..
 
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.

If you're located at E80 or even E98, then you're too far outside the RADAR environment to get a good performance report. You might get a good performance report if you were to fly to AEG with the ADS-B OFF, turn it ON before taking OFF again, then fly around KABQ, land at AEG and turn OFF the ADS-B, leaving it OFF while flying THE REST OF THE DAY..... (FAA performance errors are accumulated over a 24 hr period!).

Hope that helps..

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.
 
Last edited:
odd situation wit flight ID

I have a customer who configured his uAvionix Echo with his N number and ICAO call sign.... but the flight ID showing up to controllers is his wi fi address.
Odd, has anyone else seen this? I have asked uAvionix and will post their answer here in case it happens to another customer.
Of course the compliance report from the FAA fails. I am waiting for a controller to ask him near Chicago... why he has his wi fi address on the scope!
 
quick response from uAvionix! wow

Nicholas,

There are three reasons why a pilot might see a callsign of PING-XXXX.

1. Anonymous mode is enabled.
2. The pilot entered an ICAO of all zeroes which is invalid.
3. The Setup Source in the app is set to EFIS but the EFIS is not sending a valid ICAO. We see this often with GRT where the MODE S code defaults to all zeroes.

Please let me know what the cause is. I apologize for the difficulty.
Best,
Ryan Reed
uAvionix Support
 
BARO Errors

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.

Interesting. But you stated that you had a 60% failure rate, meaning some (40%) of the correct altitude had been received correctly. So the echoUAT is working correctly some of the time (when it's being pinged by RADAR).

Try flying into KABQ with the ADS-B OFF, departing KABQ, flying around inside the RADAR environment, then landing at KABQ again, shutting OFF the ADS-B and flying back to KAEG.
 
A little concerned...

I myself am becoming a little concerned with how this box will perform long term. I've only flown it 2 flights yet, due to extreme cold up here, but here are some issues I see or am concerned about.

First, regarding Fred's workaround, I think that it's a major band-aid to take off without powering on your ADS-B system and then fly to that class B area for the testing. Sure, that can produce a 100% or nearly so, reliable test, but then it's not a real world situation. It's akin to using cliff notes to pass a test, but in the end you are just stupid, because you never did the homework. If your system performs 100% for the "test", and only 85% for the 10 years after, some day the FAA is going to come knocking at your door.

I've been working this past week with someone doing major data capture and processing of the output of these boxes and have learned a lot more too.
First, don't be surprised if you don't get baro alt, and you have no altitude encoder input. You may very well end up in situations on many flights when your system simply doesn't get this baro altitude all of the time, due to it not being sent from the transponder, or sent frequently enough. Same potential for squawk code. I don't see this as the biggest urgent issue, but it's just one that has me concerned with how the long term prospects of using the box will be. Coming from an ADS600B NavWorX unit, I had hard wired transponder codes, and hard wired baro alt. That really is the "better" way to do things.

But the differences get much bigger when you look further at the feature list:

First, the 2 serial ports are not asynchronous and you'll see in settings that you can't set a different baud rate for RX than you have for TX on a port. Originally I wired mine for GTX transponder control, 38,400 baud GDL90 out for the EFIS (both COM1) and then GPS NMEA in at 115,200 baud from the SkyFYX, and then hoped to output on COM2 115,200 baud GDL90 to another system. Right now, this in so many ways is simply never going to work, but, the ADS600B did it perfectly. The GTX requires 9600 baud, my EFIS 38,400 baud. You simply have to choose, which one do you really want. Of course, traffic on the EFIS, right? So there goes the hard wired squawk, and with the asynchronous issue, you will never have any way of getting in altitude encoder input either. The box is simply handicapped. We're flying behind boxes that were not built for GA, they were built for drones, and were adapted for just barely be suitable for GA if you can live with the tradeoffs. Output power is also less than the ADS600B. The 2 places it has the ADS600B beat handily are, DUAL FREQ, and a very convenient configuration interface with wifi. Other than that, when you look at the molex connector and things like MCX connectors, we're looking at something really not designed for our environment.

Second, and this I think is going to be bigger than people know today, is that this box is not going to necessarily serve you traffic alerts reliably. Here's why. The NavWorX ADS600B performed traffic filtering and sorting for you before it delivered it to your EFIS. This was for very good reason. #1, if your EFIS is handicapped by a baud rate limitation like mine is, you simply can't handle 50 intruders on your screen at the same time. Personally, I really don't think you'd WANT to anyway...if you had that many, you couldn't even read airport identifiers and airway designations and features on your MFD. There's a real limit to how many targets you would want to display.

#2 though is much worse. The traffic coming out of the EchoUAT is not at all sorted by distance, filtered to limit altitudes, or anything like that. The NavWorX filtered traffic to within, I believe +/- 8000' of your altitude. Having the airliner show 30,000' above you is not only unnecessary screen clutter, but if you aren't able to pick out traffic up close due to this clutter, it's a safety issue. Beyond that, since it's delivered UN-sorted to your EFIS, your EFIS may or may not receive the targets that are out there. GDL90 spec doesn't allow for multiple batches being sent, but that's what they're doing right now...sending one pile and if it is too much it sends some in a second batch. This can lead to missing targets, blinking targets, or other issues....but the worst of it is, since it's NOT sorted by range, you may very well receive 40 targets that are 60 miles away at the nearest class B area, but NOT receive the 2 that are 2 miles away from you, headed right for you in the practice area by your local airport. NavWorX specifically sorted it so that you would ALWAYS be delivered the targets in order, from closest to furthest, and only those that were real factors for you. THAT is the way it really should be done. It's simple software pre-processing to rework this data and serve it up in sorted order. I know, because right now a friend of mine is writing code for an interface box that can fix this mess...gathering up GDL90 out of the UAT, produce a list of traffic, sort the list, and transmit the list in sorted order. But this should be done by the UAT manufacturer.

So given what I see today, I think that Uavionix will need to step up to the plate a little and start working hard on their software and/or hardware, if they want to keep playing in the GA space. NavWorX played games with their GPS module, but had a pretty good box built, otherwise. They just needed to add dual-frequency ops and upgraded their GPS and it would have been fine. And in their case, the GPS issue probably from a functional standpoint never caused any real issue...it was a paper problem and a potential integrity problem. I always knew I'd have to replace the GPS module...I just wish they'd have stuck to their original plan of selling us upgrade modules in the future, as we were told back in the 2010-2013 time period. Hopefully Uavionix doesn't play rinky dink games with their systems just the same. If they don't address baro alt and traffic display reliability, I fear that we'll all be told some day that we have to buy yet another box, and re-integrate it all over again.

If you're on the fence about an ADS-B system, and have been looking at swapping transponders to the GTX345, that may be your one guarantee of getting a system that you won't later have to yank out. But, if Uavionix steps up a bit, hopefully we will get the performance we require.
 
(snipped...)
I myself am becoming a little concerned with how this box will perform long term. I've only flown it 2 flights yet, due to extreme cold up here, but here are some issues I see or am concerned about.

Interesting. I replaced my NavWorx 600EXP box with a GRT SafeFly2020 GPS/uAvionix Echo UAT combo because I wanted the serial port combiner feature of the SafeFly GPS. That said, the first thing I noticed when I started flying with the new equipment was traffic appearing and disappearing on my GRT EFIS around my local airport that I am sure would have been displayed constantly with my NavWorx device.

Likewise I was concerned during the install that I couldn't hardwire output from my GTX327 (that previously supplied the squawk code to the 600EXP) or altitude data from my GRT EFIS. I was assured by uAvionix that their wireless sniffer would be adequate, but now I'm not so sure.

I also noticed that traffic depicted on my iPad seems different. Lots of traffic far away, up close traffic also blinking on and off, even though they are high enough that they are surely being painted by radar.

I'll be watching this discussion with interest. Hopefully uAvionix will see this and provide some insight.
 
Back
Top