search

lora-aprs / LoRa_APRS_iGate

This is a LoRa APRS iGate/Digi based on an ESP32
https://www.lora-aprs.info
MIT License
344 stars 110 forks source link

strange behaviour with multiple digipeaters close together #99

Closed on1arf closed 3 years ago

on1arf commented 3 years ago

Describe the bug two digipeaters repeat packet multiple times

To Reproduce QTH. Oostende, Belgium. 1 station transmitting APRS packet every 10 minutes: ON1ARF 2 digipeater stations: ON1TG-13 ON4AIM-10 3 igates: ON1TG-14, ON8BZ and ON4AIM-10

ON1TG-13, ON1ATG-14 and on4AIM-10 are about 1 km from eachother. ON1ARF is 2 km away. ON8BZ is 6 km away

When sending a APRS packet, I see this in aprs.fi ("raw packet")

2021-07-14 16:00:58 CEST: ON1ARF>APLT00-1,qAR,ON1TG-14:!5114.02N/00258.56E-testing APRS over Lora running micropython on a ESP32/lora32 .. 55 2021-07-14 16:01:30 CEST: ON1ARF>APLT00-1,ON1TG-13,qAR,ON4AIM-10:!5114.02N/00258.56E-testing APRS over Lora running micropython on a ESP32/lora32 .. 55 2021-07-14 16:02:03 CEST: ON1ARF>APLT00-1,ON4AIM-10,qAR,ON1TG-14:!5114.02N/00258.56E-testing APRS over Lora running micropython on a ESP32/lora32 .. 55 2021-07-14 16:02:35 CEST: ON1ARF>APLT00-1,ON1TG-13,qAR,ON4AIM-10:!5114.02N/00258.56E-testing APRS over Lora running micropython on a ESP32/lora32 .. 55 2021-07-14 16:03:07 CEST: ON1ARF>APLT00-1,ON4AIM-10,qAR,ON1TG-14:!5114.02N/00258.56E-testing APRS over Lora running micropython on a ESP32/lora32 .. 55 2021-07-14 16:03:39 CEST: ON1ARF>APLT00-1,ON1TG-13,qAR,ON4AIM-10:!5114.02N/00258.56E-testing APRS over Lora running micropython on a ESP32/lora32 .. 55 2021-07-14 16:04:12 CEST: ON1ARF>APLT00-1,ON4AIM-10,qAR,ON1TG-14:!5114.02N/00258.56E-testing APRS over Lora running micropython on a ESP32/lora32 .. 55 2021-07-14 16:04:44 CEST: ON1ARF>APLT00-1,ON1TG-13,qAR,ON4AIM-10:!5114.02N/00258.56E-testing APRS over Lora running micropython on a ESP32/lora32 .. 55 2021-07-14 16:05:16 CEST: ON1ARF>APLT00-1,ON4AIM-10,qAR,ON1TG-14:!5114.02N/00258.56E-testing APRS over Lora running micropython on a ESP32/lora32 .. 55 2021-07-14 16:05:48 CEST: ON1ARF>APLT00-1,ON1TG-13,qAR,ON4AIM-10:!5114.02N/00258.56E-testing APRS over Lora running micropython on a ESP32/lora32 .. 55 2021-07-14 16:06:21 CEST: ON1ARF>APLT00-1,ON4AIM-10,qAR,ON1TG-14:!5114.02N/00258.56E-testing APRS over Lora running micropython on a ESP32/lora32 .. 55 2021-07-14 16:06:53 CEST: ON1ARF>APLT00-1,ON1TG-13*,qAR,ON1TG-14:!5114.02N/00258.56E-testing APRS over Lora running micropython on a ESP32/lora32 .. 55

More examples in file in attach and on aprs.fi https://aprs.fi/?c=raw&call=ON1ARF&limit=1000&view=normal

So it looks that the igates ON1TG-13 and ON4AIM-10 get stuck in a situation where they keep on repeating a packet multiple times. (Perhaps due to an unforseen interaction between the two stations)

I do not know if the descision to send these packets multiple times is taken by the digipeat code or by the sx1276 chip itseld.

The igates run LoRa_APRS_iGate a dollatek t-beam My station (ON1ARF) is the same hardware, but running micropython (development code)

aprslog.txt

peterus commented 3 years ago

@dg0tm do you have time to take a look? thanks!

on1arf commented 3 years ago

HI,

Do you mean that the issue should be solved? Has the change been commited? I can ask the ham's here in Oostende to flash their node with the new software and redo the check.

Looking at the code-changes, I do not know if this is the issue. The changes are related to solving loops on the aprs routing-level, but

Perhaps it is related to have the sx1276 chip reacts when -at the end of a transmission- it detect that there is also another lora-transmitter active. Does the chip do a CAD-check after a transmission?

73 kristoff - on1arf

peterus commented 3 years ago

@on1arf the issue should be resolved in the developer branch. can you get in contact with your local hams and ask them to reflash with the latest developer version? thank you very much!

