KISS TNC LoRa con firmware RNode

La riscoperta del packet-radio in ambito radioamatoriale sta trovando un nuovo alleato in una tecnologia moderna e, paradossalmente, sorprendentemente affine allo spirito dei primi esperimenti digitali: LoRa (Long Range). L’abbinamento tra TNC in protocollo KISS e moduli LoRa basati su ESP32 (Heltec LoRa32 V3, LilyGO LoRa32, ecc.) consente oggi di creare link digitali con consumi minimi, grande robustezza e una flessibilità impensabile.

Questa guida spiega:

• cos’è LoRa e perché interessa il radioamatore,
• come funzionano i parametri fondamentali (SF, CR, BW),
• come installare il firmware RNode su Heltec/LilyGO usando un Raspberry Pi,
• come usare RNode come TNC KISS,
• come collegarlo a un nodo BBS BPQ32.

LoRa è una modulazione sviluppata da Semtech che sfrutta un concetto antico quanto la radio stessa: lo spreading. A differenza delle modulazioni lineari usate in packet (AFSK 1200, FSK9600, GMSK, ecc.), LoRa utilizza un segnale chirp spread spectrum, cioè un tono che “scorre” in frequenza in modo controllato.

PDF: LoRa Modulation Basics

Perché piace?

• funziona anche in presenza di rumore elevato,
• permette collegamenti stabili a bassissima potenza,
• attraversa ostacoli con più facilità rispetto a molte modulazioni digitali,
• si adatta alla sperimentazione, ideale per reti BBS leggere, APRS evoluto, telemetria e mesh.

Bande UHF radioamatoriali e canali LoRa

Si può sperimentare LoRa nelle porzioni di banda assegnate al Servizio di radioamatore, rispettando il band plan e la normativa nazionale.

MIMIT: Piano nazionale di ripartizione delle frequenze (PNRF)

LoRa può essere utilizzata comunemente nella porzione 433.050 – 434.000 MHz (gamma ISM). Per uso radioamatoriale non è vincolata ai limiti ISM: niente duty cycle, niente potenza ridotta.

I parametri fondamentali di LoRa

Spreading Factor (SF)

Lo Spreading Factor determina la durata del simbolo LoRa. Valori più elevati aumentano il numero di chirp necessari per trasmettere ogni simbolo, migliorando la sensibilità ma riducendo il bitrate.

• SF7: simboli brevi, trasmissione veloce, sensibilità minore
• SF12: simboli molto lunghi, trasmissione lenta, massima sensibilità (fino a circa –137 dBm con BW125)

Un SF alto permette di decodificare segnali estremamente deboli, ma aumenta il tempo di trasmissione e l’occupazione di canale.

In pratica:

• SF7 per reti locali, nodi vicini, traffico BBS veloce
• SF9–SF10 per collegamenti robusti a qualche km
• SF11–SF12 per esperimenti long-range/low-rate

Coding Rate (CR)

LoRa utilizza un codice di correzione degli errori Hamming, indicato come Coding Rate (CR).
Il CR definisce quanta ridondanza aggiungere ai simboli per correggere gli errori causati da rumore, fading, ostacoli o segnali deboli.

• CR 4/5 → più veloce, meno robusto
• CR 4/8 → massima correzione

Per un TNC KISS, CR 4/6 o 4/7 offrono un buon equilibrio.

Bandwidth (BW)

È la larghezza del canale LoRa.

• 125 kHz → miglior sensibilità, velocità moderate
• 250 kHz → più velocità
• 500 kHz → massima velocità LoRa, ma sensibilità ridotta

Mentre per collegamenti stile packet/BBS:

• 125 kHz è lo standard sicuro.
• 250 kHz per esperimenti più veloci su distanze moderate.

⚠️ Può essere molto utile conoscere come i parametri LoRa influenzano la velocità dati e la portata. Se ti interessa solo conoscere il bitrate effettivo in aria per un determinato insieme di parametri, puoi utilizzare il seguente calcolatore per inserirli e vedere il risultato.

