Skip navigation


12 posts

Phonicubes - final post

Posted by tub May 2, 2011



Since the last blog summarising blog post, we've been beavering away at building the final prototype for our toy, oh, and we came up with a name for it too, Phonicubes... phonics, and cubes!

Jason has been working on building the sound board, which is an integrated Arduino and Waveshield on one board.

Steve designed and built the enclosure for the toy, which you can see to the right.

In the mean time I've been collecting everyone's work and source files and posted everything up on github for your perusal. I've also soldered together the prototype using the following schematic (although we used a duemilanove instead of a nano so we could use the protoshield we had lying around).


Reader Diagram.png

With all this soldered together and mounted inside the owl shaped enclosure, I thought it was time for a demo video:


Phonicubes Prototype demo from BuildBrighton Hackspace on Vimeo.

Final parts list & costs

Protoshield (optional) £6

Arduino duemilanove £20

Custom arduino & waveshield £15

ID-2 RFID module £14

Acrylic for cubes (2x A4 sheets) £3

MDF board for the enclosure £1

Wire & misc bits £2

Magnets £20


Total, approx £81


I'm pretty certain we can get these costs down, we can most likely merge the sound board and control board which would immediately drop £20 off. If we design a PCB for the whole thing we'll not need the protoshield either dropping another £6 off.

With more time we should also be able to design a much cheaper RFID solution, I did a lot of investigation into building our own RFID reader module, parts for that would be less than £5 easily. We could also use much lower strengh magnets instead of the neodymium ones in the prototype. This would drop the price by around another £5-10. That would bring the cost down to around half of what we spent on the prototype, around £40 at consumer prices. Not bad

Reproducability and Part Availability

We have one  uncommon part in our design, the ID-2 RFID reader. This module is available from quite a few UK and European distributors, along with Sparkfun and a few others in the US. It would also be possible to drop in the ID-12 or ID-20 without any code changes. These parts have an integrated antenna, so they'd have to be positioned correctly.


For the case and the cubes, we laser cut our parts. This was because, thankfully, we have access to laser cutters which allow us to do some very rapid prototyping. However, there's not reason why you couldn't print the designs out on paper to use as a guide on a jigsaw to cut the pieces manually. You could even build the device out of cardboard using just a craft knife, some hot glue and a soldering kit.


Improvments and next steps

Currently the RFID card to word mapping is stored in program memory on the arduino, if you want to add a card/word combo then you have to re-flash the controller. We were planning on storing this information on the SD memory card in the wave shield, but alas we didn't have time to implement it.

Also, the resistor values we using in our potential divider circuit aren't giving us the values we were expecting on the analog input from the arduino. This means that some of the cubes have blank faces at the moment, and we were unable to add some of the words we were planning to include. Matt created a spreadsheet to calulate the resistor values, which seems to be correct. If anyone has any ideas please give us a shout.


Overall I think the project went really well, everyone had something to do and we all pulled together to create something that looks awesome and actually works!

Now we have all the parts required for our competition entry, I had to make something to put it all in!


I had to do this with stuff on hand. The UK is on extended holidays because of the Royal wedding, that means stores close early.


prototype.jpgWe mocked up a quick case at our last meeting, it needed to have space for:


  • All 4 cubes.
  • All electronics.
  • Battery power
  • RFID reader
  • Speaker


It ended up looking a bit like a body with face, so we decided to make it into an Owl.


First step - design.


It all starts with designing the case in CAD. My weapon of choice is CorelDraw. I use this mainly because I have used it ever since version 4, so I can whizz up designs quickly. Plus my el cheapo Chinese laser has a plugin that lets me directly cut. The 2 are married perfectly and I can have something drawn and cut very quickly with no mucking about!


Here are a few shots of the CAD - it is very simple (ease of manufacture and assembly). It has a slot together assembly, aided with some readily availble wood glue or hot glue. No exotic plastic cements!





The green lines are the outer cuts, pink are the inners. The design is based on 3mm material - in our version I used MDF - it is very cheap, paintable, less fragile than acrylic and easily glued. Easily modified for any thickness.


Step 2 - Cutting.


Cutting from 3 sheets total - my laser has a small bed of 260x160 - even though the unit is huge! On a medium Epilog or other laser this could be done in 1 sheet. It could also be cut on a scroll saw - or even a hand saw. 3mm MDF is easily cut with a sharp knife in a few passes.



There is goes cutting bits and bobs out!


Step 3 - Assembly.


As the unit is mostly slotted and glued together, assembly is easy! I used wood glue for the main structure, then some hot glue for the back supports.



There is the main unit test fitted together.



Gluing in the back supports. This is the cheapest way to give the unit some depth. As we have some curves in the design, I used 1.5mm styrene to cover the space.



Here I am adding the styrene filler sheets. As styrene is a thermo plastic - using hot glue will gently allow it to form into the curves as it glues - neat! Any excess glue that comes out on to the front panels is easily trimmed away with a razor blade.



