Differences

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

--- packet:lora_vhf_aprs_gateway [2025/03/30 15:44] – 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.
@@ Line 106: / Line 104: @@
 ===== 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]]