Wednesday, November 26, 2014

Attempting to Determine How Audio Data is Stored in Flash Memory

You may have seen that I've recently been analysing a toy that plays animal sounds.  It's nothing complicated, it just plays one of 108 stored sounds when a collector card is scanned though an optical interface.  For some reason I thought it would be fun to see if I could replace the audio data with my own sounds.  From what I can tell, the data is stored in a 2 MiB flash memory IC on the PCB, I'm 99% sure it doesn't hold program memory.  2 MiB is way too much for such a simple task.  Besides, that amount of memory seems the perfect amount to store the sounds the player uses.

To examine the memory I'd have to get a programming adapter to download the contents of the chip.  I did a quick search of ebay and found the EZP2010 for $40.  I know what you're saying, "there are cheaper options available", and although that's true, this had a few things going for it.  It had a faster delivery, but most importantly it came with ZIF SOIC to DIL adapters, which turn a 30 minute job into a 30 second job.

Memory Programmer
EZP2010 Memory  Programmer
After stuffing around for an hour trying to set-up drivers, I finally got the programmer installed.  There isn't much to it, but it does the job.  It has the ability to copy chips as a standalone device not connected to a computer, but as I didn't need that I didn't bother testing it.

Memory Programmer
Device Under test in DIL ZIF socket
To read the memory of the IC it was removed from the PCB with a hot air gun and placed in the SOIC ZIF adapter.  Having these made the task so much easier.

Memory Programmer
Device Under Test in SOIC ZIF scoket to DIL adapter
There's a bit of confusion over what chip I'm actually trying to read.  The image below indicates that the Chip is a 25L1605D, but the programmer detects it as a 25L1635D.  Both have the same memory capacity and both give the same results when used as a setting to read the data form the memory.

Flash Memory IC
Flash Memory IC
Once you have the software set-up it's idiot proof.  Put the IC into the socket as shown in the diagram, detect device or configure it manually, then hit the read button.

HexDump
Flash Programmer Software
I tried playing the recovered data as audio by importing it as different types of raw data in Audacity and Goldwave, but each time all I got was static.  It would've been unlikely to get the exact format, but I was hoping for some type of recognisable distortion that would help to reveal the nature of the data to me.  No such luck.

I expect to see an area to tell the device how many sounds are in memory and something like a lookup table to indicate the location of each sound byte.

My goal is to see if I can determine the structure of the data, and as a first quick test I checked out the data using the histogram function of HxD.  As you can see from the image below, apart from the spike in the centre, all the bytes seem to be evenly distributed.  Not what I was wanting to see.  It's not a certainty, but If you see an even distribution of bytes it indicates encryption or compression has been used.  I was a little excited to see the spike in the middle though.

Histogram
Byte Histogram of recovered Data
That excitement was short lived.  It turns out that there is a large block of unused memory at the end of the file containing the character 0x80

HexDump
Repeated 0x80 at end of file
To get a better idea of what I'm looking for, I had a look through digikey to find a sound playing IC that could be similar to what's used in this toy.  There's no way to know what device has been used as it's a chip on board device, but chip manufactures like to compete on features, and if it's in one companies IC there's a good chance that it's in the others too.

The cheapest device I found was a ISD3800 chip corder and a quick look at the data sheet gives us some important insights.  It supports the type of memory that our toy uses, and shows some of the audio compression algorithms that could be used.  The algorithms used may not observe byte boundaries i.e. 2,3,4,5,6,7,8, 10, 12 bit samples.

DataSheet
ISD3800 sound player IC data
For more analysis the data was opened in Audacity with the spectrograph view turned on.  There are three distinct features visible here.  Two vertical lines and a gap at the end.

Spectrogram
Spectrogram of Data when opened as a raw audio file in Audacity
Zooming in on the waveform at the first vertical line shows a couple of triangular shaped waveforms.

WaveForm
Interesting Section of Data in Audacity
The second vertical line indicates this descending step feature in the waveform.