The styrene panels that go onto the flat MDF ones are glued in place with UHU contact cement. By using plastic sheet to cover the MDF, I get a smoother surface to paint or apply decals to. Plus it covers the slot holes.


Step 4 - finishing.


Now that we have a basic case unit constructed, I decided to give it a lick of paint and some detail.


First step is to fill the small gaps between the styrene panels. I didn't take a photo of this step.


Next I add some paint - this is Plasti-Kote Acrylic Nut Brown. I had it in the paint draw and as we are making an Owl, it seemed the best colour to use :-)


2011-04-29 21.47.06.jpg

Rather than paint the whole unit I opted to make up some graphic panels, these were again designed in CorelDraw. I had to make them fit the laser cut shapes, as all the CAD is in Corel this made it easier as I have the design ready.



Here I am drawing up a quick owl in Corel.


The designs are printed onto Photopaper on a normal inkjet printer. Then they are cut on my Craft Robo. I use this because it has excellent "kiss" cutting. This is where you can align the cutting using registration marks to get perfect contoured cutouts.


2011-04-29 22.31.37.jpg

If I can fit more onto a sheet of A4 I always do. This is a bit like buying 2 components - just incase you blow one up! The Craft Robo cut out the shapes I needed, then they got a coat of lacquer. I did this because virgin photo paper can get easily marked and scratched. As we are going to be placing rfid cards onto it - this would happen.



I used Halfords (UK motor accessory store) clear acrylic. I love this stuff and if I ever spray anything - I swear by it.


After the printed parts are dry, they are glued on. I use 3M spray mount for this. It gives good coverage and sticks well. Technically contact glue could be used, but you can't scrape it off it is splurges out of the edges!


Ta da!


After all that we have a case that we can assemble our project into!



There it is from the front including logos on the bottom base part :-)



And from the back. The white panel sports a nice speaker grill, and is removable for tweaking and battery replacement.


I took it to our latest group meeting, where we did some further integration. We also had to stick some letters on the cubes. Again I used the craft robo and some black vinyl. Output from Corel again because we have to create stickers that clear the magnets.



I also soldered and glued in the new magnets to the base unit.


The others were busy with final code and integration. It is all coming together nicely :-)



Source files for all the graphics & parts are on our github repository


Finished Sound Hardware

Posted by hotchk155 Apr 22, 2011

After a couple of false starts I finally finished the sound board for the phonics reader... The circuit is pretty much the same as the one I breadboarded, but with the addition of a 5V regulator and supply smoothing caps, so it should not be fussy about supply. The board basically combines an Arduino (Atmega328 on board) with Adafruit's waveshield circuit, so its a standalone SD card reader/sound player designed to be receive commands thru the serial interface to play files from the SD card.


The idea is that it will take the audio playback load off the main processor for our phonics project. During my experimentation I was finding that the Waveshield was a resource hog during wave playback, so I think it will be useful to offload that to a second processor on the sound board, so the main processor can poll sensors and the like.


I decided to do this with SMDs to keep size down (also the SD card sockets are surface mount). Or maybe I am just a sucker for self punishment...after straining my eyes soldering caps the size of grains of sand, burning my nose a few times on a soldering iron and having to start the whole thing again after accidentally ripping up a load of traces when I tried to straighten the SD card socket, I did start to wonder if through-hole would be a better way to go.. But I gotta say there is something very satisfying about finishing something on SMD scale and having it finally work :o)


On the board there is an ICSP header which I needed to burn the Arduino booloader on the Atmega328. Once bootloader was burned, I used an FTDI USB to TTL serial cable to upload code via the 6 pin header next to the MCU. This header has serial, power, ground and reset connections and can be used to control the sound board.


There is a jumper to decide source of power (5V regulated supply via header, or other DC supply coming through on board 5V regulator). Also a power LED, a playback LED and a status LED which flashes a code if there is a startup problem.


The rest of the stuff is as the Waveshield (but without the phone socket or volume control... speaker output is via header next to the SD card socket).


A quick update on where I am with the soundbox for the phonics project...


While I was experimenting with the wave shield library code (AF_Wave), I found that 22kHz seems to be sailing a little close to the wind. Just a little extra load on the Arduino (Like polling the serial port) and that busy little timer interrupt service routine driving the DAC can disappear up its own backside , causing the code to freeze up with a crackle.


It took me a while to work out thats what was going on, but once I did, the solution was to resample the files at 16kHz, which is fine for speech on a little speaker anyway.


After resampling I went ahead and trimmed down the sound files so I could play them quickly one after the other and start playing with some “blends” of phonics into words. Thats when I hit the next problem... I was finding that there were long gaps between some files and not others. The problem only happened on some files and at first I though there was somehow still dead air in the recordings, but they sounded fine when played on Audacity and no gaps were visible on the wave form. Hmmm...


