The Box

I.	Introduction
II.	The Hardware
III.	The Shopping List
IV.	Assembly
V.	Programming
VI.	Wiring Connections
VII.	Uploading Code
VIII.	THE Code
IX.	Traffic Alerting Algorithm
X.	Required Setup
XI.	Integrating "The Box" into your Airplane
XII.	A word about the project

Introduction to "The Box"

What's inside "the box" that I'm using to fix the Echo UAT's crappy software, is a common question I've been asked. First of all, it's a lot of blood, sweat, and tears, and a pile of 100LL. The blood, sweat, and tears came from my buddy who was constantly programming and tweaking things, despite him officially ditching his Echo UAT and selling it early into the project, due to it's horrible software. It seemed that every time we got further into things, we found yet one more thing that made this Echo far inferior to any of the true "Avionics" that we had prior experience with. While I completely support his decision to get rid of his Echo, since I had 2 airplanes that I purchased the Echo(s) for, and the equipment cost being so high for getting what I *really* want, (A pair of Lynx NGT-9000 Transponders) it wasn't a financial option for me to join him. If I were made of money, this project would have never continued. But since he was willing to see it through and fix as best we could, my "dumb Echos", we pressed on. The project initially started as a fun project...to take GDL90 output from the Echo and turn it into TCAS format, serialized for RS232, to use with the Chelton EFIS. We not only did that, but we added some very cool features along the way. But, once WSI was no longer working for satellite weather, that whole box got scrapped and we started working on a way to massage the GDL90 data stream into something far better than the digital vomit that the Echo puts out.

We realized right away that this was going to involve many of the same steps and similar code, but that once we were headed down this path, there was a lot more we could do with it. For instance, with my Chelton EFIS requiring 38,400 baud, and the GPS for the Echo requiring 115,200 baud, that meant we were unable to utilize the Echo's transponder squawk input function to ensure that squawk was a directly fed item into the Echo. Hmmm. We also knew that with our "box" we would be re-processing all the GDL90 output and then sending it on from our box to the Chelton EFIS and could downshift the baud rate as necessary. That means that we would NOT need to run any ports on the Echo at 38,400 baud, freeing us to use 9600 baud for tranponder squawk and/or altitude input. Coincidentally, at the same time we were getting started, uAvionix emailed me saying they now had a "harness" that could fix many of these issues. I emailed them back, telling them my intentions as well. The issue is, if you use their harness, while the Echo can be improved, it's still not acceptably improved. The reason is, their "harness" is an active computerized device that also reads in altitude encoder data, and transponder squawk data and merges it, and sends it to the echo at 9600 baud. But, that still leaves me high and dry where I don't have any output port for Traffic/Weather that could run at 38,400 baud. But with OUR box, you could. Here's how that works. Unfortunately the GTX327/GTX330 transponders don't output Baro altitude on their serial line. If they did, things would be even easier. BUT, the old SL-70 transponder (thanks to Apollo's superior thinking to that of Garmins), did output both on the same data feed. And of course your Altitude Encoder feeds baro altitude to your Transponder too. In my case, the interfaces were as follows: ICARUS format was used to send Altitude data to the transponder (and my old NavWorX UAT). GTX format was used to send my GTX327/330 squawk information to my NavWorX UAT. Our 2nd/3rd generation of "the box" added the choice of either: [2x RS422 (2 RX + 2 TX) + 2x RS232 (2 RX + 2 TX)] OR [4x RS232 (4 RX + 4 TX)] channels in and out of the box. That meant that in my case, we now had 4X RS232 inputs....enough for 1) ICARUS Altitude, 2) GTX Transponder, 3) GDL90 Input. We also had 4X RS232 outputs, but only required 2.... 1) GDL90 Output to EFIS, 2) GDL (SL70 format) Transponder data to the Echo UAT. So all we had to do to feed the Echo the baro altitude and GTX squawk code was to be able to read in and process the GTX and ICARUS data, and then convert it to SL70 format ouptut. The GTX format is proprietary, but I had decoded that 8-9 years ago already, and knew how to read the squawk on the line. The ICARUS format is easy to read in text format. The SL70 "GDL" format is published in the SL70 install manual. And of course the GDL90 data format is a long published spec. So we had everything we needed to make this box do what we wanted.

The Hardware

Looking at the hardware, it's actually fairly simple. The brains of the box is the Teensy 3.6, an Arduino type processor using the 32-bit 180Mhz ARM Cortex-M4 processor with floating point unit. (We have been slowing the CPU down to 120Mhz just to not overclock it) It's a very very high speed processor and can handle way more bandwidth and data than we would ever be throwing at it. We had used the Teensy 3.2 on our original boxes, but the Teensy 3.6 was required in order to have 4 total serial ports. It has an on-board memory socket (not needed), and an on-board Micro-USB socket (required for programming). We bought the version that uses header pins, so that the entire module could be pulled out and swapped, should it go bad. That wouldn't really be necessary, but I'm not one to solder something in permanently if there's a chance it could fail.

The Teensy 3.6 uses 3.3V logic on it's serial ports, which is TTL signal levels. (It is NOT 5V tolerant on the pins, other than VCC) In our 1st Gen box for TCAS, we used a simple all-in-one 9-pin DB9 connector with built-in TTL to RS232 converter on it. That worked great. But for this project, needing 4x RS232 ports, we decided to use the MAX3222EEPN+ type IC chips that do all of the level conversion for you. All you need to do TTL to RS232 is a couple of these IC's, some associated capacitors to massage the voltages and run the charge pumps, and a power regulator. The power regulator did take us a couple of tries to get just right, but only because the teensy 3.6 has an issue where you need to run it with a very fast DC/DC converter or the thing will have a tendency to not boot up properly. It sees the voltage rise and starts to boot and if the rise is too slow it just doesn't work right. Later we ended up using the Traco Power TSR 1-2450 5V DC/DC converter, which was plenty fast. It hooks directly to 14V in, and converts it to a stable 5V for the Teensy to run on. But then we heard rumors that the Traco, if you don't use input capacitors, can end up acting as an oscillator and making lots of noise, and people had been having problems with the Teensy 3.6 and Traco, so rather than worry about that, we switched to a new DC/DC converter. The current generation of board uses the Murata OKI-78SR-5/1.5-W36H-C, which seems to work just fine. The vertical version of the Murata JUST fits, with zero clearance, into the box, so we flipped it around and went with the horizontal mount regulator instead.

The MAX3222 IC's require 3.3V to operated, but the Teensy 3.6 has a 3.3V output on it as well, so we used that to power the MAX3222's. If there's a flaw in the Teensy it's that there is no diode blocking between the micro-USB port to the power bus, so, if you have it wired into your plane and you plug in the MicroUSB cable to program it from your laptop, your laptop USB port will send power back thru the Teensy and try to power on your Echo UAT, AND power on anything else that it can on your panel. Be careful of this and one way to deal with it is to just pull the breaker on your ADS-B system before you plug in the USB cable. A better way is to put a schottky diode capable of 3A in line with the power wire to "the box", to prevent power backfeeding. I didn't do this at first, but I've been doing lots of reprogramming during development I decided to do it and prevent future issues. So, the entire board consists of just 11 capacitors, the Teensy module, and 2 MAX3222 ICs, and a DB15 connector. Here's the schematic:

After he made the circuit and ensured all the pins were connected, it was time to run it through some software to figure out the best way to arrange all of these wire traces. The resulting board looks like this, and is a 2 sided circuit board:

