Multi-radio support? #135

New Issue

2026-10-27T09:34:47+01:00

adam commented

2026-10-27 09:34:47 +01:00

Does the current system support multiple radio interfaces? If not, is this/could this be on the horizon?

Use case: I live in a rural area with many river valleys. Putting LoRa repeaters over a large tree covered area isn't realistically feasible. What is fairly feasible is using other radios/services to backhaul connections between villages, which tent to be in valleys. I have tested backhauling over HF ISM with with Reticulum using Modem73, but the userfriendliness of RNS is not nearly what it is for meshcore.

Request: Please add multi-radio support so we can connect a KISS MC node and a KISS soft modem. Bringing some smart routing to the table would help reduce the likeliness of issues outlined here.

Does the current system support multiple radio interfaces? If not, is this/could this be on the horizon? Use case: I live in a rural area with many river valleys. Putting LoRa repeaters over a large tree covered area isn't realistically feasible. What is fairly feasible is using other radios/services to backhaul connections between villages, which tent to be in valleys. I have tested backhauling over HF ISM with with Reticulum using Modem73, but the userfriendliness of RNS is not nearly what it is for meshcore. Request: Please add multi-radio support so we can connect a KISS MC node and a KISS soft modem. Bringing some smart routing to the table would help reduce the likeliness of issues outlined [here](https://github.com/meshcore-dev/MeshCore/issues/3094#issuecomment-5170955249).

adam commented

2026-10-27 09:34:48 +01:00

I think you could do this via docker containers. check in with @yellowcooln on that.

I think you could do this via docker containers. check in with @yellowcooln on that.

adam commented

2026-10-27 09:34:48 +01:00

You could have multiple Dockers each running their own instanace of Repeater.

But we dont currently have a solution for multiple radios on one instance of Repeater.

You could have multiple Dockers each running their own instanace of Repeater. But we dont *currently* have a solution for multiple radios on one instance of Repeater.

adam commented

2026-10-27 09:34:49 +01:00

I am interested in this for the same reason. I purchased the zebra dual for this use case hoping open hop will support it one day. We have experimented here in Nebraska the default sf7 meshcore settings for urban areas and in rural areas using sf9 on a backhaul.

I am interested in this for the same reason. I purchased the zebra dual for this use case hoping open hop will support it one day. We have experimented here in Nebraska the default sf7 meshcore settings for urban areas and in rural areas using sf9 on a backhaul.

adam commented

2026-10-27 09:34:49 +01:00

I am interested in this for the same reason. I purchased the zebra dual for this use case hoping open hop will support it one day. We have experimented here in Nebraska the default sf7 meshcore settings for urban areas and in rural areas using sf9 on a backhaul.

hey yup as was mentioned you can run multiple instances of openhop by running multiple docker instances. one for each radio.

> I am interested in this for the same reason. I purchased the zebra dual for this use case hoping open hop will support it one day. We have experimented here in Nebraska the default sf7 meshcore settings for urban areas and in rural areas using sf9 on a backhaul. hey yup as was mentioned you can run multiple instances of openhop by running multiple docker instances. one for each radio.

adam commented

2026-10-27 09:34:50 +01:00

But can it pass the traffic between the two docker instances?

But can it pass the traffic between the two docker instances?

adam commented

2026-10-27 09:34:51 +01:00

But can it pass the traffic between the two docker instances?

No this is not possible.

> But can it pass the traffic between the two docker instances? No this is not possible.

adam commented

2026-10-27 09:34:51 +01:00

New multi radio code in dev branch.

New multi radio code in dev branch.

adam commented

2026-10-27 09:34:52 +01:00

After switching to the def branch and running sudo ./manage.sh upgrade, it fails with

