What's new
Van's Air Force

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

uAvionix replacement for Navworx EXP

No problem with the 56

I have used the same G56 for the Navworx and now, for my uAvionix Skyfx and have no problem getting clean reports.

R.
 
Uavionix echo and Chelton

I installed the uavionix echo in my RV 10 and have passed the faa test. I get traffic and weather on my IPad but can not get either on my cheltons. I have been working with both chelton and uavionix but nothing works.
I have been told that several RV 10?s with chelton?s are working. Please help me figure this out.
Sam 817-821-7971
 
How to enter the "secret" advanced menu?

Even though I passed the FAA test, I'm still having issues with disappearing traffic (327+iPad+FlyQ). I'm still working with Ryan from Uavionix and I want to run out the hangar after work today and send him a screen shot of my setup.

I forgot how to enter the "secret" advanced menu. Does anybody remember how to do that?
 
Even though I passed the FAA test, I'm still having issues with disappearing traffic (327+iPad+FlyQ). I'm still working with Ryan from Uavionix and I want to run out the hangar after work today and send him a screen shot of my setup.

I forgot how to enter the "secret" advanced menu. Does anybody remember how to do that?

Hi Kelly, the secret handshake is tap the Echo logo at the top of the screen with two fingers once you've connected to the Ping wifi and started the app.

I've got an Echo with GRT's SafeFly 2020 GPS, have most current Echo software and still get disappearing traffic both on my GRT display and my iPad. Curiously the GRT display will also typically show more ADS-B ground stations than my iPad. Please report back anything you learn from Ryan!
 
Hi Kelly, the secret handshake is tap the Echo logo at the top of the screen with two fingers once you've connected to the Ping wifi and started the app.

I've got an Echo with GRT's SafeFly 2020 GPS, have most current Echo software and still get disappearing traffic both on my GRT display and my iPad. Curiously the GRT display will also typically show more ADS-B ground stations than my iPad. Please report back anything you learn from Ryan!

Thanks Lars. Will do. I sure hope they can figure this out.
 
I had traffic I was in formation with in .25 mile trail that disappeared on me randomly for periods of time this weekend. Sometimes it would be steady, sometimes it would just go away.

One side note: After some test flying of the GDL90 filter I'm working on, I found out that the Echo is not sending traffic alert data at all. i.e. if you don't have an EFIS that will do all the collision calculations for you, you will not get traffic alerting. I met up with an airplane head-on within 200' or less of altitude and less than .2 miles away, heading right at eachother and we each banked right and flew right past our wings, and there were no traffic alerts.
Some systems, like AFS/Dynon may be taking the raw data and doing their own collision algorithms on it, but the NavWorX I used to have did all of this already, and my EFIS does not. So, I don't get traffic alerts. So the GDL90 filter project of mine now adds traffic alerting to the data stream. I was just flabbergasted that the box wasn't sending collision alerts.
 
Last edited:
... So, I don't get altitude alerts...the GDL90 filter project of mine now adds traffic alerting to the data stream...

I assume you meant to say you don't get traffic alerts?

I know the 4500 and prior AFS EFIS' don't provide any traffic alert functionality.

Tell us more about your GDL90 filter project that adds traffic alerting. Is this part of the GDL90 protocol where you are injecting alerts into the existing data stream? Or are you handling with a discrete alarm or a discrete audio ouput?? I would be very interested in that.

My GTX-330 Mode S TXPDR provides audible traffic alerts which are indispensable IMHO. I am loathe to transition to a system (ADSB) that does not provide similar alerting functionality. If your eyes aren't glued to the screen, you miss a lot of conflicting traffic without an (audible) traffic alerting functionality!!!
 
Shane still with uAvionix?

Anybody have dealing with uAvionix lately? I read that Shane is no longer with the company. I spoke with Shane on the Friday before SNF via phone. We spoke for ~ 45 minutes and all seemed well.

I was getting ready to place my order this week for echoUAT+SkyFYX-EXT bundle for my RV-12 and now I?m on the fence. Remember the Navworx fiasco? I?m going to hang loose for a while?
 
