Posting on “off-topic”, as previous LoRa-related posts appeared here.
I put together a simple firmware and QSO controller for a Heltec LoRa board, which can be controlled by one’s phone and allows for simple FT8-style QSOs over the LoRa physical layer. The idea is the same as the APRS-over-LoRa devices many of us are using: implement a well-known amateur radio protocol over a different modulation/physical layer.
And here comes a question. The LoRa board I’m using communicates over the ITU region 1 ISM 433 MHz band, which overlaps with part of the UK 432MHz band. So if I make QSOs with other operators using similar boards, while following the criteria in subsection 3.7.1 of the SOTA General Rules, would I be able to qualify a summit activation? Or in other words, is there any intrinsic limitation preventing us from using LoRa as a valid amateur radio mode?
You will not be flavour of the month with Ofcom. The desire is for ham LoRa to be up at 439MHz so the higher output powers and much increased duty cycle of Amateur LoRa does not spoil the ISM LoRa users of 433MHz.
You can put it on 433. But you shouldn’t. Put it up at 439 and play nice with the other band users.
For years I have been fascinated by spread-spectrum modulation and its capabilities for below-the-noise reception. But it wasn’t until I and others set up LoRa iGates in G/LD that I discovered – walking around my local area as well as going up SOTA / WOTA summits - how amazing the Chirp version of SS is at making tracker-to-iGate/digipeater contacts (for APRS) in seemingly impossible terrain with such low power and small antennas.
So, adapting the existing ‘tracker’ firmware for FT8-like texting between mobile units would seem an ideal way for local / regional mobile-to-mobile comms in mountainous terrain (more effective than VHF analog modes and more convenient than via NVIS on 60m). There was some discussion on this reflector on how to set up trackers for text messaging but I don’t recall seeing anything on how it worked in practise.
It would be interesting to see some field trials to find out how practical it is without iGates for mobiles to receive each other’s signal. This fits very well with one of A.R.s prime directives: experimentation.
Re the 433MHz vs 439MHz discussion, it seems to me (although I’m far from being an expert) that – apart from avoiding potential interference to ISM users, the UK 439MHz configuration has several important advantages:
The much higher RF output allowed by Ofcom
Brilliant SNR (decodes up to -20 dB below noise) using SF=12 c.f. at least -7.5 dB SNR needed for SF=7 (as used by “433” configuration)
leading to better range
The disadvantages are:
Lower data rate (~293 bps at 125 kHz) compared to SF=7 (~5.47 kbps at 125 kHz)
which leads to longer Time-on-Air: ~1.3s/packet vs 30-50ms/packet
which leads to higher battery consumption
In practise they shouldn’t be a problem.
Re 2) the longer T-o-A times are only a problem if it were to lead to multiple packet collisions, which, with small numbers of mobile units operating at the same time in the same area, is very unlikely.
Re 3) I find I can do many activations using my tracker before any significant drop in battery charge. Unless you are texting like a teenager in love, the text-over-LoRa ought not to be worst than using APRS-over-LoRa.
Of course, if it proves practical and used for SOTA, it might be a contender for the “Ultimate SOTA Minority Sport” prize [MT, make a note to create one] simply trying to find a chaser with the same setup.
I was considering adding APRS support to the FT8/LoRa firmware, but as you said it’s probably more useful to go the other way around, create a fork of CA2RXU’s project and add FT8/messaging functionality to it. That way I can benefit from their handling of the GPS interface and support to different boards (mine works only on Heltec v3 at the moment). I’ll look into it.
Can I suggest a soundtrack for the prize ceremony?
The tracker APRS messages are received by iGates (and forwarded to the APRS servers). I had assumed simplex texting would be mobile to mobile, and those packets would be ignored by iGates and digipeaters. Is it realistic to combine both APRS and test messaging into the same firmware?
If text was embedded in APRS messages, how would iGates know not to route them to the APRS servers?
It could. AFAIK, the APRS protocol spec includes messaging and even support for acknowledgements, so one could even build a sort of whatsapp-style app with double-tick!
I’m not sure if the APRS implementation over LoRa by CA2RXU implements it, though. It certainly doesn’t implement an interface for the operator to send and receive the messages – which is what the FT8/LoRa linked above does differently, by allowing you to read and write messages through your phone, which connects to the LoRa board via its WiFi interface. It happens to use FT8 syntax for the messages at the moment, but could certainly be changed/extended to follow the APRS packet format.
The “position” and “message” are different packet formats in the APRS protocol. Their first character is different, so if the iGates implementation of the protocol is sound, they will know how to distinguish them.
@G3CWI and I had a text message exchange a while ago using LoRa. It went via a digipeater (or two) though not simplex - I couldn’t find a way to set the LoRa firmware to use DIRECT rather than a WIDE path but it should be possible to tweak the message headers in the firmware to do this. I’ve deleted the screenshots of the ‘QSO’ now. I think Richard was on Shining Tor at the time so if it had been a simplex contact would it have counted as a chase?
Messages were sent using APRSDroid at my end, the same way I send a spot to APRS2SOTA.
I know someone who is interested in using a T-Deck for messaging to cut out the phone/Bluetooth bit. This would be similar to the Meshtastic/Meshcore devices.
I think the important aspect is whether the APRS packets were sent over a simplex RF link, or using other means (digipeater, mobile data, etc.)
AFAIK, APRSDroid can be configured to send APRS packets in three different ways:
1- over the internet (your data provider, or WiFi if within range)
2 - as audio out of your phone speaker (so it can be transmitted by your radio)
3 - over bluetooth (so it can be transmitted by some TNC, which could be a LoRa board)
If APRSDroid is configured with option 2 or 3, and the radio/TNC is transmitting/receiving directly to/from the activator using a similar setup, over an amateur band and within the constraints of their licenses, I would say it should count as a chase.
What I am currently trying to do is to use a phone to connect to the LoRa board using the board’s WiFi interface – the board becomes a WiFi access point, and provides the phone with a webpage to send/receive messages and control the LoRa radio. The phone only connects to the LoRa board next to it, no internet access needed. There is no need for any app either (all the control is done over a browser), so it works with all smartphones (Android, iphone, etc.)
Having a T-Deck to handle the message input and display is also a good alternative, but would require a more complex (and possibly energy-hungry) firmware. By delegating a lot of functionality to the phone, I am trying to keep the LoRa board firmware lean, portable, and energy-efficient (which is a design choice that CA2RXU also followed).
I like your idea. FT-8 over LoRa sounds like great fun! Of course LoRa packets sent direct from a summit station to a chaser would qualify as a QSO, however this would take a bit of setting up, with both ends needing to flash boards with the same frequency, but one that is different to the 439.9125Mhz that the trackers and i-gates use, so a bit of a faff really.
I’m keen to see how the FT-8 idea will be implemented in a simple and efficient way.
It seems that “standard” LoRa APRS iGates and digipeaters are completely agnostic to the payload type. They do not selectively drop text packets; instead, they successfully decode the data packet, recognise the message data identifier, and actively forward them to the global online APRS-IS server infrastructure. This allows you to text other radio operators globally or use services like SMSGTE to bridge your radio text messages straight to real mobile phone numbers.
My source could be wrong so it would be good to find out the actual case. Both cases could be true depending on the firmware implementation.
I thought it should be enough to add a Simplex Mode so to say by setting the path to WIDE0-0 ?
Then digis should ignore the package. This would allow a SOTA valid QSO over LoraAPRS ? Maybe it needs a check also if the packet did not got d’peated ?
You are right! I have just double-checked the sources of CA2RXU’s iGate firmware, and it is extremely permissive. It will forward anything it receives, regardless of the APRS type: position, message, telemetry, status, weather, it all gets forwarded. Interestingly enough, it checks if the callsign is well formed, and whether the callsign hasn’t been blacklisted.
So if we want to make sure any QSOs performed over LoRa are simplex and don’t go through any iGates, I guess we should steer away from their allocated APRS frequency and/or spreading factor (which, in the UK, this means away from 439.9125 MHz SF 12).
@GM4LLD Do you have any more detail about Ofcom’s intentions for Amateur LoRa? i.e. which part of the 439MHz sub-band?
It appears that existing ‘439’ iGate / digipeater firmware would ‘upload’ or ‘repeat’ the texting packet so violating the SOTA Prime Directive about not using repeaters. You could have a “70cm QSO” with a specific callsign (who has the means) anywhere in the world.
Ofcom doesn’t explicitly restrict LoRa to 439.9125 MHz, but they do regulate the modes, bandwidths and power levels permitted across the rest of the 70cm band.
As long as you hold a valid UK Amateur Radio licence and comply with the RSGB band plan, you should legally be allowed to experiment with LoRa on other 70cm frequencies.
In the 2026 Band Plan for 70cm, it reserves 439.6000-440.0000 MHz MHz for Digital Communications
And Note 9 says Coordinated usage includes - Low-power Lora 125kHz Max BW at 439.9125 MHz, POCSAG Pagers at 439.9875MHz
So, if you picked an unused 125-kHz range in that sub-band, IMO you should be alright.
So on normal AX.25 APRS you can see if the packet was heard directly or if it has been digipeated. Does LoRa not just embed the existing AX.25 data into a LoRa packet? Or is it different so you cannot tell if the packet was heard direct or not? Obviously if you can’t tell if it was heard direct then there is a chance it’s been digipeated.
If this is the case there’s nothing to stop you picking a different coding rate for direct messaging and use the same frequency. That way the iGates etc. wont decode your packet and you’ll know anything receiving you will be receiving you direct or it wont decode.
That seems the best solution. So, if you chose a different spreading factor eg SF=10 and hence a different data coding rate, existing iGates and digipeaters on the same frequency would treat those packets like background noise.