WaveForm
Interesting Section of Data in Audacity
As seen before, the section at the end of the file is a grouping of the 0x80 byte, in this format interpreted as a zero.

WaveForm
Nothing at end of File
I follow +Oona Räisänen on twitter and have seen how useful baudline can be.  So I gave it a try.  I'm still learning the interface, but it will come in handy for a few other tests I want to run.  While in Linux I tried the data in binwalk but got absolutely nothing.  The entropy plot did show the regions noted above though.

Spectrogram
Baudline Interface
The bit view window turned out to be not so helpful,  the poincare plot was all black.  I'm not sure if I used it right, did I over saturate it and it just shows everything  as black.  I might do my own in octave.

Binary Data
Statistical Analysis of Data in Baudline
So where am I at?  I have more of an idea of what I'm looking for, but have no leads.  I have an SPI bus protocol analyser coming that will come in handy.  I can play one sound and record what memory addresses it accesses and what data is returned, for some reason they may not use a sequential addressing system. The rate it does this could also reveal that a variable bit rate compression algorithm was used.

To sum up, I don't like my chances, but it's a fun cat and mouse game.  I'm learning some new techniques, while solving a challenging puzzle.













Saturday, November 15, 2014

How a Collector Card Sound Player Works

Today I'm going to have a bit of fun.  Once again the local supermarket has released a set of cards with pictures of animals on them for children to collect.  I've written about certain mathematical aspects of these promotions before.


This time they've added an extra feature to the cards, when swiped through an electronic device, that's also for sale, the sound of the animal on the card is played back for the collector.  In this post I'll give a quick explanation of how the device works.

The cards come in a sealed pack of 4 so people can't pick and choose what ones they'll get, it's a random draw.  They do however have a bar code printed on the back that allows the sound player to know what card it is, and what corresponding animal sound to play.

Collector Cards
Sealed Animal Collector Card Pack
The device that reads the barcode from the card and plays the appropriate sound is a simple mass produced device that seems to be rugged and reasonably well built for a six dollar product.

Card Reader
Card Reader
I posted a rather quick teardown of the reader as soon as I bought it.  It's not very detailed but it gives you an idea of how It works, and will make the rest of the details make more sense.


The internal construction is what you'd expect from a high volume low price device.  I estimate that they probably had somewhere around 100,000 of these readers made, so it's no surprise to see a chip on board solution on a single sided PCB of medium quality.  It comes with three no name AAA batteries.  I haven't probed the board, but I can't see any voltage regulation. There's a bulk capacitor on the input and there could be a regulator under the black blob.

Electronics
Card Reader Construction
The barcode on the card is sensed by an optical reader that's located on a separate board over the swiping slot.  It's held in place by plastic studs that are melted once it's installed.  The reader seems to consist of an infra red LED and an optical sensor like a photo-diode.  As the card is drawn through the slot under the reader, the amount of light reflected from the barcode changes and can be detected.  This is how the barcode is read and the reader know what sound to play.

Card Reader
Reader Slot

PCB
Active Optical Sensor
The part I'm most interested in is the 8 pin SOIC package on the board.  It appears to be a Macronix MX25L1605D 16 Mib flash memory IC and is the most likely place to store the sounds played by the device.   I'm curious as to how the data is stored on it.  There are 108 cards and each card seems to have a unique sound, this means that there are 155 kb for each sound. If we assume a worst case scenario of 4 bit audio (It's a pretty average speaker, any more bits and you'd be wasting them), that means there are about 38 k samples per audio clip.  Clips last around 4 seconds so that would mean about 10 k samples per second.  Due to Nyquist, this would limit the maximum frequency to 5 kHz.  This is a possibility, but I'd really like to get the data off the chip and see for myself.  While I'm there I'd also like to know if I could reprogram it and maybe put different audio on it.  This post was originally going to be an attempt to do that, but the flash memory reader I ordered hasn't arrived yet.  Oh well.

