Issues with MeshAdv-Mini Board #131

New Issue

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

adam commented

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

I'm running a Raspi Zero 2 with the MeshAdv-Mini board.

I'm not receiving anything. When is try to send I see these errors in the livelog:

SX1262_wrapper - ERROR - [TX] TX completion timeout - no interrupt received!
SX1262_wrapper - ERROR - Transmission wait timed out after 3.2 seconds - radio may not be transmitting
SX1262_wrapper - ERROR - Interrupt status at timeout: 0x0000
SX1262_wrapper - ERROR - Failed to send packet: TX completion timeout

The board is fine, i tested it with meshtasticd.

I just used the board preset. the pins are set as they should be according to the documentation.

I'm running a Raspi Zero 2 with the [MeshAdv-Mini](https://github.com/chrismyers2000/MeshAdv-Mini) board. I'm not receiving anything. When is try to send I see these errors in the livelog: ``` SX1262_wrapper - ERROR - [TX] TX completion timeout - no interrupt received! SX1262_wrapper - ERROR - Transmission wait timed out after 3.2 seconds - radio may not be transmitting SX1262_wrapper - ERROR - Interrupt status at timeout: 0x0000 SX1262_wrapper - ERROR - Failed to send packet: TX completion timeout ``` The board is fine, i tested it with meshtasticd. I just used the board preset. the pins are set as they should be according to the documentation.

adam closed this issue

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

adam commented

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

Root cause found; fix verified on Raspberry Pi 4 + MeshAdv Mini, HAT EEPROM reads Frequency Labs / MeshAdv Mini.

Root cause: the meshadv-mini entry in radio-settings.json is missing two flags the board's E22-900M22S module requires. The vendor's official config for this HAT (lora-MeshAdv-Mini-900M22S.yaml) specifies:

DIO2_AS_RF_SWITCH: true
DIO3_TCXO_VOLTAGE: true

The openHop preset has the correct GPIO pins (CS 8 / IRQ 16 / BUSY 20 / RESET 24 / RXEN 12) but omits use_dio2_rf and use_dio3_tcxo, which repeater/config.py then defaults to false. With both false, the module can't run its TCXO-fed oscillator or key the TX RF switch via DIO2 — depending on state you get TX completion timeouts with IRQ status 0x0000 (as in this issue's log), or a node that looks alive (SPI fine, dashboard fine, TX_DONE fires) while producing and hearing no usable RF.

Workaround — in /etc/openhop_repeater/config.yaml under sx1262:, set:

  use_dio3_tcxo: true
  dio3_tcxo_voltage: 1.8
  use_dio2_rf: true

then sudo systemctl restart openhop-repeater.

Proposed fix — add the two flags to the meshadv-mini block in radio-settings.json, same pattern as the meshadv and pimesh-1w-v2 entries:

     "meshadv-mini": {
       "name": "MeshAdv Mini",
       "bus_id": 0,
       "cs_id": 0,
       "cs_pin": 8,
       "reset_pin": 24,
       "busy_pin": 20,
       "irq_pin": 16,
       "txen_pin": -1,
       "rxen_pin": 12,
       "txled_pin": -1,
       "rxled_pin": -1,
       "tx_power": 22,
+      "use_dio3_tcxo": true,
+      "use_dio2_rf": true,
       "preamble_length": 32
     },

Clean TX, RX from a companion node, and round-trip messaging confirmed.

