Saturday, August 31, 2013

Using Sox spectrogram tool to analyze audio noise

While out on a walk near Lagos (Algarve, south Portugal) I noticed a loud buzzing/crackling sound. It sounded very similar to the kind of buzz/crackle you'd hear near high voltage transmission lines, but there was no power lines in sight. So I though I'd capture a few seconds of audio with a voice recorder app on my phone and look at the spectrum later to rule in/out an electrical origin: any thing electrical would have peaks at exactly 50Hz and harmonics of 50Hz.
It turns out that sox has a neat tool to create a spectrogram from any audio file:

sox recording.wav -n spectrogram -o spectrum.png

However the frequencies I was interested in were down well under 1kHz, so I first resampled at a rate twice the highest frequency of interest:

sox recording.wav -r 2k -o t.wav
sox t.wav -n spectrogram -o spectrum.png

So this is the result:

The buzz sound can be seen in the spectrograph as horizontal streaks at about 60Hz and 120Hz. Not being exactly 50Hz rules out an electrical origin. The frequency can also be seen to vary a little with time.

Here is a spectrogram of another recording I took on the way down to the beach later. There was multiple sources in this recording (audio file here) but fainter/further away.

and other (audio file here):

You can see multiple horizontal streaks  of varying frequencies.


It's clear now the noise is from an insect. What insect, I have no idea. (Update: I think it might be Cicada)

If puzzled about the origin of a strange sound, record it and create a spectrogram... it might yield clues. Anything relating to utility power will be at the AC frequency (50Hz most of the world, 60Hz US).

Wednesday, August 28, 2013

LPC800 Mini Kit sous vide cooking controller


This project uses a LPC800 Mini Kit evaluation board as a sous vide cooking controller together with a DS18B20 temperature sensor and a modified timer unit and a rice cooker. A simple user interface (using just one microswitch and one LED) allows the user to select a set temperature. PID control and other techniques are used to heat and maintain water at the set temperature. An optional computer attached via a serial port captures debugging and temperature logging data. The firmeware source is open source and is available on GitHib. A video overview of the project is here.


NXP sent a free LPC800 Mini Kit board a few weeks ago.  As part of the promotion they are running a "LPC800 simplicity challenge"... for weird and wacky apps using the LPC810 (open until end August 2013). This is my entry for this competition.

The LPC810 comes in a 8 pin DIP package of which two pins are reserved for power and ground. It costs about $1 in single quantities and that price drops to less than half in large quantities. The LPC800 Mini Kit board features this LPC810 but also a side connector for a serial port, two micro switches and a blue LED as well as some prototyping space.

I've been experimenting with sous vide cooking recently. This is cooking technique were meats and vegetables are sealed in a vacuum packed bag and slow-cooked in a bath of hot water at a very carefully controlled temperature. In this application temperature accuracy and control is paramount. For example: when cooking beef steak, the difference between a rare and a well done steak is just 5°C (10°F) (from 55°C to 60°C). Moreover if the water temperature is under 50°C (120°F) bacteria can multiply raising food safety risks.

Any appliance that heats water electrically can (in theory) be converted into a sous vide cooker. My choice was a 400W rice cooker which was on special at Lidl a few weeks ago (for €20?). The sous vide controller measures the temperature of the water and toggles the state of the heating element to precisely (and accurately) control the water temperature.

I used a hacked mains timer unit for the element control. I removed the user interface components of the device and broke out the low voltage relay control line. I've written about this in a previous blog post. For electrical safety I electrically isolated this with a Lite-On LTV-817S opto-isolator.

My first attempt at water proofing a DS18B20
temperature sensor.
For temperature sensing I used a DS18B20 digital temperature sensor. This is a three lead device (TO-92 package) which requires just one digital IO line to operate (the other to leads are for power and ground). The choice of a digital sensor avoids the need for analog to digital conversion (the LPC810 has no regular ADC capability). Water proofed probes using this sensor exist and I have one on order, but I'm not expecting it to arrive for a few weeks. So I improvised my own water proofed probe.

My first attempt involved a small section of PVC tubing. I injected silicon bathroom sealant into about 5cm (2 inch) of tube and then shoved in the sensor soldered to a 1 meter length of cabling. It's important that all the exposed metal is enclosed in the sealant. Failure to do so will result in the rapid corrosion of the sensors leads due to electro-chemical effects and a failure of the sensor in a matter of hours.

