Hi. I'm seeing a failure to repeat in certain circumstances with OpenHop, when OpenHop is a last hop (via other repeaters), or is an interim hop along the path. I'm hoping I just have a setting incorrect somewhere, but I believe I have checked.
I have executed many tests with the following devices:
Public Key: c2610c16f28eb978255463e5b37322073a8c58cd01f53c5827186c4f56a6c50a
Companion BT: LilyGo T-Beam (SX1262) (Meshcore.io 1.16.0) Meshcore App (1.45.0, Android, installed via Github repo)
Public Key: 1f5de5d1ebde39ecc8c9cf1c3fee4523c843b82f8a76c16f072123254c1fc825
Companion BT: LilyGo T-Beam (SX1262) (Meshcore.io 1.16.0) Meshcore App (1.45.0, Android, installed via Github repo)
Public Key: b01ce09577c2d46858ac5e0dd293ad27ad4654d5400def0889c0fa058f7c4c4e
"OPENHOP01 Repeater" (Raspberry Pi 3b+, Debian 13.5, RAKwireless WisMesh Pi HAT RAK6421, RAK13302, OpenHop Repeater: v1.0.11 Dev Build: 130, Core: v1.0.14)
Public Key: 3ecaea7956ed2db9028e2fd3f3153a60b8c2045a8c095122928cfe7b3580b2fb
"OPENHOP02 Repeater" (Raspberry Pi 3b+, Debian 13.5, RAKwireless WisMesh Pi HAT RAK6421, RAK13302, OpenHop Repeater: v1.0.11 Dev Build: 130, Core: v1.0.14)
I set the path on the c2 (or 1f) node to test paths.
When sending a message from c2 to 1f (or 1f to c2), the following scenarios occur:
0 hop direct: always succeeds
1 hop: always succeeds (using any one of the repeaters individually)
2 hop: fails if an OpenHop repeater is the last repeater in the path (i.e., af,b0) otherwise succeeds
3 hop: fails if an OpenHop repeater is the last repeater in the path (i.e., af,19,b0) or an OpenHop repeater is anywhere in the path other than being the first hop (i.e., b0,3e,c8) otherwise succeeds (i.e., b0,c8,af)
4 hop: fails if an OpenHop repeater is the last repeater in the path or an OpenHop repeater is anywhere in the path other than being the first hop (i.e., b0,c8,af,3e) otherwise succeeds (i.e., b0,c8,af,19)
...and so on.
I've tested this with every possible scenario with the hardware above, and the statements above always are true.
Settings are as follows:
(Meshcore.io repeaters)
Frequency: 910.525 MHz
Bandwidth: 62.5 kHz
Spreading factor: 7
Coding rate: 5
I just checked with OpenHop Repeater: v1.1.2 Dev Build: 9, Core: v1.1.2, and it's working under all scenarios I tested!
It did not work with OpenHop Repeater: v1.1.2 Dev Build: 6, Core: v1.1.2.
I just checked with OpenHop Repeater: v1.1.2 Dev Build: 9, Core: v1.1.2, and it's working under all scenarios I tested!
It did not work with OpenHop Repeater: v1.1.2 Dev Build: 6, Core: v1.1.2.
<!-- github-comment-id:4878659519 -->
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Hi. I'm seeing a failure to repeat in certain circumstances with OpenHop, when OpenHop is a last hop (via other repeaters), or is an interim hop along the path. I'm hoping I just have a setting incorrect somewhere, but I believe I have checked.
I have executed many tests with the following devices:
Companion BT: LilyGo T-Beam (SX1262) (Meshcore.io 1.16.0) Meshcore App (1.45.0, Android, installed via Github repo)
Companion BT: LilyGo T-Beam (SX1262) (Meshcore.io 1.16.0) Meshcore App (1.45.0, Android, installed via Github repo)
"Test Repeater 0001" (LilyGo T-Beam 1.2 (SX1276) (Meshcore.io 1.16.0)
"Test Repeater 0002" (LilyGo T-Beam 1.2 (SX1276) (Meshcore.io 1.16.0)
"Test Repeater 0003" (LilyGo T-Beam 1.2 (SX1276) (Meshcore.io 1.16.0)
"OPENHOP01 Repeater" (Raspberry Pi 3b+, Debian 13.5, RAKwireless WisMesh Pi HAT RAK6421, RAK13302, OpenHop Repeater: v1.0.11 Dev Build: 130, Core: v1.0.14)
"OPENHOP02 Repeater" (Raspberry Pi 3b+, Debian 13.5, RAKwireless WisMesh Pi HAT RAK6421, RAK13302, OpenHop Repeater: v1.0.11 Dev Build: 130, Core: v1.0.14)
I set the path on the c2 (or 1f) node to test paths.
When sending a message from c2 to 1f (or 1f to c2), the following scenarios occur:
...and so on.
I've tested this with every possible scenario with the hardware above, and the statements above always are true.
Settings are as follows:
(Meshcore.io repeaters)
Frequency: 910.525 MHz
Bandwidth: 62.5 kHz
Spreading factor: 7
Coding rate: 5
(OpenHop repeaters)
Frequency: 910.525 MHz
Bandwidth: 62.5 kHz
Coding rate: 4/5
Preamble length: 17 symbols
Here are logs from each OpenHop repeater testing with a message from c2 to 1f, via path 3e,b0 that failed (resent 5x):
3e "OPENHOP02 Repeater":
b0 "OPENHOP01 Repeater":
This seems like an openhop deduplication bug if it overhears things it's supposed to repeat next.
I just checked with OpenHop Repeater: v1.1.2 Dev Build: 9, Core: v1.1.2, and it's working under all scenarios I tested!
It did not work with OpenHop Repeater: v1.1.2 Dev Build: 6, Core: v1.1.2.
Yes, the bug has been found and hopefully fixed in the test feat branch, thanks for the info guys 👍