LoRa Bitrate & Sensitivity Calculator

Il TNC KISS con firmware RNode

Il progetto RNode / RNS (Reticulum) fornisce un firmware avanzato che trasforma i moduli LoRa a base ESP32 in TNC KISS via USB, quindi un’interfaccia radio per reti digitali.

Il vantaggio è evidente: con una semplice porta seriale KISS, un software per nodi come BPQ32, AGW Packet Engine o comando axcall, si può usare LoRa allo stesso modo con cui usa un TNC classico AFSK, un modem 9600 baud, direwolf o soundmodem.

RNode Firmware: Link all’articolo

Using RNodes With Amateur Radio Software: Link all’articolo

Schede ESP32 compatibili

• LilyGO LoRa32 v2.1 (aka T3 v1.6 / T3 v1.6.1)
• LilyGO LoRa32 v2.0
• LilyGO LoRa32 v1.0
• LilyGO T-Beam
• Heltec LoRa32 v2
• Heltec LoRa32 v3
• Heltec LoRa32 v4
• LilyGO LoRa T3S3
• RAK4631
• LilyGo T-Echo
• LilyGO T-Beam Supreme
• LilyGO T-Deck
• Heltec T114
• Seeed XIAO ESP32S3 Wio-SX1262

Come installare il firmware RNode TNC

Di seguito una procedura collaudata eseguita utilizzando un Raspberry Pi con Debian Bookworm armhf come macchina di flashing.

Prima di iniziare, assicuratevi di avere:

• Un Raspberry Pi (qualsiasi modello recente va bene; nei test ho usato in Pi 2 Model B Bookworm).
• Accesso a Internet, necessario per installare i pacchetti e scaricare il firmware.
• Una scheda LilyGO LoRa32 v2.1 (identificabile anche come T3 v1.6 / T3 v1.6.1), perfettamente supportata da RNode.
• Un cavo USB dati (non solo alimentazione), preferibilmente corto e di buona qualità.
• Permessi amministrativi (l’uso di sudo è indispensabile).

1]​ Aggiornamento repository e upgrade

$ sudo apt update

$ sudo apt upgrade

2] ​Installare o aggiornare Python3

python3 → l’interprete principale.
python3-full → include utility, strumenti standard e librerie addizionali utili.
python3-pip → installatore pacchetti Python.
python3-dev → include header per compilare moduli nativi.

$ sudo apt install python3 python3-full python3-pip python3-dev -y

Consultate il log per verificare l’eventuale presenza di errori e, se necessario, aggiornate pip alla versione più recente.

$ python3 --version

$ pip install --upgrade pip --break-system-packages

$ pip3 --version

⚠️​ Nota “break-system-packages” : è un “permesso speciale” che pip richiede quando si tenta di installare o aggiornare un pacchetto  Python al di fuori dell’ambiente gestito dal sistema operativo, rischiando di sovrascrivere librerie installate tramite apt.
E’ necessario quando gestiamo software esterno (come RNS/RNode) che richiede dipendenze non fornite dal sistema, usare pip globalmente senza creare un virtual environment di Python.

⚠️​ Nelle versioni più vecchie di pip (precedenti alla 23), l’opzione –break-system-packages non è supportata e provoca l’errore “no such option: –break-system-packages”. In questi casi è sufficiente rimuovere tale opzione dal comando.

3] ​Collegare la scheda e verificare la porta seriale

$ ls /dev/tty*

Nella lista individuate ad esempio /dev/ttyUSB0

⚠️​Potrebbe essere riconosciuta come /dev/ttyUSB1, /dev/ttyAMA0, ecc.

 

4] ​Installiamo rnodeconf via rns package

$ pip install rns --upgrade --break-system-packages

Per rendere disponibile l’utility appena installata da pip, è necessario aggiungere la cartella degli eseguibili locali al PATH dell’utente. In questo modo i comandi verranno riconosciuti da qualsiasi directory del terminale.

