Overview

Part of the new Digital Technologies curriculum for year 7 and 8 involves students learning about wired and wireless networks, and methods of data transmission and security. There are activities from the Digital Technologies Learning Hub that deal with routing and issues with performance (that are pretty good unplugged activities). I use these or variations on these when I teach those concepts, but I wanted to put together something that actually involved technology in the classroom, and dealt with ideas a bit lower down the network stack.

Playing with Microbits

This year we got some BBC Microbits, and I’ve been looking at how to use them with my classes in an effective (and manageable) way. After playing around with some basic communication via Bluetooth with the Microbits, I thought I’d have a crack at writing some simple programs for students to use to encounter some of the problems with wireless networking, and use it as a hook for looking at ways that we’ve fixed those problems.

Microbits can broadcast messages via Bluetooth Low Energy, and allow you to choose the channel that they transmit/listen on per device. I wrote a (slightly tedious) program in the blocks interface (link here: feel free to use/abuse it) that did the following:

  • A button: choose a random picture to display on the screen
  • B button: broadcast the picture, pixel by pixel, to any listening Microbits
  • A+B buttons: switch to the next channel (cycle through 7 channels)

The video below shows two of them in action.

Lesson ideas

If you dig through the code for the program, you’ll see there are artificial pauses between the transmission of each ‘pixel’/LED state. I ran into speed issues when transmitting them as fast as I could, where a number of pixels would not light up. This sort of worked out for the best, since it gave me an artificial latency figure I could manipulate, as well as giving students the idea that not just the lit up LED states were being transmitted, but also the state of the unlit ones.

I didn’t want to send the state of the entire board at once, since two of the concepts I wanted students to discover were those of attenuation and interference from signal-absorbing materials (mostly from, in my words: “giant sacks of water”, i.e. lots of students standing in between the transmitter and receiver). Since pixels were being transmitted one at a time, there was plenty of opportunity for images to be corrupted in transmission. I had kids hiding behind metal doors of cabinets, calling to each other across the courtyard asking what picture popped up on the receiver, and basically seeing what broke when. It was chaotic but pretty neat.

I have two other teachers who deliver at the same time as me, and I had prepped them with their own Microbits for that lesson. I didn’t realise that one of them was in the next room however, which made the fact that all devices started transmitting on Channel 1 entertaining at the start of the lesson, but also a good jumping off point for why we need different channels, and rules for effective transmission in crowded networks.

Where to next

The block code is really quite limiting for this sort of program. It involved all sorts of horrible attempts at type casting, and was both fun to write (in the end!) and quite frustrating. At the same time it was good to see how complex a solution to my problem I could get without having to switch to Python.

Some take-aways

  • I’m not sure if it’s an feature of the block code or not, but you can’t set the radios up to listen for different types of messages. For example you can’t have integers, strings, and key/value pairs being broadcast and figure out what to do with them based on the type of message. This is why I ended up having the horrible reset method in there which checked the length of the value in the key/value pair.
  • The block code has a method for changing strings to integers, but doesn’t seem to have a way to change integers to strings. This is relevant because I had a go at transmitting the entire state of the LED array as a bit string (see the bit at the end on next lesson) to avoid having to process each LED individually (which worked well for this lesson anyway, but isn’t ideal).
  • The block interface handles if-else if-else if-…etc really nicely. Hit the config button in an if block, and then drag in as many else-if blocks as you need. Huge improvement on the way something like Scratch works.
  • The simulator is just rubbish for any moderately complicated radio transmission. I got an incredibly basic program to work in the simulator and was briefly impressed, but this one just refused to work at all, despite working fine on the real hardware.

Encryption

We ended the lesson with the problems of clear text communication, with lots of students suggesting that we need a “different language” so that eavesdroppers don’t know what we’re saying to each other. I’ve had mixed success looking at encryption with this level of students before, so want to try something different this time around.

Usually there’s lots of historical navel gazing at Caesar Ciphers, moving onto columnar ciphers and the like, and then we run out of time and move on. This time I want to look at one time pads (well, actually multi time pads, but I don’t want to have to figure out how to transcribe a one time pad into each Microbit using two physical buttons each time - sorry serious security people!) using XOR, and then try and find a good way of ending up at the idea of public/private keys, if not an actual implementation.

My plan is to implement the program I used for this class in Python, and then, with better control over the actual data, set up the devices with their own pads in pairs to use, so we can see how this affects others ability to eavesdrop on the transmitted pictures, despite still using the same channel.