Differences

This shows you the differences between two versions of the page.

--- packet:lora_vhf_aprs_gateway [2025/03/30 15:22] – 2e0hkd
+++ packet:lora_vhf_aprs_gateway [2025/03/30 15:52] (current) – 2e0hkd
@@ Line 1: / Line 1: @@
-====== VHF-LoRa APRS Gateway ======
+====== VHF-LoRa APRS Gateway Experiment by 2E0HKD ======
-**Work-in-Progress by 2E0HKD**
 LoRa based APRS has taken off, but still remains largely separate from classic 2m FM APRS other than both being ingested into APRS-IS. As LoRa was fairly quiet in my area, I wanted to try and make a cross-band gateway where LoRa and VHF APRS could interact, giving more local info to LoRa users and allowing messaging between the two.
-Using the [[https://github.com/richonguzman/LoRa_APRS_iGate|CA2RXU firmware]] on a LoRa module, you can enable KISS over TCP,and use this to drive the gateway. As I already run a BPQ packet node, which supports APRS and KISS TCP, my first attempt was to add it as a BPQ port along side a 2m port, set them up for APRS, and configure cross-port digipeating (using Digimap, not BRIDGE). This does essentially work (and can nicely integrate into the packet node at the same time if you wish), but it does lack some fine grained control. In the end I went with an APRX based setup instead which let me be a bit more precise.
+Using the [[https://github.com/richonguzman/LoRa_APRS_iGate|CA2RXU firmware]] on a LoRa module, you can enable KISS over TCP,and use this to drive the gateway. As I already run a BPQ packet node, which supports APRS and KISS TCP, my first attempt was to add it as a BPQ port along side a 2m port, set them up for APRS, and configure cross-port digipeating (using Digimap, not BRIDGE). This does essentially work (and can nicely integrate into the packet node at the same time if you wish), but it does lack some fine grained control. In the end I went with an [[https://thelifeofkenneth.com/aprx/|APRX]] based setup instead which let me be a bit more precise.
 ===== APRX Config =====
@@ Line 91: / Line 89: @@
 </beacon>
 </code>
+===== <digipeater> Sections =====
+Each "source" in the digipeater sections identifies one of the <interface> definitions (essentially, the radios) by their assigned callsigns. By having both interfaces as sources, all the packets received on each source will be digipeated on that transmitter. Have this for both LoRa and VHF and you cross band digi in both directions.
+This also means you are acting as a digi in each band individually (VHF-VHF, and LoRa-LoRa), and you can control all those options individually.
+For example, I am close to a very well situated VHF digi which picks up everything in the area much better than my VHF setup can, so there was no point in me wasting air time even digipeating most WIDE1-1 level packets, because it would get them anyway. So I enabled viscous-delay on just VHF-VHF digipeating, which means it waits 5 seconds to see if something else will digi the packet first. If some some reason the big nearby digi doesn't pick it up, I will digi it and hopefully fill in the gap. But for all those times it does pick it up, I won't waste any airtime repeating it a second time.
+Also on VHF I opted for "relay-type directonly", which basically acts as a fill-in digi responding to paths like WIDE1-1 (and not WIDE2-1), because there are bigger digi's that can handle wider area than me on that band. Whereas, on LoRa, there are no other digi's nearby, so I left out directonly.
+Also added are rate limits to avoid flooding the frequency, and these are tighter on LoRa due to it being a slower mode.
 ===== Beacons =====
-I opted to disable the beacons on the LoRa module and instead control them entirely via APRX, because it allowed me to beacon on both bands from different callsigns more easily. The reason for this is the self generated beacon is not sent over KISS and so it not automatically digi'd on the other band. In the UK, we are assigned different callsigns for classic APRS, and LoRa APRS, but I wanted visibility of each on both bands. Usually you would generate an APRS OBJECT when you want to place something with a different callsign, but I did not want 2 competing objects to reach APRS-IS from 2 different callsigns (one from LoRa and one from VHF). So instead, I make a standard beacon, and then a "pseudo-digi'd" beacon on the other band, by constructing a raw beacon that looks the same as if it were digi'd from the other callsign. This way, both bands get to see both sides of the gateway hit the map on RF, with no competing objects on APRS-IS and no use of the wrong callsign on the wrong band.
+I opted to disable the beacons on the LoRa module and instead control them entirely via APRX, because it allowed me to beacon on both bands from different callsigns more easily. The reason for this is the self generated beacon is not sent over KISS and so it not automatically digi'd on the other band.
+In the UK, we are assigned different callsigns for classic APRS, and LoRa APRS, but I wanted visibility of each on both bands, without using the wrong callsign on the wrong band as they are assigned to specific frequencies. Usually you would generate an APRS OBJECT when you want to place something with a different callsign, but I did not want 2 competing objects to reach APRS-IS from 2 different callsigns (one from LoRa and one from VHF). So instead, I make a standard beacon, and then a "pseudo-digi'd" beacon on the other band, by constructing a raw beacon that looks the same as if it were digi'd from the other callsign. This way, both bands get to see both sides of the gateway hit the map on RF, with no competing objects on APRS-IS and no use of the wrong callsign on the wrong band.
 Also included in this example is a similar process for placing an object for my packet node GB7BSK, and the same object pseudo-digi'd on the other band, solving the competing objects issue again.
+===== Results =====
+I only ran the gateway for a few weeks until my 2m port was needed for other packet duties. During that time it seemed to perform well, and didn't hog either frequency too much. I had seem warnings about avoiding digipeating loops between the bands, but from my testing it seemed to properly identify when a packet had already been digipeated (even cross band) and behaved well. (This is one reason to use Digimap and not BRIDGE if you were to do this kind of thing in BPQ, because you want digipeated packets with their modified paths, and not just blindly copied, unmodified packets). Obviously if you have more activity in your area you'll want to keep an eye on things to make sure it doesn't generate too much traffic.
+===== References =====
+[[https://thelifeofkenneth.com/aprx/aprx-manual.pdf|APRX documentation]]