The matrix consists of multiple ‘nodes’ which are arranged in a rectangle.
Each node is a micro:bit which is running the same node code as all the other nodes…
… with 1 exception – each node has a unique ID (UID), which is an integer that identifies its location in the matrix (so the top left node is 0 and the bottom right, in a 100 micro:bit matrix, is 99). This is currently hard-coded into the node code, which is a weakness and does not scale very well (try editing and flashing the code 100 times!). Having discussed ideas on this with some of the micro:bit ‘heavy hitters’ I have a plan to address this.
The video below shows a 5×4 matrix. Each node is running the code discussed on this page:
Latest iteration of #microbit matrix code is satisfactory. If you are interested the code is here: https://t.co/rcqWSy6ZPX – read the HowTo if you fancy a play (you’ll need at least 2 micro:bits). @blogmywiki @whaleygeek pic.twitter.com/dfchXvumGl
— Philip Meitiner (@pragmaticPhil) November 19, 2017
Also shown above – the PhilTronic2000. More on how this is used as a server at the end of this chapter.
In brief, this is how a node works:
- Nodes listen over radio for messages being transmitted over a specific channel.
- Messages sent from the server are sent to either the whole matrix, a whole row, or a specific node. I’ve listed all the protocols governing the messages here.
- Messages from the sever to the node either contain image data, or instructions.
- Nodes only process the messages that are relevant to them. Note that the server will tell the nodes the dimensions of the matrix – this allows each node to infer the row and column that they are located in (rem – nodes have an integer UID). This in turn allows the server to send images / instructions to a whole row / column at the same time.
- Nodes have a built-in 10-frame buffer. This buffer is filled by data from the server.
- Nodes can either scroll specific frames from their buffer or they can run through the frames on their buffer sequentially. Where they are set to scroll this can be right or left, and the speed can be controlled.
- All node behaviour is controlled by the server.
In testing the node code works really well – the lag from sending the image from the server to the node is tight – almost real time and way inside ‘best case scenario’ parameters. It was time to bank the node code and begin work on the server.
You can find the very latest version of the node code on this GitHub repo. The repo also includes extensive notes on how to use it – the commands nodes respond to and how they respond to those commands. There is also simple server test code. If you have 3 or more micro:bits it should work out of the box for you.
The roles of the server:
The video clip linked to above shows the matrix at this iteration. I used 2 micro:bits as servers, each perform a distinct type of role:
- Control behaviour. A micro:bit is attached to the Philtronic2000 (PT2) controller, which is used to issue commands to the matrix. Speed of animation, animation type (scroll between frames or show frame-by-frame), scroll direction (full list of instructions that are supported) – all controlled by the PT2. This part of the server solution is fine – I am happy to use PT2 in this capacity, and there is room to add more instructions.
- Provide image data. Another micro:bit has a pile of images hardcoded as strings. It converts these into the correct format and transmits them via radio to the nodes. It works fine, but is limited by using pre-supplied, hard-coded images. A more robust solution is necessary.
The big challenge that I had was to provide server2 above with images, ideally in real time. I needed to design an external system that could feed images into server2, to be encoded and transmitted to the nodes. Something visual – a GUI that was fun and easy to use…
Next – The micro:bit matrix (4) – ex:bit
The micro:bit matrix saga currently consists of 6 chapters: