SoftRF version MB174

[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.

The main new feature is the ability to operate in two unrelated protocols "at once", through time slicing.  Specifically, can use the FLARM-compatible "Latest" protocol (or ADS-L) along with either FANET or P3I (PilotAware).  (Cannot use FANET and P3I at the same time.)  The time-slicing dedicates time slot 0 (400-800 ms after PPS) to "Latest", since FLARMs transmit their fresh positions during that time.  (SoftRF can also optionally listen to both FLARM and ADS-L simultaneously during time slot 0, as in version MB172.)  During time slot 1 (800-1200), and also much of the time between slots (200-400), SoftRF in this mode listens to FANET (or P3I).  FLARMs transmit a repeat of the same position during time slot 1 as was already sent during slot 0.  Thus SoftRF in this dual mode is almost as good as single-protocol mode for the purpose of collision avoidance.  Conversely  SoftRF in this dual mode will receive about 60% of incoming FANET (or P3I) transmissions.  (And 100% of such transmissions if they come from another SoftRF device in the same mode.)

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

[Constantin H. Klug]

Hi Moshe,

super cool, that you looked into this!! I believe having this dual-mode is a big step forward in aviation collision avoidance (at least for paragliding, as many have either FLARM or FANET). 

I will try to test it, but it will probably take some time, as I currently only have one T-echo.

I want to get the T-echo Plus next, but it is currently not available yet in the configuration I want (supposed to be available sometime in February).

BR

[Moshe Braner]

On the face of it, it looks like the T-Echo Plus should be able to run the same binary.  Let us know if that is true once you test that.

That is not the case for the T-Beam Supreme, it will NOT run a binary compiled for the classic T-Beam, since they have different processors.

[Carsten Strasser]

Hello, is it necessary to solder a barometric chip to the Tbeam? The received ADS-B data already contains the barometric altitude. Regards, Carsten

--
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/84a88833-386b-4b05-94d5-e72fb2d89c4an%40googlegroups.com.

[Moshe Braner]

FLARM and similar systems use GPS altitude.  The barometric pressure or altitude are irrelevant to the collision prediction.  Thus adding a baro sensor is not needed, unless you want a more accurate "vario" function based on the data output from SoftRF into relevant software on another device.

ADS-B transmissions report barometric altitude.  That is a bit of a problem for collision predictions regarding ADS-B traffic in SoftRF (if you add the ADS-B receiver module to SoftRF).  My code handles it like this:

* If there is also a baro sensor attached to the SoftRF device, it uses that to convert baro altitude to GPS altitude.

* Otherwise it listens to some other types of ADS-B messages from aircraft that are not very different in altitude, some of those messages also report the difference between GPS and baro altitudes, that can be used to convert baro altitude to GPS altitude.

[Gary Jones]

Hey Moshe.. This is all amazing but I'm having brain overload now. I'm wondering if you can suggest an ideal advanced configuration for us all. Our setup here at 5B2 is an SSA supplied base unit, never upgraded and T-Beams with a few running the ADS-B chip. I've had these configured OGNTP to date and i've been able to see other OGN, updated FLARM and ADS-B traffic. It's been great. Now we have more options and I'm looking for best config going in to the 2026 season.

So what do you suggest for us as an ideal? OGNTP still the way to go? or go latest with a secondary configured?  

Appreciate your thoughts on this one.

Gary

[Moshe Braner]

OGNTP by itself is definitely NOT what I would recommend for aircraft.  I see SoftRF's first and most important  purpose to be collision avoidance.  Since you are in an environment with gliders, some of which are equipped with FLARM, you want to "see" them, and for them to see you.  Thus use the "Latest" protocol, which is 2-way compatible with FLARM.  And the standard OGN ground stations will see the "Latest" SoftRF just like they see FLARMs.  Thus OGNTP really does not add anything.  Except perhaps that the OGN stations can receive OGNTP transmissions from a bit farther away, due to the error correction built into the ground station software.  Thus, you can use "Latest" as the main protocol, and OGNTP as the alt-protocol, to gain that benefit.  That will transmit OGNTP once every several seconds.

In other environments people may want to use different settings.  For example, if you fly gliders and there are a lot of paragliders in your area using FANET, you may want to use the FLARM+FANET dual protocol.  Same if you fly paragliders and there are also gliders in your area.  If you have drones in your area transmitting ADS-L (this is certainly not the case in the USA but may be the case in some places in EU) then turning on the flr_adsl dual-protocol reception may be useful.

[Adam Mościcki]

Yesterday I managed to change my T-Echo soft to MB174. I connected the device to app "SoftRF Configurator" via BLE.  In section Base of this app I can not change Protocol. Whenever I change it , it is sending data do T-Echo,, it resets ...but after reconnecting it is always protocol PRoL .

Also , when I choose "UI" on the app - I can only see moving circle (waiting symbol).

Is "SoftRF Configurator" working properly with MB174 ? or should I change settings by editing the txt file on the device ?

[Moshe Braner]

I have not tried the Bluetooth app in years.  (Is there more than one app?)  It is quite possible that there is by now an incompatibility between the app and my SoftRF.  Also there are a lot of new settings I added in my version, that are not handled by the app.  It is much better to edit the settings.txt file.  Or, for the most basic settings, I have added a way to do that within the T-Echo itself by pressing the buttons.  See the documentation.

[Adam Mościcki]

Yes, it looks like BLE apps for configuration T-Echo are not comatibile with new MB174. I will use method : editing config.txt.

I will start a new post to discuss options to set up.

Thanks 

Adam

[Vlad Belayev]

Looks like there is more than one app now, I had a look recently. The later version called "SoftRF Configurator", its built by Egzumer is on github https://github.com/egzumer/softrf_configurator/tree/main 
It is still based on the old app and designed for original version of SoftRF therefore limited what it can do for MB174, as most parameters in MB174 are not supported by that app. 
The app is built with "MIT App Inventor" and easy way to build Android/IOS apps without much skills.  I couldn't figure out how to do it. But if someone with experience may be able to customise SoftRF Configurator to work with MB version?
My understanding is the tool would need to convert UI configuration into series of $PSRFx sentences and send over BLE, right?
It would be good to have an alternative to settings.txt editing. ?

[Moshe Braner]

If anybody wants to work on an app, go for it.  But, it is easy to edit the settings.txt file.  Simply plug the T-Echo, with a USB cable, into a computer.  It opens as a "mass storage device", like a flash drive.  Open the settings.txt file in any text editor, such as Notepad.  Edit and save.

[Vlad Belayev]

People also be edited settings.txt on an Android phone via USB cable,  while preparing to take off. So no real need for an app.

[Moshe Braner]

Good to know.  Anything that can work with a flash drive should be able to open the "drive" to reach the settings file.  And let me repeat that, in my version of SoftRF, the basic settings (main and alt protocols, aircraft type, etc) can be adjusted within the T-Echo itself by pressing the buttons.