Quando um par de alunos testa um script de rádio no micro:bit isoladamente numa secretária, quase sempre funciona. Quando vinte pares testam o mesmo script em simultâneo, a rede colapsa: as mensagens chegam com segundos de atraso, de forma intermitente, ou desaparecem por completo. O hardware não avariou e a rede Wi-Fi da escola não está a interferir. A sua sala de aula deparou-se diretamente com dois estrangulamentos fundamentais de rede: colisões físicas de pacotes sem controlo de débito e a saturação do buffer de receção.

Os dois pontos de estrangulamento invisíveis

Para resolver o problema, é necessário compreender o que o BBC micro:bit está realmente a fazer quando executa os blocos de rádio do MakeCode. O micro:bit utiliza um emissor-recetor da Nordic Semiconductor (o nRF51 na v1, ou o nRF52 na v2) a operar no espetro de 2,4 GHz. Por predefinição, opera sem qualquer confirmação por deteção de portadora (carrier-sensing) ou protocolo de tentativas automáticas de retransmissão.

Quando o script de uma aula instrui um micro:bit a enviar um sinal, cria dois problemas distintos à escala:

• Colisões no ar (Airtime Collisions): Se dois micro:bits transmitirem na mesma banda de frequências no mesmo instante, os seus sinais de rádio sobrepõem-se no ar. A antena recetora capta uma mistura impercetível de ambas as transmissões. O micro:bit verifica o Cyclic Redundancy Check (CRC) do pacote, deteta a corrupção e descarta o pacote silenciosamente. Não é gerado qualquer erro; os dados simplesmente desaparecem.
• Esgotamento do buffer RX: O ambiente de execução (runtime) de software do micro:bit (CODAL / DAL) armazena os pacotes de rádio recebidos num pequeno buffer de receção suportado por hardware, que normalmente comporta apenas quatro pacotes antes de os passar para o código do utilizador. Se quatro micro:bits enviarem mensagens enquanto o recetor está a atualizar a sua matriz de 5×5 LEDs ou a aguardar dentro de um bloco de pausa, esse buffer enche-se de imediato. Qualquer mensagem subsequente que chegue durante essa janela é descartada.

O verdadeiro problema: a torrente do ciclo "forever"

Em quase todas as salas de aula onde as comunicações falham, o culpado é um padrão de código para principiantes que se parece com isto:

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

Dentro de um ciclo forever normal sem um atraso explícito, um micro:bit transmitirá entre 30 e 50 pacotes a cada segundo. Um par de alunos a gerar 40 pacotes por segundo consome uma fração modesta do tempo de antena local. Multiplique isso por quinze pares a trabalhar em simultâneo numa única sala de aula, e o espaço fica repentinamente inundado com 600 pacotes por segundo.

Como o código básico de rádio transmite às cegas — o que significa que o micro:bit não espera por um canal livre antes de enviar, nem solicita uma confirmação de receção —, transmitir a alta frequência garante praticamente que cada transmissão irá colidir no ar com o pacote de outro dispositivo.

Como estruturar comunicações de rádio fiáveis na sala de aula

Resolver a instabilidade do rádio não requer protocolos de rede avançados. Exige apenas quatro disciplinas básicas de programação na sala de aula.

1. Nunca utilize o grupo de rádio predefinido

Os tutoriais dizem frequentemente aos alunos para escrever radio.setGroup(1). Se toda a turma utilizar o grupo 1, cada recetor processa os pacotes de todos os emissores, mesmo que os filtre posteriormente por software. O MakeCode suporta grupos de 0 a 255. No início do período letivo, atribua a cada mesa ou par o seu próprio número de grupo permanente:

• O Par 1 utiliza radio.setGroup(10)
• O Par 2 utiliza radio.setGroup(20)
• O Par 3 utiliza radio.setGroup(30)

Os identificadores de grupo alteram a configuração do endereço de rede no chip. Embora grupos próximos continuem a partilhar o mesmo espaço geral de canais nos 2,4 GHz, a filtragem ao nível do endereço de hardware impede que pacotes alheios inundem a fila de receção de um par vizinho.

2. Proiba ciclos sem controlo de débito

Com exceção de raras telemetrias de física de alta frequência, quase nenhum projeto escolar exige 50 atualizações por segundo. Um carro telecomandado ou um comando por inclinação responde de forma fluida a 5 ou 10 atualizações por segundo. Imponha uma pausa explícita dentro de cada ciclo de transmissão contínua:

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

Melhor ainda: passe de polling para transmissão orientada por eventos. Um comando só deve transmitir quando o utilizador prime um botão, ultrapassa um limite significativo de inclinação ou deteta um obstáculo. Se nada mudou, o rádio deve permanecer em silêncio.

3. Introduza variação temporal (jitter)

Se todos os micro:bits de uma sala transmitirem rigorosamente a cada 100 milissegundos, os seus relógios acabam por sincronizar em uníssono — o que significa que dois dispositivos colidirão repetidamente em cada ciclo. Pode eliminar colisões rítmicas adicionando "jitter" pseudoaleatório ao atraso do ciclo:

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

Esta ligeira aleatorização de 0 a 30 milissegundos garante que, mesmo que dois dispositivos colidam numa fração de tempo, as suas transmissões seguintes fiquem desfasadas, permitindo que os pacotes passem sem problemas.

4. Reduza as suas cargas úteis (payloads) ao mínimo

A transmissão de rádio demora tempo físico; quanto mais longo for o pacote, maior é a janela de colisão. O MakeCode permite enviar cadeias de caracteres longas com radio.sendString("FORWARD_LEFT"), mas as strings consomem dezenas de bytes. Em vez disso, utilize números inteiros individuais ou pares valor-chave de caráter único:

O que fazer quando toda a turma tem de comunicar com um único recetor

Em atividades de votação em grupo ou no registo de dados de estações meteorológicas, quinze micro:bits de alunos têm de enviar dados para um único micro:bit concentrador (hub). Esta arquitetura é particularmente propensa ao colapso do buffer.

Para que isto funcione sem perda de dados, inverta o fluxo de comunicação: implemente uma arquitetura de polling em vez de uma transmissão aberta e desregulada. O micro:bit concentrador transmite um pedido para um identificador específico (por exemplo, enviando o número 1). Apenas o dispositivo do aluno configurado como dispositivo 1 transmite o seu payload. Uma vez recebido, o concentrador solicita os dados do dispositivo 2. Esta estrutura round-robin elimina por completo o risco de colisão e garante que o micro:bit recetor nunca tenha mais de um pacote em espera no seu buffer de cada vez.

Para programas estruturados que gerem dezenas de alunos no desenvolvimento de projetos de hardware em rede, a Sheen Robotics apresenta currículos modulares e configurações de sala de aula através do Infinity for Schools para ajudar a manter as aulas práticas de hardware a funcionar de forma previsível, em vez de passar o tempo a resolver colisões invisíveis no espetro de rádio.