Cross-band-like APRS connectivity

[travnewmatic]

Is there a way to send the serial output of a 'conventional' APRS iGate to the input of a LoRa APRS iGate? (And the other way around)

The behavior that I've noticed is that

• LoRa APRS trackers can see each other,
• Conventional APRS trackers can see each other, but
• without APRS-IS connectivity, the trackers (and devices connected to trackers) have no knowledge of what's going on in the other freq/modulation

Is it possible for received LoRa APRS packets to get digipeated via LoRa as well as conventional APRS modulation? (And ideally, vice-versa)

The goal would be for LoRa APRS trackers to be made aware of conventional APRS nodes, and for conventional APRS nodes to learn about LoRa APRS nodes, via RF.

This seems to be conceptually similar to crossband repeat. But it's not just the frequency that's changing, it's the modulation too (I think). In my head this seems like a cool idea, but I'm not sure if this is beyond the feature set of APRS.

Thanks and have a great day!

[travnewmatic]

actually it looks like this is already a feature of the iGate

[iw2ejh]

you should know that LoRa is running a different frequency and different modulation than VHF APRS. We also have VHF APRS digi and iGates, mixed in some area with UHF APRS , these two groups of devices obviously cannot communicate via RF. Both groups (VHF and UHF) are linked via APRS-IS servers that may route messages where they should. The same occurs with LoRa, it is just another Frequency and modulation, but it is connected to APRS-IS and can interchange messages using internet. Not way to make LoRa to speak with VHF or UHF APRS directly.

[richonguzman]

Travis, do you mean to transmit to LoRa all gps position packets and message packets from APRS AFSK/VHF into LoRA ???

[travnewmatic]

Travis, do you mean to transmit to LoRa all gps position packets and message packets from APRS AFSK/VHF into LoRA ???

Yes, this is what i would like to achieve.

RF Traffic heard by a LoRa iGate is (somehow) re-transmitted by separate, conventional, APRS iGate via RF. (with the correct modulation for conventional APRS)

RF Traffic heard by a conventional APRS iGate is re-transmitted by that LoRa APRS iGate. (again, with the correct modulation for LoRa APRS).

So that, without APRS-IS, a LoRa APRS tracker could hear about and see a conventional APRS object without being able to hear about it directly (and the other way too).

My thinking is that the iGate shouldn't be re-transmitting everything, but only objects within some radius of the iGate.

I've confirmed that messaging can pass between LoRa and conventional nodes using APRS-IS, but not position beacons. With APRSDroid connected to a LoRa Tracker, I can see other LoRa devices heard by the tracker directly or digipeated by the LoRa iGate. I do not see non-LoRa devices, even if i have successfully messaged them.

Is this an unreasonable expectation of APRS?

[SQ2CPA]

You mean forwarding traffic from VHF APRS into LoRa APRS or vice versa?

You must know that LoRa APRS packet = ~600ms where VHF APRS packet is several times longer so forwading traffic from VHF APRS into LoRa APRS is OK because you can see VHF APRS traffic on your LoRa devices and this will not flood the network.

Forwarding traffic from LoRa APRS into VHF APRS is albo possible BUT you MUST create a lot of filters, add a rate limit. For example, you can start from forwarding messages from LoRa APRS into VHF APRS. You have to exclude all static beacons, status messages. This is very hard but possible and without proper knowledge this should not be done because you will kill VHF APRS.

As I know, VHF APRS, most of them don't send message from APRSIS into RF so if you send message from LoRa APRS, it will go into APRSIS server but will not come back into VHF APRS RF to destination. Message sent from VHF APRS will probably go from APRSIS into LoRa APRS RF because we are mostly transmitting messages and we are using APRSIS into RF on our devices with correct filters (only messages).

If you are using aprsdroid with APRSIS connection you will see all objects sent into APRSIS server, the technology to send this message doesn't matter (TCPIP, LoRa, VHF, DMR, D-Star, etc) but if you will connect into TNC via BT into for example tracker you will see only objects RECEIVED by this device and nothing more and your packets will be trasmitted ONLY by that device (to which you are connected), will not be sent directly to APRSIS.