on1arf commented 3 years ago

Hi, I had just adapted me previous message. I will ask the local hams to do the change and flash their device. I will also try to go on site and take some on-air snapshots to check what is really transmitter and by what station.

But as said, I am not sure if this is just a 'logic' bug

on1arf commented 3 years ago

Hi,

I am still waiting for my fellow local hams to upgrade the firmware of their igate (yes, summer :-) ).

But I did some more experiments, and I think I found the issue. As far as I can see, the issue is related to how the digipeater changes the aprs routing-path in the packets in relays.

Setup: my station (ON1ARF-0), 2 lora digipeaters at 8 km (ON1TG-13 and ON4AM-10), 1 igate (ON1TG-14) micropython application on my station that transmits lora-packets and dumps lora-packets it receives I transmit at low power (3 dm), so only one of the digipeaters (ON1TG-13) is able to receive me directly!

The tests: (lines starting with 'S' is what I sent, starting with 'R' is what is being received)

Take note of the 2nd packet (from ON4AIM-10). It receives it from ON1TG-13 (as on4AIM-10 cannot receive me directly), but the path of that packet only contains ON4AIM-10, not ON1TG-13,ON4AIM-10*

It all seems to point to the same problem: the digipeater software does not append its callsign to the APRS path, but replaces what ever is already in the path (even longer paths) by its own callsign. If you do this in an environment where multiple digipeaters are active, this will break the aprs-routing 'loop-protection'.

If I look at the bugfix #99, I do not think that that fix will solve this issue.

Kristoff - ON1ARF

dg0tm commented 3 years ago

Hi,

we backing on you. The logic is only repeat if WIDE1-1 is in path and replace the path without WIDE by only DIGI Call. Than it should be no more repeatet take place.

I will build an test setup to make my one tests to morrorow.

73 de DG0TM

Am 29.07.21 um 20:22 schrieb Kristoff Bonne:

Hi,

I am still waiting for my fellow local hams to upgrade the firmware of their igate (yes, summer :-) ).

But I did some more experiments, and I think I found the issue. As far as I can see, the issue is related to how the digipeater changes the aprs routing-path in the packets in relays.

Setup: my station (ON1ARF-0), 2 lora digipeaters at 8 km (ON1TG-13 and ON4AM-10), 1 igate (ON1TG-14) micropython application on my station that transmits lora-packets and dumps lora-packets it receives I transmit at low power (3 dm), so only one of the digipeaters (ON1TG-13) is able to receive me directly!

The tests: (lines starting with 'S' is what I sent, starting with 'R' is what is being received)

  • test 1: S APLT00-1:!5114.02N/00258.56E-testing APRS over Lora running micropython on a ESP32/lora32 R APLT00-1,ON1TG-13:!5114.02N/00258.56E-testing APRS over Lora running micropython on a ESP32/lora32 R APLT00-1,ON4AIM-10:!5114.02N/00258.56E-testing APRS over Lora running micropython on a ESP32/lora32 (repeating)

Take note of the 2nd packet (from ON4AIM-10). It receives it comes from from ON1TG-13 (as on4AIM-10 cannot receive me directly), but the path of that packet only contains ON4AIM-10, not ON1TG-13,ON4AIM-10*

*

Test 2:
S APLT00,WIDE1-1:!5114.02N/00258.56E-testing APRS over Lora
running micropython on a ESP32/lora32
R APLT00,ON1TG-13*:!5114.02N/00258.56E-testing APRS over Lora
running micropython on a ESP32/lora32
(...)
ON1TG-13 seams to have changed the path of the packet, replacing
the 'WIDE1-1' with its callsign!
Again, the packet goes into a loop between ON1TG-13 and ON4AIM-10

*

test 3:
S APLT00,ON1ARF-2*:!5114.02N/00258.56E-testing APRS over Lora
running micropython on a ESP32/lora32
R APLT00,ON1TG-13*:!5114.02N/00258.56E-testing APRS over Lora
running micropython on a ESP32/lora32
(...)
Same thing as above: ON1TG-13 seams to have changed the path of
the packet, replacing whatever I place inthere with its callsign!

*

test 4:
S APLT00,ON1ARF-2*,ON1ARF-3*:!5114.02N/00258.56E-testing APRS over
Lora running micropython on a ESP32/lora32
R APLT00,ON1TG-13*:!5114.02N/00258.56E-testing APRS over Lora
running micropython on a ESP32/lora32
(...)
Same thing as above.

It all seems to point to the same problem: the digipeater software does not append its callsign to the APRS path, but replaces what ever is already in the path (even longer paths) by its own callsign. If you do this in an environment where multiple digipeaters are active, this will break the aprs-routing 'loop-protection'.

If I look at the bugfix #99 https://github.com/lora-aprs/LoRa_APRS_iGate/issues/99, I do not think that that fix will solve this issue.