It's packed in nice and tight, but we actually had a version that was even tighter, and had sockets for 2 MAX3222's PLUS the RS422 IC's. I did personally use IC Sockets for the 18-pin MAX3222's, in case you trash one. The MAX3222's have a note in the datasheet about not being very tolerant to soldering heat, and some version of the chip should not be hand soldered. Therefore you will be safer just buying sockets for the ICs. That also can help with static prevention. The I/O pins are static protected, but not every pin is, so my suggestion is to handle the IC's with care, and probably buy a spare IC as well. We actually had an issue in an earlier rev of the board where the RS232 receivers were not being reliable, but found it was due to having a floating pin on the (EN)able line of the IC. When it floated, it would pick up stray charge, and if got high enough it would disable the receivers and cause the whole IC not to work. It caused random issues with 2 channels at a time. This was fixed in Rev 5.0/5.1 of the board, and only affects a couple of boards build before that, which have now been destroyed.

Here are some Oshpark images of the board

Board Bottom	Board Top	Board Bottom Layer
Board Top Layer	Board Bottom Soldermask	Board Top Soldermask
Board Bottom Silkscreen	Board Top Silkscreen	Drills

To order your board, they are available from OSHpark.com, a great circuit board producer for small projects. The minimum number of boards you can order is 3, but they are only $31 for 3 of them at the time of this writing.

If you are interested in building an RS422 to RS232 converter for integrating a GTX345 to systems that only support RS232, see THIS LINK.

The Shopping List

So to build one of these things, the shopping list is a little over $100 by the time you get it all shipped to you.

Quantity	Approx Price	Description	Digi-Key p/n	Mouser p/n
1	$31 for 3	Oshpark Circuit Board
1	$8	2.54mm Header Pins 40-pin Female	Amazon Link
1	$5	Murata OKI-78SR-5/1.5-W36H-C 5V DC/DC Converter	811-2692-ND	580-OKI78SR51.5W36HC
1	$2	Panasonic 25SEP10M Capacitor (Used for C9)	P16317-ND	667-25SEP10M
2 or 10	$.12	Wurth WCAP-ATG5 50V .10uF capactitors 860020672001 (Note: You can use these or non-polarized Ceramic on the RS232 ICs; use these on the input power filter C10 and C11)	732-8847-1-ND	710-860020672001
0 or 8	$.40	Murata RCER71H104K0DBH03A 0.1uF +/-10% 50V Ceramic Capacitors X7R (Automotive Grade) (These are good to use on the 8 spots required by the MAX3222 IC: C1 thru C8)	490-7514-1-ND	81-RCER71H104K0DBH3A
2	$6.50	MAX32222EEPN+ RS-232 3-5.5V 250kbps transceiver	MAX3222EEPN+-ND	700-MAX3222EEPN
1	$3.60	Harting D-Sub board mount Female 15-pin connector 09682537612	1195-5133-ND	617-09682537612
2	$2.00	Mill-Max 18-pin gold plated IC Socket 110-43-318-41-001000	ED90035-ND	575-11043318
1	$2.00	15-pin D-Sub Backshell 86303638BLF	609-1425-ND	649-86303638BLF
1	$37.00	SparkFun Teensy 3.6 WITH Header Pin Board	1568-1465-ND	474-DEV-14058
1	$13.00	Hammond 3.2x2.2x.91" Extruded Aluminum Enclosure 1455C801	HM969-ND	546-1455C801
1	$.80	Cinch D-Sub Connector 15-pin Male 40-9815M (To mate to "the box")	367-1190-ND	601-40-9815M
2	$.30	4-40 thread Female Screwlocks 5207953-3 or 5748558-3 or similar (Or pull them off a junk PC for free)	5207953-3-ND	571-5207953-3
1	$.50	Schottky Diode 20V 3A DO201AD 1N5820/E3/54 (To put inline with power wire)	1N5820-E3/54GICT-ND	625-1N5820-E3/73

		Additional Optional Parts You May Want
Optional Parts you may want or need: If you're converting an old NavWorX ADS600B, you may want to buy a 37-pin connector and backshell similar to (3-199-1253-7) to use to connect to all of the Echo UAT components and "the box". Also, Kapton tape for protecting the pins from the enclosure. (or use packaging tape) D-Sub machined pins for the box connector (Pins such as 204370-8 or MilSpec M39029/64-369 are not included in the above). (Alternate Pin source: SteinAir SA-1018) Echo Molex connectors 0436450600 and Pins 0462350001 for adding wires to the Echo Harness. (Mouser and Digi-Key Sell the molex parts) If you want to join the 37-pin connector shell to another mating connector, you may want these hex nuts Conec 160X10379X or Digi-Key 626-2113-ND.

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.

Assembly

Assembly is pretty straight forward. Use any 60/40 or 63/37 solder and I usually start with the 18-pin IC Sockets since it's easiest to do the shortest items first. Then move on to the capacitors, and make sure that you put the striped or marked side of the capacitor to the negative side of the capacitor socket...they are marked. If you don't understand capacitor markings, read up on them. The electrolytics are polarity sensitive. Then solder in the power regulator, and the header pins...snipping the header pins off to the proper pin count first. Now you can fit the DB15 connector. ** Note about the DB15 Connector: Depending on how your board was trimmed in production, the board may stick out past the DB15 connector, which will cause your enclosure end plate to not sit flush on the DB15. Test fit your DB15 to the board, and see if the board sticks out past the base of the DB15. If so, file or grind it down slightly so that the end plate will fit flush. Then you can solder the DB15 in place. At that point, flip the board over and cut short all of the pins that stick out far from the board, especially the 2 large ones that are on the DB15 connector, and anything that may touch the bottom of the enclosure. Mine were very close to touching so I trimmed the IC socket and header pins short. I trim them short and also stick a layer of Kapton tape on my enclosure (you could use thick clear box packaging tape too), to prevent shorts. Then tweak the legs of the IC's slightly and VERY gently and line them up with the IC Sockets. It's EXTREMELY easy to bend a leg and make it nearly impossible to install. Push evenly and get them into the sockets tight. Then pop in the Teensy 3.6, keeping the pressure level as well, as you can damage the board if you flex it. Then drill out the hole for the microUSB port in the enclosure, and drill out the D-Sub hole on the other end of the enclosure and add the 2 holes for the hex screwlocks...and screw the end cap right into the D-Sub connector.
That's it, your box is built. Keep it outside of the enclosure until it's programmed, as the FIRST time you program it, you need to hit the button on the top of the Teensy 3.6.

If you want nicely cut holes for the D-Sub connector and the micro-USB, you'll want to do it in CNC, although they can be drilled and cut by hand. Here is a set of files that may help you get started with either drilling yourself or having them cut for you:

Box End DXF File
Box End PDF File

Programming

Programming is pretty simple, but you have to get set up first.

What you need:

1) Get a nice long 6 or 10' microusb cable to program it with, like this one:

https://smile.amazon.com/gp/product/B012WF7ORW/ref=oh_aui_search_detailpage?ie=UTF8&psc=1

You can use any microusb, but a long one you can bring outside the plane for your laptop. For a while, you may even want to leave it plugged into this box and route it out into the cabin so that we can reprogram it again soon.

Then, for software you just go to this page:

https://www.pjrc.com/teensy/td_download.html

FOLLOW THE PROCEDURE ON THAT PAGE

** 11/15/2018: Regarding Software versions, in many places such as the paragraph below, I may refer to Arduino 1.8.5 or TeensyDuino 1.42. Be aware that at the time you are reading this, it may use different versions, and we recently found how various versions can cause various issues. We found Arduino 1.8.5 will not compile our newer 1.5.9 and up code without errors, and 1.8.7 won't compile the older 1.5.8 and older code without errors. Some of this is due to changes in the Arduino app, and some is due to changes in the TeensyDuino app. I'm not going to attempt to keep this page 100% up to date, but I will try to include notes with the software download link so that you have at least a little guidance as to what versions you should be using. At thie time of this note, 1.8.7 and 1.44 are what we are using with version 1.6.0 and up of the code. Now, lets continue reading some aged information...

It has you first download and install an arduino programming package. Get version 1.8.5 so you're on the newer one. Just follow the directions on the page. After that is installed, you install the "Tennsy Duino" app (I used Version 1.41, but version 1.42 is out now. If you want version 1.41, email me and I'll send you a link, otherwise, I'm guessing 1.42 will also work fine) which modifies the stock software to work with the Tenensy 3.6, which is the processor used.

Then after you get that you configure it for the proper CPU and speed settings.
Here is what I'm using: (Note that I have changed the CPU speed to 120Mhz, and set Board type to Teensy 3.6)
Once the device is recognized by your PC, you can select "Port" in that menu and find the serial port that it installed to. It may be a high number, like 9, or even 25 or 37. I do find that to get the serial driver installed and working it seems like it's best to just try and program the board, and during the initial programming it detects the device differently and assigns it a serial port. If you want to see what is going on during bootup, you can select "Serial Monitor" once the serial port is selected below, and when you plug it in again you should see a message pop up.

The first time you program you'll need to compile the program and upload it and hit the button on the Teensy. After that, programming is as simple as hitting the compile button on the Arduino software and then hitting the upload button after it's compiled.

3/26/2019: I wrote some directions here that are more complete for installing the software and modifying the buffers in the serial1.c and serial3.c files. Check that out.

Optional (but highly recommended) materials: If you want to test the I/O (I suggest you do this) before you burn the actual software to the Teensy, get yourself a PC with a real serial port or a USB to serial dongle (My Favorite is the Cables 2 Go 26886 HERE on Amazon for under $9)

Next, a test harness that allows you to connect the ground pin 5, and pins 2 and 3 of the serial adapter into the various pins on "The Box". These are just 2 or 3 single wires, with a male D-sub pin on one end and female on the other. Pin 3 on the Serial dongle is transmit, Pin 2 is receive, and Pin 5 is ground. The female pins can be stuck over the exposed pins on the serial dongle. The male end of the wire can go into the proper port on "The Box" to test the receivers.

To Test Receivers: Pin 3 on Dongle to Pins 3,5,7,9 (one at a time) on the Box should show Baro Alt in Serial Monitor
To Test Transmitters: Pin 2 on Dongle to Pins 2,6,8,10 (one at a time) on the Box should show "TEST" in RealTerm (or other terminal software) Window

