Primarily for general aviation discussion, but other aviation topics are also welcome.
  • 1
  • 6
  • 7
  • 8
  • 9
  • 10
User avatar
By GrahamB
FLYER Club Member  FLYER Club Member
#1846208
Sooty25 wrote:Both FLARM and PAW are closed commercially controlled protocols so should be excluded.

I think you’ll find that PAW’s protocol, P3i, is openly published and available to all.

The annual licence you pay to PAW is for use of the proprietary software/hardware, not the protocol.
rdfb liked this
#1846245
GrahamB wrote:
Sooty25 wrote:Both FLARM and PAW are closed commercially controlled protocols so should be excluded.

I think you’ll find that PAW’s protocol, P3i, is openly published and available to all.

The annual licence you pay to PAW is for use of the proprietary software/hardware, not the protocol.


Warning: Personal Rant starting: :x

I think we get overly concerned with this aspect - in the computing world pretty much all private individuals and small business run on commercial standards - my guess is everyone on this forum runs something from Mr Gates or Mr Jobbs.... In that world formal open standards for communications do not have a good track record (if you've been in the computing industry in the 1980's you may have witnessed the massive amount of time, money and effort wasted on "Open Systems Interconnectivity" standards which never yielded a single practical system). There a mix of commercial (Windows / Ios) and de-facto standards (eg html) works just fine.

Flarm may be "closed", but it can easily be licenced - I sometimes think we would be a lot further on if, 10 years ago, the CAA/EASA had negotiated a licencing deal on Flarm. A proprietary standard has several advantages - it is much quicker to extend the standard as you have control, not multiple layers of committee's, and you can tailor it better - look at what Flarm can achieve vs ADSB on a fraction of the power. Since it's initial release Flarm has been extended to obstacle avoidance and is now being used for "avoid zones" for things like parachute dropping or drones, and (given the limitations of transmit power) is still IMHO the best traffic avoidance outside of full TCAS.

Seems to me we've ended up with another "camel*" here - as just one example why does ADSB need 1Mb data rates, which compromise receive and transmit at low power? Porting Flarm to a "safe" frequency & allowing for a modest increase in transmit power would have been easy - it already caters for US differences, we would have had choice from a dozen or more vendors, a more sophisticated traffic warning (Flarm data message contains more information than ADSB enabling this) & we'd be looking at shippings tens of thousands of units across the UK/EU/Aus not just a few thousand which brings down costs.

P3i is a great idea, but sadly not a single commercial supplier outside of PilotAware has taken it up, even just as a received protocol.

Rant off: :shock:

* As you all no doubt recall "a camel is a horse designed by a committee"
Last edited by ls8pilot on Tue May 11, 2021 11:25 am, edited 1 time in total.
Forfoxake, Marvin, nallen and 1 others liked this
#1846257
@ls8pilot your frustration is noted and to add another one; the ICAO committees took something like 5 years to agree a common standard for the extension of the AFTN networks to modern standard. with the typical 7 year cycle before publication and then States agreeing and funding modifications to the systems world-wide it is only now that the 7 bit Teletype interface is slowly being replaced - but I digress.

<geek mode> I may suggest that one of the factors in the design of ADS-B and its data rates is more to do with the original intention of providing position information for separation in controlled airspace to 3nm. Current radars refresh at typically every 6 seconds, 4 seconds on an aerodrome approach, and there are about 120 to 150 interrogations and associated replies not all of which will be decoded due garble, fruit etc.

The information from ADS-B is a single transmission broadcast every 2 seconds for the position information and there are other messages with differing content also sent out at other intervals. Not every transmission will be received/decode due to interference/fruit/garble etc hence the frequency of broadcast, transmission rate etc. Again it needs to provide a data integrity for ATC system to be capable of the separation standards not Electronic Conspicuity or close in collision avoidance like FLARM protocols. </geek mode>

I agree that committees are not the best vehicle for design of some standards and commercial interests can be more agile but sometimes you need to look at the original purpose to see why the camel is the result. :) :)
ls8pilot, Cub, gaznav liked this
#1847088
Marvin wrote:PS, if there is ever a MAC resulting from an infringement then it’s game over, no question.


There was a MAC between a jet airliner and a P28A which infringed controlled airspace back in 1986; the intruder went unnoticed because he wasn't transponder equipped and the controller was distracted by another infringer of his airspace.

That led to the mandate for TCAS so let's hope that there isn't such a repeat occurrence not least because of the human tragedy of that incident, and as a result, who knows what will be mandated upon us all.....
#1847108
Thanks @t67m, but that doesn’t really give all the info, or at best it is exceptionally light on info. So, for example, if you look at slide 10 of your link, then it doesn’t set out which byte is what aircraft type, or there is no data on the algorithm used for cyclic redundancy checker, nor is there an indication of the quantisation of the speeds, altitudes or position data in the various bytes of data. It also doesn’t state the frequency used, which I found elsewhere at 869.525Mhz. There are lots of other bits of missing data of the puzzle to make a working device that is P3i and ATOM compatible.

