[aprssig] LoRa GPS tracking

Tue Sep 6 10:52:06 EDT 2022

On Tue, Sep 6, 2022 at 12:43 AM Dana Myers <k6jq at comcast.net> wrote:
> Has anyone proposed/implemented APRS functionality on LoRaWAN?

I've been thinking of something similar for a student group I've been
working with. We're making a system that does both "traditional" APRS
and LoRa APRS (and LoRa sensor data) with a raspberry pi pico. The
main reason why we're using traditional APRS is because of the
excellent existing network infrastructure compared to LoRa, but things
like LoRaWAN (e.g., Helium, Things Network, etc.) are challenging
that. Of course with the caveats that Helium is encrypted, not
licensed amateur radio, and costs fractional pennies per packet (for
better or worse).

First a, a distinction: LoRa is just the physical and link layers (and
can be used as licensed amateur radio when operating at higher powers,
at least in the US). LoRaWAN is the network layer added on top of the
LoRa link layer (it is encrypted and generally thought to be
incompatible with licensed amateur radio). Therefore, there are at
least two strategies:

1) You can implement the APRS network as a whole just using LoRa as
the physical and network layers (kind of like how HF implements APRS
using a different physical layer than VHF APRS). Justin KD8IAY's link
is a great example of LoRa implementation of the APRS network (with
digipeating and igates). This approach is not LoRaWAN, but is in the
spirit of amateur radio in that the network is entirely over-the-air
and unencrypted (there's some whitening and proprietary encoding, but
it's open to anyone listening):
https://github.com/sh123/esp32_loraprs
There's also at least one other project for trackers and igates:
https://github.com/lora-aprs
That can be used for licensed amateur operation when used with higher
powers (although, like with APRS, more power doesn't necessarily mean
better). These implementations are basically the APRS network, just
not using VHF AX.25 (i.e., not using the physical and link layers that
VHF APRS uses). However, this isn't exactly what you are asking.

2) You can use LoRaWAN instead of the APRS network (no digipeating nor
explicit igate hardware). This is actually just using APRS at the
highest levels (application/presentation) and using completely
different physical, link, and network layers. Since LoRaWAN does its
own networking (and relies on network servers to be the endpoints of
uplinks), I believe you'd need something at a higher level in the
stack to act as a broker for the APRS packets. This centralization is
a "weakness" of LoRaWAN compared to the APRS networking, but the
benefit is that not every packet needs to be relayed constantly - and
you can more efficiently send a packet exactly where you want. This
might look like an APRS MQTT server or "MQTT Integration" (using
Helium terminology) where APRS clients subscribe to their callsign and
altnets to receive messages, and then an aprs-is bridge between
LoRaWAN/aprs-is would subscribe to all messages and forward them to
aprs-is (and take messages from aprs-is and put them on the APRS
MQTT). This MQTT server would essentially be something like a "LoRaWAN
APRS domain name server" that points packets to their recipients.
Maybe there's a way to directly message another device, I just haven't
found how yet.

This does bring up another question: if the future of APRS is actually
messaging between devices on different networks (e.g., VHF, HF, LoRa,
& several LoRaWANs), it's crucial that there is some specification
about how all these networks interact (what Steve Dimse K4HG points
out). Maybe HF APRS should be able to send a message to a LoRaWAN APRS
device, but the exact way LoRaWAN APRS and HF APRS communicate with
each other within their own network will be different. That is
something I think might be good for the foundation to discuss: what is
APRS? Right now it's kind of defined as VHF AX.25 packets with
specific data format. Maybe modular specifications would be more
appropriate where APRS just defines the interfaces rather than the
whole stack, because new innovations will keep coming - the key might
be to spend energy that allows all these innovations to be
interoperable.

-Scott KD9PDP

On Tue, Sep 6, 2022 at 12:43 AM Dana Myers <k6jq at comcast.net> wrote:

>
> I've done some experimenting with a GPS tracker (Dragino LGT-92)
> fitted with an external mag-mount antenna. While this operates
> in the 902-928MHz band, it falls under Part 15 unlicensed operation.
> Transmit power on the LGT-92 is +20dBm (100mW).
>
> In several test drives, I've found excellent coverage via Helium hotspots.
> Yes, Helium costs money ($1 for 100,000 packets) but the infrastructure
> is pretty amazing.
>
> I appreciate the change here from licensed amateur radio operation
> to unlicensed operation - but consider this makes it available to all.
> With a bit of planning, this easily permits global coverage.
>
> I also appreciate the LoRa radios are Semtech proprietary IP. They're cheap
> enough and widely available.
>
> LoRaWAN uses AES-128 encryption from edge devices, so there's
> little eavesdropping that can be done. Note that encryption is not
> an issue for Part 15 operation.
>
> Has anyone proposed/implemented APRS functionality on LoRaWAN?
>
> 73,
> Dana  K6JQ
>
>
>
>
> On 8/7/2022 11:07 AM, Polymath wrote:
> > Hopefully folks are checking out the multitude of LoRa trackers already
> being worked on... so that there is a convergence of implementations
> instrad of a Tower of Babel...
> >
> >
> > Sent from my iPhone - my apologies for autocorrection and thumb typing
> mistakes
> >
> >> On Aug 7, 2022, at 18:00, aprssig-request at lists.tapr.org wrote:
> >> 
> >> From: Jason KG4WSV <kg4wsv at gmail.com>
> >>
> >> Are you using LoRa or the full LoRaWAN stack?
> >>
> >> -Jason
> > _______________________________________________
> > aprssig mailing list
> > aprssig at lists.tapr.org
> > http://lists.tapr.org/mailman/listinfo/aprssig_lists.tapr.org
>
>
> _______________________________________________
> aprssig mailing list
> aprssig at lists.tapr.org
> http://lists.tapr.org/mailman/listinfo/aprssig_lists.tapr.org
>

-- 

*Scott Howard, PhD*
*Associate Professor*
Department of Electrical Engineering
College of Engineering Bioengineering Program
University of Notre Dame
http://ee.nd.edu

574-631-2570 (direct)
574-631-4393 (fax)

https://howardphotonics.nd.edu
Follow me on Twitter @HowardPhotonics <https://twitter.com/HowardPhotonics>

262 Fitzpatrick Hall
Notre Dame, IN 46556
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.tapr.org/pipermail/aprssig_lists.tapr.org/attachments/20220906/8ef46455/attachment.html>