Then I realised that the gaps got progressively bigger the further I went through the alphabet... A.WAV was really snappy but Z.WAV took nearly a second to start up! Digging in the AF_Wave code I found that every time it opens a new file there is a scan through the FAT16 directory descriptors, right from the beginning... and I guess the files copied to my SD card in alphabetic order! I guess this is an issue anyone would hit with a WaveShield when trying to play a lot of small WAV files in rapid succession.


I got round the problem by rewriting the Arduino code so that the actual FAT 16 descriptors are looked up in advance for a list of files and cached for instant playback. The “playlist” here would be the set of phonics for a given word. Once the code has found all the required files on the SD card it just needs to be told which ones to play.


This complicates the control method a bit, because you need to tell the sound box what files you are going to need before you can play any of them, but it is much faster to cue the files - and blending now looks like a possibility. So I am looking at a serial control protocol for the sound box something like this


+b,a,ck = Load up a set of WAVS from the card (i.e. B.WAV, A.WAV, CK.WAV) but don't start to play them yet


*1 =Play the first file (B.WAV)


*1*2 = Play files 1 and 2 in succession


** = Play all the files


So far this seems to be working...


I will also add the ability to read the contents of a “word list file” from the SD card. This would need to have something like the following for each possible word


  • Target Word (e.g. “CAT”)

  • Target Word Sound File (e.g CAT.WAV – contains a voice saying the full word)

  • Phonics (e.g. C,A,T)


Next thing to try is to see if blending is a possibility... The access time for the SD card card might be a problem, given what I have seen so far, but we shall see...

If you've not been keeping up with our Hackspace Challenge entry, we're designing and building a toy to help teach kids how to speak and spell English using the Phonics system. It involves setting a 'target word' for the kid to spell, and let them enter the word one phoneme at a time. The toy will say each phoneme as it's put down, and when the target word is spelled correctly the toy will pronounce the word. This flow is detailed in the diagram below:

Phonics Flow.png

Because we went for a modular approach for the input and output methods (detailed in our first post), we've been able to try out lots of new tech we've not used before.

It's come to the time to decide what tech we're going to use, and after much deliberation we've chosen the various components we're going to use for our final prototype.



We've chosen two separate input methods for our toy, one for the individual letters and one for the target word.

To select the target word, we're going to use RFID. Specifically the Innovations ID-2 RFID module, which has a serial interface and performs the manchester decoding and checksums for you. We decided to go for this stand-alone module instead of making our own RFID circuits because Toby (i.e me) had spent quite a while both trying to build a reader from scratch, and hacking existing reader circuits (you can read about that in my earlier post). I'll be writing up my further experiences with RFID a bit later, keep an eye out.

For the letters, we've gone with Steve's idea of using cubes as they look and feel a lot like existing alphabet blocks used by children for hundreds of years. The blocks he designed have a pair of magnets in each of their faces which match up with a pair of magnets on the reader device. Inside the block the magnets are linked together using a resistor. The magnets make an electrical contact with the reader, and we can determine the face that's connected by reading the voltage, and hence the resistance, over the two magnets. You can see him lasering the cubes below:



For the speech output of the toy we looked at the Speakjet from magnevation and the wave-shield by Ladyada. We decided to go with the wave-shield as the speakjet, however cool it sounded, wasn't quite comprehensible enough for our use. We don't want kids growing up talking like robots.

Both Steve and Jason worked on using the waveshield for our speech output, and I recorded a whole set of phonemes. Steve's demo video, above, shows the waveshield loaded with some computer-generated voice samples (he's a bit stage shy). Jason build a wave-shield from scratch using bits and pieces he already had lying around and investivated mixing phonemes together to make words. He documented a lot of his waveshield efforts in another post.


Next steps

So far we've spent about £100 on components, a lot of that was RFID readers. We've just ordered a load of acrylic and magnets so we can make the final prototype of the toy using our new laser cutter which will be turning up on Tuesday! (We've also got Steve's laser as a backup).

In the mean time, we've got enough components to prototype the control layer using an arduino, a waveshield, the ID-2 RFID reader and the two-letter magnetic reader that Steve originally prototyped.





Cube reader for input

Posted by blinky465 Apr 4, 2011

As part of an ongoing development, Ben and Chris finally got a working prototype of Ben's cube-reader idea.

Small cubes are used as input devices - in the final, complete concept, these could be used for pretty much anything: as a password entry system, as an electronic interactive puzzle game, as musical style selections and so on.


For the BuildBrighton Global Challenge, we're looking to print different phonemes onto the face of each dice and use them as an input method for the phonics-builder project. By placing different cubes into the tray reader, with different faces showing, the user will be able to create words from a variety of different phonemes. Because each cube has the potential of being "unique" (we're using a two-byte identifier so can have up to 65,535 different IDs, but this can easily be expanded) and because the tray reader will know which face is showing and even the orientation of each cube, there's no reason why we can't have the same phonemes repeated on different cubes if required.