So really, armed with just this 13 slides of info, this is not really an open protocol until full details on how to transmit and receive are openly published - presumably without a licence fee applied too. The same can be said of FLARM, although they take one step further in that they say they will prosecute unlicensed usage - which is truly ‘closed shop’. You can read the protocol documents on FLARM in far more detail than this 13 slide presentation.

In comparison, this is the ADS-B Protocol laid bare in a 312 page document (ICAO 9871): http://www.aviationchief.com/uploads/9/ ... tion_1.pdf

I find that 9871 is quite hard to read, and so this 160 page guide is better: https://mode-s.org/decode/book-the_1090 ... zi_sun.pdf

Both are a bit different to the 13 slides that gives a rough description of the P3i signal protocol and give you an idea of what is missing to be declared a truly open protocol that anyone can develop. Unless, of course, such a guide exists that I haven’t found yet? :thumleft:
#1847129
@gaznav Any company or individual with half a clue about programming would in combination of the protocol document simply analyse the data stream between the radio module and processor as part of the development. It is a trivial task as RFSoft TTGO demonstrates with their Flarm and PAW capability.
If this isn't a trivial task for the developer then they shouldn't be mucking about trying.
If you are looking for a Ladybird book "How to do P3i" I doubt you will find it.
P3i is open and no threat to take any new developer to court.
The ADSB protocol is based on 'good old' 1940s technology resulting in the 80 year+ old sows ear out of a silk purse 312 page document which we appear to be stuck with today ;-)
Not to say this all bad, after all we are still using round wheels invented by cave men :-)
#1847131
@Straight Level
But if you want it to be an open protocol then why leave people to guess or come up with their own version? For example, if you want P3i to be ‘standardised’ then why not set out the bytes that indicate aircraft type?
Image

It makes no sense if you truly want other developers to use your protocol? :?:
#1847143
I think p3i is "open" in the sense that is not protected by patent, licence or encryption but it is not at the stage where I would describe it as an "open standard" . For that I would expect to see a publicly available repository of technical documentation, plus you would expect some forum for developers to discuss/clarify implementations & future developments. As just one example the documentation referenced earlier has no release level or version control, nor is there any indication how changes take place (for example if you needed an new aircraft type for Drones >xxKg or something)

I'm sure all this could be done, but there has been no need as there is no community of developers. Just saying you can reverse engineer something is not enough for an open standard. There are plenty of examples around in the computing world and lots of places where you can do this.

So I would'nt want to suggest any deliberate attempt to hide P3i, it just illustrates that, as yet, it has'nt really "taken off" in a wider development community - maybe new developments like "air grid" will provoke more interest.

It's also worth noting that while the air:air protocol for Flarm units is not published, they do publish the "back-end" protocol which is used to pass Flarm data to a traffic display or mapping device - open systems like XCSoar or LK8000 make use of this.
#1847285
@leemoore1966

Every OGN station in Europe detects PilotAware

Every Atom station in Europe detects PilotAware

Stratux EU detects PilotAware


Maybe that needs a little more qualification to reveal the truth? To see Pilot Aware, then the Stratux EU needs to be in range of a OGN station that is configured to see Pilot Aware or an ATOM ground station (of which there are still only very few in Europe). This picture is from the Stratux EU webpage: https://github.com/b3nn0/stratux

Image

So, if you are in range and line of sight of an ATOM or an OGN configured for PAW, then Stratux EU users may see Pilot Aware :pirat:

This shows the Pilot Aware ATOM ground stations in Europe - not many!
Image

This is what you need to do to an Open Glider Network (OGN) ground station to make it see Pilot Aware. I don’t believe that every ground station has been modified.
http://wiki.glidernet.org/wiki:add-pilotaware-uplink
#1847300
@gaznav
#gazfactchecker ON

This is what you need to do to an Open Glider Network (OGN) ground station to make it see Pilot Aware. I don’t believe that every ground station has been modified.


Sorry Gaz, but you are wrong.
Version 0.2.8 of the OGN decoder, OGN Stations will detect
- OGN
- Flarm
- PilotAware
- Fanet+

The same 0.2.8 decoder is used in Stratux EU, decoding PilotAware directly.

Your statement about being in range of an OGN station - does not make sense ?
An OGN station has a receive only capability
An ATOM station has a receive/transmit capability

So to re-iterate all OGN and ATOM stations in Europe and UK can see PilotAware :thumleft:
and anything else using the OGN decoder - eg Stratux EU

#gazfactchecker OFF
  • 1
  • 6
  • 7
  • 8
  • 9
  • 10