Anybody have dealing with uAvionix lately? I read that Shane is no longer with the company. I spoke with Shane on the Friday before SNF via phone. We spoke for ~ 45 minutes and all seemed well.

I was getting ready to place my order this week for echoUAT+SkyFYX-EXT bundle for my RV-12 and now I?m on the fence. Remember the Navworx fiasco? I?m going to hang loose for a while?

Shane was working the uAvionix exhibit at Sun 'n Fun and I was in email contact with him regarding a uAvionix matter as late as 4/18.
 
Sorry, yes, I meant I don't get TRAFFIC alerts. (Not sure why/how I typed "altitude") It's just one major additional place where it isn't really a good replacement for the old NavWorX box. The NavWorX programmers are starting to look like real experts now...too bad on the business end they made some unhappy customers.

The GDL90 filter box I'm working on does many things now.
1) Adds GTX format input from Garmin Transponders

2) Adds ICARUS Altitude format from most encoders

3) Combines those 2 into GDL (SL-70) Format to send in to the Echo.

All of the above are 9600 baud and go into COM1.
This fixes completely the problems I've seen with "ADSB Maintenance Failure" alerts that were being caused by non-regular reporting of Baro alt to the EFIS, and allows hard wiring the transponder and encoder to the Echo just like was done with NavWorX, so the Baro Alt is now reliable and so is squawk.

4) Receives 115,200 baud GDL90 data from the Echo.

5) Allows GDL90 (Processed) output at whatever baudrate is necessary for the EFIS.

6) Filters traffic by a user defined altitude above, and also one below, so you do not see traffic that is so far above/below you that it would just be screen clutter.

7) Sorts the remaining traffic by distance from Ownship, creates a table and keeps an updated table of all traffic in order of distance. Allows you to limit number of targets sent to keep screen clutter down AND prevent overrunning what the output baud rate can handle, and all targets can get sent per the GDL90 spec in ONE segment. Now you never miss the nearby targets that you sometimes would miss due to overload on a stock Echo.

8) Provides coasting of traffic for a few seconds so if you miss one or two seconds of their transmission they don't just disappear, but it projects based on their speed, track and VS where they will be for a few seconds before it just drops them from the table. The coasting is also user definable.

At this point you now have reliable traffic display and nobody blinks out.

9) Adds traffic alerting functionality for traffic that is "a factor". Right now we have fully functional some basic alerting where if someone gets too close to you it sets the proper bits on that target to cause your EFIS to call out "TRAFFIC" like it should. MEGA safety benefit there over the stock "dumb" Echo UAT. We're working on a collision trajectory based algorithm yet that is smarter that knows if a target is closing in or moving away from you, and how many seconds before it collides with the safety "bubble" around you. This should make it so that if another plane is no factor, you don't get an alert, such as any opposite direction traffic after they pass by you, and many more things. It also takes into account Vertical speed of both ownship and target.
But we're still finishing that up.

10) De-Ghosting. (also called Shadowing I guess officially) I've had some bad problems with the Echo having shadow targets of myself when flying anywhere near some class B areas. The NavWorx did it VERY VERY rarely too, but the Echo does it often. Sometimes when the FAA sends up primary targets it sends you your own target as well. This shows up as constant traffic right at your position. We've got some additional filtering in place now to try to make sure that these false Ownships don't get sent to the EFIS, at least when they're right at your position going your direction at your airspeed and track, and with non-ICAO code identifiers. So this helps eliminate all those spurious ownship targets that plague me with the Echo.

11) And finally, one special custom feature that I wanted....the ability to NOT alert on the handful of people that I fly formation with, so that we can keep our traffic systems on, even when in formation, and still continue to get traffic alerts on all the other airplanes out there. This is done simply by adding their ICAO Hex code to a list.

I can't remember if I missed anything, but, the Echo goes from being something that I wanted to throw against a brick wall and then drive over with a truck, and burn with a torch, into something that actually functions...although I highly doubt it has the performance that someone who purchases a nice new GTX345 or Lynx NGT-9000 would have. But as long as the FAA doesn't start getting too many negative reports and the box still qualifies as "Legal", it should help make it a box that I can live with until I can save my oodles of pennies it takes to get something more. I'd be interested in their transponders, except I get the feeling that since all of these things are mostly software issues, I'd be expecting similar issues there as well.
 
