Pilotware reception no longer working? (version 1.74 onwards)

[Alan Hall]

I have not used SoftRF since last year, and on updating to 179 have found that P3I reception no longer works reliably, or at all. This is the same on Tbeam versions with SX126x or SX127x.

Testing with the two SoftRF units at version 179 and a genuine Pilotaware unit, the SoftRFs are received OK by the Pilotaware, but they do not reliably receive each other or the Pilotaware. With a TX count of 500, they typically have an RX count of only 2 or 3.

Checking older versions, it seems that version 170 was definitely OK but 174 definitely not. Checking the intermediate versions was confusing as I found that they would sometimes not transmit P3I but “Latest” protocol was OK. This was not consistent between update loads despite clearing the settings files and so for the moment I have disregarded it.

Since Pilotaware are reportedly changing to ADS-L you might say this doesn’t matter, other than out of curiosity, but AFAIK the “Pilotaware” derived verision of ADS-L is using the same transmission parameters as their current protocol and may suffer the same problem.

Happy to investigate this myself, but I just wondered if this rings any bells with the changes between those versions?

And yes, I ws astonished to find that ADS-L is really 3 different air protocols!

Alan

[Moshe Braner]

Thanks Alan.  Nobody uses P3I around here (North America) so real-world testing needs to come from people who use it, like you.  So yes we hear that Pilot Aware is in flux, with the transition to ADS-L.  I'd like to know which flavour of ADS-L that is, then I can try and support that in SoftRF.

[R. van Twisk]

How is ADS-L really 3 air protocols?

As far as I can see, looking at the documentation it's all the same protocol.

R. van Twisk
Tel:+31.6.820.53.703
GA/TAS Conspicuity

--
You received this message because you are subscribed to the Google Groups "SoftRF_community" group.
To unsubscribe from this group and stop receiving emails from it, send an email to softrf_communi...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/softrf_community/96a5d470-391b-4ea0-92ed-77b257058597n%40googlegroups.com.

[Moshe Braner]

Different frequencies and modulation parameters (bitrate etc).  Pawel calls them LDR (low data rate), MDR (medium) and HDR (high).  Incompatible with each other, i.e., if receiver and transmitter are not set to the same flavour then no reception.  Aren't standards wonderful?

[Alan Hall]

The payload format is common but it can be carried over 3 different and mutually incompatible radio transports all in the SRD860 band. Two (maybe all 3) of these seem to be similar, if not identical to the existing Flarm and Pilotaware ones, presumably reflecting the involvement of those companies in the ADS-L specification. Fine if you have a SDR receiver (as merely hinted at in the ADS-L documentation) but most low power airborne EC isn't built that way. If you need separate receivers anyway, it's hard to see any real benefit in standardising the payload since the existing ones can be interpreted to yield the same information. BTW I was disapointed to see that the the data payload also lacks the necessary trajectory information to enable an open but  Flarm-like glider EC solution!

The EASA documention on ADS-L (the workshops etc) is a bit of a chew but interesting. For me, it didn't explain why they have gone the route they have, but it does make it clear that the main purpose is surveillance for USPACE, not EC. Even that is based on a lot of optimistic assumptions regarding acceptablity to ATC etc in the future. As with everything EC related it's not simple and I think this just makes it even more complicated.

https://www.easa.europa.eu/en/document-library/agency-decisions/ed-decision-2022024r#group-easa-downloads

Back to EC/SoftRF, the main practical benefits seem to be:

Receiving ADS-L may allow detection of the less common systems like FANET (if they all adopt the same ADS-L radio protocol of course)!

Transmitting ADS-L may in the future allow airspace (especially USPACE) access.

Anyway sorry, this is getitng a bit off the SoftRF topic!

[VirusPilot]

As far a I know, PilotAware now converted everything to ADS-L O-Band LDR.

[R. van Twisk]

Ah, I understand what you mean now.

The modulation and frequencies differ, but the protocol itself remains the same.

From what I can tell about the ADS-L protocol, the uplink on the O-band uses different timing compared to traffic on the M-band. This means that with a single transceiver, you can switch between them and still maintain full coverage. In practice, this works well—I’m able to receive uplink traffic and M-band traffic on the same transceiver without issues.

What stands out to me is that ADS-L is primarily focused on traffic awareness rather than providing traffic advisories.

As a side note: since FLARM operates more in the “advisory” domain and that’s a key part of its specification, it’s possible that advisory functionality was intentionally left out of ADS-L to avoid overlapping with FLARM’s market. That said, this is just speculation. Historically, FLARM only provided north/east trajectory data without altitude, so its picture wasn’t even that complete in my opinion. ADS-L could add that later if they wanted to...

R. van Twisk
Tel:+31.6.820.53.703
GA/TAS Conspicuity

To view this discussion visit https://groups.google.com/d/msgid/softrf_community/d22d0568-c9c3-407d-ba12-743f7ce6bf43n%40googlegroups.com.