Load up this software on to the box (See Below for more info). Then Download this Serial Altitude Simulator I found online (Great stuff BTW). Also download and install RealTerm. (or any other serial software such as TeraTerm. What you do is just upload that serial test software. Plug the box into the USB port and it boots up. Then you can run the serial altitude simulator program and set it to ICARUS altitude and set a specific altitude. OPEN the Port on the RS232 port that your USB dongle uses (Not the teensy), and hook the Transmit wire up to each of the 4 inputs on "The Box" one at a time, while running the serial monitor on the arduino software. (See above for pins) If everything is working, you should be able to see scrolling on the screen the altitude you set in the app, being received by the box on all 4 ports. Don't forget to CLOSE the Port on the altitude simulator when you're done. Then test all the outputs too. Shut down the serial altitude simulator, turn on Real Term or your serial console app and set it to 9600 baud for the same serial port as you just used for the Dongle, and ASCII format (not hex). Then just connect each one of the 4 output ports on "The Box" (See Transmitters Above) to your input on the dongle. You should see a message coming in on RealTerm on each port. That way you now know that all I/O ports are working physically before you try to wire up and run "The Box" in your airplane. If you have failures, you may have a solder bridge issue, bad MAX3222 IC, or have programmed something wrong.

Wiring Connections

Standard Serial Port Pinout

DB-15 Pinout of "The Box"

Pin	Function
1	+14V Power
2	Transmit 1 - Unused
3	Receive 1 - GDL90 Traffic/Weather In from Echo
4	n/c
5	Receive 2 - Unused
6	Transmit 2 - GDL90 Out - Filtered - To Display/EFIS
7	Receive 4 - GTX In from Garmin 327/330 Xponder
8	Transmit 4 - Unused
9	Receive 3 - ICARUS Baro Alt In from Encoder
10	Transmit 3 - GDL (SL-70) Baro+Squawk to Echo
11	GND
12	GND
13	GND
14	GND
15	GND

Once you're done testing the transmitters and receivers, you're ready to upload the real code and try it out.

Uploading Code (always refer to the changelog below before loading any code)

** Update 11/15/2018: There was a change in the TeensyDuino application and now the version is 1.44 as of the time of this writing. If you were installing today, you would use Arduino 1.8.7 and TeensyDuino 1.44. The code had to change (very slightly) to use these new versions. If you are using the newer 1.8.7 / 1.44, make sure you're downloaded .ino file is version 1.5.9 or newer. 1.5.8 was the final released version that worked with 1.8.5 / 1.42. And on the flip side, if you are using version 1.5.8 or older, you must use TeensyDuino 1.42, and Arduino 1.8.5. I can give you a link to those if you can't find these version at the time you're reading this web page.

** Update 11/15/2018: With Release 1.6.0, the layout of the file has changed, to allow you to use the same base code for multiple airplanes more easily. The difference is that there are now 2 files. The .ino file contains all the running code. The Aircraft_Settings.h file is a file that must be in the same folder as the .ino file, and when compiled, they compile together into the running code. So for most users, you will be able to not touch the .ino file at all, and simply edit any values you require in the separate file.

** Update 3/25/2019: All old code releases have been removed. We found that the buffers need to be increased in the compiler for the teensy. See the changelog below for more details, and make sure that if you compile code, you increase the buffers in serial1.c, serial2.c, and serial3.c.

Once you've installed the Arduino 1.8.5 software, and TeensyDuino 1.41, the actual code uploading isn't too hard at all, other than the first time when you have to hit the button on the teensy, and my windows PCs seem to get a little crazy trying to get the serial port to install. It takes me a couple of tries when loading a brand new never-programmed Teensy, to get the port showing up so that I can load the software.

To load it, just plug in the Micro USB to your PC for starters. One rule to remember is that the code file you're loading has to be in a directory named exactly the same as the filename of the code, other than the .ino extension. So TESTCODE.ino needs to be in a TESTCODE directory, for intstance. On windows at least, I can just double-click the .ino file and it launches Arduino 1.8.5 and shows the code on the screen, just as the image below.

Step 1: Verify the code. Simply hit the Checkbox button at the top. When you do that, you'll see a bar graph progress indicator in area 3 as it compiles.
If there are any compilation errors, they will show up in the window where #4 is. I haven't been getting any fatal errors when compiling the code, so
if you start getting them, you may have a coding mistake for any changes you made. Once Step 1 is completed, the Teensy loader pops up on my windows PC.

Step 2: Once you see this Teensy window appear, you're ready to load code. Note that it says "Press Button on Teensy to manually enter Program Mode". This is necessary the first time you program a Teensy. Otherwise, hit the Arrow button labeled #2 above, and that loads the code onto the teensy. If the serial port is recognized properly and you did everything right, the Teensy window should have a progress bar graph that pops up on it very briefly, showing that it's loading code.

Step 3: Once I load the code, I like to verify it. The serial port test code is set up to display a row of periods ".........." when it is receiving nothing. If you transmit it Baro Altitude for a test using that simulator mentioned above, you should see the baro altitude show up each time you connect one of the receive pins to your serial dongle with a jumper wire that is transmitting the altitude. For the transmitter test, the box is set to output a "TEST" string on all 4 transmitter ports that you can listen to with the Serial Dongle. In order to use the serial monitor, first plug in the teensy, then in the Arduino software, select the proper serial port, and open serial monitor.

That's all there is to programming the code. The test code and the actual code program the same way.

The Code
Read this section and the code download link is below
Part of the reason that this code took so long to release is because of the crazy world we live in. Nobody wants to be liable for anything, and nobody on the other side wants to accept personal responsibility for their own actions. That stems from people pushing liability on other people (sometimes every manufacturer and person around) for things that they ultimately were responsible for. First let me state a few things: Although this code has been flown by me and tested, consider it to have been programmed by a monkey. No, that's not an insult to my great friend who did the programming, as he's genuinely the smartest dude I hang with. But, he doesn't work for any Avionics manufacturer, and didn't have anyone else review his code, and this whole project was just a hobby...not being sold to anyone for any profit. Even if I happened to have a circuit board available, and you buy it, that board is YOUR board and YOUR responsibility. If you think there's a chance that the board has a defect, TEST it before you use it. If you don't like the circuit or components that we chose, PICK YOUR OWN. If you don't understand the circuit, have it reviewed by someone else. When you build this kit, no matter the source of the components, EVEN if for some reason I was nice enough to solder an item in for you, this kit is YOUR kit and YOUR responsibility, and if something happens when you are using it, it's YOUR fault for being a cheapskate and buying an Echo UAT that wasn't made to the highest standards out there, and a box to fix it that is a Do-it-Yourself Project. If you wanted a flawless system, you should have spent the money and bought a Transponder from Garmin or better yet, the Lynx NGT-9000 which works great with the Chelton EFIS and others. You compromised, just like I did, when you bought that Echo, and we both shouldn't have been such cheap bastards trying to find the frugal way into ADS-B. In the long run, I personally don't even plan to KEEP my Echo, because after learning all of its flaws, I'm not willing to make it a permanent part of my plane. Regarding the code, if you choose to load the code, it's completely your own responsibility. I can't prove that the code you upload is the same code I post, so it could have been corrupted in upload, or any number of other failures. ASSUME that the code is full of bugs, and buffer overflows will happen, and you will probably not see the airplane coming straight at you, and it will definitely crash into your plane and it's unlikely nobody will survive. YES, that statement is made for liability reasons, but let that be your warning. There, now that you grasped the worst case scenario, understand that this is YOUR fault if it happens. If you wanted a rock solid complex system that worked all the time, you should NOT have built it yourself and copied some code off the internet, especially from a guy who just told you that. It's all on you, dude. We fought unexpected code things every day early on, and even a hardware flaw here and there. We're at Revision 5.2 on the circuit board as this is written, and while I think we worked most of the things out, there's absolutely no guarantee that we did, and in fact I EXPECT that some day we will find some other bug or way that this can fail. I'd ENCOURAGE you to modify the code, if you are adept at it, and make it customized. That way you really understand that it's ALL YOUR THING. Open Source, no warranty, baby.

Code Updates
One other note on the code. The initial code release was 1.53. There are some future things still on the to-do list for the code. There are also changes and fixes that will happen from time to time. BE SURE to read the release notes below, to know about the changes. One is that we have obtained a very technical, professionally written document on TCAS and Traffic Alert algorithms. We intend to rewrite the traffic alert code to use that algorithm and test it out. So that, if it ever happens, will be a major code release that you will probably want. Also, at the time of 1.53 release, I still had many ghost (shadow) targets when traveling through some ATC areas. This is because the radar primary target getting sent up to your receiver does not always merge properly with your broadcast ICAO code, and they send a track file ID number...it looks a lot like an ICAO code, but isn't. Initially we saw most started with 2A, such as 2A0001 thru 29FFFF. So we blocked those codes. I have not flown with the latest test, but, all US based ICAO codes start with A, so A10000 thru AFFFFF should be US codes. Other countries start with other numbers. To help filter track files, this was expanded now to filter targets between 2A0001 and 9FFFFF. We don't have the specific definition of what the US ATC system uses for track file ID codes, so this may be filtering way less than we intend, or way more than we intend. There is still more work we will be doing on testing this. So please, consider your project to be a work in progress, and plan to update code on it over the next year a few times. To that end, I suggest leaving a micro USB cable attached to the box, coming out into the airplane in an accessible area, so that you can throw a laptop on it and reprogram it whenever you need to. Secure the cable if you mount it anywhere near controls, so it doesn't fall out and jam a control.

A note on Testing
See the next section on Squawk and Baro integration. If Squawk and Baro fail, you could be be violating the law with your transmitter. The way to see if it is set correctly is to always, on every flight, multiple times, connect your iphone/ipad app "Echo utility" to the Echo and click the "Monitor" button. There you can see your current squawk and baro altitude. If it's correct, then it should likely be working fine. If it is not, you may have an issue. I do NOT watch mine every flight, but, I am telling you that the only way you can verify it is to check it, so if you are concerned about violating the law, check it for yourself. The humorous thing about it is, the stock Echo UAT in transponder monitor mode, does a horrible job at times, if your transponder isn't being interrogated, at keeping the squawk and baro altitude updated. So I feel better at trusting mine after "the box" than before.

A special note on Squawk and Baro integration
While originally testing the GTX data processing and GDL SL70 output, we did run into a couple of minor unexpected items that caused some issues for a short time. First, we had a list of maybe a dozen squawk numbers that the system didn't like. (There were good reasons for these exceptions, and we figured out why they happened) Then we had it down to 1, and then it was fixed. It all made sense as we worked on it, but it goes to show that all it takes is a little coding error and you could end up not getting the squawk code to the Echo.
Regarding Baro altitude, that was a very straightforward interface to read the ICARUS altitude stream, but keep in mind that it's then combined and converted to the GDL (SL70) stream, and this is another place where there is a potential for bugs. Additionally, should either one of the hardware RS232 channels not work, you could easily end up with a system that stops working for any one or multiple RS232 inputs or outputs. There was ONE day that I went to fly and noticed my EFIS wasn't receiving GDL90. I knew nothing had changed, so I pulled the box out and just did what I've done for years in troubleshooting things...remove all power, pop out removable components (in this case I swapped the 2 MAX3222 IC's) and then popped it together. It worked fine after that. I didn't know why it didn't want to fire up that day. Was it that I plugged in the USB power with the breaker not pulled? Well, I found a hardware issue that we changed in board rev 5.1 that should fix that...the receivers were not always staying enabled because the enable pin hadn't been tied to ground. So as they built up induced voltage on the floating pin, the box could stop working. At any rate, be aware that all it would take is the sqawk or baro interface to not work, for you to cause yourself issues with the FAA. If you use this box, you will want to verify that things are working properly, perhaps each time you fly. The upside is, with the Echo web interface, it's easy for you to check it out. Simply pull up the web interface in MONITOR mode and you can see what squawk the Echo is receiving and see what baro alittude it has also, and it should match the one on your transponder. I personally think that we have it all nailed down pretty good, but it's up to YOU to verify, if you build one of these boxes for yourself. The reason it's taking an extra couple months to feel good enough to open source this project is that I want to take 2 airplanes with the system installed, and fly them both about 3,000nm and see that they both perform consistently, with the very latest board rev and software.

What do I do if the box stops working?
Fortunately most people these days use iPads for charts, and this means that should this box fail, you really can cope with it until you get home from whatever trip you're on. If you see that no Baro altitude is coming in, or no squawk is working, simply use the Echo configuration utility to set your Echo back so that the altitude/squawk source is set to "Transponder Monitor" mode again, so that the Echo is forced to get it "over the airwaves". Your GDL90 stream to the EFIS may quit working, but you can always get traffic and weather on your ipad with any of the EFB apps as a backup. Yes, I know, this would suck to have the Echo perform IN THE MANNER IT WAS SOLD TO YOU, but they, if they can maintain their FAA blessing even with such a flaky system, at least you are operating it in the manner they sold it to you and then they have some responsibility in it.

