SoftRF version MB172

[Moshe Braner]

Now posted to github.  This version introduces significant new functionality.  I've given it some limited testing, on the ground.  If you run into issues, please report them.  Older versions are still on github if you need to revert.

Pawel Jalocha (the person behind the OGN stations and OGN trackers software) has recently introduced dual-protocol reception.  The trick is to leave some of the "sync word" detection to the software.  Now my version of SoftRF can use the same method.  The purpose is to receive both FLARM and ADS-L transmissions simultaneously.  This adds visibility of ADS-L traffic in SoftRF without losing any other functionality.  To turn this on, set the main protocol to "Latest" and the alt protocol to ADS-L.

Moreover, this opens the door for more relaying of traffic data.  FLARMs react badly to "seeing" their own ID, e.g., as a relayed message.  But now SoftRF can relay traffic in the ADS-L protocol, invisible to FLARMs, but visible to SoftRF devices that are using the dual-protocol reception.

Find more information in the "under the hood" document.

A couple of other minor changes in this version:

The frequency for the New Zealand region has been changed from to 869.25 to to 869.20, to follow what FLARMs (other than perhaps some old OZflarms) use.

And added the ability to specify the actual GPIO pin number of altpin0 and ppswire.  This offers more flexibility in unusual setups.

[Vlad Belayev]

Thanks Moshe, really useful. Will be testing it on T-Echo. And will check how LATEST/ADSL combo works.
PS . Just noticed MB173 is there now.

[Moshe Braner]

Hoping to hear back how it works for you and others.  Yes MB173 now posted replacing MB172.  The differences are small.  Now relays FLARM traffic closer than 10km if it is much lower.  And relays ADS-B traffic within 16/10/8 km for jets/helicopters/others.  Relaying is only done if airborne, if you want to test it on the ground put SoftRF into "test mode" (see the documentation).

[Gary Jones]

Hey Moshe... been a while. That time of year to upgrade the club devices. So to be clear then, the gliders which have ads-b chips installed will now relay those additional sentences to the tow planes which are simple t-beams only. That saves me some work this winter!!! If I'm missing the point certainly correct me but thanks again for all you do. Continues to be game changing. I'll update you on what I learn testing out the units.

[Moshe Braner]

Yes, the relaying of ADS-B traffic is intended to spread the benefit of the ADS-B receiver module in some units to other nearby ones without the module.  "Nearby" as in within a few km, since only traffic within 8 km of the relaying unit is relayed.  Relaying is only done once in several seconds, and if there are multiple targets each will be relayed less often than that.  For that reason the curent firmware only relays ADS-B traffic if the ADS-B module is present.  If the module is not present, then it relays non-ADS-B (FLARM) traffic instead.  And in that case only traffic *farther* than 10km, since the purpose of that is to increase the range at which gliders can be "seen", by either other gliders with SoftRF, or OGN ground stations.  Standard OGN ground stations can receive all the protocols at once.  (OGNbase can only receive "latest" and "legacy" for now, although I may eventually add the dual-protocol reception mode to OGNbase.)

To put SoftRF into dual-protocol reception, set the main protocol to "latest" (7) and the alt protocol to ADS-L (8).  By default it is just "latest", and with that setting ADS-L is not transmitted.  If not in dual mode, relaying of ADS-B traffic is done in the "legacy" protocol (which can be seen by other SoftRF in non-dual mode), and FLARM traffic is not relayed at all (except for "landed out" traffic).  In dual mode, SoftRF also transmits its own position in the ADS-L protocol, once every 4 seconds.

If set to main protocol "latest" (7) and alt protocol OGNTP (1) then SoftRF is in "2.5 protocols mode", transmitting its own position in the ADS-L protocol every 8 second and in OGNTP every 8 seconds, and receiving FLARM and ADS-L protocols (but not OGNTP).  The benefit of this mode is that OGNTP messages can be received by OGN ground stations from farther away, thanks to the more elaborate bit error correction built into the ground station software.

Currently if the main protocol is OGNTP and the alt protocol is "latest" then, too, reception is FLARM+ADS-L and not OGNTP, but most transmissions are OGNTP, and "latest" is transmitted once every 8 seconds.  If that is a bad idea, let me know what you would rather SoftRF do with that (uncommon) setting.  AFAIK almost no aircraft transmit OGNTP, so in order to see traffic around you the FLARM+ADSL reception mode is better.  If you want to transmit and receive OGNTP alone, set it as the main protocol and set alt-protocol to "none" (255) - but the only situation where that is useful seems to be as an additional device besides a FLARM, with the OGNTP encrypted - i.e., in major glider competitions.

If the protocol is set to FANET or P3I, alt-protocol is not allowed, and there is no dual-mode reception.  If operating mainly in FANET or P3I but occasionally transmitting (but not receiving) in another protocol is a good idea, let me know.  Maybe it can be done, but it is trickier, since FANET and P3I do not share the time-slots that FLARM and OGNTP use.  (ADS-L doesn't either, but in this implementation it uses the same time slots and ferquencies as FLARM, except that ADS-L transmission is limited to the window of 450-1000 ms after PPS as per the ADS-L specs.)

[Ryan Dewsbury]

Out of curiosity would it be possible to get ADS-B relay via a SofRF device connected to a Stratux? 

I seem to recall that the communication is one way from the SoftRF to the Stratux? Would be easy enough to rig up a Stratux in one of our Towplanes and it could forward things to the gliders that only have SoftRF.

[Moshe Braner]

Would the Stratux send ADS-B traffic info to SoftRF as GDL90 sentences?  I already have the option to accept such into SoftRF.  Could add relaying of that traffic similar to the relaying of traffic from the GNS5892 optional module.  Only issue is, SoftRF can't know the source of the GDL90, it could be ADS-B or it could be something else.  For example, somebody here has said they want to set up another device listening to FANET and forward that data to SoftRF as GDL90.   (Spoiler alert: I am now working on making FLARM+FANET dual-mode happen within SoftRF itself.)

[Moshe Braner]

Hmmm, looks like I have already added that, since version MB166 if not earlier.  If you set the "relay" setting to "all" then it relays GDL90 traffic.  Just be careful to turn that on only if what's coming in via GDL90 is OK for that.  In particular: never relay FLARM traffic (in FLARM protocol) since FLARMs get upset seeing their own ID and switch to a random ID.

In my latest version with relay=all and the Latest+ADS-L dual-mode it relays FLARM traffic in ADS-L protocol, invisible to FLARMs.  That's if you do NOT have the GNS5892.  Otherwise it only relays ADS-B traffic instead.  I only want to dedicate a small percentage of the transmission oportunities to relaying, to maintain the main purpose: frequent reporting of own position for collision avoidance.