$ echo 'export PATH="$HOME/.local/bin:$PATH"' >> ~/.bashrc

$ source ~/.bashrc

 

5] ​Installazione del firmware nella scheda

Una volta preparato il Raspberry Pi e collegata la scheda LoRa, si può procedere con il caricamento vero e proprio del firmware RNode. Questa è la fase più sensibile dell’intera procedura, perché richiede che la scheda venga posta correttamente in modalità di flash e che le partizioni interne dell’ESP32 vengano configurate in modo adeguato.

Questo comando:

• rileva automaticamente il tipo di scheda collegata,
• imposta la modalità di programmazione dell’ESP32,
• prepara le partizioni interne (bootloader, firmware, filesystem),
• verifica che la comunicazione seriale sia stabile,
• imposta la scheda in TNC operating mode ( -T ).

$ rnodeconf -T --autoinstall

Di seguito una copia dell’avanzamento e la risposta alle domande, verrà chiesto di confermare:

• vostra porta seriale
• tipo di scheda LoRa
• Banda di frequenza ( 433 MHz )

Hello!

This guide will help you install the RNode firmware on supported
and homebrew devices. Please connect the device you wish to set
up now. Hit enter when it is connected.
Detected serial ports:
[1] /dev/ttyAMA0 (None, None)
[2] /dev/ttyUSB1 (CP2104 USB to UART Bridge Controller, 02143854)
[3] /dev/ttyUSB0 (CP2102 USB to UART Bridge Controller, 0001)

Enter the number of the serial port your device is connected to:
? (2)⚠️​

Ok, using device on /dev/ttyUSB1 (CP2104 USB to UART Bridge Controller, 02143854)

Probing device…
[…] Device connected
…
—————————————————————————
Device Selection
The device seems to have an RNode firmware installed, but it was not
provisioned correctly, or it is corrupt. We are going to reinstall the
correct firmware and provision it.

What kind of device is this?

[3] LilyGO LoRa32 v2.1 (aka T3 v1.6 / T3 v1.6.1)
[4] LilyGO LoRa32 v2.0
[5] LilyGO LoRa32 v1.0
[6] LilyGO T-Beam
[7] Heltec LoRa32 v2
[8] Heltec LoRa32 v3
[9] Heltec LoRa32 v4
[10] LilyGO LoRa T3S3
[11] RAK4631
[12] LilyGo T-Echo
[13] LilyGO T-Beam Supreme
[14] LilyGO T-Deck
[15] Heltec T114
[16] Seeed XIAO ESP32S3 Wio-SX1262
—————————————————————————

Enter the number that matches your device type:
? (8) ⚠️​

—————————————————————————
Heltec LoRa32 v3 RNode Installer
Important! Using RNode firmware on LoRa32 devices should currently be
considered experimental. It is not intended for production or critical use.
The currently supplied firmware is provided AS-IS as a courtesy to those
who would like to experiment with it. Hit enter to continue.
—————————————————————————
What band is this LoRa32 for?
[1] 433 MHz
[2] 868/915/923 MHz
[3] 433 MHz, with TCXO
[4] 868/915/923 MHz, with TCXO

? (1)⚠️​

——————————————————————————
Installer Ready
Ok, that should be all the information we need. Please confirm the following
summary before proceeding. In the next step, the device will be flashed and
provisioned, so make sure that you are satisfied with your choices.
Serial port : /dev/ttyUSB1
Device type : Heltec LoRa32 v3 420 – 520 MHz
Platform : ESP32
Device MCU : Espressif Systems ESP32
Firmware file : rnode_firmware_lora32v21.zip
——————————————————————————

Is the above correct? [y/N] ⚠️

[…] Checking firmware file availability…
…
[…] Firmware file downloaded
[…] Verifying firmware integrity…
…
[…] Done flashing
…
[…] Waiting for ESP32 reset…

