I haven’t touched this in a while, but I may forget if I don’t keep working on it. An advantage of running APRS (on whatever protocol, even if on a license-free band) is the existing infrastructure (APRS-IS) and ability to use existing software for interface (e.g., APRSDroid). Additional advantages of using ESP32 devices are 1) low cost, 2) easy to get, and 3) no need for license, but you can’t use nearly as much power and still be legal.
Of course, there is still the caveat that LoRa itself is a proprietary protocol, so if you need everything to be open, you’ll have to look elsewhere. My interest is working networks. If you want encryption, Meshtastic might work for you.
Copying what I wrote at https://github.com/SQ9MDD/TTGO-T-Beam-LoRa-APRS/issues/29#issuecomment-926018368:
I can confirm that the https://github.com/lora-aprs/LoRa_APRS_iGate project can act as an iGate for a device running this code, if the baud rate is set at 300, not 1200. SQ9MDD’s code can both send and receive packets sent by the lora-aprs code, and vice versa.
This doesn’t solve the ticket, but does make it possible to deploy an iGate/digipeater if you are OK using different code for it. I’m pretty excited for that, at least.
Some notes I took while learning are below.
—–SQ9MDD:
These codes mean:
– 300 baud: `Bw125Cr45Sf4096`
– bandwidth 125 kHz
– coding rate 4/5
– spreading factor 4096 chips/symbol (SF 12)
– 1200 baud: `Bw125Cr47Sf512`
– bandwidth 125 kHz
– coding rate 4/7
– spreading factor 512 chips/symbol (SF 9)lora-aprs:
(values are default except for frequency, which I changed for my device)
Spreading factor is here given in different units? A number between 7 and 12.
2^{𝑆𝐹} 𝑐ℎ𝑖𝑝𝑠 =1 𝑠𝑦𝑚𝑏𝑜𝑙 (source).
So a spreading factor of 12 is 4096 chips/symbol and a spreading factor of 9 is 512 chips/symbol.
