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 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.

This configuration assumes the VHF radio's TNC is on serial KISS (such as a NinoTNC in 1200 baud mode), and the LoRa module has TCP KISS enabled. There is come explanation under the config itself

mycall  MB7UBK
myloc lat 5116.93N lon 00107.49W

<interface>
   tcp-device    my-lora-module-local-hostname  8001    KISS
   callsign      MB7UBA
   tx-ok         true
</interface>

<interface>
   serial-device  /dev/serial/by-path/platform-20980000.usb-usb-0:1.3:1.0 57600 8n1    KISS
   callsign       $mycall
   tx-ok          true
</interface>


<digipeater>
    transmitter     $mycall
    # A slightly stronger than default rate limit, as the docs say the default "saturates" a 1200 baud channel, so lets go under that.
    # 30 packets a minute average, 60 peak. This is half the default.
    ratelimit 30 60
    # And a tighter limit from any individual callsign
    srcratelimit 10 30
    <source>
        source         $mycall
        # Only digi direct heard packets, this makes us act as a fill-in on the VHF side
        relay-type     directonly
        # Also delay digipeating VHF packets back out on VHF, to give the bigger nearby digipeater a chance to do a better job, and we will just pick up any slack
        viscous-delay  5
    </source>
    # The source below is from LoRa and means VHF will be digipeating all LoRa packets
    <source>
        source         MB7UBA
    </source>
</digipeater>

<digipeater>
    transmitter     MB7UBA
    # Stronger than default rate limits for LoRa as it is a slower mode, 10 packets per minute average, peak 20
    ratelimit 10 20
    # And no more than 5 packets a minute from a single callsign
    srcratelimit 5 5
    <source>
        source         MB7UBA
        # Optionally add "relay-type directonly" if you want to be only a fill-in level digi on LoRa side.
    </source>
    # The source below is from VHF and means LoRa will be digipeating all VHF packets
    <source>
        source         $mycall
    </source>
</digipeater>


<beacon>
# All beacons will go to radio and APRS-IS
beaconmode radio
cycle-size 30m

# Primary MB7UBK VHF beacon
beacon interface MB7UBK via WIDE2-1 symbol "1#" $myloc comment "LoRa-VHF APRS Gateway (LoRa via MB7UBA) https://ukpacketradio.network/aprs:mb7ubk"

# MB7BUK VHF beacon pseudo-digi'ed on the LoRa side from MB7UBA (saves using an object, when we do not really want APRS-IS to get both a position and an
# object of the same thing, and while we can avoid gating both, something else may gate it anyway)
beacon interface MB7UBA srccall MB7UBK symbol "1#" $myloc comment "LoRa-VHF APRS Gateway (LoRa via MB7UBA) https://ukpacketradio.network/aprs:mb7ubk"

# Primary MB7UBA LoRa beacon (very slightly different GPS coordinates than $myloc used for VHF)
beacon interface MB7UBA via WIDE2-1 symbol "L#" lat "5116.92N" lon "00107.51W" comment "LoRa-VHF APRS Gateway (VHF via MB7UBK) - LoRa: 439.9125mhz, BW 125khz, SF12 CR5 - https://ukpacketradio.network/aprs:mb7uba"

# MB7UBA LoRa beacon pseudo-digi'ed on the VHF side from MB7UBK (saves using an object, when we do not really want APRS-IS to get both a position and an
# object of the same thing, and while we can avoid gating both, something else may gate it anyway)
beacon interface MB7UBK srccall MB7UBA symbol "L#" lat "5116.92N" lon "00107.51W" comment "LoRa-VHF APRS Gateway (VHF via MB7UBK) - LoRa: 439.9125mhz, BW 125khz, SF12 CR5 - https://ukpacketradio.network/aprs:mb7uba"

# GB7BSK BBS object to VHF
beacon interface MB7UBK via WIDE2-1 object "GB7BSK" symbol "/B" $myloc comment "432.625 MHz 9600 GFSK IP2P+CRC https://ukpacketradio.network/nodes:gb7bsk"

# GB7BSK BBS object to LoRa, pseudo-digi'd as if originating from VHF MB7UBK (this means the object will only appear once on APRS-IS, as this will look like a digi'd copy of the identical object)
beacon interface MB7UBA srccall MB7UBK object "GB7BSK" symbol "/B" $myloc comment "432.625 MHz 9600 GFSK IP2P+CRC https://ukpacketradio.network/nodes:gb7bsk"
</beacon>

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.

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.

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.

APRX documentation