Code Update Changelog

4/26/2019: Version 1.65 is now released.   1.64 only removes 2 lines that were sending debugging info to the serial port even when debugging wasn't enabled. 1.65 did a little rework of the SD card section because if you used the SD card for logging (I do during testing), it would give a false error when booting saying the SD card wasn't available. Make sure you're running 1.63 or newer to clean up critical issues, but 1.65 doesn't do anything substantial unless you do logging to the SD card.

3/25/2019: Version 1.63 is now released. During some test flights we found some bad CRC checks on some data, and determined them to be due to problems buffering some of the input data under load. This has been fixed by changing the receive buffer size on the Teensy compiler. It is CRITICAL to change these buffers if you want all data to be properly received. 3 files should be edited, before compiling. On windows, they are located at C:\Program Files (x86)\Arduino\hardware\teensy\avr\cores\teensy3\serial3.c (and serial1.c / serial2.c as well).    You need to find those 3 files and edit a line within the file for each of them.

Inside those files you will see lines that look like this:
#define SERIAL3_RX_BUFFER_SIZE     64 // number of incoming bytes to buffer
That "64" number needs to be changed to something larger. I am using 4048.
Example: #define SERIAL3_RX_BUFFER_SIZE     4048 // number of incoming bytes to buffer

Once you have changed that information, you need to recompile, but, due to caching of data, if you have previously compiled, you will need to make a change to the overall design to get it to recognize that there has been a major change. I suggest going into the tools menu and changing the "OPTIMIZE: FASTER" to "FAST". Then compile it. You need to see the compile message "Build options changed, rebuilding all" or it didn't change the buffers. Once you compile it on "FAST" change it back to "FASTER" and compile and load it onto your board. Another suggestion is to before you do that, go into the FILE - PREFERENCES menu and turn off aggressive caching in the menu. This change will affect all future versions.

Download the Code
Note: All old code versions have been removed.
All code for download will now use the Dual File Format, and I have been using Arduino 1.8.7 and TeensyDuino 1.44 for compiling

## See Note on new Dual File Format that is now used with and up.
## See Note on using Arduino 1.8.7 and TeensyDuino 1.44
## See Note on changing Receive Buffers on the Teensy compiler

Versions >=1.63: Versions >=1.63 were produced with RX buffer changes that are required for reliability (see above). Version >=1.63 also includes some code the originating programmer uses personally that can display aircraft type for the traffic on his AFS screen. This code isn't documented here, but it allows him to only have one code base that needs to be kept updated. If you are interested in this functionality, I can help get you information on using it. >=1.63 also prevents data from being used if it fails CRC check. All older versions have been removed to keep people using only current programming.
Release 1.65 (RS232 only)
Release 1.65 (RS422 to RS232)

Click one of the above to download the code, release versions subject to change. Know that you are accepting full responsibility for everything when you use it. When putting it on your PC, put it in a folder with the same name as the code filename, without the .ino on it. Then just double-click and if you have all the software loaded, the arduino app should launch. If you are using version 1.6.0 and up, you will also have an Aircraft_Settings.h file that needs to be in the same folder with the .ino file.

Lets explain some of the things that are tweakable in the code as planned defaults. This is as of version 1.5.2. For versions beyond 1.5.2 you may find differences in the options.
"The Code" is uncompiled, and just a text file....I'd suggest editing it right in the Arduino app itself. To run, it needs to be in a folder that is the same name of the filename, without the extension. The Arduino software is an editor too.

Here are the options from top to bottom: (See the end of the article for the bare minimum that you need to configure)