The water proofing worked, but the performance was terrible. Its performance was measured by allowing the sensor to cool to room temperature and then dunking it in hot water. The resulting exponential curve as a result of the step function of being dropped into water reveals the sensors 'time constant'. Using curve fitting this was found to be 67 seconds.

My second attempt at making a water proof DS18B20 involved soldering it to 3 wires of ribbon cable, then dunking that into a tube of silicone sealant so that the sensor and the exposed metal was well covered. I cut of the sealant at the very top of the sensor so that the top of the DS18B20 package was exposed directly to water. This worked much better with step time constant of just 13 seconds.

User interface

I was very limited in what I can do for the user interface (UI)  because the LPC800 Mini Kit has just one user LED (blue) and two microswitch. One switch I need for reset,  so that leaves just one switch and LED available. I could of course add extra hardware communicating SPI or I2C, but for this challenge I wanted to restrict myself to only the hardware available on the LPC800 Mini Kit. Also with just 4kBytes of program memory, there is little space to implement a complicated UI.

My temperature range of interest is from 55°C to 60°C for cooking beef steak. So I took advantage of that narrow range in the UI design. The operation is actually quite simple: After reset the user presses the switch marked "ISP" once for each degree over 54°C. So, for example, for a set temperature of 57°C three button presses are required. After a brief pause the LED will blink back the selection.

At any time during normal operation the user can query the temperature of the water by pressing the ISP button. The temperature will be read back by blinking the LED. There will be two sets of blinks with a pause between them. The first set reads out the temperature and the second set the units. So 54°C will be 5 blinks, pause, then 4 blinks. A zero digit is represented by one very short blink.

Temperature Logging

Debugging information and temperature logging data is sent using the LPC810's built in UART (serial port). An optional connected computer can then be used to chart the data in real time. The serial port is also used to re-flash the firmware. Temperature can be charted using gnuplot using a simple script like this: [insert]

Temperature Control Algorithm

This is still a work in progress. PID (proportional, integral, differential) control is usually used in these applications. However I found that it was difficult to avoid an initial overshoot. So I started to experiment with a two-phase approach. The first phase is the warm up: a test heating with the element on for 90 seconds and measuring the temperature change as result of this. The remaining time can then be calculated to bring the water right up to temperature. The second phase hands over control to a PID algorithm.

An interesting limitation of the Cortex M0 / M0+ MCUs is the lack of hardware floating point support. With just 4kBytes of program memory linking in float point library is not an option.  So I've used fixed point to implement the control algorithm.

The firmware

I'm using LPCXpresso, although the code can also be compiled with the GCC ARM compiler for bare metal systems. The firmware is open source and is available here: It compiles to about 4kBytes, unfortunately leaving very little room for enhancement.

Power requirements

So far I've been using the serial cable linking it to the laptop to power the controller. However this could easily work off a battery.  The ARM Cortext M0+ is designed for super low power applications and in this application the unit spends much of it's time idle. The UI requires practically no power at all (the odd LED blink).  In the program space available I've attempted to apply simple measures to reduce power consumption. For example all timing, delays etc is accomplished with the SysTick timer and anytime the program needs to wait for an event I invoke the WFI (wait for interrupt) instruction. I am not using deep sleep / power down modes at this time.


The LPC800 Mini Kit makes a successful sous vide cooker controller. The user interface is basic but is simple to use and understand. There is just enough program space and plenty of SRAM to implement the UI, control loop and serial port logging.

Project risk assessment and disclaimer

There are two risks to be aware of if attempting a similar project: first there is a potential shock hazard in designing a switching unit to control the heating element. The second is a food safety: cooking meats at too low temperature (<50°C) will result in bacteria growth and can cause food poisoning. There are many of sources of information on sous vide cooking on the internet so do your research! I would recommend validating the set temperature with a second thermometer until the firmware has proved reliable. If you undertake this project, I take no responsibility for your actions.

Friday, August 2, 2013

Silvercrest (Lidl) TwinTalker 4810 446MHz PMR radio teardown

I picked up these  "Silvercrest" (Lidl) brand TwinTalker 4810 446MHz PMR (private mobile radio) which are on special at Lidl right now. ("Silvercrest" is a Lidl own brand,  Topcom is the manufacturer of this device).