Noah,

Are you going to make the GDL90 Filter Project available to others that have the uAvionics system replacement for the NavWorx 600EXP units? I'd definately be interested....


I assume you meant to say you don't get traffic alerts?

I know the 4500 and prior AFS EFIS' don't provide any traffic alert functionality.

Tell us more about your GDL90 filter project that adds traffic alerting. Is this part of the GDL90 protocol where you are injecting alerts into the existing data stream? Or are you handling with a discrete alarm or a discrete audio ouput?? I would be very interested in that.

My GTX-330 Mode S TXPDR provides audible traffic alerts which are indispensable IMHO. I am loathe to transition to a system (ADSB) that does not provide similar alerting functionality. If your eyes aren't glued to the screen, you miss a lot of conflicting traffic without an (audible) traffic alerting functionality!!!
 
Noah,

Are you going to make the GDL90 Filter Project available to others that have the uAvionics system replacement for the NavWorx 600EXP units? I'd definately be interested....

<Ahem> I'm not the originator of this device, TimO is, but I might be interested in something like this as well, due to the limitations inherent with the Echo as demonstrated and carefully documented by Tim here:
http://www.myrv14.com/N14YT/20180320_ADSB_Update/index.html#Why_Im_Not_a_Fan_of_the_Echo_UAT
 
Has anyone heard from uAvionix? Would sure be nice, if uAvionix would provide an update as to whether they are working on a software update for the UAT to address the concerns that Tim Olson has voiced and is continuing to solve with his VERY novel interface.
 
On the boards, I'm not 100% sure yet as to what I'll do going forward. Certainly from a hardware perspective I'm likely interested in allowing people to build their own. On the software side, I'll have to discuss it with my buddy who's really the brains behind the software (and he laid out the hardware too).
I guess I'd say stay tuned for a bit and lets see. I want to finish getting the collision alerting working just right in a way that guarantees that it generates alerts in all situations that traffic is a factor but doesn't alert for things that are not. Once that is all tuned in, I'll see where we're at and maybe it'll be all open sourced for people to build and use. It was a considerable amount of work...really I'm sure in the couple hundreds of man hours, so I don't want to make any promises without approval from my very hard working pal.
It really does improve the box though, and does it better than anything else I can think of, including the active harness they made at uAvionix. The issue is that without an entire post-processor, you are left with a box that actually CAN integrate to your transponder and encoder, but with the limitation that the output GDL90 would have to be the same baud rate as the input GPS that you're using...and that would not work for me as my EFIS is 38,400 baud and the transponder/encoder systems run 9600. So to date, even though they have tried to come up with a harness that fixes some of these issues, it falls short of being something that would work for me. And when you factor in the lack of traffic alerting, it falls short enough that I would toss the system altogether without fixing that.
 
Tim,

Thanks for thinking about it. I have to give you guys a lot of credit for taking on this project.

I'm looking for just the ECHO output filtering functions as I have a GTX330 transponder supplying the squawk code & altitude to the ECHO device. My GRT EFIS's (3) can receive the ECHO 115200 baud output, but they are still overloaded with the traffic flow (resulting in dropouts).

I have the ability to stuff the board, and probably load the software. I'm a retired Electrical engineer that used to build control systems (10 years ago).

Let us know what you decide...

On the boards, I'm not 100% sure yet as to what I'll do going forward. Certainly from a hardware perspective I'm likely interested in allowing people to build their own. On the software side, I'll have to discuss it with my buddy who's really the brains behind the software (and he laid out the hardware too).
I guess I'd say stay tuned for a bit and lets see. I want to finish getting the collision alerting working just right in a way that guarantees that it generates alerts in all situations that traffic is a factor but doesn't alert for things that are not. Once that is all tuned in, I'll see where we're at and maybe it'll be all open sourced for people to build and use. It was a considerable amount of work...really I'm sure in the couple hundreds of man hours, so I don't want to make any promises without approval from my very hard working pal.
It really does improve the box though, and does it better than anything else I can think of, including the active harness they made at uAvionix. The issue is that without an entire post-processor, you are left with a box that actually CAN integrate to your transponder and encoder, but with the limitation that the output GDL90 would have to be the same baud rate as the input GPS that you're using...and that would not work for me as my EFIS is 38,400 baud and the transponder/encoder systems run 9600. So to date, even though they have tried to come up with a harness that fixes some of these issues, it falls short of being something that would work for me. And when you factor in the lack of traffic alerting, it falls short enough that I would toss the system altogether without fixing that.
 
