FT8 over LoRa

[G8CPZ]

@G5LSI

That sounds like a good plan

But there’s a catch …

For the simplex mode texting mobile to mobile, you no longer have the benefit of all those well-located iGates and digipeaters. So, you want to avoid anything that would degrade the rx sensitivity of the mobiles.

SF=12 is already the maximum spreading factor for some of the chipsets. Moving from SF12 to SF10 means you lose roughly 5 to 6 dB of receiver sensitivity. In a non-line-of-sight environment (like a deep Lake District valley), this can mean the difference between decoding a message and getting nothing but noise.

So, you might want to consider the tradeoffs of two options: 1) use the 439.9125-MHz frequency but change SF=10 to avoid non-simplex paths or 2) chose a nearby alternative frequency and keep SF=12 for maximising receiver sensitivity.

[MM0EFI]

@G8CPZ

chose a nearby alternative frequency

I think that’s the sensible option. 439.800Mhz?

[M9SOE]

If you have a look at the GB0SNB (Kelveden Hatch) WebSDR on 70 cm wide band and go to 439.9125 you will see why LoRA signals are stuck there. The bandwidth of LoRA signals is very wide.

GB0SNB/MX0SNB/M0SNB – Kelvedon Hatch Secret Nuclear Bunker

[M9SOE]

This is the bandwidth of the LoRA signal. On the left, you can see some DV signals from repeaters!

[G8CPZ]

@M9SOE

bandwidth of LoRA signals is very wide

125 kHz

[M9SOE]

I’m told it’s a visual illusion - SDR display stretching and packet duration, rather than the signal’s actual RF footprint. LoRA is still ten times wider than DV signals

[G8CPZ]

@M9SOE

LoRA is still ten times wider than DV signals

Because cheap LoRa trackers lack highly-stable components, their actual operating frequency can drift with changing outdoor temperatures. A 125-kHz wide bandwidth creates a big safety cushion so that any drift doesn’t cause the receiver to decode a symbol wrongly.

The UK ‘439’ LoRa standard utilises Spreading Factor 12 (SF12) to maintain compatibility with global firmware systems. SF12 maximises receiver sensitivity but also inadvertently makes the system extremely vulnerable to temperature drift.

Had the tracker boards used expensive highly-stable components, you could have chosen a smaller bandwidth for the 70cm LoRa standard, and benefit from a higher SNR on the analogue front-end of the receiver. But probably many fewer people could have afforded that.

This was a real-world tradeoff: accept using a 125-kHz bandwidth (no big deal on 70cm) to get reliable operation with cheap hardware. It means the amateur community has gained access to a massive ecosystem of incredibly cheap, mass-produced commercial hardware (like LilyGO T-Beam trackers or basic SX1276 modules).

[G8CPZ]

@M9SOE

I’m told it’s a visual illusion

I don’t know why you were told that - the SDR display looked fine to me.

I clicked on your link and waited (awhile) until 3 packets were displayed. Measuring crudely from the waterfall, each extended from 439.850 to 439.975 which makes sense to me for a signal centred on 439.9125 MHz with bandwidth +/- 0.0625MHz.

[G5LSI]

Hi all, thanks for the comments and suggestions.

The weekend was busy with the SOTA Hog Roast and activations in Wales and Shropshire, so only had some time to look into this last night (while watching two fairly entertaining world cup matches).

I checked again the code of the APRS iGate, and did a few tests with the FT8/LoRa nodes and my APRS iGate, and I couldn’t find any way to isolate traffic transmitted on the same frequency using the same spreading factor. I tried using different APRS packet types/headers, as well as different LoRa sync words, but FT8 traffic would still be received by the APRS node, and vice-versa. So it confirms what many of you said: we need a different frequency or a different spreading factor.

As previous comments indicate, the decision on which frequency is suitable for LoRa traffic seems to be beyond my remit, so the best option seems to stick to the same frequency and bandwidth already used by APRS, and use a different spreading factor. Chirp modulation guarantees the (quasi) orthogonality of the spreading factors, so FT8 and APRS won’t interfere with each other.

So I will set the default spreading factor for FT8/LoRa to be 11 (but allow people to reconfigure that if they want). With SF 11 we lose about 2.5 dBm compared to SF 12, so receiver sensitivity will be reduced but not by much. On the other hand, it reduces transmission times by almost half, which is handy in the unlikely case this becomes popular and multiple people are using it simultaneously.

I have also created a merge between FT8/LoRa and CA2RXU’s APRS Tracker firmwares, so we can have both of them running on the same board. I tried to leave the APRS Tracker functionality completely untouched, so it keeps working as before (including configuration menus), until it detects a triple-button press during tracking mode. At that point, it stops sending out APRS packets, enables WiFi to serve the FT8/LoRa interface, and allows QSOs to take place just as the standalone FT8/LoRa I shared before. Another triple-button press, it shuts down FT8/LoRa and goes back to APRS Tracker. The rationale is to allow people to continue to use their APRS trackers exactly as before as they travel/hike, and then change into FT8/LoRa when they are on the summit to try a few QSOs. At the moment, I have only tested this on the T-Beam board, and it works well. I’ll do some more tests, and will see if it works just as well with the Heltec Tracker (which I believe is the most popular LoRa board among SOTA folks). Once I’m happy with the tests, I’ll upload everything to github and share the link here.

[GM4LLD]

I was thinking further about this. You could keep the spreading the same but change the frame checksum or CRC or whatever, I haven’t looked to see what it uses. But let’s assume CRC… change the polynomial so the CRC is different. Then APRS nodes will hear the packet but not decode it and likewise new code will ignore APRS packets. That gets you the 2.5dB loss back.

[G5LSI]

I have now finished the tests with both Lilygo T-Beam and Heltec Tracker boards running the merged firmware with APRS Tracker and FT8. It works really well (photos below).

Tracker running normal APRS mode.

FT8 mode is enabled with a triple-button press. At that point, the WiFi access point is enabled, and the board is ready to be controlled by a phone/tablet for FT8 contacts.

CQ message transmitted.

Reply to the CQ received.

At any point, a triple-button press shuts down the access point and the FT8 mode, and returns to APRS mode.

The interface running on the phone/tablet is exactly the same as in the video from the first post in the thread.

I created a separate repository on github for this one, so people can choose to run FT8/LoRa standalone (link on the first post of this thread), or along the APRS tracker (link below):

GitHub - indrusiak/LoRa_FT8_APRS: fork of CA2RXU's LoRa APRS firmware extended with...

[G5LSI]

@GM4LLD

You could keep the spreading the same but change the frame checksum or CRC

That’s a good trick! But it that case, FT8 traffic would compete/interfere with APRS traffic, and I’d rather avoid that.