More updates on my NavWorX replacement with EchoUAT
The past few days I've had a few flights with the Echo UAT and am starting to see a trend. I'm curious as to how it is for other people as well.
With the Echo I'm seeing lots and lots of times that traffic randomly comes and goes. I see it on the ipad and there may be a bunch of planes on the north side of a class Bravo area, then a minute later those flash out and maybe there will just be a couple of random targets but a few seconds later there are a large group on the south side of a class Bravo. So it appears that traffic is very intermittent.
Bench testing the unit with a "Ted" stubby antenna, I find that a stratux unit (I have a Seattle Avionics Merlin), has quite a bit better reception range, but that's just a side note.
One thing that I've been plagued with much more often than with the NavWorX is with ghost traffic in my location. I am used to a ghost callout for "traffic" maybe once every month or two, when flying around class B areas, but I now get ghost traffic multiple times on some flights. Yesterday I probably had ghost alerts 6-8 times in less than an hour.
Based on the above, I'm thinking that there is not nearly the processing/filtering being done that the NavWorX did. As you may have noticed from a previous post, another RV builder and I have been working to build a filter/converter box for the GDL90 data coming out of the Echo. Right now the output isn't in GDL90 format, but it would be easy to do so. But in the process of logging GDL90 data, and feeding it in, processing it, and outputting it, we are finding multiple things that can easily be improved in software.
Here's a rundown of a few off the top of my head:
Coasting: By using a short-term table of nearby targets, sorted by distance, and coasted, we are able to greatly reduce the blinking out of these targets. You keep track of Vertical speed, speed, altitude, and track of the targets, and when they disappear, if they were in your table (we keep track of 31 nearby targets), you use their previous reports to generate traffic output that would continue their previous trajectory. We have it set to a user definable setting so you can receive projected traffic positions for an extra 15-30 seconds after it blinks out on the UAT. If it pops back up, the position updates and everything syncs back up, as each target is tracked by Mode S code.
With the sorting by distance, I only send to my EFIS a max of 31 targets, and they are only the 31 nearest ones that are heard. If a new one pops up, it displaces the furthest one from the list. This coasting really makes the system much more useable since you don't constantly lose and regain targets.
Ghosting improvements: By keeping track of ownship track/speed/altitude and comparing it to any targets within a certain very close range (a few hundred feet), you can look at that targets track/speed/altitude and if the parameters closely match yours, and the position is within a couple hundred feet, you can blow it away and eliminate the ghosting.
COM Port Speed matching: One nice thing about doing this by a post processing box is that I was finally able to use my GTX wire connection for the UAT. If you remember in previous posts, I said that one of the pains of the box is since the ports aren't asynchronous, you can't have a 9600 baud transponder connection, and a 38,400 baud EFIS GDL90 connection on COM1 TX/RX, and you are fairly locked into using 115,200 baud on COM2 with the SkyFYX GPS, so that eliminates using a 38,400 baud EFIS on that port. But, by post processing it, it made it possible to push the GDL90 at 115,200 baud to this box, process it and filter it, and then output it at 38,400 baud, allowing the box to be integrated into COM2. That frees up COM1 for use at 9600 baud with the transponder. Once I did that, my squawk code was able to change immediately when I tested it. Before this, I tried in-flight quickly entering 1234 and noticed that the UAT did not receive the update. This was on climb-out, and I didn't wait a long time to see if it would finally get the squawk, as it was not my assigned code, but it did illustrate that you may have a delay in switching squawk codes by the monitor function.
Max Intruders: Another nice feature is being able to limit the output a little to not clutter the screen with too many intruders. I can user configure a setting to display any number from 1-31 of intruders. Once you get near the top of that range, you can make your EFIS so messy that as I was flying around MSP airspace, you could barely read the airport info or airspace info within the class B area with as much traffic as their was. Having a way to limit counts is a great thing...having it sorted by distance is crucial then though.
Distance filter: Rather than just pick up traffic from whatever the default distance is, I have a user-defined variable for setting the maximum target distance, so it does not pass on or display anyone further out than that. This keeps down the unnecessary processing of the other targets, because if someone is over 100nm away, you really don't need to know about them.
Anyway, this is just a little of what I've bee working on and finding, but I'm curious as to how common this ghosting is for others using the Echo, and how much disappearing traffic you have. Those things should be fixable as Uavionix puts more time into developing the software, so hopefully if you are having issues, you can see those things improve down the road.