Quando una coppia di studenti testa da sola al proprio banco uno script radio per micro:bit, quasi sempre funziona. Quando venti coppie testano contemporaneamente lo stesso script, la rete collassa: i messaggi arrivano con secondi di ritardo, a singhiozzo o svaniscono del tutto. L'hardware non è rotto e il Wi-Fi della scuola non c'entra. La classe si è scontrata direttamente con due colli di bottiglia fondamentali delle reti: le collisioni fisiche di pacchetti senza limitazioni e la saturazione del buffer di ricezione.

I due colli di bottiglia invisibili

Per risolvere il problema, occorre comprendere cosa fa realmente il BBC micro:bit quando esegue i blocchi radio di MakeCode. Il micro:bit utilizza un ricetrasmettitore Nordic Semiconductor (l'nRF51 sulla v1 o l'nRF52 sulla v2) che opera nello spettro dei 2,4 GHz. Di default, funziona senza handshake per il rilevamento della portante né protocolli di ritrasmissione automatica.

Quando lo script di una lezione ordina a un micro:bit di inviare un segnale, su larga scala si generano due problemi distinti:

• Collisioni via etere: se due micro:bit trasmettono sulla stessa banda di frequenza nell'esatto medesimo istante, i loro segnali radio si sovrappongono nell'aria. L'antenna ricevente capta un segnale confuso e sovrapposto di entrambe le trasmissioni. Il micro:bit controlla il Cyclic Redundancy Check (CRC) del pacchetto, rileva il dato corrotto e scarta il pacchetto senza avvisare. Non viene generato alcun errore; i dati svaniscono semplicemente nel nulla.
• Esaurimento del buffer RX: il runtime software del micro:bit (CODAL / DAL) memorizza i pacchetti radio in arrivo in un piccolo buffer di ricezione gestito a livello hardware, che solitamente contiene solo quattro pacchetti prima di passarli al codice utente. Se quattro micro:bit inviano messaggi mentre il ricevitore sta aggiornando il display a matrice LED 5×5 o è bloccato all'interno di un blocco di pausa, quel buffer si riempie all'istante. Ogni messaggio successivo che arriva durante tale intervallo viene scartato.

Il vero problema: l'idrante del ciclo "forever"

In quasi tutte le classi in cui le cose non funzionano, il colpevole è un pattern di programmazione per principianti che si presenta così:

basic.forever(function () {
    radio.sendNumber(input.acceleration(Dimension.X))
})

All'interno di un tipico ciclo forever privo di ritardo esplicito, un micro:bit trasmette tra i 30 e i 50 pacchetti al secondo. Una coppia di studenti che genera 40 pacchetti al secondo occupa una porzione modesta del tempo di trasmissione (airtime) locale. Moltiplicatelo per quindici coppie che lavorano contemporaneamente nella stessa aula, e la stanza si ritrova improvvisamente inondata da 600 pacchetti al secondo.

Poiché il codice radio di base trasmette alla cieca — ovvero il micro:bit non attende che il canale sia libero prima di inviare dati, né richiede una conferma di ricezione (acknowledgement) — trasmettere a frequenza così elevata garantisce quasi matematicamente la collisione in volo con il pacchetto di un altro dispositivo.

Come strutturare una comunicazione radio affidabile in classe

Risolvere l'inaffidabilità radio non richiede protocolli di rete avanzati. Richiede invece quattro buone pratiche di programmazione da applicare in classe.

1. Non usare mai il gruppo radio predefinito

I tutorial dicono spesso agli studenti di impostare radio.setGroup(1). Se l'intera classe usa il gruppo 1, ogni ricevitore elabora i pacchetti di tutti i trasmettitori, anche se vengono filtrati successivamente a livello software. MakeCode supporta gruppi da 0 a 255. All'inizio dell'anno o del modulo, assegnate a ciascun banco o coppia un proprio numero di gruppo permanente:

• La coppia 1 usa radio.setGroup(10)
• La coppia 2 usa radio.setGroup(20)
• La coppia 3 usa radio.setGroup(30)

Gli ID di gruppo modificano la configurazione dell'indirizzo di rete sul chip. Sebbene i gruppi vicini condividano comunque lo stesso spazio di canale generale a 2,4 GHz, il filtraggio a livello di indirizzo hardware impedisce ai pacchetti estranei di inondare la coda di ricezione della coppia vicina.

2. Vietare i cicli senza limitazioni

A eccezione di rari casi di telemetria fisica ad alta frequenza, non esiste quasi nessun progetto scolastico che richieda 50 aggiornamenti al secondo. Un rover telecomandato o un controller a inclinazione rispondono in modo fluido già con 5-10 aggiornamenti al secondo. Imponete una pausa esplicita all'interno di ogni ciclo di trasmissione continua:

basic.forever(function () {
    radio.sendValue("speed", currentSpeed)
    basic.pause(100) // massimo 10 pacchetti al secondo
})

Meglio ancora, passate dal polling alla trasmissione guidata dagli eventi (event-driven). Un controller dovrebbe trasmettere solo quando l'utente preme un pulsante, supera una soglia di inclinazione significativa o rileva un ostacolo. Se non è cambiato nulla, la radio deve rimanere in silenzio.

3. Introdurre un jitter temporale

Se ogni micro:bit nella stanza trasmette esattamente ogni 100 millisecondi, i loro clock finiranno per sincronizzarsi all'unisono: ciò significa che due dispositivi entreranno ripetutamente in collisione a ogni ciclo. È possibile eliminare le collisioni ritmiche aggiungendo un "jitter" pseudo-casuale al ritardo del ciclo:

basic.pause(100 + Math.randomRange(0, 30))

Questa lieve randomizzazione di 0–30 millisecondi garantisce che, anche se due dispositivi collidono in un dato ciclo, le trasmissioni successive risulteranno sfasate, consentendo ai pacchetti di arrivare a destinazione senza interferenze.

4. Ridurre all'osso i payload

La trasmissione radio richiede un tempo fisico: più lungo è il pacchetto, più ampia è la finestra di collisione. MakeCode permette di inviare stringhe lunghe con radio.sendString("FORWARD_LEFT"), ma le stringhe consumano decine di byte. Utilizzate invece singoli numeri interi o coppie chiave-valore con un unico carattere:

Cosa fare quando l'intera classe deve comunicare con un unico ricevitore

Nelle attività di voto di gruppo o nella registrazione dei dati di una stazione meteo, quindici micro:bit degli studenti devono inviare dati a un unico micro:bit che funge da hub. Questa architettura è particolarmente soggetta al collasso del buffer.

Perché funzioni senza perdita di dati, occorre invertire il flusso di comunicazione: implementate un'architettura di polling invece di una trasmissione indiscriminata. Il micro:bit dell'hub centrale trasmette una richiesta per un ID specifico (ad esempio inviando il numero 1). Solo il dispositivo dello studente configurato come dispositivo 1 trasmette il proprio payload. Una volta ricevuto, l'hub richiede i dati al dispositivo 2. Questa struttura round-robin elimina completamente il rischio di collisioni e garantisce che il micro:bit ricevente non abbia mai più di un pacchetto in attesa nel buffer alla volta.

Per i programmi strutturati che gestiscono decine di studenti impegnati in progetti hardware in rete, Sheen Robotics delinea percorsi didattici modulari e configurazioni per la classe tramite Infinity for Schools, aiutando a garantire che le lezioni pratiche con l'hardware si svolgano in modo prevedibile, anziché dover risolvere invisibili collisioni nello spettro radio.