openhop-repeater[30665]: Traceback (most recent call last):
openhop-repeater[30665]:   File "<frozen runpy>", line 198, in _run_module_as_main
openhop-repeater[30665]:   File "<frozen runpy>", line 88, in _run_code
openhop-repeater[30665]:   File "/opt/openhop_repeater/venv/lib/python3.13/site-packages/repeater/main.py", line 35, in <module>
openhop-repeater[30665]:     from repeater.handler_helpers import (
openhop-repeater[30665]:     ...<8 lines>...
openhop-repeater[30665]:     )
openhop-repeater[30665]:   File "/opt/openhop_repeater/venv/lib/python3.13/site-packages/repeater/handler_helpers/__init__.py", line 8, in <module>
openhop-repeater[30665]:     from .protocol_request import ProtocolRequestHelper
openhop-repeater[30665]:   File "/opt/openhop_repeater/venv/lib/python3.13/site-packages/repeater/handler_helpers/protocol_request.py", line 21, in <module>
openhop-repeater[30665]:     from openhop_core.protocol.cayenne_lpp import (
openhop-repeater[30665]:     ...<7 lines>...
openhop-repeater[30665]:     )
openhop-repeater[30665]: ImportError: cannot import name 'encode_barometric_pressure' from 'openhop_core.protocol.cayenne_lpp' (/opt/openhop_repeater/venv/lib/python3.13/site-packages/openhop_core/protocol/cayenne_lpp.py)
systemd[1]: openhop-repeater.service: Main process exited, code=exited, status=1/FAILURE
systemd[1]: openhop-repeater.service: Failed with result 'exit-code'.
systemd[1]: openhop-repeater.service: Consumed 2.350s CPU time.
systemd[1]: openhop-repeater.service: Scheduled restart job, restart counter is at 58.
systemd[1]: Started openhop-repeater.service - openHop Repeater Daemon.

Git status/latest log:

lora@lorahf:~/src/openhop_repeater $ git status
On branch dev
Your branch is up to date with 'origin/dev'.

nothing to commit, working tree clean
lora@lorahf:~/src/openhop_repeater $ git log |head
commit 6028dcdc336da3ce48ce13f6ff16a3b871a4bf71
Merge: d57baab 9660f8f
Author: Lloyd <lloyd@rightup.co.uk>
Date:   Thu Aug 13 16:48:15 2026 +0100

    Merge pull request #390 from openhop-dev/intergration
    
    Intergration

commit 9660f8f3896d7d0db8ce31f70534c8915026fb33

After switching to the def branch and running `sudo ./manage.sh upgrade`, it fails with ``` openhop-repeater[30665]: Traceback (most recent call last): openhop-repeater[30665]: File "<frozen runpy>", line 198, in _run_module_as_main openhop-repeater[30665]: File "<frozen runpy>", line 88, in _run_code openhop-repeater[30665]: File "/opt/openhop_repeater/venv/lib/python3.13/site-packages/repeater/main.py", line 35, in <module> openhop-repeater[30665]: from repeater.handler_helpers import ( openhop-repeater[30665]: ...<8 lines>... openhop-repeater[30665]: ) openhop-repeater[30665]: File "/opt/openhop_repeater/venv/lib/python3.13/site-packages/repeater/handler_helpers/__init__.py", line 8, in <module> openhop-repeater[30665]: from .protocol_request import ProtocolRequestHelper openhop-repeater[30665]: File "/opt/openhop_repeater/venv/lib/python3.13/site-packages/repeater/handler_helpers/protocol_request.py", line 21, in <module> openhop-repeater[30665]: from openhop_core.protocol.cayenne_lpp import ( openhop-repeater[30665]: ...<7 lines>... openhop-repeater[30665]: ) openhop-repeater[30665]: ImportError: cannot import name 'encode_barometric_pressure' from 'openhop_core.protocol.cayenne_lpp' (/opt/openhop_repeater/venv/lib/python3.13/site-packages/openhop_core/protocol/cayenne_lpp.py) systemd[1]: openhop-repeater.service: Main process exited, code=exited, status=1/FAILURE systemd[1]: openhop-repeater.service: Failed with result 'exit-code'. systemd[1]: openhop-repeater.service: Consumed 2.350s CPU time. systemd[1]: openhop-repeater.service: Scheduled restart job, restart counter is at 58. systemd[1]: Started openhop-repeater.service - openHop Repeater Daemon. ``` Git status/latest log: ``` lora@lorahf:~/src/openhop_repeater $ git status On branch dev Your branch is up to date with 'origin/dev'. nothing to commit, working tree clean lora@lorahf:~/src/openhop_repeater $ git log |head commit 6028dcdc336da3ce48ce13f6ff16a3b871a4bf71 Merge: d57baab 9660f8f Author: Lloyd <lloyd@rightup.co.uk> Date: Thu Aug 13 16:48:15 2026 +0100 Merge pull request #390 from openhop-dev/intergration Intergration commit 9660f8f3896d7d0db8ce31f70534c8915026fb33 ```

adam commented

2026-10-27 09:34:52 +01:00

what version of core are you running?

should be
R:v1.1.2-dev201
Core:v1.1.3-dev19

what version of core are you running? should be R:v1.1.2-dev201 Core:v1.1.3-dev19

adam commented

2026-10-27 09:34:53 +01:00

Where do I look to see what version it's running?

Where do I look to see what version it's running?

adam commented

2026-10-27 09:34:54 +01:00

After re-running the build, this is what it finishes with.

Logs still looping with:

