While playing with a new release of Stratux software, it detected a number of bearingless targets. All seemed to originate from a single plane transmitting Mode-S, but I got multiple targets which jumped around on the screen and also changed symbols between GA and jet planes.
Here's a capture:
It would be nice if this would be a bit more smooth.
I guess you have to ask Stratux? Not much we can do about it I fear.
There is no standard at all how bearingless traffic is to be coded in GDL90. uAvionix uses it's own methology, PilotAware has also its own "dialect", and I don't know how Stratux encodes bearingless traffic. Its the uavionix code combined with PAW code combined with FLARM code combined with GDL90 preferred way of handling traffic who's position is not accurate that seem to pickup these Stratux coded bearingless traffic.
Normally each aircraft (bearingless or non bearingless) is encoded using a unique identifier that can be used to uniquely identify targets. The 6 aircraft mean there are either 6 unique id's, or 6 entries with no ID at all (I suspect the latter). In my personal experience only FLARM and PAW can do reliable bearingless traffic, but in honesty I probably have missed a few developments on the other products.
The circles represent the estimated range as provided by the device, often by "abusing" the NACp datafield in the GDL90 datastream.
I am using https://github.com/b3nn0/stratux . This is a fork that does a good job in keeping the main code in sync with the main stratux development, but adds pretty good Flarm support to it. I found the offending code in 'traffic.go' which actually tries to plot 8 planes in 45 degree intervals. It uses a different ID for each plane, which makes it look like there are multiple planes. Distance is calculated from signal strength combined with type of aircraft (larger usually has stronger xpdr) and altitude (>FL100 is big ship). It's a guestimate..
Unfortunately it's developed in Go, for which I have no development tools. Oh well... I'll report it to the developer and see if we can get something done about it.
Statux Europe Edition is apparently sending data about bearingless traffic both via GDL90 and FLARM. Since GDL90 does not support bearingless targets, this edition of Stratux is sending those dummy targets via GDL90 and also bearingless target via FLARM. I think the best solution would be to create a switch in EV4 settings to manually enable/disable GDL90 and/or FLARM for traffic reception. This would be especially useful if there are similar issues with other traffic detection devices.
That might be a fix. Meanwhile I have 'tamed' Stratux EU a bit. The source code and compiler are actually on the SD card, so you can edit and make your own version. I have modified my version to only show two targets instead of eight. They are at 90 and 270 degrees, and with this the display of bearingless targets is pretty good.
I managed to find a workaround by disabling GDL90 output from Stratux. It requires changing /etc/stratux.conf file and deleting the following lines:
{
"Conn": null,
"Ip": "",
"Port": 4000,
"Capability": 5,
"MessageQueueLen": 0,
"LastUnreachable": "0001-01-01T00:00:00Z",
"SleepFlag": false,
"FFCrippled": false
},
Stratux then send the data via FLARM protocol and EV4 shows single traffic information about a bearingless traffic, which is the closest one, as a circle and banner.
Unfortunately I also noticed that the connection between Stratux and EV4 over FLARM (both UDP and TCP) is dropping once every 20 seconds or so.
--
Another question related to Stratux is: which altitude unit does EV4 expect to receive, MSL or HAE (height above ellipsoid)?
Another question related to Stratux is: which altitude unit does EV4 expect to receive, MSL or HAE (height above ellipsoid)?
It doesn't really matter, you can (should ;-))) always "calibrate" you device using menu->system, there is an option called "AMSL geoid correction".