Kristoff - ON1ARF

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/lora-aprs/LoRa_APRS_iGate/issues/99#issuecomment-889361715, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACZZ3OYSGGF6OCGVQ4GTIQLT2GL43ANCNFSM5AMDZQUQ.

on1arf commented 3 years ago

Halle,

If you need  help, feel free to let me know.

I have two 't-beam' devices, a LiliGo t3 and a seperation board with a RFM82, so I can test if needed.

I can easily craft packets in any format as needed.

I am on matrix @.***) and on DMR.

Kr.

On 31.07.21 23:30, dg0tm wrote:

Hi,

we backing on you. The logic is only repeat if WIDE1-1 is in path and replace the path without WIDE by only DIGI Call. Than it should be no more repeatet take place.

I will build an test setup to make my one tests to morrorow.

73 de DG0TM

Am 29.07.21 um 20:22 schrieb Kristoff Bonne:

Hi,

I am still waiting for my fellow local hams to upgrade the firmware of their igate (yes, summer :-) ).

But I did some more experiments, and I think I found the issue. As far as I can see, the issue is related to how the digipeater changes the aprs routing-path in the packets in relays.

Setup: my station (ON1ARF-0), 2 lora digipeaters at 8 km (ON1TG-13 and ON4AM-10), 1 igate (ON1TG-14) micropython application on my station that transmits lora-packets and dumps lora-packets it receives I transmit at low power (3 dm), so only one of the digipeaters (ON1TG-13) is able to receive me directly!

The tests: (lines starting with 'S' is what I sent, starting with 'R' is what is being received)

  • test 1: S APLT00-1:!5114.02N/00258.56E-testing APRS over Lora running micropython on a ESP32/lora32 R APLT00-1,ON1TG-13:!5114.02N/00258.56E-testing APRS over Lora running micropython on a ESP32/lora32 R APLT00-1,ON4AIM-10:!5114.02N/00258.56E-testing APRS over Lora running micropython on a ESP32/lora32 (repeating)

Take note of the 2nd packet (from ON4AIM-10). It receives it comes from from ON1TG-13 (as on4AIM-10 cannot receive me directly), but the path of that packet only contains ON4AIM-10, not ON1TG-13,ON4AIM-10*

*

Test 2: S APLT00,WIDE1-1:!5114.02N/00258.56E-testing APRS over Lora running micropython on a ESP32/lora32 R APLT00,ON1TG-13*:!5114.02N/00258.56E-testing APRS over Lora running micropython on a ESP32/lora32 (...) ON1TG-13 seams to have changed the path of the packet, replacing the 'WIDE1-1' with its callsign! Again, the packet goes into a loop between ON1TG-13 and ON4AIM-10

*

test 3: S APLT00,ON1ARF-2:!5114.02N/00258.56E-testing APRS over Lora running micropython on a ESP32/lora32 R APLT00,ON1TG-13:!5114.02N/00258.56E-testing APRS over Lora running micropython on a ESP32/lora32 (...) Same thing as above: ON1TG-13 seams to have changed the path of the packet, replacing whatever I place inthere with its callsign!

*

test 4: S APLT00,ON1ARF-2,ON1ARF-3:!5114.02N/00258.56E-testing APRS over Lora running micropython on a ESP32/lora32 R APLT00,ON1TG-13*:!5114.02N/00258.56E-testing APRS over Lora running micropython on a ESP32/lora32 (...) Same thing as above.

It all seems to point to the same problem: the digipeater software does not append its callsign to the APRS path, but replaces what ever is already in the path (even longer paths) by its own callsign. If you do this in an environment where multiple digipeaters are active, this will break the aprs-routing 'loop-protection'.

If I look at the bugfix #99 https://github.com/lora-aprs/LoRa_APRS_iGate/issues/99, I do not think that that fix will solve this issue.

Kristoff - ON1ARF

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub

https://github.com/lora-aprs/LoRa_APRS_iGate/issues/99#issuecomment-889361715, or unsubscribe

https://github.com/notifications/unsubscribe-auth/ACZZ3OYSGGF6OCGVQ4GTIQLT2GL43ANCNFSM5AMDZQUQ.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/lora-aprs/LoRa_APRS_iGate/issues/99#issuecomment-890405959, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAGUBK3DTWN4SLWWSZAR52DT2RTODANCNFSM5AMDZQUQ.

on1arf commented 3 years ago

Hi, Is the bugfix for this issue already implemented?

Kr.

dg0tm commented 3 years ago

For now only in dev branch!

73 de DG0TM

Am 18.08.2021 um 20:26 schrieb Kristoff Bonne:

Hi, Is the bugfix for this issue already implemented?

Kr.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/lora-aprs/LoRa_APRS_iGate/issues/99#issuecomment-901334536, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACZZ3O3VBPMYTSAJZ4E5KCLT5P3OHANCNFSM5AMDZQUQ. Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&utm_campaign=notification-email.