Started openhop-repeater.service - openHop Repeater Daemon.
Traceback (most recent call last):
  File "<frozen runpy>", line 198, in _run_module_as_main
  File "<frozen runpy>", line 88, in _run_code
  File "/opt/openhop_repeater/venv/lib/python3.13/site-packages/repeater/main.py", line 35, in <module>
    from repeater.handler_helpers import (
    ...<8 lines>...
    )
  File "/opt/openhop_repeater/venv/lib/python3.13/site-packages/repeater/handler_helpers/__init__.py", line 8, in <module>
    from .protocol_request import ProtocolRequestHelper
  File "/opt/openhop_repeater/venv/lib/python3.13/site-packages/repeater/handler_helpers/protocol_request.py", line 21, in <module>
    from openhop_core.protocol.cayenne_lpp import (
    ...<7 lines>...
    )
ImportError: cannot import name 'encode_barometric_pressure' from 'openhop_core.protocol.cayenne_lpp' (/opt/openhop_repeater/venv/lib/python3.13/site-packages/openhop_core/protocol/cayenne_lpp.py)
openhop-repeater.service: Main process exited, code=exited, status=1/FAILURE
openhop-repeater.service: Failed with result 'exit-code'.
openhop-repeater.service: Consumed 2.358s CPU time.

After re-running the build, this is what it finishes with. <img width="571" height="226" alt="Image" src="https://github.com/user-attachments/assets/cff6e744-172f-4309-9749-594582bfa1a6" /> Logs still looping with: ``` Started openhop-repeater.service - openHop Repeater Daemon. Traceback (most recent call last): File "<frozen runpy>", line 198, in _run_module_as_main File "<frozen runpy>", line 88, in _run_code File "/opt/openhop_repeater/venv/lib/python3.13/site-packages/repeater/main.py", line 35, in <module> from repeater.handler_helpers import ( ...<8 lines>... ) File "/opt/openhop_repeater/venv/lib/python3.13/site-packages/repeater/handler_helpers/__init__.py", line 8, in <module> from .protocol_request import ProtocolRequestHelper File "/opt/openhop_repeater/venv/lib/python3.13/site-packages/repeater/handler_helpers/protocol_request.py", line 21, in <module> from openhop_core.protocol.cayenne_lpp import ( ...<7 lines>... ) ImportError: cannot import name 'encode_barometric_pressure' from 'openhop_core.protocol.cayenne_lpp' (/opt/openhop_repeater/venv/lib/python3.13/site-packages/openhop_core/protocol/cayenne_lpp.py) openhop-repeater.service: Main process exited, code=exited, status=1/FAILURE openhop-repeater.service: Failed with result 'exit-code'. openhop-repeater.service: Consumed 2.358s CPU time. ```

adam commented

2026-10-27 09:34:54 +01:00

its on the web GUI bottom left side bar.

its on the web GUI bottom left side bar.

adam commented

2026-10-27 09:34:55 +01:00

Since it is not starting back up, I'm unsure as to how to get there?

Since it is not starting back up, I'm unsure as to how to get there?

adam commented

2026-10-27 09:34:55 +01:00

/opt/openhop_repeater/venv/bin/python -c "from importlib.metadata import version; print(version('openhop_core'))"

`/opt/openhop_repeater/venv/bin/python -c "from importlib.metadata import version; print(version('openhop_core'))"`

adam commented

2026-10-27 09:34:56 +01:00

lora@lorahf:~/src/openhop_repeater $ /opt/openhop_repeater/venv/bin/python -c "from importlib.metadata import version; print(version('openhop_core'))"
1.1.3.dev19
lora@lorahf:~/src/openhop_repeater $

``` lora@lorahf:~/src/openhop_repeater $ /opt/openhop_repeater/venv/bin/python -c "from importlib.metadata import version; print(version('openhop_core'))" 1.1.3.dev19 lora@lorahf:~/src/openhop_repeater $ ```

adam commented

2026-10-27 09:34:57 +01:00

did you install the other branch when testing as well?

did you install the other branch when testing as well?

adam commented

2026-10-27 09:34:57 +01:00

I have bumped the DEV version, I think this is Prob the issue your system is not upgrading as its stuck on the older version.

if you do another sudo ./manage.sh upgrade

I have bumped the DEV version, I think this is Prob the issue your system is not upgrading as its stuck on the older version. if you do another `sudo ./manage.sh upgrade`

adam commented

2026-10-27 09:34:58 +01:00

I've just started another upgrade, it seems to be the same as what it is in the screenshot above, but the version from the command I ran looks to be a newer version. I'm unsure the reason of the mismatch.

