ADS-B Upgrades Continue
March 2018 ADS-B UpdateI'd like to start by saying a few things up front. First, I'm not the brains behind some of the great technical works that I'm about to speak of on this page. I am very lucky to have very smart friends. I am, however, tenacious at making products be what they should be, and am very insistent that we don't have to settle for second-rate quality in the products we put into our planes. If a vendor blows off something, especially a safety issue, I become even more motivated to make sure that everyone knows about it, and then to fix it...or make them fix it. What will probably come across on this page as slamming uAvionix is not really intended to be that, but to be insistent on what they need to make a better product. The more they resist product improvement, the harsher my tone becomes. To date, I've had only limited success getting these concepts planted with them, so I feel it's important to warn YOU, the builder, before you buy these products.
To skip to why I'm not a fan of my Echo UAT, (even though I own 2 and am flying with both of them) click here, but the rest may be interesting to you.
Let me start by a quick final summary statement that this page will basically point you to: You may want to avoid any ADS-B systems, especially the lower-end systems such as the Echo UAT until you know more about their GDL90 data stream. The issues I will write about here affect not just the Echo, but other systems such as the iLevil 3AW also, but where it becomes an issue is when you try to interface it with RS232 to your EFIS. If all you were going to do is use them on the iPad and were not intending to get any critical information, especially collision alerts, then your needs are minimal. But if you want reliable weather and traffic and warnings when you are about to be hit by someone, your standards need to be kept higher. If you are looking for a good ADS-B solution now in 2018, you have many choices. I used to be a solid believer that all light GA planes should go the UAT route, which transmits and receives on the 978mhz frequency, for their ADS-B solution. Unfortunately there were many manufacturer players who went the other route and pushed light GA planes to 1090mhz ES systems. The way it has so far shaken out is that supposedly 75% of all ADS-B installs use 1090mhz as the transmit frequency. Luckily most of the companies now support dual-frequency receive, which is an important thing as it gives you the ability to see any ADS-B equipped airplane in the sky, directly, without having their information repeated through a GBT (Ground Based Transmitter). This is in fact the one reason I purchased my Echo UAT, rather than just keeping my NavWorX systems in place.
My ADS-B history goes back further than most peoples, in fact. My first exposure to ADS-B was when Bill Moffit from NavWorX contacted me back in 2008, about his new ADS-B system. Here's a write-up of me testing his portable ADS-B system in my RV-10. He was fishing for planes to test it in, to ensure it worked well. I had/have a Chelton EFIS system in both of my airplanes, and Chelton was the very first EFIS to use ADS-B, back when the government funded the Capstone project in Alaska. So Chelton was ADS-B ready even when I first started flying my plane back in 2006. At this time, in 2008, there were very few GBTs in the US. One of the first happened to be in Oshkosh. That's an hour away for me. Also at the time, my only traffic system was my GTX330 with Mode-S, which worked great when you were by major class B areas, but, the feds were deciding to start removing Mode-S from their class B areas. So I was also planning ahead for how I was going to get traffic display on my EFIS. I had already been using WSI satellite weather for years, but traffic was important to me too. Anyway, if you read that link, you'll see that we basically quick set my Chelton up to not use WSI, I cut in an adapter harness for his ADS-B system and set the Chelton for ADS-B, and it worked, right out of the box. We had METARs, traffic, TAFs, and everything. I was thoroughly impressed. Back in these days, Bill was great to work with, too.
By May 2009, Bill had sent me an ADS600B system to install in my plane. I was one of his very early customers. He understood that I wanted to KEEP my WSI satellite weather, because Satellite weather is FAR superior to the free FIS-B weather that ADS-B provides. So, his box was built with an ARINC module to provide ARINC traffic output from the NavWorX. This was much harder for us to do than this simple statement would say. The Chelton uses a serialized version of TIS-A, actually more like the RYAN TCAD protocol, or more specifically the TCAS-I ARINC 735A format, except it's not sent over ARINC, but RS232 since my Chelton screens don't have ARINC input for traffic. So the interface took some work. I did many many test flights, logging and capturing serial data, eventually having to decode the data and learn how to descramble this digital HEX data to read ARINC labels or words. This was quite the process and took a lot of work. What we ended up with was excellent though. The Chelton used to require a DAC GDC34A ARINC to Serial converter box for the GTX330 to display traffic on the Chelton, and Bill was able to create a Chelton specific interface so that not only could we read IN the GTX330's TIS-A, but we could merge it with ADS-B targets and output it to the Chelton, without any converter box required. It was really cool stuff. He also took the time to hook up with other EFIS makers and learn their protocol requirements, to ensure that his boxes would work with other systems, including things like my GNS480. (Although I never used it on my 480) He was working his programming butt off getting these products to work for everyone. Later in 2009/2010 I did lots of data logging flights and serial analysis to learn the Garmin GTX transponder squawk change format, which would allow a person to hook a wire to their GTX327/330 and change the squawk on the NavWorX without having to use that transponder sniffer on the cable. Yeah, that was me that helped with that one...and it became a NavWorX feature.
I should tell you too that although the FAA made NavWorX look pretty bad, (as did the poor communication NavWorX was providing back in the 2014-2016 time frame), Bill was always up front with people. I KNEW that I didn't have a 2020 compliant system because of the GPS module. He was selling the ADS600BG that would be compliant, but encouraged people to go with the ADS600B for now, because down the road he was going to be able to order in bulk, a pile of GPS modules at a lower price that would allow 2020 compliance. His system was smartly a modular system, so you just needed the GPS module and you were good to go. I listened, and I believed. The problem was that none of us had a crystal ball. The good GPS's that provide the guts for things like the Freeflight 1201 and Chelton GPS are made by Accord Technologies. Accord got purchased by Aspen Avionics back in 2015. That's I think where this whole thing went sideways for everyone. Up until that point, Bill could easily order GPS modules, but now there was a new owner. As I heard later in 2017, the rumor is that the new Accord did not supply compliant modules or perhaps would not supply them, which is what actually sunk NavWorX. But back to my story.
Over time, NavWorX pursued the TSO'd market though, and things were looking pretty good for NavWorX. Their name was getting out there and they had a well made system that was suitable for certified planes as well as experimental aircraft. At that point, Bill removed the Chelton Specific interface from the box, when he was doing his TSO work. So at that point, I resorted to just having the ADS600B transmit ARINC traffic and I re-installed my DAC GDC34A to do the RS232 conversion so I still had traffic on my EFIS. I should say that I did approach uAvionix about this serial format but they had no interest in doing such an interface.
So then we came to OSH 2017. By that time, people were rightly getting a little pissed off at NavWorX. I understood why, too. NavWorX was subject to an AD by an irritated FAA who I believe should have done much better than they did. Bill knew from testing that the GPS used in his box met the performance spec (although lacked integrity monitoring), and he set his boxes to present themselves as having that quality of GPS when indeed they didn't because of the integrity monitoring. He was trying to find a way around this GPS module supply issue, from the best that I can tell. Anyway, at OSH, I was pleasantly surprised to hear that NavWorX would be all done with the FAA soon, we'd have our GPS modules, and even better yet, they would later on be pursuing dual-frequency receive operation in their system. When they were sent in for GPS upgrade, you got a whole new main board and that board was dual-freq capable. I was happy with that. But, by later in 2017, nothing was materializing and then the worst thing happened, NavWorX closed shop. My good buddy who helped me megatons on this project had been ticked off at NavWorX's communication that at OSH 2017 he purchased an Echo UAT. I myself went by their booth and checked out the system too, but was much less impressed than he was, although it did appear a viable option for the hundreds of Chelton EFIS users I know. I say this because it could do 38,400 baud output, and it was in GDL90 format. So, when Dallas Avionics intervened and worked with uAvionix to secure a replacement ADS-B System for orphaned NavWorX customers in late 2017, I decided I had to get on board if I was ever going to have a dual-frequency system, and didn't want to have to rewire my planes to use an external GPS for the NavWorX. Oh, I had forgotten to tell you, I bought a second ADS600B for my RV-14 when I built that, so I was doubly invested in ADS-B systems and that meant that by 12/31/2017 I had to buy TWO Echo UATs immdediately, to ensure I could get both for the discounted price.
Now that you have all the background, this is starting to be all current early-2018 information.
The Echos arrived and I started to install them. Sadly, despite many emails to uAvionix and calls to Dallas Avionics, I was never presented with the proper RF adapters for use with the Echo. They built the upgrade kit around the ADS600-EXP model and when I tried to tell everyone that the ADS600B users needed different adapters, I was thoroughly ignored again. Oh well, I bought some on Amazon so that I could get it all installed, as I could tell that nobody was listening. So the adapters you see here are mine, not what they provided. Future customers were able to get it rectified, after I told them to make sure to call after they received their systems without the right cables, and they had some shipped to them.
The Echo UAT box is very small, and very light. You'd think this is all good,but there are downsides. First, it's only a 20W transmitter, which is much less than the NavWorX was, and something like 10X less than the transponders will transmit. Second, the molex connectors are small and light but not durable and wire protecting. I initially had one of my pins push itself backwards out of the connector when I installed it, and had an unreliable GPS signal for a few hours that I had to troubleshoot. Third, the countersunk mounting hole style on the UAT is a pain in the butt. Fourth and more important, the coax connectors aren't what most people will use with any avionics systems they have in place. The UAT is so small that the Echo UAT uses an SMA connector, which is OK, for the transmitter/receiver. SMA I can deal with because it can still use RG400. But, you'll now need an SMA to TNC or BNC adapter for that wire. Also, since it's not a nice sturdy BNC/TNC bulkhead style connector on the Echo, any vibration and flex will transmit that flex into the echo. Some day that thing may not last if there is a lot of pressure on it. But the one that stinks more is the connector on the SkyFyx GPS that uAvionix sells. That is an MCX Female connector, so requires a MCX Male to TNC Female connector to adapt to your existing GPS antenna. There is no twist lock to the connector, and a good tug on the connector will pull it right out of the GPS. This connector I would not recommend for ANY avionics system for permanent mounting in an airplane. The one good thing I can say is that the GPS is very quick at acquisition. Otherwise, the small size, unusual mounting ears, and weak connectors can make for a harder install than the nice NavWorX box with built in mounting ears and D-Sub connector. I had to make a plate to mount it all on, and even when done it's tough to get the wiring bundle to be secured as well as I'd like. Also, as I said, the contacts in those molex connectors are a weak spot, as I had a wire that wanted to keep pushing itself out of the connector which led to GPS signal issues until I finally gobbed glue on the wires to keep them all together. In the end, I doubt there was much weight difference than the larger NavWorX box, due to the mounting plate, and not much space saved due to the multiple components on the Echo system. Having it all built into one bigger box ends up actually being a benefit, if you need all of the components.
 |
 |
 |
 |
 |
