Indice MeshCom ARTICOLO 8

Troubleshooting

I 10 errori più comuni in un nodo MeshCom, raccolti dalla pratica. Per ognuno: sintomo, causa probabile, come diagnosticarlo, soluzione. Se il tuo problema non è qui dentro, di solito è una variante di uno di questi.

1

LoRa init failed, code -2

Sintomo — al boot leggi:

[LoRa]...SX1276 Chip Initializing ... failed, code -2

Significa: la libreria RadioLib non riesce a leggere il registro VERSION_REG del SX1278. La SPI non parla con la radio.

Cause in ordine di probabilità:

  1. Un cavetto in cattivo contatto (90% dei casi su breadboard)
  2. MISO ↔ MOSI scambiati — errore classico
  3. VCC non è 3.3V (misura con multimetro)
  4. Saldatura "fredda" o corto di stagno tra due piazzole adiacenti
  5. Modulo Ra-01 difettoso/danneggiato (raro ma possibile)

Soluzione: passa un dito su ogni dupont premendoli verso le sedi; ricontrolla MISO/MOSI; misura VCC. Se hai un secondo modulo Ra-01 provalo, e se hai una seconda ESP32 invertili (test incrociato).

2

Init success ma niente emissioni reali

Sintomo: la seriale dice SX1276 Chip Initializing ... success, ma sull'analizzatore di spettro non vedi niente quando il nodo dovrebbe trasmettere, e gli altri nodi non ricevono i tuoi pacchetti.

Significa: la SPI funziona (init OK) ma l'IRQ TX_DONE non scatta mai → il firmware non sa quando avviare/concludere la TX.

Causa: DIO0 non collegato (o male collegato).

Soluzione: verifica che il pin DIO0 del Ra-01 sia collegato a GPIO 26 dell'ESP32. È l'errore più subdolo perché tutto sembra funzionare. Dopo aver corretto, riavvia e prova un --sendpos dal seriale: dovresti vedere un burst di ~80 ms sull'analizzatore.

3

Boot loop — il device si resetta sempre

Sintomo: il banner rst:ets Jul 29 2019 si ripete continuamente, non arrivi mai a CLIENT STARTED.

Cause:

  1. Corto RST-GND sul Ra-01: il chip resta in reset permanente → il firmware crasha → watchdog → reset → loop
  2. Brownout: l'alimentazione cala sotto 2.8V durante un picco → reset
  3. NVS corrotto: dati persistiti malformati causano crash

Soluzione: verifica con il multimetro che non ci sia continuità RST↔GND sul Ra-01 a freddo; usa alimentazione USB stabile (no hub passivo); se il problema persiste fai un esptool erase_flash seguito da reflash pulito.

4

I dati impostati non si salvano

Sintomo: imposti callsign / WiFi / GPS da seriale o app, poi al riavvio è tutto tornato come prima.

Causa nascosta: l'apertura della porta seriale può resettare il device. Quando uno script (pyserial, alcuni monitor) apre /dev/ttyUSB0, di default il driver mette DTR/RTS alti per un attimo. Su ESP32 DTR è collegato a EN → reset del chip. La tua sessione di edit viene cancellata prima del --save.

Soluzione: usa un monitor seriale che preservi DTR/RTS bassi:

  • picocom --noinit /dev/ttyUSB0 -b 115200
  • In pyserial: s.dtr = False; s.rts = False prima di s.open()
  • stty -F /dev/ttyUSB0 115200 raw -echo clocal && cat /dev/ttyUSB0

Sull'app MeshCom via BLE questo problema non c'è. È specifico del flusso seriale USB.

5

L'app MeshCom non vede il nodo via BLE

Sintomo: la scansione BLE dell'app è vuota, oppure il nodo non compare.

Cause:

  1. Sull'Android il GPS è spento: la scansione BLE su Android richiede la posizione attiva (limitazione Google)
  2. Permessi Bluetooth non concessi all'app
  3. Bluetooth del telefono spento
  4. Il nodo è già collegato ad un altro client (BLE supporta solo 1 connessione attiva)
  5. Il nodo non è ancora in stato CLIENT STARTED — dagli ~10 secondi dal boot

Soluzione: attiva GPS, dai i permessi, scollega da altre app, attendi CLIENT STARTED sulla seriale. Riavvia il nodo dal pulsante EN se è dubbioso.

6

Non ricevo nessun pacchetto LoRa

Sintomo: il nodo è in stato RX_LISTEN ma non arriva mai nessun pacchetto. Sull'app MeshCom i contatti restano vuoti.