lora@lorahf:~/src/openhop_repeater $ sudo ./manage.sh upgrade
[sudo] password for lora: 
Starting upgrade process...
Current version: 1.1.2.dev201
Using package source: local checkout (/home/lora/src/openhop_repeater)
=== Upgrade Progress ===
[1/9] Migrating legacy paths...
    ✓ No stale source-tree paths found
[2/9] Ensuring required directories...
[3/9] Backing up configuration...
    ✓ Configuration backed up
[4/9] Updating system dependencies...
Reading package lists... Done
Building dependency tree... 55%

I've just started another upgrade, it seems to be the same as what it is in the screenshot above, but the version from the command I ran looks to be a newer version. I'm unsure the reason of the mismatch. ``` lora@lorahf:~/src/openhop_repeater $ sudo ./manage.sh upgrade [sudo] password for lora: Starting upgrade process... Current version: 1.1.2.dev201 Using package source: local checkout (/home/lora/src/openhop_repeater) === Upgrade Progress === [1/9] Migrating legacy paths... ✓ No stale source-tree paths found [2/9] Ensuring required directories... [3/9] Backing up configuration... ✓ Configuration backed up [4/9] Updating system dependencies... Reading package lists... Done Building dependency tree... 55% ```

adam commented

2026-10-27 09:34:58 +01:00

yes it should show core as 1.1.3.dev20 now.

yes it should show core as 1.1.3.dev20 now.

adam commented

2026-10-27 09:34:59 +01:00

✓ Package and dependencies upgraded successfully!
[9/9] Reloading systemd and restarting service...
    ✓ Service restarted and active
Upgrade completed successfully!
Version: 1.1.2.dev201 -> 1.1.2.dev201
✓ Service is running
✓ Configuration preserved
=== Upgrade Complete ===
lora@lorahf:~/src/openhop_repeater $ /opt/openhop_repeater/venv/bin/python -c "from importlib.metadata import version; print(version('openhop_core'))"
1.1.3.dev20
lora@lorahf:~/src/openhop_repeater $

``` ✓ Package and dependencies upgraded successfully! [9/9] Reloading systemd and restarting service... ✓ Service restarted and active Upgrade completed successfully! Version: 1.1.2.dev201 -> 1.1.2.dev201 ✓ Service is running ✓ Configuration preserved === Upgrade Complete === lora@lorahf:~/src/openhop_repeater $ /opt/openhop_repeater/venv/bin/python -c "from importlib.metadata import version; print(version('openhop_core'))" 1.1.3.dev20 lora@lorahf:~/src/openhop_repeater $ ```

adam commented

2026-10-27 09:34:59 +01:00

The second "radio" is a socat connection to modem73 - I'm using the command sudo socat TCP:127.0.0.1:8001 pty,rawer,echo=0,b115200,link=/dev/ttyModem73,mode=666 . It seems to be failing trying to set the frequency.. Which modem73 does not support. Is there a way to make this optional?

KissModemWrapper - INFO - KISS modem connected to /dev/ttyModem73 at 115200 baud
KissModemWrapper - WARNING - SetHardware sub_cmd 0x17 timeout               
KissModemWrapper - WARNING - SetHardware sub_cmd 0x17 timeout
KissModemWrapper - WARNING - SetHardware sub_cmd 0x17 timeout
KissModemWrapper - WARNING - KISS modem did not become ready after reconnect
RepeaterDaemon - ERROR - Failed to initialize radio hardware: Failed to initialize KISS modem: Failed to initialize KISS modem
RepeaterDaemon - WARNING - Radio type 'kiss' unavailable; starting in no-radio mode to keep service alive. Check radio configuration and hardware mapping.

The second "radio" is a socat connection to modem73 - I'm using the command `sudo socat TCP:127.0.0.1:8001 pty,rawer,echo=0,b115200,link=/dev/ttyModem73,mode=666` . It seems to be failing trying to set the frequency.. Which modem73 does not support. Is there a way to make this optional? ``` KissModemWrapper - INFO - KISS modem connected to /dev/ttyModem73 at 115200 baud KissModemWrapper - WARNING - SetHardware sub_cmd 0x17 timeout KissModemWrapper - WARNING - SetHardware sub_cmd 0x17 timeout KissModemWrapper - WARNING - SetHardware sub_cmd 0x17 timeout KissModemWrapper - WARNING - KISS modem did not become ready after reconnect RepeaterDaemon - ERROR - Failed to initialize radio hardware: Failed to initialize KISS modem: Failed to initialize KISS modem RepeaterDaemon - WARNING - Radio type 'kiss' unavailable; starting in no-radio mode to keep service alive. Check radio configuration and hardware mapping. ```

