Dual protocol LEGACY-FANET on T1000-E
106 views
Skip to first unread message
Vlad Belayev
Jan 16, 2026, 6:26:20 PMJan 16
to SoftRF_community
Today made had some progress on getting it to work on T1000E Card.
This has been asked for many in paragliding community.
The change is done on the upstream version 1.7.1 and seemed easy, but no doubt the bugs will pop out.
While testing by receiving the dual mode T1000E device on two other devices , one MB173 set to LATEST and the other is set to FANET. Both receive OK. Occasionally, I see drop out ( 5 second expiry) on one of them, understandably.
The timing of the dual device is set to spend 10 seconds in FLARM and 5 seconds in FANET ( which I think quite generous) The switch itself takes about 700ms. But not sure yet.
Would be see some debugging messages from the receiving devices.
This is a new territory , as it has LR1110 radio chip, but it seems behaving nicely. The bonus is that it doesn't need register setting to configure it, but using more user friendly API.
Any comments, directions welcome.
The debug / timing looks like this.
This has been asked for many in paragliding community.
The change is done on the upstream version 1.7.1 and seemed easy, but no doubt the bugs will pop out.
While testing by receiving the dual mode T1000E device on two other devices , one MB173 set to LATEST and the other is set to FANET. Both receive OK. Occasionally, I see drop out ( 5 second expiry) on one of them, understandably.
The timing of the dual device is set to spend 10 seconds in FLARM and 5 seconds in FANET ( which I think quite generous) The switch itself takes about 700ms. But not sure yet.
Would be see some debugging messages from the receiving devices.
This is a new territory , as it has LR1110 radio chip, but it seems behaving nicely. The bonus is that it doesn't need register setting to configure it, but using more user friendly API.
Any comments, directions welcome.
The debug / timing looks like this.
22:41:35.501 -> [RF] Switching to LEGACY
22:41:35.501 -> [RF] Switching: 5 → 0
22:41:35.501 -> [RF] Step 1: Shutdown radio
22:41:36.883 -> [RF] Step 2: Reconfigure radio chip
22:41:37.260 -> [RF] Step 3: Set frequency
22:41:37.260 -> [RF] Step 4: Enter RX mode
22:41:37.260 -> [RF] Step 5: Configure protocol timeslots
22:41:37.260 -> [RF] Using LEGACY (FLARM) protocol descriptor
22:41:37.260 -> [RF] Step 6: Update timeslot parameters
22:41:37.260 -> [RF] Air time: 6ms
22:41:37.260 -> [RF] TX interval: 600-1400s
22:41:37.260 -> [RF] Slot 0: 400-400
22:41:37.260 -> [RF] Slot 1: 800-400
22:41:37.260 -> [RF] ✓ Protocol switch complete!
22:41:45.483 -> [RF] Switching to FANET
22:41:45.483 -> [RF] Switching: 0 → 5
22:41:45.483 -> [RF] Step 1: Shutdown radio
22:41:46.865 -> [RF] Step 2: Reconfigure radio chip
22:41:47.241 -> [RF] Step 3: Set frequency
22:41:35.501 -> [RF] Switching to LEGACY
22:41:35.501 -> [RF] Switching: 5 → 0
22:41:35.501 -> [RF] Step 1: Shutdown radio
22:41:36.883 -> [RF] Step 2: Reconfigure radio chip
22:41:37.260 -> [RF] Step 3: Set frequency
22:41:37.260 -> [RF] Step 4: Enter RX mode
22:41:37.260 -> [RF] Step 5: Configure protocol timeslots
22:41:37.260 -> [RF] Using LEGACY (FLARM) protocol descriptor
22:41:37.260 -> [RF] Step 6: Update timeslot parameters
22:41:37.260 -> [RF] Air time: 6ms
22:41:37.260 -> [RF] TX interval: 600-1400s
22:41:37.260 -> [RF] Slot 0: 400-400
22:41:37.260 -> [RF] Slot 1: 800-400
22:41:37.260 -> [RF] ✓ Protocol switch complete!
22:41:45.483 -> [RF] Switching to FANET
22:41:45.483 -> [RF] Switching: 0 → 5
22:41:45.483 -> [RF] Step 1: Shutdown radio
22:41:46.865 -> [RF] Step 2: Reconfigure radio chip
22:41:47.241 -> [RF] Step 3: Set frequency
22:41:47.241 -> [RF] Step 4: Enter RX mode
22:41:47.241 -> [RF] Step 5: Configure protocol timeslots
22:41:47.241 -> [RF] Using FANET protocol descriptor
22:41:47.241 -> [RF] Step 6: Update timeslot parameters
22:41:47.241 -> [RF] Air time: 36ms
22:41:47.241 -> [RF] TX interval: 2500-3500s
22:41:47.241 -> [RF] Slot 0: 0-0
22:41:47.241 -> [RF] Slot 1: 0-0
22:41:47.241 -> [RF] ✓ Protocol switch complete!
22:41:50.454 -> [RF] Switching to LEGACY
22:41:50.454 -> [RF] Switching: 5 → 0
22:41:50.454 -> [RF] Step 1: Shutdown radio
22:41:51.890 -> [RF] Step 2: Reconfigure radio chip
22:41:52.267 -> [RF] Step 3: Set frequency
22:41:52.267 -> [RF] Step 4: Enter RX mode
22:41:52.267 -> [RF] Step 5: Configure protocol timeslots
22:41:52.267 -> [RF] Using LEGACY (FLARM) protocol descriptor
22:41:52.267 -> [RF] Step 6: Update timeslot parameters
22:41:52.267 -> [RF] Air time: 6ms
22:41:52.267 -> [RF] TX interval: 600-1400s
22:41:52.267 -> [RF] Slot 0: 400-400
22:41:52.267 -> [RF] Slot 1: 800-400
22:41:52.267 -> [RF] ✓ Protocol switch complete!
Moshe Braner
Jan 16, 2026, 9:52:29 PMJan 16
to SoftRF_community
Very interesting Vlad. First I want to emphasize that your "dual protocol" is time-slicing, rather different from the dual-protocol mode my most recent version of SoftRF offers, which can actually receive either FLARM or ADS-L packets, which ever arrives at any time. That is possible thanks to those two protocols sharing the modulation type, frequency, etc. That is not possible with FANET paired with "Legacy" so you have to time-slice.
I wonder why your protocol switch takes so much time though. You said 700 ms, the time line in the captured serial output shows an even longer time. This may be due to the way the "upstream" code is organized, when things happen in the loop()? Or the way the RadioLib is structured? I would think it can be done much much faster. The time-consuming steps seem to be "Shutdown radio" and "Reconfigure radio chip"- does the RadioLib have long delay()s in those ops, to ensure the radio chip is stable in its new configuration?
For comparison, in my code, if you activate an "alt protocol", for example if it is listening and transmitting Legacy/Latest and you want an occasional OGNTP transmission, when the time comes for that transmission the chip is reset and the protocol is switched in the LMIC structure and the frequency is calculated etc. And all that, I would guess (should measure?), takes a few ms at most. All it does is load the control registers of the radio chip with the right values.
The code to reset the sx1262 radio chip in this library has a delay(1), just one ms. Right after the alt protocol transmission it reverts to the main protocol for reception, with similar operations. Just like it returns to rx mode after each tx even when not switching protocols. At a random time within each 400 ms time slot (of the Legacy protocol) it reconfigures for tx, sends out a packet, then reconfigures for rx - and those reconfigurations cannot take long, since it successfully receives one packet per time slot from each nearby similar device.
VirusPilot
Jan 19, 2026, 9:48:09 AMJan 19
to SoftRF_community
Only a few observations as I have also played with the T1000-E:
- Linar seems to be not so happy with this device as the device is shipped with SoftDevice version 7.3.0 but needs to be downgraded to v6.1.1 to work with upstream SoftRF (quite a messy process), he now recommends the ThinkNode M3 instead which has the same RF chip LR1110 but ships with SoftDevice v6.1.1
- I managed to do this downgrade and can successfully compile and upload my modified versions
- The LR1110 contains an SX1262 and a GNSS chip and if I understood the upstream code correctly, Linar uses the radiolib for this chip while for the other pure sx12xx chips he is using the lmic library and therefore the recently introduced changes in Moshe's fork related to preamble need to be verified and ported to the LR1110 (tbc.)
Vlad Belayev
Jan 19, 2026, 3:28:04 PMJan 19
to SoftRF_community
Ah yes, thats OK, for the first issue downgrading the bootloader ( indeed a tedious process ) I have an answer in terms of this python based utility.
https://slash-bit.github.io/SoftRF-PG/
It would take 2 min to do the whole flashing process.
I had a look at ThinkNode M3 , its cool , and practically identical spec. I think it would be a matter of pilot's choice, the firmware would be the same.
The M3 ( its slightly thicker) But better IP66 rating.
so if you wanted to install on the outside of the glider , you you could :-) I was thinking a Shark fin type of enclosure with a slot where it would slide in. But you won't hear the buzzer though.
https://github.com/lyusupov/SoftRF/wiki/Pocket-Edition
I am also curious, if something needs to be done for lr11xx setup in light with recent changes in preamble and syncword.
I have it opened and can't see definitions in radiolib.cpp. Instead they seem come from Legacy.cpp file which would be common to all chips, right?
This is it, attached, I think ?
https://slash-bit.github.io/SoftRF-PG/
It would take 2 min to do the whole flashing process.
I had a look at ThinkNode M3 , its cool , and practically identical spec. I think it would be a matter of pilot's choice, the firmware would be the same.
The M3 ( its slightly thicker) But better IP66 rating.
so if you wanted to install on the outside of the glider , you you could :-) I was thinking a Shark fin type of enclosure with a slot where it would slide in. But you won't hear the buzzer though.
https://github.com/lyusupov/SoftRF/wiki/Pocket-Edition
I am also curious, if something needs to be done for lr11xx setup in light with recent changes in preamble and syncword.
I have it opened and can't see definitions in radiolib.cpp. Instead they seem come from Legacy.cpp file which would be common to all chips, right?
This is it, attached, I think ?
VirusPilot
Jan 19, 2026, 3:34:43 PMJan 19
to SoftRF_community
Yes, the definitions come from Lecacy.h but there is no code (yet) in the radiolib to process LEGACY_SYNCWORD_SKIP.
Constantin H. Klug
Jan 20, 2026, 3:53:28 AMJan 20
to SoftRF_community
Hi all,
I have a question on the sideline.
GxAirCom states that it is capable of transmitting FLARM and FANET at the same time.
Can we achieve the same with SoftRF?
BR
Vlad Belayev
Jan 21, 2026, 1:50:03 PMJan 21
to SoftRF_community
Where GxAirCom states that?
On a single chip such as SX1262 (or LR1110) it can be either FLARM or FANET at any given time. They are two significantly different radio protocol one is GFSK based an the other LoRa based,
so the radio modem needs to be switched. I believe GxAirCom does it based on internal clock 2-3 seconds spent in one mode and another 2-3 sec in another.
This is a compromise, as it will not receive one protocol whilst operating the other.
On a single chip such as SX1262 (or LR1110) it can be either FLARM or FANET at any given time. They are two significantly different radio protocol one is GFSK based an the other LoRa based,
so the radio modem needs to be switched. I believe GxAirCom does it based on internal clock 2-3 seconds spent in one mode and another 2-3 sec in another.
This is a compromise, as it will not receive one protocol whilst operating the other.
Moshe Braner
Jan 22, 2026, 9:43:37 PMJan 22
to SoftRF_community
I now have a beta version that can both transmit and receive in both FLARM-compatible and FANET protocols at the same time! If anybody wants to help test it let me know. There are way more operational modes than I can test myself, and I can't do airborne tests until spring.
It is of course not quite "at the same time", but the time slicing in my scheme is designed to minimize the performance impact. It always listens to FLARM packets (and optionally ADS-L too, truly at the same time!) during time slot 0 (400-800 ms after PPS), which is when FLARMs transmit a fresh position. FLARMs transmit the exact same position again during time slot 1, but this version of SoftRF, in dual- (or triple-) protocol mode, dedicates slot 1 (and a bit more) for FANET. That means close to 60% of FANET packets will be received. The same scheme, with P3I (Pilot Aware) instead of FANET, is also an available option.
Moshe Braner
Jan 22, 2026, 9:47:50 PMJan 22
to SoftRF_community
Oops, forgot to mention: my beta version is for the old (non-Supreme) T-Beam only, at the moment. I will soon compile it for the T-Echo too. I am not able to compile it for other devices (such as the T1000-E or Thinknode M3) at this time - somebody needs to develop code to handle the LR1110 chip in those.
Moshe Braner
Jan 23, 2026, 7:17:15 PMJan 23
to SoftRF_community
Now compiled for T-Echo too, so ask me for it if you want to test it. Noticed that MB173 on T-Echo in pure-FANET mode does not transmit. If you need that, ask for the beta version, or revert to an earlier version.
Reply all
Reply to author
Forward
0 new messages