All posts by dave

Pattern matrix – putting it together

Here is a member of staff at Miners Court trying some tangible weave coding in the midst of our crafts area – at the moment it’s simply displaying the weave structure on the simulated warp weighed loom with a single colour each for warp and weft threads, the next thing is to get ‘colour & weave’ patterns working.


The pattern matrix is the second generation of tangible programming device from the weavecoding project. It’s been built as an open hardware project in collaboration with Falmouth University’s Makernow fablab, who have designed and built the chassis using many 3D printed parts and assembled the electronics using surface mount components (far beyond my stripboard skills).

Here you can see the aluminium framework supporting the AVR based row controller boards with the Raspberry Pi in the corner. The hall effect sensors detect magnetic fields – this picture was taken before any of the wiring was started.


The row controllers are designed to read the sensor data and dispatch it to the Raspberry Pi using i2c serial communication running on their atmega328 processors. This design was arrived at after the experience of building flotsam which centralised all of the logic in the Raspberry Pi, resulting in lots of wiring required to collect the 128 bits of information and pass it to the GPIO port on the Pi. Using i2c has the advantage that you only need two wires to communicate everything, processing can be distributed and it can be far more modular and extendible in future. In fact we plan to try different sensors and configurations – so this is a great platform for experimenting with tangible programming.

This video shows the current operation of the sensors and row controllers, I’ve programmed the board with test code that displays the state of the magnetic field with the status LED, making sure that it can tell the orientation of the programming block:

The row controllers have a set of multiplexers that allow you to choose between 20 sensor inputs all routed to an analogue pin on the AVR. We’re just using digital here, but it means we can try totally different combinations of sensors without changing the rest of the hardware.

After getting the first couple of rows working and testing it with elderly people at our Miners Court residency there were a couple of issues. Firstly the magnets were really strong, and I worried about leaving it unattended with the programming blocks snapping together so violently (as we plan to use it in museum settings as well as at Miners Court). The other problem was that even with strong magnets, the placement of the blocks needed to be very precise. This is probably to do with the shape of the magnets, and the fact that the fields bend around them and reverse quite short distances from their edges.

To fix these bugs it was a fairly simple matter to take the blocks apart, remove 2 of the 3 magnets and add some rings to guide placement over the sensors properly:


Future Thinking for Social Living: Weavecoding in assisted housing

Our work on weavecoding is now reaching out to other uses and projects. One is Future Thinking for Social Living, run by Magda Ty┼╝lik-Carver and Fiona Hackney.

This research project aims to look at the relationship between wellbeing, home, making and technology and is centred on Miners Court, who provide assisted housing in Redruth in Cornwall. As well as a range of flats and accommodation, the residents have shared communal areas with a variety of activities throughout the week. Along with Christiane Berghoff, Robin Hawes and Lucie Hernandez we set up camp with a lot of materials for knitting, crochet and weaving as well as some Raspberry Pis and the all new pattern matrix tangible weavecoding device.


The Future Thinking for Social Living project is set up to research how we can think more critically about home and community, and with particular focus on the future. From discussions with the staff at Miners Court – specific issues they are interested in are how to make better use of communal spaces, and how can they get more men involved with crafts and shared activities.

I’m also interested in how we can use these settings for artists residencies – how does working with people like this affect a design process, does working in such a place – and using it as way to start conversations (rather than being too much in ‘teacher mode’) affect the people living there positively? Also the weavecoding project provides some ideas in bridging gaps, both between technology and people – but also across gender gaps, mixing textiles with electronics for example.

Here is the new magnetic pattern matrix, running the 3D Raspberry Pi warp weighted loom simulation (more on this soon!) with a nice 4 shaft loom in the background.

On Monday and Tuesday we spent a long time talking, weaving, knitting and making cups of tea of course (and a bit of time debugging magnets on my part). I’ve found helping people weave with tablets on the inkle loom is a good way to get talking, as this seems new to even people who are experienced with crafts. It also appeals to people with mathematics or design background who normally are uninterested in knitting and other crafts, and seems gender neutral perhaps for the same reasons. It also helps to talk about the history of what we are weaving with, the fact that this is an ancient technique and yet there are so many surprises – I can’t really predict to them what will happen e.g. to the pattern when we change rotation direction, and this seems to be important.