SETTING	Description
#define DEBUG	This is commented out by default but if un-commented it will allow you to monitor the micro-usb in-flight and see what's happening on the serial monitor
#define GDLCONTROL	This is active by default and enables the processing of the Altitude Encoder and Transponder communications inputs and outputs. Note that this ONLY uses ICARUS altitude format, and GTX transponder control format, and ONLY outputs SL70 (GDL) format.
#define SHADINZ	If you are not using ICARUS format, but getting SHADINZ format such as from a GRT EFIS for your altitude encoder, you may need to disable ICARUS and use SHADINZ format in.
#define ICARUS	Uncomment this option if you are using a standard ICARUS format Altitude Encoder for Baro Alt.
#include "Aircraft_Settings.h"	This is new in version 1.6.0. It allows you to have a separate file where you keep your tweaked settings for your aircraft. This way if you want to change things during testing, you can save various versions of this file and simply load the one you want. The filename can be change to whatever you want...suggest using your N-Number, but make sure to change the "include" line in the .ino file to match the filename.
#define FRIENDS	This is active by default and enables you to have "Friendly" targets (Other airplanes) that will NEVER give you traffic alerts. If you fly formation, it is handy to not constantly have traffic alerts while you fly with them. Additionally it will, on the Chelton EFIS at least, display the friendly targets as a different symbol type, whenever they are over a mile away from you. This makes it easier to find your friends and join up with them.
int32_t ownModeSCode=	Example: int32_t ownModeSCode=0xABC123 This is where you enter your own airplanes ICAO Code. You prefix it with "0x" The ICAO Code needs to be the HEX version, NOT the Octal version, from the FAA site. Whatever ICAO code is listed in this setting will never be displayed as traffic on the output data stream.
int gdl90_outbaud=38400;	This is the baud rate used for the output GDL90 Data Stream to your EFIS
int gdl90_inbaud=115200;	This is the input baud rate from COM2 of the Echo UAT or other system into "The Box"
int icarus_inbaud=9600;	This is the baud rate of your Altitude Encoder's ICARUS Altitude
int gtxremote_inbaud=9600;	This is the baud rate of your GTX327/330 Squawk Signal
const int outputBufferSize=3456;	This sets some internal buffers for the processing: gdl90_outbaud* 0.9; 10368 for 115200bps; 3456 for 38400bps
bool maintenanceOverride=true;	This will override the ADSB Maintenance flag if there is a problem with the system. It should be "false" by default but if you aren't using GTX and Altitude Encoder inputs, it may need to be "true" to prevent spurious alerts due to the poor function of transponder monitor on the Echo.
Ghost Filter Settings
float ghost_dist_diff=0.25;	This is the distance in miles that shadow targets (Ghosts) will be filtered out. Shadows caused by being primary targets to radar have a different ICAO code format, a "Track File ID" instead of an ICAO number. We will not display airplanes that could be your own airplane, in a close proximity to you, if they are a trackfile ID.
float ghost_alt_diff=200;	This is the difference in altitude that the track file ID shadow target will be filtered out, relative to your altitude.
float ghost_track_diff=45;	This is the track difference from your own track that helps identify a shadow target. If they are on approximately the same track, it is probably you, and should be filtered. Reduce this track angle to make it more sensitive and not filter shadows as easily.
Traffic Alert Settings
int32_t alert_alt_diff=400;	This is the altitude difference maximum that a nearby target must be, for it to cause a traffic alert. Straight and level traffic that is more than this value above or below your altitude will not alert. To alert on airplanes more easily, expand this value.
int32_t alert_fuzzy_alt_diff=950;	This is the altitude difference maximum that a target will be, to cause an alert, if either it, or you are climbing or descending. It us used in the projected altitude functions to estimate if you will be coming together with the other aircraft and be close in altitude if you continue your trajectory. If you want to have more alerting if you will be close in altitude when you meet another plane, expand this number. If the number is too large, you will have many alerts whenever someone is climbing or descending to your general projected position, even if they level off at a cruising altitude far above or below you. That is why 950' was chosen as a default.
int32_t alert_seconds_before=40;	This is the amount of time that will trigger an alert when you are closing in on another airplane. i.e. in 40 seconds or less, you will close in and come together or have a near miss with the other aircraft. This is done by time calculation so you will get 40 seconds warning whether it's coming up fast behind you, or coming head on in front of you, as it calculates actual "Time to close" on the intruder. Expand this to get more warning, but be aware that at 150kts you are traveling nearly 3 miles in 60 seconds, so a 40 second gives you more than 4 miles of warning in a head on situation with a similar speed aircraft.
int32_t alert_vector_length=40;	To explain this, imagine a vector projected out in front of your airplane, like a very long pitot tube on your nose. This vector is 40 seconds long, and thus is longer the faster you go. There are algorithms that will use this vector ahead to monitor for traffic that will be crossing paths anywhere along your 40 second vector with their 40 second vector, like 2 Star Wars warriors with light sabers. :) Should these light sabers touch, you will get an alert. Make the vector longer and you will have a greater look-ahead to traffic that may cross your path. Make it too long and you will receive many alerts. Make it too short and you won't get many at all.
float alert_dist_diff=0.5;	This is the distance in miles that we have a backup alert for alerting on close proximity that may be traveling nearly parallel. If the track vectors will not be crossing, even nearly head-on traffic may not alerts, and this backup alert will still give you minimal warning whenever someone is coming near to you.
float positive_closure_distance=1.0;	This is the distance in miles that will be alerted as long as a target has a positive closing rate on your airplane. It is used in conjunction with positive_closure_max_time for this alert.
int32_t positive_closure_max_time=180;	This is the time in seconds that a positive_closure_distance target must be under, before it will alert. In the default of 180 seconds, a plane must be coming at you where you will come together in less than 3 minutes if it is within a mile of your position. If you are converging so slowly that it will take more than 180 seconds, it will not alert until it reaches the alert_dist_diff setting above. This way you can fly near other airplanes on similar tracks but if you will not meet for more than x seconds, you will not receive an alert.
Traffic Tracking Settings
const int maxIntruders=60;	This is the number of intruder airplanes that are monitored in a table of targets. Only targets within filterAltitudeAbove and filterAltitudeBelow altitudes relative to you, and filterDistance range from you, are added to the table. This is simply the number of airplanes tracked in the table. The table always sorts in order of distance, so you always are calculating on the nearest 60 targets, but all of the others beyond 60 are ignored.
const int maxIntrudersOut=20;	This is the maximum number of targets sent out on the RS232 stream to the EFIS. 38,400 baud can only handle 32 targets with 4 uplink messages per second. By limiting the targets to 20, we can send one additional uplink message per second, and prevent the EFIS screen from being cluttered by targets. You can adjust this as high as 32, but reduce maxUplinkMessages to 4 if you go higher than 24.
Traffic Filtering Settings
float filterDistance=80;	This is the distance in miles that traffic will be limited to. Any traffic further than this will not be placed into the traffic table or displayed on the EFIS.
int32_t filterAltitudeAbove=5000;	This is the number of feet above you beyond which traffic will not be displayed. It eliminates high-altitude aircraft from being displayed for you. You may wish to expand this if you frequently fly near parachuting operations.
int32_t filterAltitudeBelow=10000;	This is the number of feet below you beyond which traffic will not be displayed. It eliminates low-altitude aircraft from being displayed for you. The default is set higher so that you can see traffic at the destination airport many miles out as you descend, but it may be set to a number as low as 5000' if you do not wish to see such traffic.
Coasting Settings
uint16_t coastTime=15000;	Traffic must report its position every 1-2 seconds to be displayed on the EFIS. If a target doesn't transmit regularly or your antenna doesn't pick it up regularly, it will disappear. The coasting algorithm calculates where a target will be based on its last transmission. coastTime=X is the number of seconds to project where this target will be, before simply dropping it. Be aware that if a target does a rapid turn, climb, or descent, it may not be where it was projected to be, so coasting is not perfect, but it is better than not seeing the target on screen at all. Keep this to 15000 miliseconds or lower (15 seconds) to ensure the position is fairly accurate. Reduce it to minimum to do no coasting or minimal coasting, but expect to see traffic blink on and off at times.
Misc
maxUplinkMessages=5;	This is the maximum number of uplink messages to process in a second. 4 is the GDL90 standard default.
int heartbeatInterval=1000;	This is a heartbeat packet interval between the box and the EFIS. It sends one every 1000 milliseconds to keep the EFIS happy.
Friendly Settings
const int totalFriends=8;	This is the number of friend aircraft in the array below this setting. You need this number of ICAO Codes to match the number of them in the array. And friends airplanes that you do NOT want to get traffic alerts on, should be put into the array. Be aware that you will NEVER get collision alerts on them.
int32_t friendArray[totalFriends]={0xABC123,ABD124};	This is the array of friends ICAO codes. They are inserted with comma separation (no spaces) if you have multiples. In this example, there are 2, and the above totalFriends value should be 2.
float FRIEND_dist_start=1;	This is the distance within where the friendly targets will display with the standard symbol. On the Chelton EFIS, standard is an arrowhead. A friendly on the Chelton is made by artificially degrading the appearance of the quality of their signal, which makes them into a rounded nosed type symbol. If set to 1, within 1 mile the friendly will have the normal symbol. Set this number low if you want to see that symbol all the time. Set it far if you never want to see it.
FRIEND_dist_max=80;	This is the maximum difference that the friend type symbol will be displayed. Beyond this distance it would display with the standard arrow symbol.
Alert Setting
unsigned long alert_hold_time=10;	This is a hold timer on traffic alerts. If you receive a traffic alert, but the airplane changes course and will no longer be a factor, it will stop alerting. This holds the alert to continue alerting even if the algorithms no longer detect a collision. A setting of 10 holds the alert for 10 extra seconds. This is done to prevent an alert from stopping and starting a lot if you happen to go in and out of conflicting paths with another plane. If you are alerting too long, set it lower. Too short, set it higher.

Traffic Alerting Algorithm
Some of this may be explained above, and anyone using this code should definitely read through ALL of the above code settings and get a good understanding of it. First let me say that although we have some fairly good working traffic alerting going on, don't think you can trust every situation to warn you about traffic. We recently found a real good TCAS document with a corresponding traffic alert algorithm that is pretty darn mathematically complicated, but is a true professional algorithm designed to alert on traffic that could be a factor. That is NOT yet something we have tried to implement in code. It REALLY made me angry when I found out that the Echo UAT does not even calculate in ANY method, when traffic will be a factor for you. Sure, some EFIS systems will do this for you, but not all of them do, and the fact that Echo doesn't alert is a huge safety issue. I would not recommend buying ANY of their products until they get that fixed...period. They simply are not playing in the big leagues of Avionics makers until they implement features like that. How did I find out about this? I flew on a course that there was another airplane circling on, and I got within 100-200' of his altitude and as I got near him I spotted him. He rolled out of a turn directly towards me. We both had our landing lights on. We passed within 300-500' from eachother, offset but head on, within 150' of altitude, and there was no traffic alert...and that was with a stock Echo UAT.

What we currently have in code is a mix of 3 different methods to determine if traffic is a factor or not. One of them projects a lead vector in front of your plane, like holding a sword out in front of you. It calculates the same on the other planes. The vector is longer or shorter based on speed. The algorithm detects if those lines are going to intersect at all. Pretty cool, but it doesn't account for people coming in close to you that won't actually cross your path. AND, if you were head-on with someone and they were going to pass 10 feet off your centerline, you wouldn't get an alert, because your paths don't cross.