Here are a couple of pics of my replacement mounts for my systems. The top is in my RV-14. The bottom is in my RV-10.
You'll notice one special thing above the GPS in my RV-10, and that's a little black box. That's where some magic comes in for all of this that I'll be writing about more here.
 |
 |
 |
 |
After installing the Echo and getting it outside, I took iit for a test flight. I found that the wifi indeed worked thru the baggage bulkhead, and I could see traffic on Foreflight, WingX, and FlyQ just fine. The configuration is pretty easy with the web interface that the echo has. That's one more spot where uAvionix did ok. The one place they failed is on the firmware updates, when you have to go into advanced mode and select a different option for one of the firmwares. They could have made that more intuitive, and in helping other Echo purchasers, we all wonder why the menu couldn't be made simpler. Anyway, the system functioned.
What I was NOT happy to see, however, was that NONE of the traffic was restricted from being displayed...even on my EFIS. I didn't even need to get the UAT up in the air before my first disappointment hit, as once I saw this, I knew there were going to be problems. These pics don't necessarily show it, but if you look at some of the Chelton screenshots below you can see that I clearly see airplanes 20,000+ feet above me. More on that later.
 |
 |
 |
 |
 |
 |
 |
 |
 |
Back to getting this thing to work with my Satellite weather! So, if you remember, in order for me to have Satellite weather, I needed to use ARINC out on the NavWorX for traffic, OR, I needed to get the data in the RS232 ARINC format. What to do? Well, get a friend who's smart enough to take all the reverse engineered serial ARINC data stream info that I helped Bill do in 2009, and see if he can do it again using today's microprocessors. A Teensy 3.2 did the job nicely. All you needed was a TTL to RS232 level converter DB9 connector, a Teensy 3.2, and a regulated power suppy, and with the programming he did, we were able to take GDL90 output at 115,200 baud, process it into TCAS format, with a lot of other cool features at the same time, and spit it out to the Chelton at 38,400 baud as TCAS RS232 Serial ARINC format. We kind of knew that the days were limited for this system, because WSI may be stopping soon....and it did. But, it laid the ground work for our next project.
Below is our Teensy 3.2 box that did all of the magic. It was basically a prototype, and I would have been maybe the only person that ever used it. It was built cheaply, but did a fine job for a two-off system.
 |
 |
 |