What we have yet to do (but a few weeks to experiment yet) is bridge the technology gap. Many of them have an immediate reaction of distaste to computers, as most of them have them but report that they have become unusable or feel that they are not designed well with their needs in mind. Partly the situation of having some circuit boards getting tangled up in the more familiar materials and using the Raspberry Pi simulation to show what is happening on the loom next to it is a start. One interesting thing is that neither the Pi nor the AVR boards look enough like ‘a computer’ for it to stand out too much (which also part of the Pi’s role in the classroom) – this was more so after plugging it into their large TV and getting rid of the monitor. As it gradually gets into a working state, I’d like to first try using it to demonstrate well known weaves – e.g. plain, twill and satin.

Working in this environment on the pattern matrix between weaving with different people has already had an effect on it’s design process. One initial observation resulted in reducing the magnet strength – I hadn’t even considered before that having them snap together too forcefully would be a problem for some people. Such things are obvious in these kinds of settings.

More kite based UAV toolkit action

Some further kite testing with UAV Toolkit last week at Gwithian beach, with a strong offshore wind (and rather good looking surf too). We managed to max out the kite altitude and get some great photographs including surfers and flocks of birds. See the previous kite post for more details on the kite.




I’ve also started experimenting with combining the sensor data with the images to provide geo-referenced images in GeoTIFF format. This uses the magnetometer data to orient the image and GPS for position. This is still work in progress with quite a lot of converting between coordinates going on, all using the GDAL suit of tools with python to glue it all together:


Loose threads from weavecoding

Midway through the weavecoding project and our researches have thrown up a whole load of topics that either don’t quite fit into our framework, or we simply won’t have time to pursue properly. Here are some of the tangents I’ve collected so far.

Coding with knots: Khipu

One of the cultures I’m increasingly interested in are the Incas. Their empire flourished to up to 37 million people, without the need of money or a written language. We know that some numeric information was stored using Khipu, a knot based recording system which was used in combination with black and white stones to read and calculate. Two thirds of the quipus we have are un-translated, and do not fit into the known numeric coding system – what information do they hold?


Harvard University provides a Khipu Database Project with many surviving examples documented – I’m hoping to run a workshop soon to look through some of this data in a variety of ways.

Tablet weaving NAND gates

Diagram thanks to Phiala’s String Page – the only place I’ve seen tablet weaving explained properly.

There are logic gates in tablet weaving logic. I haven’t fully figured this out yet, but I noticed modelling tablet weaving that you end up basically mapping the combinations of the weaving actions (such as turn direction) and colour as truth tables.

Top face colour based on top left/top right hole yarn in a single card and turn direction (clockwise/counter clockwise)

TL Yarn : TR Yarn : Turn : Top face colour
Black   : Black   : CCW  : Black
Black   : Black   : CW   : Black
Black   : White   : CCW  : Black
Black   : White   : CW   : White
White   : Black   : CCW  : White
White   : Black   : CW   : Black
White   : White   : CCW  : White
White   : White   : CW   : White

Things get stranger when you include twist and combinations of actions with multiple cards. Would it be possible to compile high level programming languages into weaving instructions for carrying out computation? Perhaps this is what the untranslatable quipus are about?

Nintendo made a knitting machine

We could really do with some of these, unfortunately they never went beyond prototype stage.


Asemic writing

Asemic writing is a post-literate written form with no semantic content. Miles Visman programs procedural asemic languages and hand weaves them. I think this may be an important connection to livecoding at some point.


Easter Python/Minecraft programming day at dbsCode

Thursday saw our second dbsCode Easter programming taster, and like last year we focused on minecraft programming with our procedural architecture api.

The main change this time was that for the 20 11-16 year old participants we doubled our teachers to 4 (Glen Pike, Francesca Sargent and Matthew Dodkins and me), plus a couple of interested parents helped us out too. This meant that the day was much more relaxed and we noticed they were engaged with the programming for a much higher proportion of the time. Another factor was that we went straight into coding, as none of them needed introduction to minecraft this year. I think one of the biggest strengths of this kind of learning is that they are able to easily switch between playful interaction (jumping into each other’s worlds, building stuff the normal way) and programming. This means there is low pressure which I think makes it more of a self driven activity, as well as making a long (4 hour) workshop possible.

Here are some screenshots of their creations – this was a melon palace created in a world that had somehow become sliced apart:


Inside the melon palace, the waterfall pulsed with a while loop and sleeps that altered the water source blocks.


As last year there was a lot of mixing of activities, using code to create big shapes and then editing them manually for the finer details:



Here, a huge block of water inexplicably cuts through the scenery:


And two houses, that became merged together and then filled with bookshelves and other homely items:


Kite mapping with UAV toolkit

Some photos taken by the UAV toolkit on a recent flight at our gyllyngvase beach test site, using a KAP foil 1.6 kite instead of a drone. Kites have many advantages, no flight licences required, no vibration from engines and a fully renewable power source!


We’re using a 3D printed mounting plate for the phone strung from the top of the single line just below the kite. It needs more wind than we had to get higher altitudes but the first impressions are good. I’ve also added a new trigger mode to the UAV toolkit programming language that remembers the GPS coordinates where all the photos are taken, so it can build up overlapping images even if the movement is harder to control.



The tail of the kite – which turned out to be important for stabilising the flight.



Here is the code using the when-in-new-location trigger to calculate overlap based on the camera angle, gps and altitude – which ideally should be driven somehow by the length of the line. As an aside, this screenshot was taken in the chrome browser which now runs android apps.


Training teachers in coding at Truro School

I’m part of a UK Department of Education funded project to join up 10 primary schools in Cornwall and get them programming. The teachers are very important people in this equation, so our first activity was a training day for them. The idea of this was to get them familiar with using the Raspberry Pi and try out some programming, while at the same time allowing me to gather some research on feasible projects that can result in long term benefits for the schools involved.

We gave Sonic Pi and our Minecraft Python architecture coding a go, and I also briefly demoed the weavecoding project via flotsam – as one of our eventual aims is to produce teaching materials for this too. I’ll start with some of the broader things we discussed, see below for more specific observations for these programming systems.

Unaddressed needs of teachers

Despite a big push in coding in schools, there are still plenty of areas where support is lacking or even misguided. The focus on hardware platforms (Raspberry Pi, BBC’s Micro Bit) is not so relevant as schools have plenty of existing hardware, also the mass of community open source activity needs a lot of work to translate for classroom use. A further problem is that a lot of existing initiatives tend to be high visibility but too short term in their scope. Codeclub is a notable exception in this area. Technology also tends to get considered as a distinct subject – whereas it needs to be linked with other topics (i.e. teaching local history by making computer games about it) in order to make sense.


Long term thinking

Events for teaching a small proportion of children programming has short term benefit unless it is to enable the children to teach each other. This turns out to be successful in after school code clubs, so is it possible to design events and workshops with this aim specifically in mind?

Teachers need access to people who work with technology when they need it, but how can this be done – a local support network perhaps, we also discussed hacklabs for teachers where they can drop in and get advice. Hacklabs could provide teachers with feedback on their ideas, perhaps some small one on one training to help realise them – as well as perhaps building hardware or software specifically according to their needs. The funding for this is an open question at the moment.

One of the issues reported by the teachers is that it takes a lot of effort to get students to a certain tipping point with technical ability, after which they shoot ahead and quickly overtake the teacher. I’m not sure if this is seen as a problem in itself, but it does seem like there needs to be a situation designed where this can easily feed back into the collective knowledge of the group.

Classroom materials are worth their weight in gold, like the ones supplied with Sonic Pi or those provided by Code Club – and they take a long time to check and get right. The problem is that it’s actually hard to get funding to make these, relative to teaching hours. Releasing all teaching materials as creative commons to pool resources nationally (and beyond) is key. One thing that came out clearly with the worksheets we used for both Sonic Pi and the ones we wrote for Minecraft coding was that they are not really very well suited for primary school use. We seem to tend to write documentation that focuses on example recipes to follow rather than encouraging exploration – this was a surprise to me. The teachers were more keen on simple lists of commands (and liked the dropdown menus in Sonic Pi for example) which were then left for the children to discover how they fit together, and less wordy explanations.


Hardware problems

Many schools have already moved away from desktop PCs, whether using laptops or (shudder) tablets exclusively. The Raspberry Pi has considerable extra hardware needs – we discussed whether recycling hardware being thrown out from local businesses was one option to help with this.

We came to the conclusion that one promising area to look at is robotics, making use of the Pi’s easily accessible hardware interface. The problem then is where to get the required motors and other hardware from – one potential resource are the forgotten boxes of lego, electronics and bits and pieces gathering dust in school storage. Again the challenge is how to make effective use of this rather than spending money on new kit.

