Lorsqu'un binôme d'élèves teste seul à son bureau un script radio sur micro:bit, tout fonctionne presque à chaque fois. Lorsque vingt binômes testent simultanément le même script, le réseau s'effondre : les messages arrivent avec plusieurs secondes de retard, de manière intermittente, ou disparaissent totalement. Le matériel n'est pas en panne et le réseau Wi-Fi de l'établissement ne crée aucune interférence. Votre classe s'est simplement heurtée de plein fouet à deux goulots d'étranglement réseau fondamentaux : les collisions physiques de paquets non régulées et la saturation du tampon de réception.

Les deux points d'étranglement invisibles

Pour résoudre le problème, il faut comprendre ce que fait réellement le BBC micro:bit lorsqu'il exécute les blocs radio MakeCode. Le micro:bit utilise un émetteur-récepteur Nordic Semiconductor (le nRF51 sur la v1 ou le nRF52 sur la v2) fonctionnant sur la bande des 2,4 GHz. Par défaut, il fonctionne sans détection de porteuse (carrier-sensing) ni protocole de réessai automatique.

Lorsqu'un script d'activité demande à un micro:bit d'émettre un signal, cela crée deux problèmes distincts à grande échelle :

• Collisions sur les ondes : si deux micro:bit émettent sur la même bande de fréquences exactement au même instant, leurs signaux radio se chevauchent dans l'air. L'antenne de réception capte alors un mélange inintelligible des deux transmissions. Le micro:bit vérifie le contrôle de redondance cyclique (CRC, Cyclic Redundancy Check) du paquet, constate l'altération des données et rejette silencieusement le paquet. Aucune erreur n'est générée ; les données disparaissent tout simplement.
• Saturation du tampon RX : l'environnement d'exécution logiciel du micro:bit (CODAL / DAL) stocke les paquets radio entrants dans un petit tampon de réception matériel, ne pouvant généralement contenir que quatre paquets avant de les transmettre à votre code utilisateur. Si quatre micro:bit envoient des messages pendant que le récepteur met à jour sa matrice de 5×5 LED ou patiente dans un bloc de pause, ce tampon se remplit immédiatement. Tout message ultérieur arrivant durant cette fenêtre est abandonné.

Le vrai problème : le déluge de la boucle « Toujours »

Dans presque toutes les classes où la communication échoue, le coupable est une structure de code typique des débutants, qui ressemble à ceci :

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

À l'intérieur d'une boucle forever classique dépourvue de délai explicite, un micro:bit émet entre 30 et 50 paquets chaque seconde. Un binôme d'élèves générant 40 paquets par seconde n'occupe qu'une modeste fraction du temps d'antenne local. Multipliez cela par quinze binômes travaillant simultanément dans une même salle, et la pièce est soudainement inondée de 600 paquets par seconde.

Comme le code radio de base émet « à l'aveugle » — ce qui signifie que le micro:bit n'attend pas que le canal soit libre avant d'émettre, pas plus qu'il ne demande d'accusé de réception —, diffuser à haute fréquence garantit pratiquement que chaque transmission entrera en collision avec le paquet d'un autre appareil en plein vol.

Comment structurer une communication radio fiable en classe

Résoudre le manque de fiabilité de la radio n'exige pas de protocoles réseau complexes. Cela nécessite quatre bonnes pratiques de programmation simples en classe.

1. Ne jamais utiliser le groupe radio par défaut

Les tutoriels indiquent fréquemment aux élèves d'écrire radio.setGroup(1). Si toute la classe utilise le groupe 1, chaque récepteur traite les paquets de chaque émetteur, même si vous appliquez ensuite un filtre logiciel. MakeCode prend en charge les groupes de 0 à 255. En début de trimestre, attribuez à chaque table ou binôme son propre numéro de groupe permanent :

• Le binôme 1 utilise radio.setGroup(10)
• Le binôme 2 utilise radio.setGroup(20)
• Le binôme 3 utilise radio.setGroup(30)

Les identifiants de groupe modifient la configuration de l'adresse réseau sur la puce. Bien que des groupes proches partagent toujours le même espace de canal global à 2,4 GHz, le filtrage au niveau de l'adresse matérielle évite que les paquets des autres ne viennent saturer la file d'attente de réception du binôme voisin.

2. Proscrire les boucles sans temporisation

Hormis de rares expériences de télémétrie physique à haute fréquence, presque aucun projet scolaire ne nécessite 50 mises à jour par seconde. Un rover télécommandé ou une commande par inclinaison réagit de manière fluide avec 5 à 10 mises à jour par seconde. Imposez une pause explicite à l'intérieur de chaque boucle de transmission continue :

basic.forever(function () {
    radio.sendValue("speed", currentSpeed)
    basic.pause(100) // 10 paquets par seconde au maximum
})

Mieux encore, passez de l'interrogation périodique (polling) à une émission événementielle. Une télécommande ne devrait émettre que lorsque l'utilisateur appuie sur un bouton, incline le boîtier au-delà d'un seuil significatif ou détecte un obstacle. Si rien n'a changé, la radio doit rester silencieuse.

3. Introduire une gigue temporelle (jitter)

Si chaque micro:bit de la salle émet rigoureusement toutes les 100 millisecondes, leurs horloges finissent par se synchroniser en cadence — ce qui signifie que deux appareils entreront en collision de manière répétée à chaque cycle. Vous pouvez éliminer ces collisions rythmiques en ajoutant un décalage pseudo-aléatoire (« jitter » ou gigue) au délai de la boucle :

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

Cette légère variation aléatoire de 0 à 30 millisecondes garantit que même si deux appareils entrent en collision lors d'un cycle, leurs émissions suivantes se retrouveront déphasées, permettant ainsi aux paquets de passer sans encombre.

4. Réduire au strict minimum la taille des charges utiles

La transmission radio prend du temps physique ; plus le paquet est long, plus la fenêtre de collision est large. MakeCode vous permet d'envoyer de longues chaînes de caractères avec radio.sendString("FORWARD_LEFT"), mais les chaînes occupent des dizaines d'octets. Utilisez plutôt de simples nombres entiers ou des paires valeur-clé d'un seul caractère :

Que faire lorsque toute la classe doit communiquer avec un seul récepteur

Lors d'activités de vote collectif ou de relevés pour une station météo, quinze micro:bit d'élèves doivent transmettre des données vers un unique micro:bit concentrateur. Cette architecture est particulièrement sujette à l'engorgement du tampon.

Pour faire fonctionner ce système sans perte de données, inversez le flux de communication : mettez en place une architecture par scrutation (polling) au lieu d'une émission anarchique générale. Le micro:bit central diffuse une requête demandant un identifiant précis (par exemple, en envoyant le nombre 1). Seul l'appareil de l'élève configuré comme l'appareil 1 émet sa charge utile. Une fois celle-ci reçue, le concentrateur appelle l'appareil 2. Cette structure de scrutation à tour de rôle élimine complètement le risque de collision et garantit que le micro:bit récepteur n'a jamais plus d'un paquet en attente dans son tampon à la fois.

Pour les programmes structurés accueillant des dizaines d'apprenants autour de projets matériels connectés, Sheen Robotics propose des cursus modulaires et des configurations de classe via Infinity for Schools, permettant de garantir le bon déroulement des travaux pratiques plutôt que de perdre du temps à diagnostiquer des collisions invisibles sur le spectre radio.