Each cube contains a PIC microcontroller but draws its power from the tray reader when in place (so no need for fiddly batteries inside).

When powered, the cube broadcasts a message, telling the host it's ID number and which face is connected to the terminals in the reader (and from there we can infer which face is uppermost in the tray).




The tray/reader polls each input pin, looking for the presence of a cube. If a cube is found, the serial data is read from it and stored in internal buffers. When the cube is in place, one of four possible input pins are pulled low, so the reader can work out which way around the cube is sitting, in the tray.

The reader is powered by an 18F4550 PIC microcontroller and includes visual indicators to show which cube(s) have been successfully interrogated and recorded as present.


On Thursday night's meeting, Ben and Chris managed to get a reader and cube prototype working.

Although not in a cube shape, the 16F PIC for the cube and a number of four-pin contacts were constructed on a breadboard and messages were successfully transfered from the cube to the tray/reader - and these messages were successfully transferred to a host PC via USB.

In the final reader device, the messages can be transferred either over USB or serial (to allow the input device to be easily connected to another microcontroller-based host so that a full USB host stack is not required by the potential host device).


A full write-up of development is maintained at

I've been spending the last couple of weeks tinkering with options for audio output for the project and thought it was about time I wrote something up.


The way I am seeing how this phonics game might work is that the child is set a target word somehow (e.g. by selecting a picture card) and as well as seeing a picture of a target object (for example a Cat) the game will also speak the word. It doesn't seem such a good idea for the child to see the word written down at this time, since they could just copy the word by recognising letter shapes without thinking about their sounds (which is after all the idea of phonics)


So, as the child selects individual phonics (on blocks, cards etc) and assembles them into a sequence to make a word, they should get to hear the individual sounds as they slot them in place, for example “C”, “A” and “T”.


Once the target word has been completed correctly, it would be good if the game could audibly “blend” the indivudual phonics sounds, by playing them quickly in succession, before speaking the complete word as a confirmation (together with a suitable congratulatory message)


So we need some kind of voice output device that can do the following things:

1 – Make recognisable phonics sounds in isolation

2 – Speak complete target words in an easily understood way

3 – Demonstrate “blends” of the individual phonics into as close a representation of the target word as is possible.


So what device to use... we considered several options including the following:


a) Speech synthesizer Ics/modules (e.g. Magnavation Speakjet),

b) Text to speech software (e.g. like that provided by Android OS)

c) Audio file playback of pre-recorded words and sounds (e.g. Arduino WaveShield)


The first option we tried was the SpeakJet. The SpeakJet is a monolithic speech and sounds IC with a serial input and a full set of phonemes built in and no external components needed. In fact it is packed with a bunch of sound effects (including some excellent R2D2 noises) and a multi voice synthesizer. Its a great toy full of features, but how suitable is it for our project?


It was easy to try out the SpeakJet, simply using an FT232 USB to Serial breakout board and a few bits of wire. Magnevation have a free utility called Phrase-a-Lator which lets you get the SpeakJet up and running (and swearing, of course) pretty quickly.


The sound is reminiscent of the old Texas Speak'n'Spell. While it has a certain robotic charm we felt it was not going to work well in our application, especially when trying to speak the individual phonics. Outside of the context of a word, a single SpeakJet phoneme can be very difficult to recognise.


And so on to another option...


The WaveShield is an Arduino shield which is an open-source Adafruit design and can be purchased in kit form or fully assembled from many places, or you can build your own by dowloading the schematic and Eagle files (although I found the Eagle project reported as “inconsistent” when loaded).


The Waveshield plays uncompressed WAV files direct from an SD card. It can play at 22KHz sample rate and gets a 12-bit resolution (limited by the DAC used). All perfectly adequate for speech, and very convenient for our project (Ability to prepare sound files easily on a PC and drop them to SD card, ability to swap SD cards over to support different “word packs” for the game)


Steve has already got a WaveShield and demonstrated its potential with his working cube game prototype shown in his blog.


So all the pointers say this approach has potential...


Something I noticed is that the WaveShield is resource-heavy. I breadboarded up the circuit and found that I could not run it with an ATMega168 but needed to swap for a 328 after which it ran fine. Depending on what type of sensing and other outputs we use on this project (and how much they load the MCU) I thought we might end up needing a dedicated MCU to run the sound part.


Well maybe we won't, but its good to be prepared, so I am working towards building the full ATMega328 + WaveShield circuit on a single board. Using SMD components I should be able to get it nice and small so it can be tucked into whatever game hardware we come up with.


A second “brain” MCU would be able to communicate with the sound board using the serial interface to trigger sounds and fetch additional information from the SD card.


We'd still have the option to use only the MCU on the sound board to control everything if we can get away with it.


So next steps are


  1. Get some clean recordings of phonics set and sample target words

  2. Come up with some scheme for cataloguing the target words against the phonics that make them up, via some text file on the SD card.

  3. Experiment with “blending” recorded phonics together via the AF_Wave library to see how well it works

  4. Check out the load on the MCU to see if we need another to control the game and, if so, come up with a serial protocol for the two MCUs to communicate.

  5. Build the board