6] ​Verifica dell’installazione

$ rnodeconf /dev/ttyUSB1 -i

Se l’installazione è andata a buon fine:

[…] Opening serial port /dev/ttyUSB1…
[…] Device connected
[…] Current firmware version: 1.85
[…] Reading EEPROM…
[…] EEPROM checksum correct
[…] Device signature validated
[…] Device info:
[…] Product : Heltec LoRa32 v3 420 – 520 MHz (b1:b4:37)
[…] Device signature : Validated – Local signature
[…] Firmware version : 1.85
[…] Hardware revision : 1
[…] Serial number : 00:00:00:01
[…] Modem chip : SX1278
[…] Frequency range : 420.0 MHz – 520.0 MHz
[…] Max TX power : 17 dBm
[…] Manufactured : 2025-10-07 22:31:39
[…] Device mode : Normal (host-controlled)

 

7] ​Parametrizzazione del TNC KISS LoRa

Se siete arrivati fin qui, significa che la parte più complessa è ormai alle spalle: il vostro nuovo TNC KISS LoRa è pronto per essere configurato. Ora è il momento di impostare i parametri operativi, cioè quelli che definiscono il comportamento radio del modulo LoRa.

Le scelte di frequenza, banda, potenza e modulazione dipendono dagli obiettivi del link. Nelle mie sperimentazioni orientate alla stabilità, alla compatibilità e alla copertura media, ho utilizzato la seguente configurazione:

• Frequenza: 433.650 MHz
• Larghezza di banda (BW): 125.0 kHz
• Potenza TX: 22 dBm
• Spreading Factor (SF): 7
• Coding Rate (CR): 5
• Modalità TNC: attiva (KISS mode)

Questi valori offrono un buon compromesso tra velocità e robustezza del segnale, si stima ~ 5 kbps.

Se vuoi semplicemente sapere quale sarà il bitrate effettivo in trasmissione (on-air) per un determinato insieme di parametri, puoi usare il seguente calcolatore: inserisci i parametri e visualizza il bitrate risultante: https://unsigned.io/understanding-lora-parameters/

Per applicare questi parametri al dispositivo appena configurato, eseguite il comando:

$ rnodeconf /dev/ttyUSB1 -T --freq 433650000 --bw 125000 --txp 20 --sf 7 --cr 5

Vi risponderà:

[…] Opening serial port /dev/ttyUSB1…
[…] Device connected
[…] Current firmware version: 1.85
[…] Reading EEPROM…
[…] EEPROM checksum correct
[…] Device signature validated
[…] Radio reporting frequency is 433.65 MHz
[…] Radio reporting bandwidth is 125.0 KHz
[…] Radio reporting TX power is 20 dBm
[…] Radio reporting spreading factor is 7
[…] Radio reporting coding rate is 5
[…] Device set to TNC operating mode

 

8] ​Prova di connessione

A questo punto ci si addentra in un territorio che può sembrare immediato oppure sorprendentemente articolato, a seconda della familiarità con il mondo Packet Radio, AX.25 e i vari strumenti storici utilizzati per gestire un TNC in modalità KISS.

Chi ha già masticato comandi come kissattach, kissparms, axcall, o ha passato anni su BPQ32, linbpq, uronode, AGWPE, si sentirà a casa.
Per chi invece inizia da LoRa o dal digitale moderno, questo capitolo rappresenta una prima finestra sulla tradizione del packet.

Questo articolo è solo la prima parte: nelle prossime pubblicazioni porterò i risultati delle prove reali effettuate su differenti contesti LoRa, con link a lunga distanza, con BBS e con nodi BPQ32/AXIP.

Per i nostalgici:

$ sudo kissattach /dev/ttyUSB1 ax0 44.146.1.199

$ sudo kissparms -c 1 -p ax0 -s 250 -r 192 -t 32

$ axcall ax0 IZ3MEZ-7

Note e Riferimenti