Verifica con priorità:

  1. Parametri radio identici: la rete MeshCom EU usa 433.175 MHz / SF11 / BW 250 / CR 4/6 / sync 0x12. Se hai cambiato anche uno solo di questi nel tuo nodo, sei "fuori rete"
  2. Copertura: nessun nodo MeshCom nelle vicinanze trasmette? Con antenna scarsa e nodi distanti potresti essere "muto" per ore. Verifica sulla mappa GRF chi è attivo in zona
  3. Antenna scollegata: senza antenna la ricezione è quasi nulla anche su nodi vicini
  4. SWR alta o cavo bagnato: il segnale entra/esce male

Test rapido: trova un altro radioamatore vicino con un nodo MeshCom (gruppo Telegram, GRF) e fate test a vista. Se vi sentite, è un problema di antenna/posizione; se non vi sentite, è un problema di config.

7

Reset random durante la trasmissione

Sintomo: il nodo si riavvia in modo apparentemente casuale, spesso durante o subito dopo una trasmissione.

Causa: brownout. Il Ra-01 in TX a 20 dBm assorbe picchi di 120-150 mA. Gli LDO 3.3V degli ESP32 Dev cinesi più economici sono dimensionati per 100 mA → il bus 3.3V scende sotto 2.8V → il chip ESP32 ha il brownout detector → reset.

Soluzione:

  • Condensatore 100 µF elettrolitico + 100 nF ceramico tra VCC e GND, vicinissimo al Ra-01
  • Alimentazione USB di qualità (no hub passivo, no cavi sottili da 1 m)
  • Se persistente: alimenta direttamente il bus 3.3V con un LDO esterno AMS1117 (1 A)
8

SWR alta — il cavo o l'antenna sono il problema

Sintomo: portata ridicola anche con antenna che teoricamente è "buona". Il rosmetro segna SWR > 3:1.

Cause:

  1. Antenna scarsamente tarata sui 433 MHz (capita su antenne generiche "433/868")
  2. Connettori SMA-RP (WiFi) usati al posto di SMA standard — non fa contatto al centro
  3. Cavo coassiale danneggiato (calza interrotta, centrale schiacciato)
  4. Acqua nei connettori outdoor
  5. Sigillatura cavo-antenna fatta male, cavo "succhiato" dalla muffa

Diagnosi: NanoVNA (30 €) collegato al cavo lato apparato. SWR < 1.7:1 a 433 MHz = OK. Se è alta, ricontrolla a metà cavo (taglia e rimisura) per isolare se è cavo o antenna.

9

Il nodo non compare sulla mappa

Sintomo: hai un nodo attivo, lo vedi sull'app MeshCom, ma sulla mappa Gruppo Radio Firenze non c'è.

Cause:

  1. Il tuo nodo non ha mai trasmesso una posizione GPS (POS beacon). Imposta lat/lon manuali da settings se non hai modulo GPS
  2. Il tuo nodo non è raggiungibile da nessun gateway connesso al server centrale: il suo segnale resta locale
  3. POSINFO_INTERVAL è troppo alto: il default è 30 minuti, dagli tempo o forza con --sendpos
  4. Il callsign contiene caratteri non standard: usa solo A-Z, 0-9, trattino per SSID

Soluzione: imposta lat/lon, forza --sendpos, e attendi che un gateway nelle vicinanze rilanci il tuo pacchetto verso il server (a volte serve un quarto d'ora).

10

Niente echo sulla seriale dopo il boot

Sintomo: al primo boot vedi il banner e CLIENT STARTED, ma dopo è il silenzio totale — nessuna risposta a --info, --help, ecc.

Causa: il firmware MeshCom in idle non logga nulla sulla seriale per default. Le risposte ai comandi sono asincrone (il flag viene settato, l'output arriva nel loop principale).

Soluzione: abilita il debug verbose con:

--debug on
--loradebug on
--setinfo on
--save

Da qui in poi vedrai [MC-DBG], [MC-SM], eventi RX/TX, ecc. Per uso normale tienili off (ingombrano e usano corrente).

Il tuo errore non è qui dentro?

Apri il monitor seriale, abilita debug, fai una cattura completa di 30 secondi (banner di boot + qualche comando) e portala su uno dei gruppi della comunità. Il 99% dei problemi MeshCom si vede dai log con poche righe.

Gruppi comunità
App MeshCom Indice MeshCom
Home MeshCom