To fix that, there are a couple other layers of detection in there that detect traffic closing in on you. One looks at anyone who will come close to you within X seconds. So any airplane that will be very near your position within X seconds will cause an alert once it gets within a certain time or distance barrier. The box is actually tracking all of these targets that are nearest you, based on distance from you, sorting them in that order, and keeping track of the closing rate on all of those targets. Yeah, that's a lot of math going on, in 1 second intervals.   So with that, we can now detect traffic that will be a factor. There are a couple of other features we did as well. First, if traffic is behind you and moving away from you, you don't need an alert, so other than a tight proximity alert, we ignore those. But, one problem we ran into was that sometimes, especially the "crossing paths" algorithm, would detect that you were going to converge paths, but then for a second or two, the vector changed and did not converge. With that you'd get an alert and it would disappear and then return again. We wanted to KEEP the traffic flashing long enough to see it on screen if it alerted, so there's a holding timer in there that once an alert triggers, it stays for X seconds. The only time it gets annoying is if people are moving away from you, you still get alerted until that timer quits.

Climb/Descent tracking collision alerts are also handled. "The Box" tracks your speed, climb rate, altitude, and ground track and does the same for all of the targets it is currently tracking.   It then looks to see if you are going to climb up or descend down into a target or if they will do the same to you. That's why some of the settings are "fuzzy" in the setting section, because you don't want to simply calculate if you are going to meet at a certain point, but meet NEAR a certain point. Think of the letter "V" as 2 airplanes descending. If all you calculated on was the lower tip of the V, and your descent rates change a little, you may collide at a different point from the tip. So you want to calculate within a zone around that tip, above and below it. You want to know that any climbs and descents don't put you too close to other airplanes. At the same time, just because someone is 4,000' above you and descending at 2,000fpm doesn't mean they're going to hit you, if they decide to level off 1,000' above your altitude. So we tried to balance the settings a little so that you don't get a warning unless the altitude is going to be within a certain altitude boundary. It's tough to guarantee, unless you knew what both planes intended.

Friendlies

There are also features in there for people like me who fly in formation with friends, or meet other airplanes in the air on some trips. By enabling the #Friendly code, and setting up certain ICAO codes as "Friends", you can get some cool features. Not all EFIS systems support the standard symbology for ADS-B targets, but on my Chelton EFIS, there are symbols ranging from Arrowheads, to "boats" (for lack of better description), to diamonds to circles. Most targets show up as arrowheads, and ones that are alerting are yellow. Ones that are nearby are blue filled, and ones that are distant are blue outlines. The Friendly code works by doing a couple things. 1) it makes the target look like a "low integrity" target that DOES have track information. Once that happens the friendlies turn into the Boat symbol shown below on the 2nd line. Now you can easily pick your friends out when they're within X miles. (I set it to 80nm) Makes it easy to find the person you're meeting.   The second feature to "Friends" is that if you fly in formation like I do, you get tired of CONSTANTLY being alerted for "TRAFFIC" when the target is your buddy flying 50' off your wing. So by enabling someone as Friendly, you can cause them to NEVER alert for traffic. OF COURSE you need to be careful with this, because you won't get collision alerts from them, but, you should already be paying attention if you're flying in formation. I have a lower bound on distance to mark it a friendly symbol as well, because on my EFIS the boat symbol is bigger and to make it easier to discern their direction, I have them drop back to an arrowhead when they're within a mile of me.   So the Friendly function can be nice to have, if you have reason to use it. If not, I'd recommend commenting it out at the top of the program and not using it at all. If you do use it, make sure to add their ICAO code and change the count to match the number of friends.

Coasting

One of the common complaints about the Echo is that airplanes disappear and then come back. This would be especially painful for when you get traffic alerts, since every time they reappear they would cause another alert to yell out. It also is no fun to not be able to see a target that was headed for you, and you knew "he was just right there!", and then not see where he is. Well, "the box" tracks a large number of targets, and tracks their speed, vertical speed, altitude, and track among other things, and by using that information you can continue to calculate where someone SHOULD be, even if they momentarily do not transmit position to you. If they are turning or you are turning, you may shield your antenna and miss a position report. This is especially true when they're using a weakly transmitting Echo UAT compared to a powerful transponder transmitter, or you're using the Echo receiver that may not be as sensitive as the receivers in other systems. By using their calculated position, and then updating it as soon as you get their next position report, you can at least have a good idea where the traffic will be. This in practice helps TREMENDOUSLY. Since the Echo is a dual freq receiver, you'll see any equipped target in the sky, directly. By 2020 it will be very very hard to not see most airplanes. Even if their transmitter is weak and they climb up into your airspace, you will likely have a couple of hits of their position and by coasting it, you should have them on screen long enough to notice them in your scan, before they drop off. Coasting time is NOT something you want to crank up high. It will, of course, be LESS accurate the longer you coast them. 60 seconds would be too long, as that could coast someone for 3 MILES at RV speeds. But if you keep the number to 5 to 15 seconds, you'll at least not have blinking targets that you can't find when you need to. 5-10 seconds is a fairly conservative and safe compromise. Their position will be at least approximate. The alternative is to not coast them, which I feel will reduce safety by a LOT more.

Ghosts (or "Shadows")

The other annoying thing I experienced a lot of with the Echo that I very rarely experienced with the NavWorX system I replaced, is ghost or shadow targets. I THINK the Echo filters out your own ICAO code, so that it does not send to your EFIS. But, we filtered out your own ICAO code on "the box" just in case it leaked through. That way you NEVER display your own airplane if it's sent using it's own ICAO code. But there are other ways to get shadows, and most often they will happen when near Class B areas.   If you are being picked up as a primary target by radar, the FAA's job is to merge your position with the primary radar return and combine them into one target. This doesn't always work well. If the radar return is a little off positon or altitude, you may be detected improperly by radar and appear as a 2nd airplane in a similar location. OR, if your much weaker transmitter in the Echo UAT, compared to powerful transponders, is not received by them for a few pings, but they DO have your primary target, they will fail to merge the two targets. When the FAA sends a primary target it then sometimes get sent with a "track file ID" that is formatted like an ICAO code, but is NOT an ICAO code. Your Echo interprets this as traffic, either way, and tries to display it.   So what do we have to do? Well, we look at our own track, altitude, and speed, and match it up with that of the target. If they are basically the same, and within X (lets say .25) nautical miles, just drop them, for sure if they're a track file id and not an ICAO code.
Could someone slip through and be an actual airplane that you could hit? Yes.   BUT, if you are coasting targets and especially if you are watching your screen, and considering we already have traffic alerting going on, you should have had many many seconds that you were already being alerted or at least aware that this target was there. Think about what .25 nm looks like. When you line up for takeoff at your home field, it's just past the 1,000' markers by a couple hundred feet.   So we're only dropping targets within a very very close proximity of your position, and only primary targets. If someone has their own ICAO code, as will most people by 2020, and they're broadcasting, you'll get the alert on them the whole time.   By not having ghost filtering, I was constantly being alerted to "Traffic" that turned out to be right at my position, and followed me wherever I flew, and it was worse in some airspace than others, and definitely worse in fringe reception areas.