This still leaves the possibility of using Android text-to-speech (or something similar). While this will probably sound good, it seems a bit of a cheat to use a smartphone (rather like using a laptop) but I could certainly be convinced otherwise, especially if we can find some way to run the software on a more hacked-together hardware platform

BuildBrighton has been a hive of activity for the past week, with members heading off to prototype their chosen parts of project. Here's what we said we'd do in the first blog post:

  • Toby   
    • Manage the project, making sure we meet our deadlines and targets.
    • Input: Investigate RFID, and multiplexing RFID antennae
  • Ben         
    • Input: Physical input devices, e.g. punch cards, switches etc
  • Chris and Ben         
    • Input: Look at re-purposing their cube-input project for the challenge
  • Mike        
    • Output: Android text to speech API
    • Output: Android device screen as an output
  • Barney         
    • Input: Colour sensing
    • Input: barcodes
    • Input: UV binary dots
  • Jason         
    • Output: Speakjet voice synthesis chip
    • Output: Waveshield or similar for sample-based speech output
  • Matt      
    • Input: Reverse engineering existing similar toys (he likes taking things apart)

    • Output: Implementing voice synthesis on commodity (cheap) microcontrollers

Now, due to an administrative error I'd completely forgotten to add Steve (pinter75) to the list. He was planning to investigate magnets and resistance as an input method and play around with a waveshield as a means of output.


Here's how we all got on:


The past week I've been reading up on RFID, how it works (which will be a separate post soon), circuits others have devised in order to read RFID chips and ways of making multple readers cheap. One of the ways I was looking at was using a multiplexer in order to connect multiple antennas to a single reader circuit. Turns out it's really hard when you're not very good at electronics. First thing I did was attach a DIY antenna to the USB RFID reader I already had lying around (there's a video of it working here). That worked fine, and made me think that the rest of the RFID stuff was easy too. Wrong. After the success of the antenna, I thought I'd try and hook up two antennas through a 4051 analogue multiplexer4051 analogue multiplexer and see if it still worked. It didn't. I spent quite a while tring to figure out what was going on, and I think it was something to do with the mux adding a small amount of resistance into the carrier signal, dropping the voltage on the coil. Either way, a USB RFID reader isn't very easy to interface to so I thought I'd build my own. How hard could it be?

Toby's un-square wave.

The circuit I based my design on was from this Cornell Uni project, which in turn was based on a Microchip reference design, a 125khz reader. The first hurdle was finding the very specific resistor values, which are almost impossible to source, quite a downer since one of the judging critera is how easy the parts are to find. For the 47.5k 1% resistor I just pulled out my trusty bag of 47k 5% resistors and tested 'em until I found one that was the right value. I did the same thing for the other odd values. Cheap resistors FTW! Once I'd sourced all the components I started to breadboard the reader, starting with the 125khz squarewave generator. Unfortunately this was my stumbling block, as I just couldn't get it to work. It just ended up as a ripple 3ish volt wobble, as you can see on the right.

Given the time constraints, I thought I'd give up on trying to build my own reader and just buy a pre-made one that was TTL friendly so we can integrate it with a microcontroller. I found a cheap reader on ebay for £8, so I bought two of 'em to play with. They've not turned up yet so in the mean time I'll be starting the interaction design of the system, so we have a better idea of what we're building over the next week. Part of the interaction design will be choosing which phonics and target words we need, which will also define what samples or speech we need in the system and how many slots we need in for phonics on our input device.


Ben & Chris

