Important: These forums are for discussions between SkyDemon users. They are not routinely monitored by SkyDemon staff so any urgent issues should be sent directly to our Customer Support.

Alternative "address types" in PFLAA messages


Author
Message
buzz53
buzz53
Too Much Forum (997 reputation)Too Much Forum (997 reputation)Too Much Forum (997 reputation)Too Much Forum (997 reputation)Too Much Forum (997 reputation)Too Much Forum (997 reputation)Too Much Forum (997 reputation)Too Much Forum (997 reputation)Too Much Forum (997 reputation)
Group: Forum Members
Posts: 22, Visits: 50
I’d like to make a plea for Skydemon to accept “Address Type” field values other than 1 & 2 in $PFLAA messages (i.e. in AirConnect and Pilotaware interface modes).

The concept of address types had been adopted by others, notably OGN, who have assigned different values (e.g. OGN use type 3 when transmitting their own, rather than ICAO addresses). When these addresses are passed to Skydemon in PFLAA messages, Skydemon currently rejects them, making it unusable with OGN devices (and possibly others) in this mode.

The specification of these messages originated with Flarm in their Dataport Interface Document, where currently only those 2 values are defined (for ICAO and FLARM addressing) which is, I assume, why SD reject other values. However the current Flarm Dataport Specification states, regarding the PFLAA message: “Data on other proximate aircraft, intended for connected devices with sufficient CPU performance. This sentence should be treated with utmost flexibility and tolerance on a best effort base.”

I suggest this is an invitation or indeed recommendation by FLARM themselves to accept other values. I suggest accepting any value in this field (I don’t think SD does anything with the present values anyway)? The alternative is that devices such as OGN or SoftRF will need to be tweaked to pretend the addresses are ICAO or FLARM when they are not. I have done this, and it works, but I feel the correct solution lies at the SD end.

Alan


Tim Dawson
Tim Dawson
SkyDemon Team (616K reputation)SkyDemon Team (616K reputation)SkyDemon Team (616K reputation)SkyDemon Team (616K reputation)SkyDemon Team (616K reputation)SkyDemon Team (616K reputation)SkyDemon Team (616K reputation)SkyDemon Team (616K reputation)SkyDemon Team (616K reputation)
Group: Forum Members
Posts: 7.8K, Visits: 8.4K
Have you spoken with Flarm about this? I imagine they would be amenable to listening to a request to add other address types into the specification for the protocol, officially that is.
buzz53
buzz53
Too Much Forum (997 reputation)Too Much Forum (997 reputation)Too Much Forum (997 reputation)Too Much Forum (997 reputation)Too Much Forum (997 reputation)Too Much Forum (997 reputation)Too Much Forum (997 reputation)Too Much Forum (997 reputation)Too Much Forum (997 reputation)
Group: Forum Members
Posts: 22, Visits: 50
No Tim, I hadn’t. I can’t really see why FLARM would wish to do that, for various reasons, and took the view that their exhortation for flexibility and "best effort" as I quoted above, was sufficient. What is the downside?

I have only worked on SoftRF but I see that the OGN tracker device, apparently well established in Europe, contains the same fudge:

#ifdef WITH_SKYDEMON
if(AddrType!=1) AddrType=2; // SkyDemon only accepts 1 or 2
#endif

So it seems Skydemon is the outlier here. Sometimes a good thing but not always!

Alan


Tim Dawson
Tim Dawson
SkyDemon Team (616K reputation)SkyDemon Team (616K reputation)SkyDemon Team (616K reputation)SkyDemon Team (616K reputation)SkyDemon Team (616K reputation)SkyDemon Team (616K reputation)SkyDemon Team (616K reputation)SkyDemon Team (616K reputation)SkyDemon Team (616K reputation)
Group: Forum Members
Posts: 7.8K, Visits: 8.4K
I can't see why we would wish to accept a different address type there unless we knew (via a protocol specification) what it actually meant. We *could* assume that addresses with the same "address type" number and the same 24bit address number identified the same aircraft - that seems reasonable - but we're not comfortable making assumptions like that, especially in the area of traffic reception. We already cope with other address types through GDL90 and we can't map potentially many more to internal structures without knowing what they mean.

