iGate relaying Lora APRS tracker positions to RF

[S57PNX]

I have a tracker A near Gate 1, and a tracker B near Gate 2. Both iGates have APRS-IS connectivity and enabled the option "Gate APRS-IS Messages to RF". There is no RF path between Tracker A and Tracker B.

The expectation is that the beacon of tracker A is received and gated by Gate 1, the beacon goes via the APRS-IS servers and is received by Gate 2. Gate 2 will transmit this package which will be eventually received by Tracker B.

The result is that in Monitor of Gate 2 I can see the beacons from Tracker A, but it is followed by "Station not Heard for the last 30 min (not TX)" and it is not transmitted, so Tracker B will not receive it on its screen.

Please help me understand the flaw in my logic:

1. is this expected to work?
2. How would a Lora APRS gate know how to forward only beacons originating from a Lora Tracker, and not from analog APRS trackers? Or can we mix beacons from different families?
3. Does it make sense to add a "Forward APRS-IS Beacons to RF" functionality ? The clientside APRS-IS filter (e.g. m/10) will prevent from transmitting to RF all the beacons in the world...

Regards, Mitja

[Mane76]

Hello Mitja,

1. is this expected to work?

2. How would a Lora APRS gate know how to forward only beacons originating from a Lora Tracker, and not from analog APRS trackers? Or can we mix beacons from different families?

3. Does it make sense to add a "Forward APRS-IS Beacons to RF" functionality ? The clientside APRS-IS filter (e.g. m/10) will prevent from transmitting to RF all the beacons in the world...

to 1: no to 2: it is technically possible but what is the intention behind ? to 3: no

I do refer to an older post from me which can also be found here. AFSK1200 is more than 4 times faster than LORA APRS with SF12 parameters. So if you would TX all beacons - also in an limited area - will lock up your LORA frequency.

What is intended to work is to send a message from Tracker A to Tracker B in your example. And this would work as you describe, Tracker A sends a message to Tracker B, iGate 1 receives it, forwards it to APRS-IS, iGate 2 will get it if Tracker B was in reach within the last 30mins and TX it.

But could you please explain what is your intention to TX beacons ?

BR Mane

[S57PNX]

Hi Mane,

I did refer to your post explaining the packet size, thanks for writing it. I am aware of the risk of TXing all beacons in the area via Lora. Can we identify only those APRS-IS beacons that originate from a Lora tracker, and transmit only those?

The intention is for Tracker B to see the position of Tracker A, even though there is no RF visibility between them. If Gate 1 and Gate 2 were digipeaters, then Tracker B would have seen the beacon of Tracker A. But since Gate 1 and Gate 2 communicate only via APRS-IS, Tracker B doesn't see the beacon (position) of Tracker A, although it does get the message from Tracker A.

I don't feel strongly about it, it's a mental exercise at this point.

Regards, Mitja

[richonguzman]

Hi Mane,

I did refer to your post explaining the packet size, thanks for writing it. I am aware of the risk of TXing all beacons in the area via Lora. Can we identify only those APRS-IS beacons that originate from a Lora tracker, and transmit only those?

The intention is for Tracker B to see the position of Tracker A, even though there is no RF visibility between them. If Gate 1 and Gate 2 were digipeaters, then Tracker B would have seen the beacon of Tracker A. But since Gate 1 and Gate 2 communicate only via APRS-IS, Tracker B doesn't see the beacon (position) of Tracker A, although it does get the message from Tracker A.

I don't feel strongly about it, it's a mental exercise at this point.

Regards, Mitja

what if you add a high altitude low power digirepeater?

this way you would see and even message directly between trackers/stations

[S57PNX]

In a real world scenario I probably would - even though adding the digi at high altitude means hiking to the mountain, bringing/installing a solar system etc.

My question is to see if we can do the same via internet connectivity that we have on both gates. Maybe with a special direct TCP/IP connection between both gates that relays everything? Just brainstorming.

[richonguzman]

In a real world scenario I probably would - even though adding the digi at high altitude means hiking to the mountain, bringing/installing a solar system etc.

My question is to see if we can do the same via internet connectivity that we have on both gates. Maybe with a special direct TCP/IP connection between both gates that relays everything? Just brainstorming.

the thing is you want to do over internet the sharing of gps beacons... why dont use an internet unit for this then?

I think this is better than forcing to Tx beacons on other parts of the world if it will be done over internet anyway

[S57PNX]

I am comparing this to the DMR model, where the DMR repeaters are connected via Internet (Brandmeister) while the last hop is over RF. And two RF devices can "talk" to each other even though there is an internet link in between.

In an EMCOM, the trackers might not have internet while the gates can have it. That's why we can't use an internet device as tracker.

Anyway, thanks for the discussion, the situation is much more clear now.

[Mane76]

I do understand this example as an exercise - yes, in principle this is possible. With the correct setup of filters you can guide e.g. a beacon from a specific tracker to be TXd on a defined iGate.

But your comparison with DMR is also valid what said before with messages. Two trackers can "talk" to each other. Try it !

To gate the position data from a tracker through the internet and then TX it with RF is a nice experiment in theory, but I do not catch the benefit in relation to the RF load this will produce.

[richonguzman]

I have a tracker A near Gate 1, and a tracker B near Gate 2. Both iGates have APRS-IS connectivity and enabled the option "Gate APRS-IS Messages to RF". There is no RF path between Tracker A and Tracker B.

The expectation is that the beacon of tracker A is received and gated by Gate 1, the beacon goes via the APRS-IS servers and is received by Gate 2. Gate 2 will transmit this package which will be eventually received by Tracker B.

The result is that in Monitor of Gate 2 I can see the beacons from Tracker A, but it is followed by "Station not Heard for the last 30 min (not TX)" and it is not transmitted, so Tracker B will not receive it on its screen.

Please help me understand the flaw in my logic:

1. is this expected to work?
2. How would a Lora APRS gate know how to forward only beacons originating from a Lora Tracker, and not from analog APRS trackers? Or can we mix beacons from different families?
3. Does it make sense to add a "Forward APRS-IS Beacons to RF" functionality ? The clientside APRS-IS filter (e.g. m/10) will prevent from transmitting to RF all the beacons in the world...

Regards, Mitja

maybe a rule to Tx only GPS beacons from TOCALL not being LoRa stations? just as an idea?

[S57PNX]

If anything, I would TX only beacons with TOCALL: APL*. I am not interested in cross-beaconing everything from APRS-IS into LoRa, it will overflow the LoRa channel.