Back in 2017 when I was first thinking about how I could use physical computing like Micro:bits in my classroom, I wrote some quick and nasty programs to demonstrate networking concepts like attenuation and latency in wireless connections as well as adapting some ideas from the Networking With the micro:bit book, and using basic wired networks for Morse Code (the linked site is not the original project I used the idea from, but there are only so many permutations).

Through a series of short activities we crammed in:

  • Calculating throughput
  • Asymmetric speeds in networks (albeit in a slightly clumsy way)
  • Wired vs wireless communication
  • Broadcast and unicast wireless transmission
  • Attenuation and interference
  • Noisy channels and collisions
  • Latency
  • Privacy of communication on networks (still trying to come up with a better way of introducing crypto in a hands on way, my previous attempt was not great)

Whilst I still think the ideas are good ones, it was a classic case of plans not surviving contact with the enemy: my students found all the ways to break my programs, misunderstand how they worked, and otherwise turn the exercise into a hassle for a significant minority of the class.

Multiple Pairs of Clients

The basic problem boiled down to that whilst it was a great prompt for discussing a lot of the problems with busy wireless networks as well as privacy, having up to 15 pairs of clients all trying to communicate at once is a nightmare.

My original solution was to allocate each pair a wireless group/channel which they manually navigated to via button presses, and then sat blissfully operating in their own little slice of spectrum. Of course this is predicated on students following instructions, not being malicious, not running past their allocated group because they pressed the button too many times (an issue when you hit group 10+ as the display starts slowly scrolling the group number and students get impatient), etc.

For a number of pairs of students, this then turns into a festival of resetting their device to return to the default group and incrementing their group once again, this time with the additional chatter of existing communication flying past on their screens as they waltz through other students’ channels.

My first solution to this problem was to have a toggle switch for the radio, so devices started out in the off state, you change the group up to yours without network activity to distract you, and then off you go. Seasoned teachers will no doubt predict how much that helped; students didn’t pay attention to the fact their radios were off by default, and complained their program wasn’t working, got to the correct channel tried it out with the radio turned off and reset their device, etc.

Enter Pairing

Over the last year I’ve been playing around with writing programs based on wireless signal strength, such as my PKE Meter. Whilst thinking about modifying my latency program to artificially introduce range-based latency, it hit me that I could use the wireless RSSI value to initially pair Micro:bits for other activities, exchanging device IDs and allowing me to sidestep the annoying problem of changing groups and malicious actors. The Micro:bit already sort of does pairing via group numbers (interestingly, using a hash of your code to determine a group number if it is not explicity set!) so I was already doing this, but as a manual step rather than as an automatic process based on proximity.

I whipped up a basic three way handshake pairing system with an RSSI threshold that required the devices to be almost right next to each other and incorporated it into my programs. It remains to be seen how well this will work with 30-odd devices running at once (I’ve had issues with the short message queue on Micro:bits before) but I live in hope. Sadly I always have my ideas right at the end of a topic, so I’m either going to have to shoe-horn this into another class for testing, co-opt some ‘volunteers’, or wait until next year.

Below is the MakeCode pairing code I’m currently using (and feels super clumsy and no doubt I’ll refine next year when it’s too late to use the changes in class again 🤣).

The basic process is:

  • Send out a pair request with a 2 second timeout.
  • Capture a pair request, check for strong signal, increment state, and send reply.
  • Receive reply, respond with success and pair, or receive response and pair, incrementing state and capturing device ID.

 Here’s a copy of the latency program incorporating the new pairing code (there’s a small logic bug to do with the 5 second response timeout on pings I’ll figure out eventually - I really dislike debugging block code :( )