Wenn ein Zweierteam ein micro:bit-Funk-Skript allein am Tisch ausprobiert, funktioniert es fast immer. Wenn jedoch zwanzig Paare dasselbe Skript gleichzeitig testen, bricht das Netzwerk zusammen: Nachrichten treffen mit Sekunden Verzögerung ein, kommen nur noch lückenhaft an oder verschwinden ganz. Die Hardware ist nicht defekt, und auch das Schul-WLAN stört nicht. Der Unterricht ist schlicht an zwei grundlegende Engpässe der Netzwerktechnik gestoßen: ungedrosselte physikalische Paketkollisionen und ein Überlaufen des Empfangspuffers.

Die zwei unsichtbaren Engpässe

Um das Problem zu beheben, muss man verstehen, was der BBC micro:bit bei der Ausführung der MakeCode-Funkblöcke tatsächlich tut. Der micro:bit verwendet einen Transceiver von Nordic Semiconductor (den nRF51 bei v1 oder nRF52 bei v2), der im 2,4-GHz-Frequenzband arbeitet. Standardmäßig geschieht dies ohne Trägerprüfung (Carrier-Sensing-Handshake) oder automatische Wiederholungsmechanismen.

Wenn ein Skript im Unterricht den micro:bit anweist, ein Signal zu senden, entstehen im größeren Maßstab zwei getrennte Probleme:

• Kollisionen im Funkkanal: Wenn zwei micro:bits auf demselben Frequenzband im exakt selben Moment senden, überlagern sich ihre Funksignale in der Luft. Die Empfangsantenne nimmt eine unlesbare Mischung beider Sendungen auf. Der micro:bit prüft die zyklische Redundanzprüfung (CRC) des Pakets, stellt die Beschädigung fest und verwirft das Paket stillschweigend. Es wird keine Fehlermeldung ausgegeben; die Daten sind einfach weg.
• Erschöpfung des RX-Puffers: Die Software-Laufzeitumgebung des micro:bit (CODAL / DAL) speichert eingehende Funkpakete in einem kleinen, hardwaregestützten Empfangspuffer, der in der Regel nur vier Pakete aufnehmen kann, bevor sie an Ihren Benutzercode weitergegeben werden. Wenn vier micro:bits Nachrichten senden, während der Empfänger gerade seine 5×5-LED-Anzeige aktualisiert oder in einem Pause-Block verweilt, läuft dieser Puffer sofort voll. Jede weitere Nachricht, die in diesem Zeitfenster eintrifft, wird verworfen.

Das eigentliche Problem: Die Dauerfeuer-Schleife

In fast jedem Klassenraum mit diesem Problem liegt die Ursache in einem typischen Einsteiger-Muster, das so aussieht:

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

In einer standardmäßigen dauerhaft-Schleife ohne explizite Verzögerung sendet ein micro:bit zwischen 30 und 50 Pakete pro Sekunde. Ein einzelnes Schülerpaar, das 40 Pakete pro Sekunde erzeugt, belegt nur einen kleinen Teil der lokalen Funkzeit. Multipliziert man das mit fünfzehn Paaren, die gleichzeitig im selben Raum arbeiten, wird das Klassenzimmer plötzlich mit 600 Paketen pro Sekunde überflutet.

Da grundlegender Funkcode „blind“ sendet – der micro:bit wartet also weder auf einen freien Kanal, noch bittet er um eine Empfangsbestätigung –, führt das Senden mit hoher Frequenz praktisch unweigerlich dazu, dass jede Übertragung in der Luft mit dem Paket eines anderen Geräts kollidiert.

So strukturieren Sie den Funkbetrieb im Unterricht zuverlässig

Um die Funkverbindung stabil zu machen, braucht es keine fortgeschrittenen Netzwerkprotokolle, sondern lediglich vier grundlegende Programmierregeln für den Unterricht.

1. Niemals die Standard-Funkgruppe verwenden

Tutorials leiten Lernende häufig dazu an, radio.setGroup(1) zu verwenden. Wenn die gesamte Klasse Gruppe 1 nutzt, verarbeitet jeder Empfänger die Pakete jedes Senders – selbst wenn Sie diese später in der Software herausfiltern. MakeCode unterstützt Gruppen von 0 bis 255. Weisen Sie zu Beginn des Schulhalbjahres jedem Tisch oder Team eine eigene, feste Gruppennummer zu:

