Issues with the EchoUAT

Keith
Posts: 15
Joined: Mon Jan 06, 2020 10:27 pm

Re: Issues with the EchoUAT

Post by Keith »

Charlie,
No I did not switch to using the EFIS as the pressure altitude source. That comes from a Trans Cal encoder that is wired to the KT76A. In the set up screen for the Sport EX, I can filter both distance and altitude for which traffic to display on the screen. I am not aware of any traffic filtering that can be done from the EchoUAT unit itself. I don't recall seeing anything like that on the EchoUAT app that was used to configure it. I also still use the iLEvil unit feeding ADSB in data to my iPad (via WiFi)where I use WingX and FlyQ for traffic display. Both of those programs have the ability to filter which traffic I see. To be clear, the GRT Sport EX uses the EchoUAT for ADSB In data displayed on its screen. The iLEvil unit I now use as back up AHRS and also still use WingX and FlyQ for displaying that data on the iPad. Completely independent of the EchoUAT unit and the GRT unit. Hope that helps
Keith
Keith
Posts: 15
Joined: Mon Jan 06, 2020 10:27 pm

Re: Issues with the EchoUAT

Post by Keith »

rv7charlie wrote:Hi Keith,

I appreciate the info. Interesting that installing the EFIS would improve your 'out' performance. Did you switch to using the EFIS as your pressure altitude reporting source when you installed it? I have heard about 'issues' with using some of the older mode C transponders to 'drive' 978MHz ADSB transmitters, but it sounds like your transponder isn't affecting your performance.

Have you played with traffic filtering with the EchoUAT unit? Has uAvionix fixed their 'firehose' issue of sending every target, regardless of altitude/distance?

Thanks,

Charlie
One more thing-- I think the improvement came from the software update to the EchoUAT unit. If you think about it, that is the only thing that changed as far as ADSB out is concerned. I was going to manually update the ECHOUAT software until I noticed that when I connected the Sport EX it updated. Doesn't make a lot of sense to me as to why that happened unless that when I connected it to the Sport EX, the Sport EX saw that I did not have the latest software and it automatically updated it. At any rate, the improvement was dramatic what ever the reason.
Keith
rv7charlie
Posts: 17
Joined: Mon Oct 13, 2014 6:28 pm

Re: Issues with the EchoUAT

Post by rv7charlie »

I *really* appreciate you taking the time to share your experience; the docs on both uAvionix and GRT tend to be a bit 'center of the universe' (the writer knows all the references and assumes everyone else does too..).

So, you're using the Echo to 'sniff' the KT76's RF for squawk code & altitude, and the EFIS is still able to 2-way communicate with the Echo? If you have a 'soft' copy of your hookup diagram, I'd be grateful if you could email it to me.

My email address is: mcsophie@gmail.com

Many thanks!
Keith
Posts: 15
Joined: Mon Jan 06, 2020 10:27 pm

Re: Issues with the EchoUAT

Post by Keith »

rv7charlie wrote:I *really* appreciate you taking the time to share your experience; the docs on both uAvionix and GRT tend to be a bit 'center of the universe' (the writer knows all the references and assumes everyone else does too..).

So, you're using the Echo to 'sniff' the KT76's RF for squawk code & altitude, and the EFIS is still able to 2-way communicate with the Echo? If you have a 'soft' copy of your hookup diagram, I'd be grateful if you could email it to me.

My email address is: mcsophie@gmail.com

Many thanks!
Charlie,
Yes that is correct. The Echo "sniffs" the KT76 for squawk and baro altitude. While the EFIS has the ability to configure the ECHO, I think on a regular basis it only is receiving info (ADSB "in") from the ECHO and is not sending anything back to the ECHO. If I had a newer style transponder, I could have controlled everything via the EFIS (including squawk code). I am not real knowledgeable about how this all works so am at the limit of my understanding. I just followed the EFIS configuration instructions for my particular set up and it worked. I will try and find some more information tomorrow about how I have it all configured and send you an email directly.
Keith
rv7charlie
Posts: 17
Joined: Mon Oct 13, 2014 6:28 pm

Re: Issues with the EchoUAT

Post by rv7charlie »

Thanks!
GRT_Jeff
Posts: 656
Joined: Tue Dec 11, 2012 12:11 am

Re: Issues with the EchoUAT

Post by GRT_Jeff »

There are a few ways to wire up a Safe-Fly and echo. If you have the control interface wired and the echo configured to listen to the EFIS for setup then it can get altitude directly from the EFIS. The Safe-Fly can be updated from the EFIS on command, but the echo can't. There haven't been any updates to the Safe-Fly since we started selling the package with the echo. The only way to update the echo is to access it over WiFi with a web browser. I haven't heard of any changes to their filtering. They have one update on their web site for performance in high traffic areas but it doesn't say if that improves IN performance or what the specific improvement is.
rv7charlie
Posts: 17
Joined: Mon Oct 13, 2014 6:28 pm

Re: Issues with the EchoUAT

Post by rv7charlie »

Thanks, Jeff. Of course, this is beginning to feel a bit like cutting edge physics; every answer raises more questions than it answers. :-)

My current situation is similar to Keith's; my G327 currently gets altitude from a standalone encoder. I do understand that a direct connection (rather than sniffing the transponder RF) will make communicating altitude & squawk more reliable. When you say that the EFIS can send altitude data, I assume that means the EFIS would be acting as the encoder for the transponder mode C, as well, right? I wouldn't think that I could legally feed the XP mode C from an encoder and the ADSB from the EFIS altitude output. Now, I'm due for a transponder static check, so it wouldn't be that big a deal to make the EFIS the altitude source, but it is more work.

edit: There's a separate discussion on another forum about uAvionix's MUX. Is it correct to say that if the EFIS serves as the encoder, no MUX is needed, and if a separate encoder is used, the MUX would be required?

Thanks,

Charlie
Bobturner
Posts: 425
Joined: Mon Mar 11, 2013 6:34 pm

Re: Issues with the EchoUAT

Post by Bobturner »

You are correct: the rules require the same altitude source drive both the transponder and the adsb-out device.
GRT_Jeff
Posts: 656
Joined: Tue Dec 11, 2012 12:11 am

Re: Issues with the EchoUAT

Post by GRT_Jeff »

If the EFIS and wiring is set up for the control interface to the echoUAT using the TMAP connection, and the EFIS has altitude, then the echo will read and use altitude data from this connection. There is currently no way to disable this in the EFIS or the echo. The echo still needs to get the squawk code by listening to the transponder. In your case you would end up with separate altitude sources this way unless you also change the 327 to get altitude from the EFIS.

If the echo is not using the TMAP connection to the Safe-Fly and EFIS (no-EFIS-control mode), then the echo will listen for both altitude and squawk code from the transponder.

The mux is used to wire both altitude and squawk from encoders and transponders with remote serial interfaces. If your altitude encoder is serial and uses the Icarus/Garmin/Trimble format, then you can wire the encoder and 327 remote interface to the mux to directly supply altitude and squawk code over serial connections to the echo. It's not possible to control the echo with the EFIS this way so you have to use an alternate configuration for the echo and Safe-Fly. That normally means telling the Safe-Fly to send 115200 Safe-Fly NMEA data out of SPC Port 3 and configuring the echo for the mux with 115200 NMEA GPS input.
Post Reply