sh123
commented
3 years ago @mrpatrick1991 , yes, sounds like a good idea as I'm not sure where to progress further, was driving with modem a lot and got idea about capabilities and coverage. Probably, APRS over LoRaWAN solution will require pulling in complete LoRaWAN stack as a dependency.
mrpatrick1991
There are quite a few LoRaWAN networks coming up that provide a lot of useful coverage in the ISM band. Examples are Helium and The Things Network. In particular, Helium has LoRa gateways in almost every major city. There is no technical reason these cannot be used as two-way i-gates for esp32_loraprs TNC devices.
The benefit to esp32_loraprs would be that anyone could use the project to send data to APRS-IS over RF, immediately, and without setting up any infrastructure. There is a strong chance that, with this feature, a user could download the repository, flash it to their ESP32 board, and see their packets sent to aprs.fi (and others) right away. Currently, there is little existing dedicated ham radio LoRa infrastructure, and there are no standard frequencies and settings. This may lead to frustration among users who want a solution that "just works" in the sense of getting their packets on the map. We could duplicate the experience which users of commercial radios with packet TNC's on AFSK 144.390 currently have, without the need to bootstrap our own system.
I suggest that this would be implemented as an optional switch in loraprs_config.h, alongside a switch for sending RF packets point-to-point. Both, one, or none could be selected. This would only be available for radios on 915 Mhz (North America), 868 Mhz (Europe) or 470 Mhz (China).
This feature would need to be combined with a process running on a server to forward packets between the LoRaWAN and APRS-IS services. I have already created this and am using it for my own testing.
One potential problem is the fact that LoRaWAN uses encryption to send packets. This could be mitigated by publishing the encryption keys used for this particular application EUI, so that anybody could decode the packets. On the other hand, this system is similar to just using the internet to forward packets to APRS-IS over wifi, over which the use of encryption has never been problematic. I'd appreciate any feedback or clarity on this.
I'm submitting this as a feature-enhancement idea because I know how to make it work, am essentially using it for my own purposes, and wanted to know if it sounded like a good idea and something that could be useful to the community.