• Team 1 verwendet radio.setGroup(10)
• Team 2 verwendet radio.setGroup(20)
• Team 3 verwendet radio.setGroup(30)

Gruppen-IDs verändern die Netzwerkadresskonfiguration auf dem Chip. Zwar teilen sich nahe beieinander liegende Gruppen weiterhin denselben generellen 2,4-GHz-Kanalbereich, aber die Filterung auf Hardware-Adressebene verhindert, dass fremde Pakete die Empfangswarteschlange eines Nachbarteams überfluten.

2. Schleifen ohne Drosselung untersagen

Abgesehen von seltenen physikalischen Telemetriemessungen mit hoher Abtastrate gibt es kaum ein Schulprojekt, das 50 Aktualisierungen pro Sekunde erfordert. Ein ferngesteuertes Fahrzeug oder ein Neigungs-Controller reagiert bereits bei 5 bis 10 Aktualisierungen pro Sekunde absolut flüssig. Setzen Sie in jeder dauerhaften Sendeschleife eine ausdrückliche Pause durch:

basic.forever(function () {
    radio.sendValue("speed", currentSpeed)
    basic.pause(100) // Maximal 10 Pakete pro Sekunde
})

Noch besser ist der Wechsel von zyklischer Abfrage (Polling) zu ereignisgesteuerter Übertragung. Ein Controller sollte nur dann senden, wenn der Benutzer eine Taste drückt, das Gerät über einen bestimmten Schwellenwert hinaus neigt oder ein Hindernis erkennt. Wenn sich nichts geändert hat, sollte das Funkmodul stumm bleiben.

3. Zeitlichen Jitter einbauen

Wenn jeder micro:bit im Raum exakt alle 100 Millisekunden sendet, synchronisieren sich ihre Takte unweigerlich im Gleichschritt – was bedeutet, dass zwei Geräte in jedem Durchlauf wiederholt kollidieren. Solche rhythmischen Kollisionen lassen sich eliminieren, indem man der Schleifenverzögerung einen pseudozufälligen Schwankungswert („Jitter“) hinzufügt:

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

Diese geringfügige Randomisierung von 0 bis 30 Millisekunden stellt sicher, dass selbst bei einer Kollision in einem Durchgang die nächsten Übertragungen phasenverschoben ablaufen, sodass die Pakete ungehindert durchkommen.

4. Nutzdaten auf das Minimum reduzieren

Jede Funkübertragung kostet physische Zeit; je länger das Paket ist, desto größer ist das Kollisionsfenster. MakeCode erlaubt das Senden langer Zeichenketten mit radio.sendString("FORWARD_LEFT"), doch Textzeichenfolgen belegen Dutzende Bytes. Verwenden Sie stattdessen einfache Ganzzahlen oder einstellige Wertepaare:

Was tun, wenn die ganze Klasse an einen einzigen Empfänger senden muss?

Bei Abstimmungen in der Klasse oder dem Protokollieren von Wetterstationsdaten müssen mitunter fünfzehn Schüler-micro:bits Daten an ein einziges zentrales Gerät senden. Diese Struktur ist besonders anfällig für überlaufende Puffer.

Damit dies ohne Datenverlust gelingt, kehren Sie den Kommunikationsfluss um: Setzen Sie auf eine Polling-Architektur statt auf unkoordiniertes Senden aller Teilnehmer. Der zentrale Hub-micro:bit sendet den Abruf für eine bestimmte ID (beispielsweise die Zahl 1). Nur das Schülergerät, das als Gerät 1 konfiguriert ist, überträgt seine Nutzdaten. Sobald diese eingegangen sind, ruft der Hub Gerät 2 auf. Dieses Round-Robin-Verfahren schließt Kollisionen vollständig aus und garantiert, dass im Puffer des empfangenden micro:bit nie mehr als ein Paket gleichzeitig wartet.

Für strukturierte Unterrichtsprogramme mit Dutzenden Lernenden, die vernetzte Hardware-Projekte umsetzen, stellt Sheen Robotics über Infinity for Schools modulare Lehrpläne und Raumkonfigurationen bereit – damit praktische Hardware-Einheiten planbar gelingen, statt in der Fehlersuche unsichtbarer Funkkollisionen zu versinken.