-
-
Notifications
You must be signed in to change notification settings - Fork 66
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Bearingless Targets #39
Comments
For GDL90: since it doesn't support the bearingless targets, this is just emulated by placing 8 fake-aircraft in a circle around you. That is far from optimal, but there is really no other way that works with existing EFBs. This can be disabled by the settings switch. The switch is mainly there to allow users to disable the 8 fake-airplanes that can certainly be distracting in some instances. And wrt. quality of range estimation: from my experience, the current approach works quite well in the <=5nm range. It's not precise of course, but then again - does it really matter if the traffic is 2,0 or 1,5 miles away at same altitude? Both values will put the pilot's guards up and make him look out the window for traffic. EDIT: note, that the observed factors for the different groups usually are less then about 50% different, so even if you encounter a descending airliner in low altitude, you would see him at 2nm distance instead of 3nm. Which is good enough to remind you to look outside. |
That explains why I don't see it on GDL90, as my Stratux box does not contain a GPS :-D. I don't know how other EFB's parse the traffic report, but another - or aditional - way could be using the Integrity/accuracy (NIC/NACp) fields in the GDL90 traffic report.? I agree that the WebSocket string does not break anything. In fact its a better way to do it, as it leaves the choice to the end product. Regards Lars |
Don't think there are many Stratux boxes without GPS around. Are you relying on your own transponder to be received by the Stratux as a position source? Or do you simply not care about the Stratux positioning as you only use the traffic information (should probably be enough for your app)?
I know of at least one EFB that properly supports the Stratux way now: Stratux gives the fake targets the tail number "MODE-S", which makes it identifyable. The EFB will then filter out all these targets, compute the distance to them, and then draw a real circle and handle it as a bearingless internally. |
Where are you based? If you are in ITU Region 1 (Europe/Africa) then all is fine. Just checking because FLARM ist also used in other regions, e.g. Australia which would require a settings change in Stratux. |
We have a lot of home-build stratux boxes that are basically just a RaspPi and one or two DVB dongles. No GPS/Presssure sensor/AHRS. For my App the user can choose position source. Either the stratux ownship report, a specific transponder ID, or the device's own GNSS. You can also make a combination, where the altitude is taken from the transponder, but the position from the device. (for planes with just basic mode-S)
Most of the gliders here fly in TMZ's. (DK), and thus have mode-s transponders. I would guess that some of them also have FLARM, but I don't know. I did get a few FLARM package last afternoon on my flight, but not much. It's most likely due to antenna stuff rather than not being transmitted. The airspace was packed with gliders and I was constantly being vectored around them :-D
This is my point exactly. Just because a product (EFB) has poor/bad/wrong support for some fields in the protocol should not mean that another (wrongly) protocol gets introduced. I'm all for workarounds like you have made, as long at it is that - a workaround - and can be disabled (which your's can). |
Hm.. but then again, isn't NACp just a workaround aswell? Even more though, because it conflicts with what NACp actually means. I think the only conformant way would be introducing a custom message - but what good is that for if nobody supports it. Still, that would be the option I'm most open to. And leave the current switch in there to be somewhat compatible to EFBs not wanting to support it. I think there are 1-2 EFB developers I could convince to implement it. Maybe that would get the ball rolling enough, who knows. EDIT: And IF we decide to make our own message for this, we need to evaluate what the message type byte will be.. Additionally, Foreflight defines 0x65 = 101 as their own message type and splits that with a subtype (https://www.foreflight.com/connect/spec/): Stratux also has custom types already (https://github.com/cyoung/stratux/blob/master/notes/app-vendor-integration.md): |
The NACp signal is broadcasted on the extended mode-S telegram (i.e extended squitter), and this is (most likely) just forwarded in the GDL90 spec. The GDL-90 box is just a retransmitter device, so that probably why the protocol is like it is. A custom message is not at bad idea. Maybe with a disable option in the settings, as it is non-standard GDL90. But then again the stratux GDL90 is already non standard that can't be disabled :-D. I know there has been experiments with a A/C decoding in dump1090 but not sure how far it went. Maybe some day this will also be included (or maybe it is??), and that could be transmitted on GDL90 in the same way as we are defining now (i.e. targets with estimated position). |
As an author of something that uses the Stratux box (Stratux for Android) , I was curious about the bearingless targets.
I can see that there is a switch in the settings that can enable/disable it, but It does not really seem to do anything.
The estimated range is always attached to the WebSocket output regardless of this switch.
As for GDL90, your text implies that this also includes estimated range int the traffic report. However the specification for GDL90 (or at least the version I have) do not have a field for this.
Is it transmitted as a different/custom package?
Basically I think that it should not be op to the Stratux box to do these estimations, but if you can disable it in the Stratux I see no harm in having it as a feature the user can choose from. (but it should not transmit the data when disabled)
I did some tinkering with the range-estimation based on receiver strength myself, but a lot of logging later, I still have not been able to come up with a good enough algorithm.
Regards Lars
The text was updated successfully, but these errors were encountered: