Cuando una pareja de alumnos prueba un programa de radio para micro:bit a solas en su mesa, casi siempre funciona. Cuando veinte parejas prueban el mismo programa de forma simultánea, la red colapsa: los mensajes llegan con segundos de retraso, de manera intermitente o desaparecen por completo. El hardware no se ha roto y la red wifi del centro no está interfiriendo. El aula se ha topado de lleno con dos cuellos de botella fundamentales en redes: colisiones físicas de paquetes sin limitación y saturación del búfer de recepción.

Los dos cuellos de botella invisibles

Para solucionar el problema, hay que entender qué hace realmente la BBC micro:bit cuando ejecuta los bloques de radio de MakeCode. La micro:bit utiliza un transceptor de Nordic Semiconductor (el nRF51 en la v1 o el nRF52 en la v2) que opera en el espectro de 2,4 GHz. Por defecto, funciona sin negociación con detección de portadora ni protocolo de reintento automático.

Cuando el código de una lección ordena a una micro:bit enviar una señal, se generan dos problemas distintos a gran escala:

• Colisiones en el aire: Si dos micro:bit transmiten en la misma banda de frecuencia exactamente en el mismo instante, sus señales de radio se solapan en el aire. La antena receptora capta una mezcla ininteligible de ambas transmisiones. La micro:bit comprueba el control de redundancia cíclica (CRC) del paquete, detecta que está corrupto y lo descarta en silencio. No se genera ningún error; los datos simplemente se desvanecen.
• Agotamiento del búfer de recepción (RX): El entorno de ejecución de software de micro:bit (CODAL / DAL) almacena los paquetes de radio entrantes en un pequeño búfer de recepción respaldado por hardware, que normalmente solo retiene cuatro paquetes antes de pasarlos al código del usuario. Si cuatro micro:bit envían mensajes mientras el receptor actualiza su matriz de LED de 5×5 o espera dentro de un bloque de pausa, ese búfer se llena de inmediato. Todos los mensajes posteriores que lleguen durante ese intervalo se descartan.

El verdadero problema: el torrente del bucle «para siempre»

En casi todas las aulas donde falla la comunicación, el culpable es un patrón de programación para principiantes parecido a este:

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

Dentro de un bucle forever estándar sin una pausa explícita, una micro:bit transmitirá entre 30 y 50 paquetes cada segundo. Una pareja de alumnos que genere 40 paquetes por segundo consume una pequeña fracción del tiempo de emisión local. Si se multiplica eso por quince parejas trabajando simultáneamente en una sola aula, la sala se inunda de repente con 600 paquetes por segundo.

Dado que el código de radio básico transmite a ciegas —es decir, la micro:bit no comprueba si el canal está libre antes de emitir ni solicita una confirmación de recepción—, emitir a alta frecuencia garantiza prácticamente que cada transmisión colisionará en el aire con el paquete de otro dispositivo.

Cómo estructurar la radio en el aula para que sea fiable

Corregir la falta de fiabilidad de la radio no requiere protocolos de red avanzados. Requiere cuatro buenas prácticas básicas de programación en el aula.

1. No utilices nunca el grupo de radio predeterminado

Los tutoriales suelen indicar al alumnado que escriba radio.setGroup(1). Si toda la clase utiliza el grupo 1, cada receptor procesará los paquetes de todos los transmisores, aunque luego se filtren por software. MakeCode admite grupos del 0 al 255. Al principio del trimestre, asigna a cada mesa o pareja un número de grupo permanente propio:

• La pareja 1 utiliza radio.setGroup(10)
• La pareja 2 utiliza radio.setGroup(20)
• La pareja 3 utiliza radio.setGroup(30)

Los identificadores de grupo modifican la configuración de la dirección de red en el chip. Aunque los grupos cercanos sigan compartiendo el mismo espacio general del canal de 2,4 GHz, el filtrado a nivel de dirección de hardware evita que los paquetes ajenos inunden la cola de recepción de la pareja de al lado.

2. Prohíbe los bucles sin limitación

Salvo en casos excepcionales de telemetría de física a alta frecuencia, casi ningún proyecto escolar necesita 50 actualizaciones por segundo. Un coche teledirigido o un mando por inclinación responden con total fluidez a un ritmo de 5 a 10 actualizaciones por segundo. Exige una pausa explícita dentro de cada bucle de transmisión continua:

basic.forever(function ()
    radio.sendValue("speed", currentSpeed)
    basic.pause(100) // 10 paquetes por segundo como máximo
})

Mejor aún: pasa de un sondeo continuo (polling) a una transmisión dirigida por eventos. Un mando solo debería emitir cuando el usuario pulse un botón, incline la placa más allá de un umbral relevante o detecte un obstáculo. Si nada ha cambiado, la radio debe permanecer en silencio.

3. Introduce variabilidad temporal (jitter)

Si todas las micro:bit de una sala emiten estrictamente cada 100 milisegundos, sus relojes acaban sincronizándose al unísono, lo que significa que dos dispositivos colisionarán repetidamente en cada ciclo. Es posible eliminar estas colisiones rítmicas añadiendo una fluctuación o «jitter» seudoaleatorio a la pausa del bucle:

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

Esta ligera aleatorización de 0 a 30 milisegundos garantiza que, incluso si dos dispositivos colisionan en un intervalo, sus siguientes emisiones se desfasarán, lo que permitirá que los paquetes se transmitan limpiamente.

4. Reduce al mínimo las cargas útiles

La transmisión por radio requiere tiempo físico; cuanto más largo es el paquete, mayor es la ventana de colisión. MakeCode permite enviar cadenas de texto largas con radio.sendString("FORWARD_LEFT"), pero las cadenas consumen decenas de bytes. En su lugar, utiliza números enteros individuales o pares de valores con claves de un solo carácter:

Qué hacer cuando toda la clase debe comunicarse con un solo receptor

En actividades de votación en grupo o registro de estaciones meteorológicas, quince micro:bit del alumnado deben enviar datos a una única micro:bit que actúa como concentrador. Esta arquitectura es especialmente propensa al colapso del búfer.

Para que esto funcione sin pérdida de datos, invierte el flujo de comunicación: implementa una arquitectura de sondeo (polling) en lugar de una emisión simultánea sin control. La micro:bit concentradora emite una solicitud para un identificador concreto (por ejemplo, enviando el número 1). Únicamente el dispositivo del alumno configurado como dispositivo 1 transmite su carga útil. Una vez recibida, el concentrador solicita los datos del dispositivo 2. Esta estructura por turnos rotatorios (round-robin) elimina por completo el riesgo de colisión y garantiza que la micro:bit receptora nunca tenga más de un paquete esperando en su búfer a la vez.

Para programas estructurados en los que decenas de alumnos construyen proyectos de hardware en red, Sheen Robotics detalla configuraciones de aula y un currículo modular mediante Infinity for Schools para garantizar que las prácticas de hardware se desarrollen de manera predecible, en lugar de perder tiempo resolviendo colisiones invisibles en el espectro radioeléctrico.