Sounds good Fred. Right now, my guess is that maybe a bit over a month from now I'll have enough time (since I have a trip coming up) where I can give some extended testing, that we'll decide what to do. The coding was a lot of work, and of course I wouldn't want anyone to take on any liability for any of it since it's all D-I-Y and coded by a trained monkey (not an insult....just want people to know that this wasn't written by a big name-brand certified company programmer). The collision alert programming is really the biggest part that I need to test out, at this point. The filtering/sorting works beautifully, as does the baro/squawk integration. At any rate, if this gets released I'd expect that the user would take their own responsibility for everything and test the system too, to ensure that it is doing what they expect it to be doing. But some parts of it have been flown for quite a few hours now and work really nicely, so I'm guessing that this will be something you can get your hands on eventually. Installation isn't too hard to add to an existing Echo UAT either. For people who go that route, I'd say make sure to buy some pins for those Echo molex connectors because you'll probably want to use most of the 6 pins.

More to come...
 
Right now I'm thinking about an Arduinio processor programmed in "C" to do exactly what you have already done. It would only have to filter the ECHO output (at 115200 baud) for range, ALT, collision alert, etc, and pass the resultant on to the EFIS displays. So far GRT hasn't done this, and I've only seen your attempts. Since this is just ECHO OUTPUT filtering process, I would just add this process in series with the current ECHO output, then send it to the displays.

Since this is display "IN" only, on an experimental aircraft, the aircraft owner has to take all responsibility/liability. I've been out of the software business too long to know how to do it myself, so any help you can give me is welcome (without any liability on your part).



Sounds good Fred. Right now, my guess is that maybe a bit over a month from now I'll have enough time (since I have a trip coming up) where I can give some extended testing, that we'll decide what to do. The coding was a lot of work, and of course I wouldn't want anyone to take on any liability for any of it since it's all D-I-Y and coded by a trained monkey (not an insult....just want people to know that this wasn't written by a big name-brand certified company programmer). The collision alert programming is really the biggest part that I need to test out, at this point. The filtering/sorting works beautifully, as does the baro/squawk integration. At any rate, if this gets released I'd expect that the user would take their own responsibility for everything and test the system too, to ensure that it is doing what they expect it to be doing. But some parts of it have been flown for quite a few hours now and work really nicely, so I'm guessing that this will be something you can get your hands on eventually. Installation isn't too hard to add to an existing Echo UAT either. For people who go that route, I'd say make sure to buy some pins for those Echo molex connectors because you'll probably want to use most of the 6 pins.

More to come...
 
I'm back from my trip and had a great trip of over 3000nm with both planes flying the GDL90 filter box. I did run into a lot of shadows of my own targets in many new areas I flew thru, but we were very conservative on how we filtered shadows in this version of software and that can easily be (and will be) improved shortly. At any rate, the hardware is doing well, and although we're planning to tweak a couple of software things yet, it looks like the GDL90 filter is basically ready for people to build if they need it. In the next few days I'll get some info together and show how you can build one for yourself. This is not a device that needs to be specifically used with only the Echo UAT, but you could use it with any GDL90 format RS232 ADS-B source, to help provide some of the functionality that is missing. For instance, my iLevil also doesn't filter ownship out (at least in the version of software I'm running now) and with this, I can fix that issue.

So, if you're one of the people who emailed me, hold on a very short bit of time and I'll shoot you an email and you will be able to start working on building one for yourself. We're going to treat it as an open source type thing so that you can enjoy a better ADS-B experience. This is NOT something I'm selling...just providing all the info you need to build one.
 
If you have emailed me about the project, you should have heard from me today. I got everything prepared so you can start building yours if you wish.
 
This is awesome Tim! Thanks for sharing your hard work.

I’ve ordered most of the components for mine, and I’ll report back when I’m up and running.

Don
 
Thanks Tim,

Oshpark boards ordered, Mouser next. I can't wait to get my ADS-B working right! Your documentation was very thorough and professional. Thank you for you dedication to this effort.

Henry
 
Can you explain how "friend" mode works? I'm hoping it de-lists this traffic before sending data to the EFIS, or at least disables proximity alerting.
 
The friend mode works like this:

In the code, you enter the ICAO codes of all of your friends who have ADS-B out capability.
You also have to enter a corresponding total count of all of the "friend" codes you have entered. (i.e. if you have 4 friend codes entered, enter "4" on another field so it knows how many it has to parse...it is in the documentation I think, but if not, let me know and I'll add it)

So when a code is a "friend", you won't get traffic alerts on them ever. This is important to know, and be careful of, because they could fly right at you and you won't get alerts...at least not alerts that are generated by the system. (your EFIS may generate it's own alerts, depending on the EFIS) The Echo doesn't generate ANY traffic alerts by default, so this box fixed that, but then removes friends from alerting. This allows you to fly formation with your buddies, and keep track of them all the time, without them having to squawk standby. (You still want to squawk standby when doing flight following in communication with ATC, so that only the lead squawks)

Additionally, depending on your EFIS capability (this works on my Chelton but may not on other systems, I'm not sure), if a target is defined as "friend", it changes some integrity parameters that are sent to the EFIS and on my EFIS it changes the target shape. I have it set so that any friend target further than 1nm away uses the shapes in the 2nd row to display the target. The default on my system is row 1. The thing that makes this nice is that if you are doing an in-flight meetup, and your EFIS supports this target stuff, you can pick them out of the crowd.

Display_Symbology2.jpg


I should note that I don't think AFS supports these other target symbols, but they have the benefit of displaying N-Numbers, while I can't on my EFIS, so this change in target type may not affect you display. The parameters are editable too, so that if you don't like the alternative target shape, you can modify it to normal.

There are other settings related that you can play with as well, and I've tried to document most of them.

The Friend code can be completely disabled, as well, if you don't want to use it, or if you just happen to be one of those guys who has no friends. :)
 
Tim,
My Mouser order arrived Monday (2 days ago), and my Oshpark boards arrive tomorrow. Weekend project will be to put my box together. I hope all goes together as well as I expect. Thanks again,
Henry
 
Just a note to say that one of my buddies using the filter box was not using ICARUS as his altitude format. He was feeding SHADIN Z format with ALT from a Grand Rapids EFIS. Our other buddy added some programming to handle that format for Altitude input as well, and it was tested on the way home from OSH. It worked. We're working on filtering shadows a bit more, but otherwise things are working out well.

Do most people use ICARUS (Garmin/Trimble) for their Altitude encoder? If not, a little more programming for other formats may be required.
 
Spoke with Uavionix at OSH - -

They said only one person has sent data for them to look at regarding dropping targets. For those waiting for an update, it may not happen unless they get more data. If the info they gave me is wrong, let me know. Thanks
 
Echo Help

ALL

does anyone know if using the UAVIONIX app in the monitor section, should my system be showing a pressure altitude while on the ground ? Also shouldn't it show the transponder code currently dialed into my transponder ? I seem to remember mine used to do that but now its not so I am trying to troubleshoot my issue.

In my last 6 flights according to the test reports I have spent a total of 3 seconds in ADS-B airspace, probably drug a wing through Albuquerque Class C, and I have been getting letters and emails from the FAA asking how and when I will remedy this issue.

KAEG - Pitts
Aspiring RV builder.
 
In my last 6 flights according to the test reports I have spent a total of 3 seconds in ADS-B airspace, probably drug a wing through Albuquerque Class C, and I have been getting letters and emails from the FAA asking how and when I will remedy this issue.

KAEG - Pitts
Aspiring RV builder.

If you fly in ADSB-out required airspace, you must have it, effective 13 months from now. But, once installed, you must run it 100% of the time, regardless of what airspace you?re in, and it must work properly. Your FAA letters are not necessarily related to being in class C.
 
Back
Top