[Moshe Braner]

I believe I have found and fixed this issue, in the now posted version mb180.  But I could only test communication between SoftRF units.  See if it works with your "genuine Pilotaware unit".

But this is a temporary thing, since Pilot Aware are moving to the ADS-L (LDR, O-Band?) protocol.  Should my SoftRF abandon the old P3I protocol and replace with the correct ADS-L protocol instead?  When would be a good time to make that switch?  Or is it necessary to support both protocols for a while?

On Monday, April 6, 2026 at 7:28:25 AM UTC-4 alanda...@gmail.com wrote:

[Alan Hall]

I confirm V180 works with a real PAW unit, in a quick short-range test anyway. Thank you for the super quick fix.

For the future I think that you are probably correct, although Pilotware are never very forthcoming with technical details. The story is that the new PAW version defaults to ADS-L (O-band) but (as a temporary compatability feature) if it receives an old PAW message from a unit which has not yet been updated then it reverts to both the old PAW and ADS-L format interleaved. I don't know any further details. So for a while at least the old format will work. No timescale to convert has been given AFAIK but presumably this will need to be publicised well in advance.

Yesterday I updated my PAW to the new version. Unfortunately it continues to emit only traditional P3I packets, even though it is not receiving any other station, although other people have found it works as expected.

I don't know what woud be the best decsription for the new protocol setting. It's unclear to me if anybody apart from PAW will be using it.

The other intersting question is what will happen to the PAW uplinked services which are currently restricted to paid-for PAW users (and so not visible using SoftRF). Presumably they will need to implement some cunning scheme to keep this private over the open data link.

[Alan Hall]

I forgot to say the revertion to interleaved PAW format only happens if the triggering aircraft is within a short distance.

[Mik Garwood]

I did a brief test last week with MB1.80 using my club's PAW groundstation and I was picking up re-broadcast flarm traffic. I didn't see any direct PAW contacts so couldn't confirm this and I don't know anyone with an actual PAW device to test this, will have to do some longer tests to capture passing traffic.

From this brief test it looks like the traffic's groundspeed is not being sent in the PFLAA sentence anymore - I will have to check this with a direct log of the SoftRF output though, in case I have a bug in my Mux device I was using for the logging.

I am also not sure about the aircraft type (with PAW) as I used to get a type of say hex11 for a re-broadcast glider and hex01 for a direct contact, so 18 for re-broadcast power and 08 for direct. Checking my old logs I last saw this in 2024. I will have to test again with a direct SoftRF log to check this.

Mik Garwood

--

You received this message because you are subscribed to the Google Groups "SoftRF_community" group.
To unsubscribe from this group and stop receiving emails from it, send an email to softrf_communi...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/softrf_community/9116b7c7-400b-4c50-93d0-22a89e8f33b2n%40googlegroups.com.

[Vlad Belayev]

Hi Mik,
I am not deeply involved with PAW, but interested to learn how it works in terms of re-broadcasts.
Not long ago I was passing by a ground station "Babraha" and had Moshe's based T1000E-Card with me , it picked up what seems like a re-broadcast. 
See photo, the aircraft type was 3 , that's why its showing H (Helicopter). Unfortunately,  the display doesn't have ground speed.
I will be passing this place on Saturday and will have the device with me in PAW mode.
For you to help monitor traffic as PFLAA sentences , see if my webapp configurator helps. 
https://ogn.helioho.st/mysoftrf/
( It connects to MB devices via BLE or Serial)
Last tab "Traffic" would show all traffic details including ground speed. It may not identify re-broadcast correctly ( as it only interprets aircraft types up to 15)
Also, triple-click the SoftRF logo to open a small console window where you will see all the live NMEA output.

Cheers

Vlad.

[Alan Hall]

It’s over 2 years since I looked at this in detail but my understanding, based on experiment and some skimpy info from PAW, was that the groundstations don’t constantly broadcast all the traffic data they have access to. Instead they only transmit data on targets within a certain distance of a genuine PAW airborne unit detected by the base station. So a SoftRF will only receive these broadcasts if they are being made on behalf of another PAW-equipped aircraft and the actual traffic may not be relevant unless the position of the aircraft is fortuitous. Presumably this is to conserve bandwidth and/or improve the update rate but also to preserve their commercial model (which is fair enough).

How do they tell genuine PAW units from SoftRF? I observed transmitted packets containing the MAC address in clear text so they would be able to tie this up with their licences as the groundstations are all on their network. I gather quite a lot of telemetry gets exchanged.

It would be nice of course if this policy has changed since then. Realistically I can't imagine that alone gets them many extra sales and they now have other features to sell on.

[Moshe Braner]

Similar to FLARM's support for ADS-R (in the USA, where it exists): unless you also request the ADS-R service (by having an ADS-B Out transponder configured to say "I can't receive UAT978") there will not be ADS-R transmissions about traffic near you, unless there happens to be a similarly configured aircraft nearby (quite rare).