Systems we tested

We tried following some worksheets for two coding projects on the Raspberry Pi, the aims were twofold – to get some initial experience with them as well as getting feedback for how we can improve them from the teachers point of view.

Sonic Pi

This was the first time I’ve used the new version of Sonic Pi in a class room. We used the version that comes pre-installed on the ‘2015-02-16-raspbian-wheezy’ release. I’m not very familiar with Ruby, the language it uses but I’d had a bit of a play with it in the days prior and had a bit of feedback from Sam Aaron on some specifics too.

One of the big questions I had was whether typing skills would be an issue with the primary age group. They are used to using drag-drop programming languages like Scratch and Espresso but would this translate to using the keyboard? The teachers thought that Sonic Pi’s minimal syntax would be really good with their children – the syntax highlighting (using colour and little lines to denote indentation) would be important to make it easier for them. One problem we noticed is that the syntax colouring might be able to go a little further – it could, for example be more context sensitive – e.g. the difference between a symbol that is user defined and one that is part of the system would be better to differentiate for explanation.

They considered the documentation, both ‘online’ as part of the interface and the wording of the tutorials was probably too prescriptive and in-depth (which to be fair is written for older children). More importantly the teachers loved the musical aspect, and immediately got into creating their own tunes (all mixing with the amen break :) Initially the concept of MIDI notes was a confusion – “why is 60 middle C?”. A popular request was for some pre-written examples of familiar tunes to fiddle with.

The interface including visible debugging/errors was very popular, as it seems a lot of existing commercial software they use in classrooms does not to this well. Being able to ‘hear’ bugs was also important. It was also good to explain Sonic Pi in terms of musical livecoding and Supercollider, as this culture gives it a kind of extra spice which is exactly what we need when ‘coding’ can so easily slip into being about boring product-centric thinking.



To contast Sonic Pi, in the afternoon we switched to the Minecraft world and the system we developed for teaching teenagers programming with Python. I’ve recently been using this for one-on-one teaching with an 8 year old, so I wanted to find out if they thought it would be useful in the classroom for this age group.

This setup relies on an IDE (we use Geany) which communicates with Minecraft via network messages running in a different window. The multiple windows and strange ‘always on top’ OpenGL rendering of the Raspberry Pi GPU makes this a fiddly business until you get the hang of it, but the upside is that this is the same approach as programming in the games industry – and kids like it when you tell them this. However it would be wonderful to be able to ‘dock’ minecraft in a Python IDE in a friendly way and have some of the features of Sonic Pi.

The projects we made with this system are again pre-created recipes without much information on things like how to get the coordinates right rather than just following the instructions. One of the teachers found out that you can use the player’s position to figure out what the coordinates should be, we need to include these kinds of hints and think a bit more broadly how to describe the creative process.

On thing I picked up from the teachers was that they had high expectations of the scale of what would be needed to capture interest for the children – for example that we’d need to write programs to create entire cities and a worry that the amount of code needed for a simple house seemed so much. However, what I’ve noticed when using this for teaching younger children – is that we’ve sometimes spent an entire hour on a single line of code. For example creating a block, changing it’s position and size in 3 dimensions and then trying changing the block type – seeing how water or lava acts in different circumstances. The strength of Minecraft is that it contains a lot of complexity which is already understood by children who play it, so they don’t really need to be convinced so much as given space to explore possibilities.

Yeastogram workshop

Last week we had our first biohacking workshop at foam kernow with the London Biohackspace. We had a great turnout and an interesting mix of people. Amber has written a more complete overview of the event.


For more information on yeastograms and how to make your own there is more info here. One of the things we helped with was the construction of a high power UV LED array needed to expose the cultures to radiation. We used 19 LEDs from here powered in 3 chains of 5 and one of 4 at 20V drawing 1.2A. After battling Ohms law for a while we found this site to be immensely useful. We also spent a lot of time on the LED heat sinks and cooling with an old PC fan – but the only problem we had was with the limiting resistors which overheated resulting in a last minute shopping trip to get some 10W rated bigguns. After that everything ran warm rather than hot and could be left overnight. One very important thing to mention with the UV light is to get proper eye protection when working with this, and not just dodgy sunglasses.