stratux
stratux copied to clipboard
b3nn0
Bearingless Targets
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
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. For WebSocket: Well, you are right. This happens, because the websocket stream is really just a JSON-dump of the internal traffic structure. Just leaving that out isn't that simple. Then again, I don't see that as too much of a problem. If you don't want it, just ignore it.
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. The current approach splits the airspace in 3 regions (<5000, 5000-10000 and >10000ft), and "assumes" that aircraft in these regions will have similar transponder power. Small ultralights <5000 and large airliners > 10000, ... Then for each of these groups a factor is selected that is multiplied with the usual formula (6db drop=double distance). To tune this factor, we take ADS-B traffic in the respective altitude bands and compute the factor for these aswell, then slowly converge to the average ADS-B-factor-values. It's all a lot of guessing, but in practice, flying in the 0-10000 region, it works well enough for close 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. This probably also means that there is no converging algorithm going on. I'm seeing about a factor 5 difference between real and computed distances. I have a flight this afternoon, so I will do some more testing. Do you take emitter catagory into account?
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.? This would also give the EFB a way to distinguish between computet targets, and "real" targets. I'm not sure if there is a way to do that now. (for GDL90)? Idealy (for my product) I would not display the computet targets in the same manner as the "real" targets.
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 p.s. By the way . super work. Hope I can test FLARM soon. Not that used where I live...
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)? But yes, without a position source, it's impossible to create the fake targets. Factor 5 seems very large, never seen that, except for very distant traffic while on the ground, where basically anything can happen (houses/trees/mountains/...). Emitter category is not taken into account right now, as often seems to be missing or wrong. Not sure if that's an issue in dump1090 or something else, didn't investigate further. I also thought about the NACp approach, but that doesn't seem to be supported by any major EFB. I.e. there would be two ways:
- Set traffic coordinate = current GPS coordinate with appropriate NACp value. But most EFBs would simply show the traffic at the reported GPS coordinate, ignoring NACp.
- Set traffic coordinate to 0/0 with appropriate NACp value: couldn't find any EFB doing something useful with this information. In fact, some will even put the traffic at real-world 0/0.
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. I think this approach is actually to be prefered, since it is compatible with old EFBs (fake targets) AND the information can be used to make more of it. Albeit it could be tweaked to not rely on the tail number but something else, that is to be defined.
Regards Lars p.s. By the way . super work. Hope I can test FLARM soon. Not that used where I live...
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.
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?
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)
Where are you based? If you are in ITU Region 1 (Europe/Africa) then all is fine.
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
I also thought about the NACp approach, but that doesn't seem to be supported by any major EFB
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). With the limited fields of the GDL90 it certanly is up to debate if the NACp field is the correct way to do it. It would say it is, but again just my oppinion :-). Maybe an option to add NACp to the GDL output ??
Hm.. but then again, isn't NACp just a workaround aswell? Even more though, because it conflicts with what NACp actually means. At least from what I understand: The NACp value is actually transmitted via ADS-B as an indication of "I have a bad GPS signal, don't rely on my position report". GDL90 just forwards that to the display so a respective "degraded positioning" icon can be shown. That's what's recommended in the spec. Admittedly, this is probably not used too much in practice, as GNSS positioning is just so good these days. Is this understanding correct?
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.. GDL90 specifies (in base 10): 0= Heartbeat 2= Init 7 = Uplink 9 = Height above terrain 10 = Ownship report 11 = Ownship geometric altitude 20 = Traffic Report 30 = Basic Report 31 = Long Report
Additionally, Foreflight defines 0x65 = 101 as their own message type and splits that with a subtype (https://www.foreflight.com/connect/spec/): 101 + 0 = Foreflight ID Message 101 + 1 = AHRS Message
Stratux also has custom types already (https://github.com/cyoung/stratux/blob/master/notes/app-vendor-integration.md): 0xCC = 204 = Stratux Heartbeat 0x5358 = 83 = Another Stratux Heartbeat 0x4C = 76 = AHRS Message
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. I don't know what the Stratux does, but would assume it is just forwarded as well. I have not looked into the source.
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. Those that do not want to implement it can just use the system as it is now where 8 targets are broadcasted with the MODE-S tail number. Those that want to do their own stuff can disable the 8-target thing, and read the custom message. So you are not breaking anything that is working now. The fields could be a copy of the traffic report with another type ID, and using NACp, or a complete custom structure could be made.
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).