adam commented

2026-10-27 09:35:00 +01:00

@agessaman can we add a flag to the Kiss modem for this? or do we create a modem73 driver that consumes the API too? hmm..

@agessaman can we add a flag to the Kiss modem for this? or do we create a modem73 driver that consumes the API too? hmm..

adam commented

2026-10-27 09:35:01 +01:00

Yes, I think we need to wire up a config override for auto_configure in:

radio = KissModemWrapper(
    port=port,
    baudrate=baudrate,
    radio_config=radio_config,
    auto_configure=True,
)

It's not currently possible. Should be trivial.

Yes, I think we need to wire up a config override for auto_configure in: ```python radio = KissModemWrapper( port=port, baudrate=baudrate, radio_config=radio_config, auto_configure=True, ) ``` It's not currently possible. Should be trivial.

adam commented

2026-10-27 09:35:01 +01:00

Lemme know if there's anything you guys need me to test.

Lemme know if there's anything you guys need me to test.

adam commented

2026-10-27 09:35:02 +01:00

Hey all, just checking in on this. Any updates?

Hey all, just checking in on this. Any updates?

adam commented

2026-10-27 09:35:03 +01:00

There has been significant multi-radio progress. See Settings > Radio Hardware in the software, and https://docs.openhop.dev/projects/openhop-repeater/config-file/#multi-radio-and-rf-fabric for configuration.

There has been significant multi-radio progress. See Settings > Radio Hardware in the software, and https://docs.openhop.dev/projects/openhop-repeater/config-file/#multi-radio-and-rf-fabric for configuration.

adam commented

2026-10-27 09:35:04 +01:00

There has been significant multi-radio progress. See Settings > Radio Hardware in the software, and https://docs.openhop.dev/projects/openhop-repeater/config-file/#multi-radio-and-rf-fabric for configuration.

Running out of today's dev - R:v1.1.5-dev7 Core:v1.1.4-dev2
The MC KISS node is still working just fine, but the socat/modem73 connection still looks like it's failing when it tries to set options that do not exist on Modem73.
It looks like I'm getting the same errors as before:

KissModemWrapper - WARNING - SetHardware sub_cmd 0x17 timeout                                                                                                    
KissModemWrapper - WARNING - SetHardware sub_cmd 0x17 timeout                                                                                                    
KissModemWrapper - WARNING - SetHardware sub_cmd 0x17 timeout                                                                                                    
KissModemWrapper - WARNING - KISS modem did not become ready after reconnect

> There has been significant multi-radio progress. See Settings > Radio Hardware in the software, and https://docs.openhop.dev/projects/openhop-repeater/config-file/#multi-radio-and-rf-fabric for configuration. Running out of today's dev - R:v1.1.5-dev7 Core:v1.1.4-dev2 The MC KISS node is still working just fine, but the socat/modem73 connection still looks like it's failing when it tries to set options that do not exist on Modem73. It looks like I'm getting the same errors as before: ```KissModemWrapper - INFO - KISS modem connected to /dev/ttyModem73 at 115200 baud KissModemWrapper - WARNING - SetHardware sub_cmd 0x17 timeout KissModemWrapper - WARNING - SetHardware sub_cmd 0x17 timeout KissModemWrapper - WARNING - SetHardware sub_cmd 0x17 timeout KissModemWrapper - WARNING - KISS modem did not become ready after reconnect ```

adam commented

2026-10-27 09:35:04 +01:00

Oh, yeah. I have this work sitting in a feature branch. I'll open a PR.

Oh, yeah. I have this work sitting in a feature branch. I'll open a PR.

adam commented

2026-10-27 09:35:05 +01:00

Any chance that PR's been merged yet?

Any chance that PR's been merged yet?

adam commented

2026-10-27 09:35:06 +01:00

I'm in a similar spot: LoRa coverage in my area isn't built out enough to be reliable, so a backhaul over a different radio or modem would make OpenHop practical here.

+1 on getting the auto_configure override merged. A config flag to skip the hardware setup commands seems like the lightest fix for soft modems that don't implement them. A dedicated Modem73 driver could come later if it needs more than that, but since there is so much dev going on right now, I would wait a bit.

I'm in a similar spot: LoRa coverage in my area isn't built out enough to be reliable, so a backhaul over a different radio or modem would make OpenHop practical here. +1 on getting the auto_configure override merged. A config flag to skip the hardware setup commands seems like the lightest fix for soft modems that don't implement them. A dedicated Modem73 driver could come later if it needs more than that, but since there is so much dev going on right now, I would wait a bit.

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: adam/pyMC_Repeater#135