I'm talking typically about Digi here, not IGate because locally we are using LoRa APRS mainly on the RF, not through APRSIS :) I hope I understood you well and explained something more!

[Mane76]

You must know that LoRa APRS packet = ~600ms where VHF APRS packet is several times longer so forwading traffic from VHF APRS into LoRa APRS is OK because you can see VHF APRS traffic on your LoRa devices and this will not flood the network.

Wow, I think there is a big mistake ! An APRS Lora Packet with 40 byte (and this is more or less minimum, encoded coords, encoded height and speed) has an approx. airtime of 1,8 seconds (!!!!). Same at VHF APRS is 4 times faster, approx. 500ms. When you check the traffic most Lora Packets are at 50-60 byte, so you have airtimes > 2,5 seconds. VHF APRS packets are even longer, >2sec airtime on VHF > 8sec airtime at LORA.

APRS on VHF has to be seen different to APRS via DMR or APRS via LoRa. Comparing APRS on VHF to via LoRa you have a completely different underlaying layer (VHF is AFSK with 1200 Baud, needs good SNR, usually 5-10 Watts ERP or more, special equipment like TNCs or Transceivers, ax25 built-in carrier detection, usually exposed locations, and so on. In contradiction LoRa is more than 4 times slower, works with negativ SNR, usually 100mW, cheap hardware and so on). For APRS on VHF it was essential to have digipeating because in the early days exposed locations were chosen next to repeaters, which were offline from the internet. Fill-in digis were used to reach exposed digis or at least an iGate with access to internet. For APRS via LoRa it is almost vice versa. Almost everyone can operate a RX iGate with internet access, a tight net of RX igates is no illusion and at exposed locations you may encounter problems because of overlapping transmissions.

For APRS via LoRa the basic idea must be "the less bytes the better it is" and "less traffic on the frequency is better". ON4AA has described this very good [here](https://aprs434.github.io/), just as an excerpt, a frame containing 113 bytes (including Headers, PATH, ...) needs at least 4,4s (!) of TX time. In order to decode properly you need to receive the full frame. In comparison, 45 bytes need 2,1s of TX time. Due to the protocol has no carrier sensing a overlapping in crowded areas is not the exception. Imagine, during movement a tracker is sending in an interval if 30sec to 2mins, if you have 10 trackers in the RX area a overlapping will happen, even without digipeating.

Therefore the Software from Ricardo aims to have a compromise between reduction of airtime AND functionality. With stock config you have 40 bytes in total, with omitting WIDE1-1 in path you can come down to 32 bytes.

So please do me a favor and do not (!) crosstransmit from VHF to LORA, this will lock up the frequency. Due to the fact that there is no channel free detection at LORA the iGate will transmit as soon as the packet arrived from APRS-IS (or serial), during this time no RX happens.

Also Digis are very sensitive to LORA, if needed the best way is to use split frequency digipeating - the software from Ricardo also supports this and helps to sanitize the frequency.

BR Manfred

[SQ2CPA]

I forgot about one important thing - we are using 1200bps speed, not 300bps and I'm using this calculator: https://www.rfwireless-world.com/calculators/LoRaWAN-Airtime-calculator.html I put everything: BW 125kHz, CR 4:7, SF 9, 50 bytes and I got about 600ms.

We don't have much traffic on VHF APRS so we don't clog our LoRa network. Everything I wrote above is an individual matter and the most important thing is what is happening locally on VHF APRS and LoRa APRS.

[Mane76]

Ah ok, good to know - so then the 600ms is valid and is the same as on AFSK, this also uses 1200baud.

But everything else what I have written is still valid and it is important to know that the underlaying layers are completely different with different pros and cons.

Enjoy our common hobby Manfred

[travnewmatic]

Thank you for taking the time to write such thorough and detailed responses. I clearly have more to learn about APRS, and about exactly how (and why) LoRa APRS is different than traditional APRS.

I understand that, while technically possible, digipeating traffic between LoRa APRS and traditional APRS isn't a great idea. I'll put that to bed for now.

Thank you again for this project and hope everybody is off to a good start this week!