Below for the top couple of pictures you can see a flight and some debugging of GDL90 to TCAS code. After those pics, however, we are testing the Echo UAT on the Chelton.
Here's where we found more Echo flaws. You can see the pics in the second row with the status screens up. The "ADSB MAINT" would sometimes fail, and cause a yellow flag on the EFIS. Read the stuff after the pics for more information on that, but it's due to the Echo UAT's "transponder monitor" feature not being perfect. Just because it can sniff the transponder, does not mean the transponder will always regularly send anything that it can sniff.
As we got into 2018 further, WSI went offline, changing the game for me. Once WSI was offline, we quickly reprogrammed the above Teensy 3.2 system to be a GDL90 to GDL90 converter/filter box. It would not fix the transponder squawk or Baro Alt issues we were having, but would at least allow us to knock off the error flag for "ADSB MAINT" and test whether or not we could successfully read in and spit out GDL90. As you get further down this block of pictures you can see some photos from a Bahamas trip where we had occasional ghost targets show up in our location, and you can see that the weather was passing thru our black box just fine.
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
With the Teensy 3.2 data flowing well, we decided it was time to fix more of the problems with the Echo UAT. Sadly, by this time, my buddy who was the bigger of the brains behind this, bailed out of the Echo UAT and sold his, and instead bought and installed a Garmin GTX 345. We were frustrated by the quality of the interface and programming, and since he had the means to just buy a new system, he ditched his a.s.a.p. I would advise most people to at least educate themselves, and ask all the Echo questions they can, and then also look at other systems, as well. Until you know the details, you may thing ADS-B is ADS-B, but not all systems are created equal. At least at this point we knew what we needed to do to be able to process a GDL90 stream in and out. But, to work around and fix the Echo's programming and hardware limitations, we had to be able to read in Baro Altitude from an Altitude Encoder, just like the NavWorX did, and also to read in the transponder squawk, just like the NavWorX did. Time to quickly learn to read a couple more data streams, and learn to output another. Fortunately, the ICARUS ALT format that I use on my encoder was an easy one to read in, and it's in ASCII format on the line at 9600 baud, so it's stone simple. The GTX I already knew because of my previous work with Bill trying to get transponder squawk into the NavWorX. What we needed now was to MERGE those 2 data types into a single input type that the Echo UAT could read in. The SL70 transponder offered the one that works, and that's Garmin's GDL format. That has both squawk and Baro Altitude in it. We also needed some additional serial lines to read in those 2 things and then one to spit them out. Those signals also were all at 9600 baud, whereas my EFIS needs 38,400, and the ideal output from the Echo is 115,200. So we needed 3 RS232 inputs, and 2 RS232 outputs. Time to build a better box!
Remember that the Echo only has 2 serial ins and 2 outs, and that you can only choose 1 bandwidth speed for each pair of ports.
The Teensy 3.6 offers more serial ports than the Teensy 3.2 did, has onboard SD card memory (which you don't need), has more memor, and an even faster 180mhz ARM CPU. My buddy drew up a circuit complete with power regulator and filter capacitors, 2 chip sockets that use the Max3222 RS232 chips, giving you 4 RS232 channels to play with. He also designed another version to work with one RS422 chip, and one 2-channel RS232 chip. Why? Because Garmin in their irritating proprietary "BUY ALL GARMIN" style decided not to put a GDL90 output format on their transponder that runs at 38,400 baud. So no, if you're a Chelton EFIS user, you can't just buy a GTX345 and have ADS-B in. In fact you will not be able to display ADS-B weather and traffic from the GTX345 on your screens at all with a stock system. But, if you have an RS422 to RS232 converter that also baud rate shifts, you can make the magic happen. The GTX345 will output it at 115,200 baud on RS422. So the RS422/RS232 box can then read in RS422 from any source, convert it to RS232, process the data as necessary, and spit it out on the wire at 38,400 or any other baud rate you desire. So it's a multi-function fix-it box for ADS-B. You can see he designed it all to fit into a nice aluminum case, too. So below are photos of the original prototypes that went into my planes. We've been flying them for months in both of my planes, and I have tested the software with the Echo as input and the Chelton as the display. Since it's standard GDL90, any display that needs GDL90 format should work with the box. Previously, I had flown the same software without transponder and altitude encoder inputs and outputs and that worked fine, and the addition of those features is separate from the GDL90 stream and also has also been tested and works.
This is the circuit board, made through http://www.oshpark.com but designed by my buddy.
 |
 |
 |
 |
 |
 |
 |
To the Left is a
screenshot of my echo UAT monitor page after I hooked it
up. My altitude encoder is feeding altitude to this
box via 9600 baud ICARUS format, my transponder is feeding
it squawk in GTX format at 9600 baud, and the output is
9600 baud GDL format into the Echo UAT's COM Port
1. COM Port 1 is configured for control panel
type EFIS control of the UAT, and COM 1 transmit is not
needed. COM Port 2 is configured for 115,200 baud Traffic and weather output of the UAT, which feeds into this filter box, where the traffic is coasted, and filtered by altitude and distance. I am currently using 80 miles as the filter distance, which would normally be a bad deal because the EFIS would be flooded with targets, but, since this filter sorts and filters and transmits only about 20-25 targets (depending on preference) and transmits the closest ones first, and follows GDL90 protocol specs, you always will see all of the nearby targets if they are being received. So no more flooded RS232 lines that are overflowed at 38,400 baud. The filtered GDL90 output can be configured for whatever baud rate you want, but for me it's set to 38,400 baud, so my EFIS is plenty happy with it. It also sends all of the weather packets in a timely manner as well. The only reason I don't have Lat/Long showing up in the screenshot is because the airplane was inside the hangar. It also adds collision alerting, which you'll be reading more about below. |
|
 |
 |
 |
 |
 |
 |
 |
Once you have the board built, you want a nice box to put it in, and he found a nice aluminum box that it slides right into with no effort. The ends were then cut for the DB15 connector and on the opposite end a hole was made for the micro USB connection that is used for programming the box. I created a label for it, with the pinouts, and have them labeled so I know which airplane they go into. It's important to have them programmed for your specific plane because the de-ghosting filter relies on having your ICAO code to never list you in the traffic table if the Echo happens to pass your ICAO code accidentally. There are some parameters that are user configurable in the software, but it needs to be programmed using the micro USB cable with a PC that has the programming software on it. (Freely available) |
|
Public Release of the Box Hardware
As of 7/5/18 the board design is now available. Here are some pictures of the the box assembled. Since we started the project we have tweaked a few things, one of them being that I went to ceramic capacitors that have high tolerance specs for the RS232. There was no issue with the electrolytics, but these are more compact and very nice. After fixing another issue, we found that the Traco regulator likely would have worked ok for us, since we had filter capacitors in the circuit, but we switched to a horizontal Murata regulator for good clearance and because the Murata hadn't been reported to have any issues with the Teensy 3.6. The original board also incorporated RS422 capability if you left out one RS232 chip. That board is still available for people who want RS422 capability, but is a bit tighter packed than this board is, because another 16-pin IC is shoehorned in there.
 |
 |
 |
 |
 |
For more information on building your own, see my write-up on "The Box"
Why I'm Not a Fan of my Echo UAT
Ok, so maybe you didn't read the stuff between the top and here, but here is why I don't like my Echo UAT as a solution for ADS-B. Now that I've "Fixed" most of the issues for myself, it's really actually an OK box for me, but I still dislike the way the Echo was programmed and designed. I want any built-in avionics that I install to be built to the highest standards just like the mainstream companies would provide for certified planes. I also have no good method to improve the output power of the transmitter, so I'm still limited in wattage.
The Echo doesn't do much more than blast out anything it hears. And it doesn't do it necessarily in a standards compliant way, at least not when you compare it to the GDL90 spec document that is available online.
First, if you're hearing that other users of the Echo "get a perfect score from the FAA Sniffers", you aren't reading all of the forums. There have been plenty of people, including myself, who have had red boxes on the report. I don't think I've had a flight yet that didn't have at least one red box. But yeah, you may end up passing the test for ADS-B Out with the Echo, especially if you test it like they want you to....fly to an area within the Class B rings with your ADS-B circuit breaker off. Then fly around with it on, and turn it off before you leave the area. If you don't do that, you may not get a clean test. I would prefer that every packet that I transmit to a GBT passes the test, or at least at a very high rate, consistently.
The transmitter power on the Echo is I believe 20W. Correct me if I'm wrong. Compare that to NavWorX being 45W if I remember correctly, and ADS-B transponders being much higher. (200W in some cases, I believe) Why is this important? I believe when your beacons are not heard well by GBTs, especially if you are in fringe areas, it may help lead to ghosting (shadows) of your ownship target. Ultimately the wattage should work most of the time, but, you're really at the bottom bottom end of the power scale with the Echo compared to other units out there.
Next, the software processing of targets and the way it's transmitted on RS232 leaves a lot to be desired. To be standards compliant, you should send all traffic targets in one packet. But, they do zero filtering on their traffic from what we could tell, which results in an overwhelming number of targets. Enough that it can make it almost impossible to display them on on RS232 with some bandwidth restrictions. There's a practical limit to how many targets you can transmit over a serial link, and additionally, the more you send the more CPU your downstream systems will require. Why is this a big deal? Because, you're out there flying trying to keep from hitting someone, and your EFIS is going to be cluttered up with dozens of unnecessary targets, obscuring the map, and airport info, and making it hard to read. EVERY target that displays on the screen eats up mental cycles when you view it and your brain processes it, too. So especially when flying in high workload environments, having dozens of non-important traffic targets displaying turns into a real safety issue. On an ipad, not so bad because you can just pinch zoom at least to some extent and work around it, but in a high workload environment you don't have time to play with the iPad anyway. But to try to display an unlimited amount of targets on an EFIS just plain stinks. The Echo breaks GDL90 standards by splitting excess targets into a second packet. Oh, and while some brands of EFIS can filter targets (and I applaud them for trying to correct this data stream), some can't. But, that doesn't mean that the EFIS maker will still be happy, because the bandwidth used by all of this may still cripple their systems. Baud rate is important. If you support 115,200 baud, you'll be better off than some systems, but you just should not blast every target out the wire that the radio can hear. And even 115,200 can't handle as many targets as the receiver may pick up in a saturated environment. Clutter is a safety issue.
Now, here's an important one. NavWorX, for example, pre-processed their target list. You also had the ability to limit the number of targets that you would send. Maybe 12-18 or maybe even 20 or so would be a good practical number on an EFIS. If you watch the serial data stream, (which I did) you will see that NavWorX sorted them out for you by distance from you, so that you always saw the nearest traffic. If you were flying 50 miles from a class B airport, you would NOT miss the guy 1 mile off your nose, because he was sent first, but you may not see the 20 planes landing at KATL or KMSP for instance. No big deal if you're still 50 miles away from those planes, but you NEED to see the planes that are closer enough to be a factor. The Echo does not appear to do any of this. They simply send a random scattered pile of traffic and when its too full they dump more into another packet and keep trying until the serial line just can't even handle it anymore. They may indeed send you all 40 planes by KATL, and 20 more surrounding at other airports, and you may NOT see the plane that's 2 miles away because the line was too full to see him. So you may be missing out on the one guy who could run right into you. If you prioritize by distance, and limit target count, you can drastically decrease the load on the RS232 line, and not miss that critical target.
Another one that I feel is a safety issue: The low end systems don't limit traffic at all by any bounds of altitude. You have a hard enough job as a pilot keeping track of these 50 or 60 targets (my buddy saw more than that his echo being sent over the wire while we were programming around these flaws). When you are sending every airplane in the sky, and laying it on your EFIS, you will get to the point where there are simply too many planes to keep track of that it's a safety problem. Now, throw into that mix that they're going to send you that Heavy jet at 37,000' that's 1 mile from you, but way up high while you're at 2000', and you've got a distraction that can lead to a safety issue. No, it probably won't cause your EFIS to alert because the altitude is off, but again, all that added clutter to your screen is a real safety issue. NavWorX displayed traffic bounded by an altitude range, such as ± 8000'. On my box that we built, I did +5000 -10000 so I could see traffic at destination airports if I were going to descend and land, but if that proves too cluttered, I can easily cut it back. NOT putting some bounds on the traffic will really just cause clutter. Open up planefinder.com once and zoom out and see how many planes there are in the sky, and FlightAware and PlaneFinder and FlightRadar24 don't even show most UAT planes. You don't need your EFIS to look like that. uAvionix seems to think that "your EFIS can filter it", when in reality the situation is SOME EFIS's can filter it...others can't, but it's still not good to try to jam all that traffic on the wire. The goal is to have Avionics makers deliver high quality products that live up to high safety standards, like what you would find in certified boxes. The only real difference a non-certified system should have is that it doesn't have the proper label on it to be certified...but there's no real excuse for not operating to the same high standard as big avionics makers.
Want one that will make your skin crawl?
The Echo UAT does not use the "Traffic Alert" function as far as I can tell. What does this mean? How would you like an ADS-B system that shows traffic on your EFIS, but does NOT alert to any traffic even when you're about to run head on into it??
While doing a recent test flight, I tested the traffic alerting and flew near another airplane that was rolling out on a turn. We were within 200' of altitude and nearly head on. We both banked Right, avoiding each other, and he passed off my left close enough for me to see in the cockpit, maybe 500' away. There were no traffic alerts given. If you read the GDL90 Spec, you'll see that there is a "Traffic Alert" mode and "Pass-through" mode. Check section 1.3 for starters. Why would any built-in ADS-B system not do this? I don't think my iLevil 3AW does this either, but that system isn't connected to my EFIS and is only for backup AHRS and data for my iPad in case of major failures. I certainly have not seen this advertised to customers as "We do ADS-B but we don't offer collision alerting". I would think that would be something that should be pointed out very clearly before people purchase a system. I'm sure you can work programming in the EFIS and work around it, if you have to, and AFS and GRT probably do, but this is a function that the traffic system should be doing itself. It was a built-in feature of the NavWorX, for example. Also, a friend just installed an NGT-9000 transponder and his does all of this with voice callouts and everything. This is a huge shameful safety issue to not offer collision alerts, especially if you don't tell people that you aren't offering them.
Signal reception. When doing our work for the filter/processor box, we logged a lot of GDL90 and watched a lot of planes in the sky. We compared the echo to the Straux home made system (actually a FlyQ Merlin) and found that the Stratux actually had better reception than the Echo. I could consistently pick up airplanes further away with the Merlin, from the ground.
Blinking targets. One thing that many people have seen is that the Echo tends to lose targets on the screen. One second the guy will be there near you, the next it blinks out and disappears. I've watched the airspace during flights with an un-processed Echo UAT output and seen class B areas where for a few seconds I will see most airplanes to the North of a class B airport. Then suddenly they blink out and a second later I may see a bunch to the SOUTH of the airport. They come and go, back and forth. I wonder if that would happen if they weren't trying to send too many, and they properly trimmed the list. It even does this when viewed on iPad. There have been software updates that have helped this a little, but if you want a rock solid box, look to the bigger companies. I'm not sure if the blinking targets is because of the RS232 interface being overloaded, or because of the reception being weaker, but it could be some of each.
Also, some boxes coast traffic to a small degree. The NavWorX did. Coasting done weakly is keeping a target on screen for a few seconds (maybe 5) after it drops from reception, so that you don't immediately lose it. The hope is that it will be reacquired and you will soon have it's new position. Coasting done well can look at that targets altitude, and altitude trend (vertical speed), and speed, and heading, and try to calculate for 5 or 10 seconds where it is going to be, and keep updating it's position so when it does reacquire it's likely where it should be, and you always know where that
approximately is. Coasting helps fix blinking. The UAT vendor will again say that they don't coast but the EFIS can do that job. Again, sure, SOME EFIS's can, and some can't. I would think that as a vendor though, a good vendor will attempt to make sure it'll work for everyone.
Poor connectors: The first day I went to fly with my echo, I had a hard time getting GPS to stay locked. I tracked it down to the cheap molex connector and contact where the contact pushed itself part way out of the molex. A mainstream avionics company would put a quality robust connector on their product. Something with screws or thumb screws or slide lock, and strain relief on wires. The molex connector is cheap, and light, but not robust. I glued my wires to the molex now to prevent pins from backing out, and create a strain release, but it's still just not made to the same quality standard.
After taking a long trip of just under 3000 miles of flying with the Echo. I had ghost targets in many areas in Florida and Atlanta, and some other places in the middle of the US. They'd show up right under your own position. We can tweak the software in my filter box to process them out of my data stream, but it's an annoyance that only RARELY happened with NavWorX. (although one of the areas I did have issues was by KATL which was the same with the Echo).
Here's another big one: The NavWorX had an input for Altitude encoder data, and an input for transponder squawk data. If you have both of those, any change in squawk or altitude gets transmitted immediately. The "transponder monitor" method of Echo CAN work, but, it has limitations. If you are not under a radar covered area or your transponder isn't interrogated, it the Echo has nothing to listen to for baro alt. After a while it'll stop sending baro alt. That happened to me a lot, and when I'd do an FAA report on the UAT, it would show lack of baro. In fact, it's worse than that. My EFIS monitored the "maintenance issue" flag of the UAT. The Echo would, after a few seconds of not hearing the transponder, start sending packets with the maintenance flag lit. This caused my EFIS to pop up a yellow flag that read "Aux Sensor" letting me know there was a problem with some system (in this case the UAT). As soon as my transponder was interrogated, it would broadcast, and the Echo would hear it and update the baro, and the flag would go away. But, it routinely set that flag many times a minute, and maybe every few minutes when at lower altitudes I'd get the flag on the EFIS. Well, the last thing I need is to have ATC give me a squawk and not see that I changed it on the UAT, or not be reporting proper baro alt to other planes around me, so it's kind of a safety or functional issue. Luckily my filter/processor box can fix this issue for me too.
Now, Uavionix recently came out with a new "harness" that can help with some of this, but the harness, at least as I've had it described to me, is basically another little computer that can help merge these signals. The issue is, the echo has only 2 serial ports. Serial 2 will be for your GPS in, and the baud rate has to be the same for any serial device that you try to use serial out for. In my case, it was 115,200 for GPS, which limited me to 115,200 out on that port. My EFIS requires 38,400. Ok, so I can use COM1 for 38,400. Great, but, if you want GTX in for transponder squawk, that's 9600 baud. You can't have mismatched baud rates. Oh well, I'll just output GDL90 at 38,400. Done. Well, now I have a UAT with no hardwired squawk input or Baro input, and I'm FORCED to use the "transponder monitor" function, which I found to not be that reliable. See, those asynchronous ports are really a big limitation. If I had an SL70 transponder I'd get all that data I'd need, but wouldn't have an additional serial port on the UAT to use the proper bitrate for my EFIS.
To deal with that issue, the box that my friend and I built (above, the silver box) will take GTX transponder data in on 9600 baud port, and it will also take ICARUS altitude data in another 9600 baud port. It then uses the data from those 2 items to build and transmit the GDL format that the SL70 uses which contains both Altitude and Squawk/Mode information. That is a format that the Echo CAN use, and feeds it in COM1. It also receives the WX and Traffic in GDL90 format from the Echo at 115,200 baud on COM2, and then filters, coasts, de-ghosts, and sorts all the traffic and then sends it out to my EFIS at 38,400 baud as required, using the GDL90 format again, compatible with most systems. So, with a few hundred man hours in design and testing, programming, and electronics assembly, we were able to work around most of the issues other than the weaker 20W transmitter and possibly weaker receiver of the Echo. That said, the receiver seems to work OK for me most of the time. Still, I would think that for most users, they're going to want the whole package of features and reliability and everything that one of the more mainstream transponder type systems would provide, so after my experience, I personally don't recommend that anyone cut corners and go for low cost anymore when shopping for ADS-B. For years, I was never a fan of everyone going to 1090mhz OUT, but am now a convert at least in concept. At this point, 75% or so of installed users are transmitting on 1090mhz, and since the market went that way, I think it makes sense to AT LEAST have dual channel receivers in any system you buy. The Echo does meet that, which is the ONLY reason I am not using my NavWorX boxes today. (I own 3 of those as well...want to buy one?). So now I have a cheap solution that works, but, I'm less than thrilled about having that quality in my plane and I'll be starting to save and wait for the next great discount or deal on a new transponder such as the NGT-9000, which due to it's more standards-based approach works with most things, OR, a Garmin GTX345 and then add on my converter box because due to the lack of 38,400 baud RS232 GDL90 data on the GTX 345, I'd have to use the converter with an RS422 chip to take the data I need out using RS422 and get it to my EFIS. Garmin shoots themselves in the foot sometimes by trying to lock you into buying MORE Garmin. Besides that, the NGT-9000 just plain rocks as a transponder, and integrates easier for me.
The echo does have a convenient config interface, which I think they did a real decent job on, and the wifi system does work well, even though it appears to be based on the ESP8266 Arduino based wifi chips. The only complaint with the Wifi is that it would be much nicer if I could configure my own SSID for the system, along with security. So far I don't think that's possible. With my NavWorX wifi dongle I was able to change my SSID, my IP subnet, and add security. So consider that if you use the Echo UAT, at least the way it was when I bought mine, that anyone listening to it can not only receive your data, but RECONFIGURE your UAT and make it not work for you anymore. Pretty cool, eh? I wonder if anyone at AirVenture will be roaming around with their phones looking for SSID's starting with "Ping" that they can reconfigure. Man that would be a nasty prank. Any company these days that would put no security option on their product should be publicly shunned and flogged.
I was told by someone once that they didn't need to buy the Cadillac. Well, It's not that it's not a Cadillac. To me it feels more like a Yugo, and a Yugo that has mechanical issues. Even the Garmin GTX345 is not a Cadillac. It's a fairly normally priced transponder. My GTX330 wasn't much different when I bought it years ago. The GTX345 is even nicer yet, and you can get it with or without GPS built in. Too bad it doesn't have the right baud rate to use with my EFIS. (Gee, thanks Garmin) If you want the Cadillac, the NGT-9000 fits that bill and it comes with GPS built-in, but is also available with diversity antennas and even active traffic integration. Now THAT would be a cadillac. Even the most basic NGT-9000 would be plenty good for me.
If you do get a an echo based system, you may want to consider buying the Dynon version of their new UAT. From what I hear, they worked for months with Uavionix to get theirs to perform to their standards before they'd start selling it. The guts are largely Uavionix based, but some things may be improved. I don't have any first-hand experience with it, however.
So to recap, this is what it appears I'm finding with my Echo install, at least at the time I bought and installed it.
This may actually be a very good way for a lot of people to go. If you're already committed to an all-Garmin panel I'd just do a GTX345 for interoperability purposes, but if you're not, this is possibly the best transponder out there for you. It's available in a few different models with and without diversity antennas and with and without active traffic. The lowest model they have is still a tremendous transponder with a built-in GPS that will definitely satisfy the 2020 mandate. The biggest downside is they do not offer it WITHOUT a built-in GPS, which puts the cost in the higher $4000's. But, if you get this system, you get one that operates with GDL90 out, at many baud rates including 38,400bps, and it also has a nice touch screen display that displays weather and traffic on screen. There is an ipad app demo for it and if you play with it, you will be hooked. If you have only 2 EFIS screens, this is an especially attractive way to go, as it gives you some Nexrad info available constantly even when you are viewing perhaps engine gauges on your EFIS. It does have wifi available, via a wifi module that appears to also just be taking a 115,200bps GDL90 stream and "Wifi-ing" it, exactly as NavWorX used to do, so you CAN use it with FlyQ, WingX, Aerovie, Foreflight, FltPlan Go, or the other popular EFB apps. There is only one other downside and that's that it's about .10" taller in the bezel than the other transponders, so in order to fit it in your panel you may need to vertically enlarge your hole where the mounting tube goes, at least slightly. So if I ever upgrade again, it is likely to be to this transponder.1) Does not limit traffic to any distance or altitude around you
2) Does not alert to traffic when there may be a collison
3) Does not follow published standards for GDL90
4) Transmitter Power is only 20W
5) Can't run RS232 ports at Asynchronous speeds -or-
6) Too few RS232 ports available to do all necessary functions
7) No collision alerts and no filtering or sorting make me feel that it isn't built with safety in mind
8) uAvionix leaves EFIS to do filtering but many EFIS systems can't
9) Weaker signal reception than some systems
10) Traffic targets "blink out" occasionally
11) No Traffic Coasting option
12) Lower quality and Less-robust connectors than some systems
13) That darn MCX GPS connector
14) Poor Baro Alt operation with Tranponder Monitor Mode (also, receiving the maint flag)
15) No security on their Wifi, and no user-changeable SSID
16) non-integrated GPS and odd footprint makes for messy install in some cases
Now, a product is generally not all bad, so here, I'll try to balance it out with what they do right:
1) They do at least offer various baud rates
2) They have a good configuration interface via ipad/iphone app
3) Software upgrades are very easy enough, but could be made even easier
4) Monitoring page to see if your GPS position, Baro Alt, and squawk work is nice
5) System isn't overly large, nor hard to install
Basically, if they did a lot more work on programming, and threw it all in a nice package with D-Sub connectors with gold pins, and SMA or TNC connectors on it, it would be a much better system. But NavWorX from a hardware perspective had that and it appears to have been all done to a higher level standard than the Echo UAT is. The biggest thing it lacked was a TSO'd GPS, and dual-frequency receivers. Until removing the NavWorX and installing the Echo, I didn't have nearly the appreciation for the actual quality of the hardware and software that the NavWorX provided. uAvionix seems to be leagues behind on both fronts yet. I sure hope they improve things for their other products, but until I test one first hand and see the data they put out, I won't believe that other products they make are any better off. This one left a bad taste. As a non-EFIS integrated system to be only used with an iPad, I'd say it would actually be ok.
What about Garmin's GTX345?
Garmin's GTX345 is a common solution for many people. It would work for a lot of users, but, here are some gotchas. First, if you're a Chelton or non-Garmin EFIS user, you might be out of luck depending on your needs. These transponders don't offer an interface with Nexrad weather and traffic, in GDL90 format, at anything but 115,200 baud RS422, especially if you want CONUS Weather. In my case, I have a Chelton EFIS that requires 38,400 baud RS232, so this one is a non-starter without building some sort of converter box for it, or buying an RS422 to RS232 converter.
Now, once you get done, be aware that although it works with ForeFlight with Bluetooth, it does NOT work with Wifi, so I don't belive it will work for FlyQ, WingX, Aerovie, FltPlan Go, or the other popular EFB apps. I may be wrong, but learn that up front. In short, Garmin once again made themselves look bad by trying to be proprietary.
What about the Lynx NGT-9000?
I have a friend who just installed this transponder. He absolutely loves the transponder and the traffic and weather are awesome on it. He says it even calls out the traffic direction such as "Traffic 11 o'clock high 2 miles" due to it's "ATAS" function, and does many other great things. He said METAR and TAF info is easy to use on it, and everything functions very simply. Despite outputting it's serial interface via RS422 to the Chetlton which uses RS232, it works great. This is per their Aspen connection diagram in the install manual. So, if you are planning to buy a GPS equipped GTX345, this should be good motivation to drop that idea and go with the NGT-9000 as the prices are currently not that far apart. Why settle for "just a transponder" when you can have a nice one like this!?!
GDL90 Spec
Now back to the GDL90 Spec stuff I mentioned. If you read this GDL 90 interface spec manual and you know what the Echo is doing, you will find many things that are not per the spec.
Check out this paragraph on bandwidth management:
"The GDL 90 application software limits the use of the data interface to 90% of the maximum
capacity. For example, with 38400 baud, and 10 bauds per byte (1 start + 8 data + 1 stop), this
gives 3,840 bytes per second. Ninety percent of this value is approximately 3,500 bytes per second."
It continues on with some of the message limits , and other good things.
How about traffic sorting??
"The proximate Traffic reports are prioritized on the interface by range proximity to the ownship
position. Proximate Traffic reports can be either for non-alert targets when the "Traffic Alert"
interface is in use, or are normal targets when the "Pass-through" interface is in use."
What about how they just Vomit the traffic targets out over RS232,
even though RS232 can't handle the volume,
especially at reduced baud rates such as 38,400 baud?
"When the Traffic Alert interface is in use, a Traffic Report message is output from the GDL 90
in each second for each alerted or proximate target. The Traffic Report message is defined in
Table 7. Reports are output for at least 32 targets, up to the maximum number that the interface
can support (depending on the baud rate and the Uplink configuration)."
So there you go, they spec varies the target count based on the bandwidth of the interface. Echo doesn't...
What about coasting?
"A Traffic Report is generated for each tracked target every second, as long as the target is
identified by CSA as a priority target. If no ADS-B message is received for a tracked target, an
extrapolated report is generated for that target. Each target is extrapolated until its track is
discontinued by CSA."
So, you figure out how to extrapolate your targets for a short period if they disappear for one of the 1 second reports.
Funny, that's fairly primitive and yet Echo doesn't do it.
And why no traffic alerts, when the data fields support it?
"This is a 4-bit field "s" which indicates whether CSA has identified this target with an alert. The
following values for this field are defined:
s = 0 : No alert
s = 1 : Traffic Alert
s = 2 through 15 : reserved
MFD Recommendation: The Display should depict targets for which a Traffic Alert exists using a flashing yellow traffic symbol.
Traffic Annunciation: An increase in the number of targets that are in the Traffic Alert status should cause an audible annunciation."
So, the system should send traffic alerts, but then when the alert flag is set, the MFD should alert on it.
But, it can't alert on it if it isn't set by the UAT, but Echo doesn't send that...
CRAZY!
Read the spec thoroughly and you find a lot of places where the low end ADS-B systems will fall short.
That's why I'd advise if you want real avionics features, you may want to look into one made by any of the companies that have many years of experience building things for certified airplanes.
These seem to be not ready to be in the same market, maybe fine for displaying on an iPad, and similar in quality to just installing a D-I-Y Stratux system with a transmitter. It's maybe more comparable to a product such as the the iLevil or other systems NOT designed to be interfaces to EFIS systems, but not nearly the quality level of systems built for panel integration such as NavWorX was, or FreeFlight, Garmin, L3, or the real players in the avionics market would make. I'm sure it's a big shift in mindset from making ADS-B for drones, to making ADS-B for panel-mount and installed avionics. Hopefully they can make that shift so they can survive in the avionics market.
Now, for more information on "The Box" we built, that will be going open-source so you can fix any of your low-end ADS-B systems as well.
Site Home | MyRV10.com