Those are a few of the main features of "The Box" software that we're running today. So from a hardware and software perspective we were able to fix most of the issues that a standard Echo UAT has. What Can't be fixed? Well, I'm not thrilled with the cheap molex connectors on the echo, nor the MCX connector on the SkyFXY GPS. Real avionics use SMA, TNC, or BNC for antennas. I'm also not thrilled with the lower power output of the Echo UAT. Remember, this was a company that made ADS-B for the drone market, so things needed to be small. We like small, but not when it sacrifices real avionics features like plenty of asynchronous serial ports, Encoder inputs, Transponder inputs, Higher wattage transmitters that work better, and things like that. Whereas I had one single nicely built 37-pin box with the NavWorx, that had 2 antenna ports on it, I'm now stuck with mounting a GPS, a UAT, adapter cables to use with REAL antennas, a homemade box to fix all the crap that's wrong with the echo, and then connect it all with multiple molex connectors that are easy to yank pins out of accidentally, and then a DB15 for the box that fixes most of it. It's a hodgepodge of a mess. If you have a good panel mount GPS you can at least save that space and wiring, but nothing will ever make the Echo as good as the system it replaced...except for the nice iPad app interface, and the fact that it receives on both frequencies. But the box can at least make it a viable system, and for me it'll fix the issues well enough until I can afford to upgrade to the NGT-9000.
Lets just hope the FAA doesn't dig in to the Echo UAT far enough to discover all of it's weaknesses, or we could find it on the "Not approved" list like what happened to NavWorX. Having the RS232 output for EFIS integration without doing traffic alerting is a huge miss, as is not having perfectly solid Baro altitude reception.

REQUIRED SETUP!!

Before you install the box in your airplane, MAKE 100% sure that you have the proper ICAO Code programmed in your echo. Go to the FAA N-Number Inquiry Page http://registry.faa.gov/aircraftinquiry/NNum_Inquiry.aspx   and search up your aircraft.   Look for the Mode S code. NOTE: I've seen users try to program the Base 8 Octal code into their Echo's before. This is NOT CORRECT!!   Use the base 16 Hex Code.    On the Echo, you enter that code as-is. On "The Box" you enter it with a 0x in front of the number. I will set the default code to 0xABCDEF or 0xABC123. You will want to change the letter strings to your proper code.   Do this on the int32_t ownModeSCode= line of the code.

Beyond that, just read through the above settings and scan through the code and see that they are all set the way you want them. I would suggest setting the maintenance override to false unless you get constant annoying errors. That happened to me but it was because of the transponder monitor mode not working correctly when not interrogated. You may also want to set the number of intruders to display on your EFIS to something else. const int maxIntrudersOut=20;    I think 20 is good number, and certainly I would not encourage you to go over 30.   For const int maxIntruders=60;   I would leave that as-is, as it's the number of intruders tracked...not transmitted. You can set the traffic max range and upper and lower altitude limits to your preference as well. I would think most people would want to keep the traffic limited to within +/- 5000' or 6000' of their altitude to avoid showing UN-necessary traffic. Remember, too much screen clutter leads to LESS Safety. Your brain has to interpret everything that it is shown, and if you are bombarded with traffic that you don't care about, it eats up mental cycles. Definitely not what you need while piloting a plane.

Keep in mind that while this fixes most of the issues when using the Echo UAT with your EFIS, it does not address any of them when using an iPad with Wifi. You will still see traffic randomly disappear or too many targets show on the screen, and all of the other issues that the Echo has, when viewing on iPad.

Integrating the box into your airplane

Although I can't possibly begin to give you diagrams on integrating this into any version of EFIS that you may have, I can provide you with my conversion diagram that I used to wire mine into my 2 airplanes. I have the Chelton EFIS. That does not mean that this only works with the Chelton EFIS. The Chelton uses a generic GDL90 data feed via RS232 at 38,400 baud. If you have an EFIS such as the AFS, that can handle 115,200 baud, it's easily changed in the code. For the most part, to display ADS-B on an EFIS, you're only looking at 2 wires, the RS232 data wire, and the RS232 signal ground. So just look at my diagram for the Chelton and replace the pins with whatever pins you would use on your EFIS.

Additionally, I originally had NavWorX ADS600B boxes in both airplanes and I wanted to replace them with Echo UATs, but if the Echo fell on it's face, I wanted to be able to throw the NavWorX boxes back in. So I purchased 37-pin connectors to make an adapter harness so that the Echo + skyFYX + The Box, would all wire up and look the same as my NavWorX did, and plug into the 37-pin connector that I used to wire my NavWorX. I figured that since ALL of the signals were there, such as Altitude Encoder, Transponder Squawk, Power, Ground, and Display OUT and signal ground, that with a little splicing I could have everything I needed. It worked out real well.

Here is a diagram of converting an ADS600B NavWorX system with 37-pin connector, to interface to the Echo UAT with "The Box"

Here is a diagram of a generic EFIS and the wiring to the Echo UAT with "The Box"

So from a wiring perspective, this diagram (click it to view or download the .pdf version), is what I am running in my planes and would work for anyone with a NavWorX ADS600B. Either way, you can see that the Echo UAT has only 2 connections to "The Box". One to send it GDL90, and one to receive the GDL data with Squawk and Baro Altitude. "The Box" has inputs for GTX (Squawk), and ICARUS (Baro Alt), and an input FROM the Echo for GDL90. The GDL90 filtered output is sent to your EFIS's receive port. Other than that, it's just power and ground wires. So your wiring should be pretty simple. When I get time, I'll try to post a non-37-pin-converted version just so that it looks simpler.

RS-422 Wiring Diagram

If you are building an RS422 version, this is the wiring diagram that you would use. Note that the code is different too, slightly, simply because RX channel 3 is used for the RS422 Input, rather than RX channel 1.

RS-422 Wiring Diagram with Chelton Specific info

If you are building an RS422 version to use an NGT9000 or GTX345 with a Chelton EFIS, this is the wiring diagram that you would use. Note that the code is different too, slightly, simply because RX channel 3 is used for the RS422 Input, rather than RX channel 1.

Project Box Labels
If you need labels for your RS232 or RS422 box, here are a couple of generic label sheets you could use.

A word about the project

This project is relatively a cheap build. It should cost ~$100 give or take, to get everything needed to build one. The boards are, at the time of writing, $31 for 3 of them. I would suggest that you just plan on eating the cost of all 3 boards, and order them. That way you get them in hand, can inspect them, and if there are issues you can talk to OSHpark about it. I did have one board with a bad trace. It was a fluke. But, since I had one spare board in the order, it didn't slow me down. If you end up building one and it works well, just offer your extra boards on the forums to others who want to build one. I'm sure they'll be happy to give you part of your $31 back. I myself spent hundreds of dollars and a few orders of boards, and threw away many components while I was testing. Most of them were not even bad, but de-soldering some of these things is next to impossible. But I wanted to make sure that everything was as good as it could be, if this was going to be an open-source project. The only thing I missed is putting a 3A schottky diode on the board. With the Teensy 3.6, if you power it by USB, it will backfeed the power to your other avionics unless you pull the breaker. Adding a diode prevents that. Even though there was cost in my project, and literally hundreds and hundreds of hours spent my me and my programmer friend, we aren't "selling" this project. It's open source, for you to do as you please. We don't want any money for the efforts, as it's nice to help the community at times. That said, I know that people often like to donate when they have something nice done for them...I know I do. So, if you do feel like donating something, I won't turn it down. I simply ask that you do not send anything unless you build a box, and it works well for you. I don't want anyone to waste any more money on something they aren't happy with. Donations we do get, will be used for airplane goodies, probably at Oshkosh, or maybe to help us pay for our camping at OSH. We're aviation geeks at heart, so it's all aviation dollars. :)

Here's a donate link if you decide you want it, but feel no obligation.

Also, I would like it if anyone building this project, would get on VansAirForce.net and search up the thread where we talk about the box, and add a comment about it, if it's working for you. The only way people will know about the project is if they hear it by word of mouth.

Good luck with your build! And remember, this doesn't just work with the Echo UAT, but can process and filter most any GDL90 format ADS-B stream. If you have an iLevil 3AW like I have as a backup system in one plane, or any other ADS-B system that runs GDL90 over RS232, this project may add the functionality you are missing today.