This PMR set peaked my interest because of the external mic/headphone socket. I have the idea that perhaps these could be adapted to packet radio without any need to hack the hardware (I find these radios handy on occasion, so I'd prefer to also keep them functional as walkie-talkies).

There was a time when devices like this came with full schematics and a service manual. Sadly, nowadays, you have to figure out everything for yourself (unless someone else already has!).

Opening it doesn't take much effort. Two screws in the battery compartment and two screws covered by rubber bungs near the top.

The first thing I noticed was the 56 pin SOIC IC at the bottom of the board. This is a Matsushita AN29160AA transceiver chip which deals with most of the radio protocols details. Excerpt from the datasheet:

"AN29160AA is IC for Transceiver. One package involve four systems about IF, PLL, Regulator, and AF. Involving 1st IFamp, 2nd Mixer, 2nd IFamp, FM-Detector, 460MHz PLL, Regulator for RXRF/ TXRF/ VCO/ MCU, OPAMPs for filter and Speaker Amplifier."

Also on that side of the PCB is a Z324 quad low power op-amps IC,  and a 2kBit K24C02C serial EEPROM which I guess is used to preserve radio settings across power cycles. The radio module and RF power amp is in a metal can along the edge of the PCB (bottom of photo above).

To view the underside of the PCB, I found that I needed to remove a blob of glue which fixed the helical antenna to the case. I was then able to pry up the PCB enough to take photos. (To remove it fully I would have had to snip the speaker wires, and I wasn't bothered enough to do that).

On the underside there is the LCD in a metal case. I assume the MCU is also in that area. There are pads for the user interface rubber buttons. Next to the button pads is a test pad which could be used to solder a breakout wire. As I want to keep this functional, I'm not going to tear down any further... besides from experience, there isn't much that can be done with the MCUs on consumer devices. The test pad labeled "TX MOD" does make me curious though...

Best I can tell the CFWM 450HT is related to driving the peizzo speaker. Next to that a crystal can marked 21.7 (MHz?). The marking on the speaker is "JW 16Ω 0.5W".

The supplied headphones use a 3 pole 2.5mm audio plug and comprise a single ear piece and a pod with a mic/push-to-talk button.

Best I can tell so far: the plug tip is for the mic and push-to-talk switch and floats at about 2.4V, the middle ring of the plug is audio out for the ear piece. When no transmission is received it's at 0V, when a transmission is received it jumps to 2.2V with the audio signal superimposed. Last ring is ground.

Measuring the resistance of the mic line of the headset to ground I see that the resistance is 3k when the PTT switch is open and drops to 1.1k when the PTT switch is pressed/closed.

Update (1 Aug 2014): I got back to looking at interfacing this PMR to a microcontroller and took another look at the headset interface (the 3 pole 2.5mm jack socket at the top).  I shall refer to the 3 lines as Tip, Middle and Sleeve.  I still haven't figured it all out yet, but these are various measurements I've taken while the headset is connected.

  • Tip-Sleeve resistance with PTT switch off: 2.9k
  • Tip-Sleeve resistance with PTT switch pressed (on): 1k
  • Middle-Sleeve resistance: 36 ohms (PTT switch has no effect)
  • Tip-Middle resistance with PTT switch off: 2.8k
  • Tip-Middle resistance with PTT switch pressed (on): 1.1k
  • Voltage of Tip relative to Sleeve with PTT switch off: 2.45V
  • Voltage of Tip relative to Sleeve with PTT switch on: 1.25V
  • Voltage of Middle relative to Sleeve with nothing being received: 0V
  • Voltage of Middle relative to Sleeve when receiving: 2.0V with audio out overlayed.

I also verified that shorting Tip to Sleeve via a 1.8k resistor will cause the unit to 'key up' and transmit (this was done with the headset disconnected). I found that the value of resistor is important. a 1k would cause the unit to only key up momentarily: the 1k resistor caused the Tip voltage to drop to about 0.9V which I guess is too low.

Here is scope trace from Middle (relative to Sleeve) when I key up and release. The waveform is the end-of-transmission bleep.

So in summary:

  • Sleeve is ground.
  • I can detect if there is an incoming signal by looking at the Middle DC offset. A value of about 2.5V indicates reception in progress. The AC part of the Middle is the received audio. Audio peak-to-peak voltage is about 1.5V at full volume.
  • I can cause the unit to transmit by dropping the Tip voltage to about 1.25V (eg shorting through a 1.8k resistor)
  • Still to do: interfacing a MCU DAC output to the audio in.
I'll update as I find out more.