PCB
Sound Card Reader/Player Circuit Board
In the meantime, if you want to impress your friends (NOTE:  if you think this will impress your friends you probably don't have any) you can show them how to read the barcodes on the back of the card to identify the number inside.

The barcode is simple binary and is made up of 13 bits.  Each bit is made of a black bar and a white bar.  If the bit is a one, the symbol will be a black bar 2 units wide followed by a white bar 1 unit wide.  If the bit is a zero, the symbol will be a black bar 1 unit wide followed by a white bar 2 units wide.  To put it simply, thin black bar = 0, wide black bar = 1.

After looking at a few cards it was obvious the last bit was always one.  Those of you familiar with serial communication will be comfortable with me calling it a stop bit.  I initially couldn't tell what the next two bits were, but it became clear that the rest of the code was the number of the card in binary.  Once again drawing on my experience with serial communication I assumed that the two bits I didn't understand were parity bits.  A pattern started to emerge, if there were an even number of wide black bars in the code these bits would be 01, if there were an odd number of wide black bars, the parity bits would be 10.

As some of the people reading this may not understand how to read binary, I've demonstrated in the image below how to easily read the code.  Starting at the bar 4th from the right, put the number 1 under it.  Under the bar 5th from the right, put the number 2, continue this pattern, doubling the number each time. i.e. 1, 2, 4, 8, 16, 32, 64, 128, 256, 1024. Once this is done you add the numbers under the wide bars together to get the number of the card.

Notes
Decoding the bar code on the cards
TADA!  Card number 108.

I've also included an ODS Spreadsheet you can use to generate your own barcodes.  Just change the number in the left column and the barcode will automatically generate for that number.

Animal Card
Animal Card

Tuesday, November 4, 2014

Mounting a Changeover Switch on a Generator Frame

Over the last month or so I've been intermittently working on adding a changeover switch to my grandmothers generator.  This will allow the battery to switched between a solar charger or the starter motor of the generator, and although it's not complete, it's 90% there and the interesting work work is all done.  Before I wrap things up you can catch up on my efforts so far in these couple of posts.

13/10/2014 Blade Switch Modification

24/10/2014 Blade Switch Modification - Part 2

The generator is a small backup unit to power fridges in the event of a power outage.  It's mounted on a steel frame with wheels that allows it to be easily moved.  Mounting the changeover switch on the frame is the easiest option that gives the best result.  The image below shows the general arrangement of the frame.  The switch is going to be mounted just above the electrical generator, in the image this is where the black and red cables are coming from.  It needs to connect to the battery in the black case on the ground, the solar charger mounted on the roof (cabling above to the right and not in frame), and the starter motor.   The starter motor connection point can be seen to the left near the yellow oil fill point on the motor.  Unfortunately I didn't have the cabling or the time to install it today, but it's a trivial task I'll complete in the near future.

Generator
Generator Frame Layout

This is the part of the project that really annoyed me.  Making a bracket to hold the switch.  I don't have the metal fabrication tools that are needed to do a professional job.  As usual I went to my fall back plan of finding a metal plate from the local hardware and making it do what I needed it to.

The plate below is just a standard joining plate used in the building industry.  I added five small holes to it.  The two on the left allow a saddle clamp to attach the plate to round tube on the frame, the bottom two holes allow metal screws to connect it to a rectangular tube, and the centre hole is the mounting point for the switch.  Two of these plates are needed, one for each side of the switch.


Bracket
Mounting Plate

The mounted switch can be seen in the highlighted section of the image below.  It's mounted on the left to keep it away from the motor exhaust.  I need to make a couple of cables to connect everything together, but the hard part is over.  I could have done things better, but when you're building something in one place and installing it in another, it makes things a little difficult.

By the way, if Santa happens to read this I could really do with a water jet cutter, press brake, and a milling machine.  Yeah, I'm aware how much that would cost, and yes it's a want not a need, but I've been reasonably good.

Generator
Mounted Switch