Ben and Chris continued developing their cube-tray input device, which gives each cube a unique ID by embedding a tiny PIC microcontroller inside. Using a particular arrangement of pins/pads on the cube, the tray can determine which face is down and the  orienation the cubes are positioned in. They made a lot of progress with their boards, and have a prototype 'exploded' cube working (i.e, the cube software and hardware work, but it's not cube shaped yet).

Chris has been documenting their efforts on a dedicated blog.


Mike started looking into Android development as a way of providing a voice output and a screen for displaying the picture of the target word. Unfortunately he only got as far as installing the SDK and running some of the examples as work commitments got in the way (boo, work ). There was a general concensus that using a smartphone for most of the brains would be cheating slightly anyway



Barney tagged a load of photo-sensors onto my RFID order from Farnell, he's got some full-spectrum phototransistorsfull-spectrum phototransistors, infra-red phototransistorsinfra-red phototransistors and ambient light sensorsambient light sensors. Some progress has been made, varying the intensity of an LED according to the ambient light, however we don't yet have a working prototype of reading several bits of data using optical sensors.



Jason had the Speakjet chip up and running very quickly, and we played around with it trying to get it to say various words. The synthesis on it is pretty robotic however, which may be a showstopper for this particular use since the speech output needs to be very clear as we're trying to teach kids how to talk. We don't want them to end up talking like robots. Well, maybe WE do, but most parents wouldn't.


As planned, Matt went to a toy-shop to find similar products that are already on the market. He bought himself a Phonics Owl and proceeded to tear it apart to figure out what made it tick, or indeed talk.

He's already written up his findings in another blog post.



Steve's auto-ejecting block mechanism.

Even though I'd missed him off the list of team members, Steve has been hard at work prototyping an input system using magnets and resistors. The magnets stop you putting the blocks in the wrong way round as they're polarised, the also act as electrical contacts. Between the magnets there are various resistor values that allow him to tell which side of which block is connected to the device. He's also written up his prototyping in a couple of different blog posts which include some awesome videos of his laser cutter in action!


Next steps

Over the next week we'll be pulling together our input and output modules, glueing them together with a microcontroller and implementing our control layer according to the interaction design I'm working on right now. I'll post another entry about the interaction design of the phonics toy soon too.

Also, we'll be thinking of a name for it, other than 'phonics toy'.



In the previous blog post I mentioned that the cubes can be auto ejected. This is after the child has sucessfully spelt the word that was requested, so they can move onto the next one without manually removing the cubes.


It uses a simple servo mechanism that you can see in the video. Basically the servo pushes a bar and this in turn presses some dowls that enter the cube socket and push the cube out. The dowls are returned using springs. This could be done manually via a lever rather than servo, but having it automatic makes it cool.


The video:



Works nicely :-)



From the talks we had about the challenge last Thursday, I have designed a simple cube reader that does not require any fancy tech.


Here is what it uses.


  • Arduino MEGA
  • Adafruit WaveShield
  • Magnets
  • Resistors
  • Lasercut enclosures


Here is how it works.


Cubes contain resistors on each face. These are soldered to magnets which are orientated on their sides and poke through slits in the cube face. This prevents them from falling out of the cube and causuing a hazard.


The cube readers simply contain 2 more magnets with wires that head off to the Arduino.


The magnets polarity on each face is oriented the same way, same on the reader. This means that we get a simple method of rejecting cubes inserted upside down - the magnets repel :-)


The reason for using magnets is that is gives a nice tactile feedback that the cube is placed correctly. It also means we get a strong connection.


The Arduino has a simple voltage divider leadng to an analog pin. The code scans each reader in turn looking for a change in value from 0. When it detects a value withing a buffer range it drags the required .wav from the SD card and plays it. At the moment I am using boggo +/- 5% resistors on the divider. These will have to go to precision resistors for all 7 cubes.


That is it, costs peanuts and is very simple. There may be environmental issues to deal with regarding dirty magnets. For a proof of concepet it works well.


Also in this design are eject holes. These are for small pusher dowels connected to a servo. After the child has successfully spelt their word, the system will eject all cubes automatically. The cubes will disengage from the magnet coupling and fall down the angled reader base.


A quick video.

Shows the cube reader in action, and a bit of laser cutting of the cubes.




Pinter75 :-)


Phonics Owl

Posted by talkingjazz Mar 26, 2011

Following on from Thursdays meet-up, as often happens I started looking at toys. The Early Learning Centre has a selection of phonics (keyword, not necessarily  actually phonics) related educational items, including a few electronic ones. Goodie.


I was upset and distressed to find that the Peppa Pig's Fun Phonics was not in stock. They did however have an exciting looking Phonics owl which appeared to contain quite a few similarities to what we were talking about on the Thursday meet-up. It also had a little toy owl on it!

The box had pictures of the cards that came with it which appeared to be all time same shape, size and colour with no visible contacts. Score.... something with contact-less ID's. Lets see how other people approached this commercially.


So anyway.... here's the Phonics owl thing:


001 - Box.png

It was also avialable with a little bear.... but owl's are way cooler. Here's the back of the box:

002 - Box Back.jpg

So this thing has 2 modes, and comes with 17 pairs of cards. Not sure yet if the pairs are the same, or unique (is the Apple card the same as the A card - or are they unique?)


On with the action, lets get it out and start playing:


003 - Set.jpg


First thing I noticed is the cards are actually card (sounds a little silly I know). They all have light blue backs and are indeed all the same shape. Putting some screws on the back , they do not stick. So if there are any magnets in there, they are very week. The base of the recess for the cards in the base unit is also made of card, ooo, probably a reason for that not being made out of plastic. More than likely a plastic base would have been too thick for doing whatever is going on here.


Les have a play:


004 - Assembled.jpg