Please try reaching out to FLARM for their comments, and let's take it from there.

buzz53
buzz53
Too Much Forum (997 reputation)Too Much Forum (997 reputation)Too Much Forum (997 reputation)Too Much Forum (997 reputation)Too Much Forum (997 reputation)Too Much Forum (997 reputation)Too Much Forum (997 reputation)Too Much Forum (997 reputation)Too Much Forum (997 reputation)
Group: Forum Members
Posts: 22, Visits: 50
OK I will try but I really can’t see why they would be remotely interested, and I imagine it would need to wait for the next protocol issue which could be some time.

Answering your question, the reason you might want to consider it is obviously because it doesn’t work at the moment!

I didn’t understand the specific concern you raised, unless there was a typo. Surely you already make that assumption for ICAO and FLARM modes? If somebody misconfigures their device you could have already two aircraft with identical coding.

The OGN tracker specification makes their addressing clear and, failing operator error, they are unique. So, there is a specification, albeit less formal! I can’t see how Flarm would undertake to give you the level of assurance that you seem to want, based on somebody else’s work, seperately specified.

But it sounds like you don’t want to discuss it right now, so I’ll report back when I have some news (or not) from Flarm.

pilot-byom
p
Too Much Forum (957 reputation)Too Much Forum (957 reputation)Too Much Forum (957 reputation)Too Much Forum (957 reputation)Too Much Forum (957 reputation)Too Much Forum (957 reputation)Too Much Forum (957 reputation)Too Much Forum (957 reputation)Too Much Forum (957 reputation)
Group: Forum Members
Posts: 323, Visits: 388
My personal opinion: for now (!) separating just ICAO from non-ICAO targets is ok and necessary and 'good enough', as this is the least common data separation all the different protocols will deliver. Flarm is just another protocol of questionable long turn relevance and yes, there are some nice functions in it, but they are no common features for all protocols. As Skydemon takes the leanest feasible way, I am ok with holding back expenses to implement software features 'because they are there'.
buzz53
buzz53
Too Much Forum (997 reputation)Too Much Forum (997 reputation)Too Much Forum (997 reputation)Too Much Forum (997 reputation)Too Much Forum (997 reputation)Too Much Forum (997 reputation)Too Much Forum (997 reputation)Too Much Forum (997 reputation)Too Much Forum (997 reputation)
Group: Forum Members
Posts: 22, Visits: 50
P-B, I'm unclear what you are proposing as the solution to the incompatibility? Either SD has to change, or everybody else, so there is effort either way!


pilot-byom
p
Too Much Forum (957 reputation)Too Much Forum (957 reputation)Too Much Forum (957 reputation)Too Much Forum (957 reputation)Too Much Forum (957 reputation)Too Much Forum (957 reputation)Too Much Forum (957 reputation)Too Much Forum (957 reputation)Too Much Forum (957 reputation)
Group: Forum Members
Posts: 323, Visits: 388
buzz53 - 5/28/2021 11:17:19 AM
P-B, I'm unclear what you are proposing as the solution to the incompatibility? Either SD has to change, or everybody else, so there is effort either way!


No, Skydemon does not have to change. In aviation only ICAO denominators are meant to be used as aircraft identifiers and the regulations are clear in Annex 10. Everything other is maybe for convenience, undoubtedly unregulated and potentially suspicious. I welcome Skydemon agreed to support non-ICAO FLARM protocol as one of the cowboy methods out there and spent the effort (and our money). Extending this to others as OGN, FAanet+, P3i or anything out there tinkered by hobbyiests and the laity mighties I would rather not have in a moving map software.

GO

Merge Selected

Merge into selected topic...



Merge into merge target...



Merge into a specific topic ID...




Reading This Topic

Login

Explore
Messages
Mentions
Search