Root cause found; fix verified on Raspberry Pi 4 + MeshAdv Mini, HAT EEPROM reads `Frequency Labs / MeshAdv Mini`. **Root cause:** the `meshadv-mini` entry in `radio-settings.json` is missing two flags the board's E22-900M22S module requires. The vendor's official config for this HAT ([lora-MeshAdv-Mini-900M22S.yaml](https://github.com/chrismyers2000/MeshAdv-Mini/blob/main/Data/lora-MeshAdv-Mini-900M22S.yaml)) specifies: ```yaml DIO2_AS_RF_SWITCH: true DIO3_TCXO_VOLTAGE: true ``` The openHop preset has the correct GPIO pins (CS 8 / IRQ 16 / BUSY 20 / RESET 24 / RXEN 12) but omits `use_dio2_rf` and `use_dio3_tcxo`, which `repeater/config.py` then defaults to `false`. With both false, the module can't run its TCXO-fed oscillator or key the TX RF switch via DIO2 — depending on state you get TX completion timeouts with IRQ status 0x0000 (as in this issue's log), or a node that looks alive (SPI fine, dashboard fine, TX_DONE fires) while producing and hearing no usable RF. **Workaround** — in `/etc/openhop_repeater/config.yaml` under `sx1262:`, set: ```yaml use_dio3_tcxo: true dio3_tcxo_voltage: 1.8 use_dio2_rf: true ``` then `sudo systemctl restart openhop-repeater`. **Proposed fix** — add the two flags to the `meshadv-mini` block in `radio-settings.json`, same pattern as the `meshadv` and `pimesh-1w-v2` entries: ```diff "meshadv-mini": { "name": "MeshAdv Mini", "bus_id": 0, "cs_id": 0, "cs_pin": 8, "reset_pin": 24, "busy_pin": 20, "irq_pin": 16, "txen_pin": -1, "rxen_pin": 12, "txled_pin": -1, "rxled_pin": -1, "tx_power": 22, + "use_dio3_tcxo": true, + "use_dio2_rf": true, "preamble_length": 32 }, ``` Clean TX, RX from a companion node, and round-trip messaging confirmed.

adam commented

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

Thanks for the fix. I will try this this weekend! :)

Thanks for the fix. I will try this this weekend! :)

adam commented

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

Thanks for the fix. I will try this this weekend! :)

No problem! 😎 PR is #369 in the dev branch.

> Thanks for the fix. I will try this this weekend! :) No problem! 😎 PR is #369 in the dev branch.

adam commented

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

I know this isn't a support forum - but something is still weird.

The repeater has been running since yesterday afternoon. But I only have 2 neighbors, my two test clients. Both are zero-hop. I can ping the repeater, but I can't get a trace through another repeater.

Basically, it seems to be doing something, but I'm confused:

RX Packets 330, Forward 163, Dropped 167

sx1262: bus_id: 0 busy_pin: 20 cs_id: 0 cs_pin: 8 dio3_tcxo_voltage: 1.8 en_pin: -1 irq_pin: 16 is_waveshare: false reset_pin: 24 rxen_pin: 12 rxled_pin: -1 txen_pin: -1 txled_pin: -1 use_dio2_rf: true use_dio3_tcxo: true

radio: bandwidth: 62500 coding_rate: 8 frequency: 869618000.0 implicit_header: false preamble_length: 32 spreading_factor: 8 tx_power: 22 cad: peak_threshold: 22 min_threshold: 16

I think these are the relevant parts of the config. Everything looks good to me, but what do I know... (it's EU Narrow btw)

If anyone has an idea, I'd love to hear it.

Thanks

I know this isn't a support forum - but something is still weird. The repeater has been running since yesterday afternoon. But I only have 2 neighbors, my two test clients. Both are zero-hop. I can ping the repeater, but I can't get a trace through another repeater. Basically, it seems to be doing something, but I'm confused: > RX Packets 330, Forward 163, Dropped 167 `sx1262: bus_id: 0 busy_pin: 20 cs_id: 0 cs_pin: 8 dio3_tcxo_voltage: 1.8 en_pin: -1 irq_pin: 16 is_waveshare: false reset_pin: 24 rxen_pin: 12 rxled_pin: -1 txen_pin: -1 txled_pin: -1 use_dio2_rf: true use_dio3_tcxo: true` `radio: bandwidth: 62500 coding_rate: 8 frequency: 869618000.0 implicit_header: false preamble_length: 32 spreading_factor: 8 tx_power: 22 cad: peak_threshold: 22 min_threshold: 16` I think these are the relevant parts of the config. Everything looks good to me, but what do I know... _(it's EU Narrow btw)_ If anyone has an idea, I'd love to hear it. Thanks

adam commented

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

Your route may be too ambiuous and could be running into a hash collision in your area. May want to try using 2-byte path hashing instead of the default 1-byte path hashing. I would give that a try and retest.

Your route may be too ambiuous and could be running into a hash collision in your area. May want to try using 2-byte path hashing instead of the default 1-byte path hashing. I would give that a try and retest.

adam commented

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

thanks d3c3p710n PR merged into DEV.

thanks d3c3p710n PR merged into DEV.

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: adam/pyMC_Repeater#131