Quite nice. When you pop in the cards the base reads out either the letter "The Letter A", or the word "Apple". When you put in a matching pair you get a nice little jingle and a "Correct". When it misreads a card (which happens if you only half insert the card it tells you to remove the card, insert a card or something else. The message it gives seems a little random between cards. No doubt related to the mechanism behind the card reading.


I was also happy to see there is no problem with putting the cards in the other way round (Apple in the first slot, A in the second).


So, there is a minimum of 34 unique cards (17 * 2, as it knows the difference between letters and words). So at lease 6 bit assuming there is some kind of digital reading going on. It could still be analogue, but that seems unlikely.


Here's a little video of it in action:



Nice, the unit seems to work pretty well. The cards a a little tricky to get out though. Again, possibly related to the reading system.


So then... how is it reading these cards. Before opening it up I decided to have a bit more of a play with it. Look what happens when you put on more than one card at once on the same space...



Interesting.... if you put more than one card on the unit at once, it reads something that's not either of the cards. And you can place the correct answer in the second slot and it tells you it's the correct answer. Further to this, it doesn't work with all cards. Some cards will read off just one of the cards you put down. Using more than one card, you can place one of the cards in the wrong way round and still get a valid read (something you cannot do normally).


So, now I'm figuring we are looking at some kind of capacitive reading system. As there are 34 possible cards (6 bit) and the system knows if a card is the wrong way round... a system that can be fooled SOMETIMES, by having one the correct way, and one the incorrect way... We must surely be looking at 7 bit, EITHER where the 7th bit is used for orientation checking, OR the capacitive sensors are positioned so that they do not line up when in the wrong way. I'm putting my money on the first option, as the system will give the different reads with cards the wrong way in.


Just before I started to open up the thing, I accidentally knocked some stuff off a shelf and on to the reader. What a spot of luck, it started saying stuff. So we have discovered you can cause reads to happen by placing something metallic on the reader in certain positions. See below.


008 - Blade on Reader.jpg

By moving the knife blade around I was able to generate a few dufferent cards (both letters and words). Before opening up the device I decided to open up a card and see what makes it tick.


009 - Open Card.jpg


Just as expected, there some conductive material in the cards. This card no longer works as some of the black conductor got ripped off and there is no longer any connection in parts. Where there is a connection the material seems to have a resistance of 2k/mm. Don't have a conductive pen so can't play with making my own cards quite yet. But this does confirm some of the operation of the cards and readers. And why it works when you stack cards on top of each other.


Anyway... lets get this thing open.


010 - Opened Up Top Side.jpg


First thing to note is the large number of inductors on the top side of the board. There are 8 of the larger through hole ones, 8 transistors, 8 diodes, and 8 pairs of wires going to the board attached to the reading area. There are also a couple of 22u caps and 4 more inductors on this side. They don't appear to be connected directly to the sensor part of the device.


The mode is also set through the power switch. The mode of operation is configured through the green and orange wires marked P23 & J1-2 on the PCB.


Also notable in the above picture is the leads going to the sensor board on the left. They are short, but covered in sleeving and heatshrink. May well be that these leads are shielded to prevent interference.


Lets crack on...


011 - Opened Up Bottom Side.jpg


Looking at the bottom of the board we can see the speaker. Following the traces we can see that some of those extra inductors are used as part of the audio output system. Other than a couple of passives, the speaker is connected to the larger chip marked U3.


The smaller blob on the back which is unmarked has traces leading from the power input, and has the other inductors connected to it. Some kind of switch-mode supply one would assume (the device runs on 3x AA's).


There are also 2 LM324 Quad op-amp's in the surface mount packages. There are some connections to the 8 leads going from the sensor board to these chips. So these must be used to amplify the output from the sensor board.


012 - Opened Up Sensor Board.jpg


And there we go. Each redder has 8 pads on it. Looking at the card we took apart earlier, and testing a few more connections using foil, the centre is common and connected (via the cards) to each of the outer pads. Each of the outer pads is connected between the two readers.


One interesting thing here is lower middle left and right pads. These are the only 2 that are not symmetrical. Instead the 2 inner pads are connected. Perhaps it is this that stops cards being inserted in the wrong way round (via means of a calculate-able checksum perhaps). The card we took apart earlier does have a connection to one of these pads. If you replicate the other connection on this card on the left hand reader (where the other pad would not be used), it works file. However when you do the same on the right hand reader it will not work. Interesting....


What's next?


What ELC have done here is very interesting. It appears to be very reliable. Cards are very easy and cheap to create. There is not too much hardware involved in reading the input cards. And it's all kept well away from the user.


Might have a play with getting something like this up and running.


Mitch teaching people to solder at BuildBrighton, photo by Barney

A Letter From Mitch

Sunday evening we received word from  Mitch Altman that we, along with 30 other hackerspaces, had been  accepted into the Great Global Hackerspace Challenge. If you don't know  what it's all about, check out the hackerspace challenge group. On hearing about our acceptance into the challenge we decided to meet  up as soon as possible to discuss ideas for the our project. A few of us  met Monday lunchtime in a pub called The Hampton and started throwing  ideas around.

We started out trying to understand the requirements:

  • Your hackerspace will create a project to help with education, using  US$900 (or equivalent) provided by Element14
  • Must use a  microcontroller
  • Must use a portable power source
  • You have 6 weeks to complete your project


Firstly  we discussed what constitutes education, it could be anything from  drooling pre-school toddlers to spotty, disinterested teenagers or even  post-graduates. Education doesn't even stop when you pass your twenties,  there's plenty of higher-education institutions and courses being run  all the time.

I personally shied away from suggesting we aim our  project at children anywhere below 16, as there are lots of safety  concerns to take into account and environmental factors to consider when  designing your hardware. For example, if you're using hi-strength  neodymium magnets you want to be damn sure they're not going to fall out  of your invention and get swallowed by kids. They can snap together  inside a person and cause all sorts of unspeakable mischief. Less  dangerous, but still important, is the fact that any contacts, switches  or wires you have will get covered in grubby, sticky... whatever it is  kids are covered in. And does anyone know what the resistance of that  substance is? Nope, me neither.

However on the plus side, there's a  lot to teach kids. They've not been around for long, and their brains  are like information sponges waiting to absorb knowledge. Also, between  our members we have contacts in schools and education, and we've already  run a succesful project helping kids visualise data they collected by  attaching arduinos to their shoes (it was called Data Steps).

Jason,  one of our newest members, suggested some sort of device to help kids  learn Phonics. For those who have no idea what Phonics is, which  included me a few days ago, it's a way of teaching English to kids by  letting them learn the sounds that particular letters and groups of  letters make. There's a much better explanation on Wikipedia,  as usual. After much googling and discussion, we decided that this  sounded pretty cool and started thinking of ways to teach it to kids in  the 5-8 year-old range. The ideas ranged from a speak-and-spell like  device to something more akin to traditional Alphabet Blocks. These ideas started to converge, and our current plan is to make a device whereby the kid has a 'target' word shown to them as a picture, e.g.  'Cat'. They have to find the right phonics and put them in the right  order to make the device say 'Cat'.

Why Phonics?

Phonics is used in many schools across the UK and America to teach children how to speak and spell English. It's also used the world over to teach English as a second language. Phonics has been widely debated in the US congress and is generally accepted as an effective way to teach early reading skills. As recently as November 2010, the UK government has announced plans to train all primary school teachers in the use of phonics.

Anecdotally, lots of people we've spoken to have said that tools for teaching phonics are a bit basic, usually consisting of flash-cards or DVDs. There are some electronics based toys on the market, but most of them just use fixed buttons as an input. We think that using a more tactile input method would engage younger children better and aid their learning.


Our plan of allowing kids to choose phonics and have them spoken by our device allows us to split the design up into several layers:

  • Input - the phonics chosen by the kids and the target word they are going to spell out.
  • Control - the logic that controls the input and output, detecting what phonics have been placed down and giving the kids feedback.
  • Output - speech synthesis, a sampled audio player or some other indication of whether your phonics are correct.

This means that we can prototype the input and output methods separately, and split up in order to try out different ideas in parallel.


Ben very helpfully put together a brainstorm of various input methods we've been discussing along with their pros and cons (click the images for larger versions):

Input method.png

... and a block diagram explaining the layered architecture and possible implementations at each level of the device:


Thursday Meetup

At BuildBrighton, Thursday evenings are our social meetup night and we decided to use it for our first proper planning session. To kick off, we went over the requirements of the project again just in case anyone at the space wasn't up to speed yet. We went on to discuss how to split up tasks and agree to report back the same time the next week. Here's how the tasks were distributed:

  • Toby  
    • Manage the project, making sure we meet our deadlines and targets.
    • Input: Investigate RFID, and multiplexing RFID antennae
  • Ben  
    • Input: Physical input devices, e.g. punch cards, switches etc
  • Chris and Ben  
    • Input: Look at re-purposing their cube-input project for the challenge
  • Mike  
    • Output: Android text to speech API
    • Output: Android device screen as an output
  • Barney  
    • Input: Colour sensing
    • Input: barcodes
    • Input: UV binary dots
  • Jason  
    • Output: Speakjet voice synthesis chip
    • Output: Waveshield or similar for sample-based speech output
  • Matt  
    • Input: Reverse engineering existing similar toys (he likes taking things apart)

    • Output: Implementing voice synthesis on commodity (cheap) microcontrollers


Other members have offered hardware, advice and time to help out everyone who's been given specific tasks, many thanks to everyone who's getting involved, it's looking like this is going to be a great project!

The prototyping starts

Later that night...


Toby starts making RFID antennae and trying to wire them up through a multiplexer. The antenna works, but for some reason it's not getting through the multiplexer:


Jason sets up his Speakjet chip and gets it talking to his laptop over serial:


Next time...

By the next blog post, we should be able to report back on all our prototyped input and output devices. We'll post pros and cons for each and narrow the field down to two input devices and two output devices. The chosen input and output methods will be refined further and we'll decide on which ones to actually use.


In the mean time, we'll also be researching how phonics is used in schools currently and how the control system needs to work in order to most effectively teach kids how to talk.