Regarding Pilot Aware, they are now switching to the ADS-L packet format.  So thing will change, not sure how/if ADS-L supports rebroadcasts.  I wonder if "real" PAW devices will keep transmitting their MAC (and other things?) in occasional non-ADS-L packets.

[R. van Twisk]

Regarding Pilot Aware, they are now switching to the ADS-L packet format.  So thing will change, not sure how/if ADS-L supports rebroadcasts.  I wonder if "real" PAW devices will keep transmitting their MAC (and other things?) in occasional non-ADS-L packets.

ADS-L Does have a Relay/Forward bit in the Header, so it's officially possible.

I stil am not sure if that's a good idea all these devies rebroadcasting the same packets poluting the already polluted spectrum.. Better to have a ground station with ADS-L Uplink IMHO..

R. van Twisk
Tel:+31.6.820.53.703
GA/TAS Conspicuity

On 14 Apr 2026, at 22:52, Moshe Braner <moshe....@gmail.com> wrote:

Similar to FLARM's support for ADS-R (in the USA, where it exists): unless you also request the ADS-R service (by having an ADS-B Out transponder configured to say "I can't receive UAT978") there will not be ADS-R transmissions about traffic near you, unless there happens to be a similarly configured aircraft nearby (quite rare).

To view this discussion visit https://groups.google.com/d/msgid/softrf_community/68b50df2-4273-4ae8-a795-8ed24dfebc63n%40googlegroups.com.

[R. van Twisk]

I currently support ADS-L uplink on my GATAS version (MLAT + Traffic it's receiving) I hope to test that soon at our airport.

I will have to read on PAW and see what they are doing..

R. van Twisk
GA/TAS Conspicuity

On 15 Apr 2026, at 14:13, Moshe Braner <moshe....@gmail.com> wrote:

I think he was talking about the uplink service that Pilot Aware
offers (to paying customers).

[Mik Garwood]

If Pilotaware doesn't keep re-broadcasting then it partly defeats the point of it as PAW pilots would no longer see flarm or ModeS transponders. Their web site says that it supports PAW and ADS-L formats right now, for the "FX" device, I presume ADS-L is not supported with the previous hardware.

I haven't done any more tests with SoftRF and PAW yet.

Mik Garwood

To view this discussion visit https://groups.google.com/d/msgid/softrf_community/1989D166-A4C3-4B2B-9FB3-AFFD3B4EA4AF%40gmail.com.

[Alan Hall]

I’ve updated my PAW Classic model to the latest software (2026-03-16) and was disappointed to find that on the bench it still transmits, by default, the original PAW protocol.  Today I went flying and found no ADS-L statistics logged for my aircraft on the PAW VECTOR analysis tool. However I know personally another PAW Classic/Rosetta owner who has had success so I think this is an issue with my particular unit and I am pursuing it with PAW. Meantime I do believe that the old Classic and Rosetta units do and must work with the ADS-L version of PAW otherwise they will soon become obsolete as the system migrates.

I also used a SoftRF to log PAW traffic today. I observed an aircraft sending info in the old PAW format but which later changed to (presumably) the new ADS-L format exclusively. The aircraft was travelling from a relatively dense traffic area to a quieter one so I assume it was initially in compatibility mode due to receiving old-style PAW traffic but reverted to native ADS-L when out of range.

Here are three consecutive packets, a PAW and 2 ADS-L ones from (I think) the same aircraft:

$PSRFI,1776600204,24526240333f773f06684f42e8014e000f03000043000398,-88

$PSRFI,1776600205,056cb595b2affced15e6d3fe0cbed7e3d5b73ee1403dd516,-88

$PSRFI,1776600207,05c29ac739b41a3fb6c1a083ff12d4190ae76e8fc0837833,-88

Now the odd thing is that by my reckoning the first byte of the ADS-L packet is the so-called network header and 0x05 is a strange value. The top 4 bits indicate protocol version 1 but surely we are at version 2? The lower 4 bits correspond to encryption key 2 and the use of FEC. Neither seem appropriate.

Another oddity is that the protocol version in the SoftRF code also seems to be Version 1 (but the encryption and error correction bits are as expected).

Am I interpreting this header correctly?

Alan 

[Moshe Braner]

Thanks Alan.  The old PAW packets are "whitened" by XOR-ing the bits with a fixed pattern.  The new ADS-L format skips whitening, but "encrypts" most of the packet instead (XXTEA with a fixed key of zero).  The payload is 24 bytes in either protocol, the "net ID" and all that is pre-pended to that and not included in the 24 bytes you are showing.  The old code in SoftRF, not knowing about the new ADS-L based protocol, applied the whitening.  Thus the first byte was XOR-ed with 0x05, it was actually 0x00, indicating "issue 1" protocol version.  Are "issue 2" receivers accepting "issue 1" packets?  Yes.  See section ADS-L.4.SRD860.B.5 "Soft Versioning".