Case reuse

One of the project goal was to reuse as much of the original speakerphone case as possible, including the power switch, volume control potentiometer, front leds and keyboard. I though that as the box already contained amplifiers circuits for the speaker and the internal microphone, I could try to reuse those as well and design my project around them…

I first poked inside the existing circuit to find a way to simply insert my circuit in the amplifier paths. But I quickly realize I would use more time trying to reverse-engineering the design instead of building my own.

Then the only constraint was to keep the existing PCB footprint to ease the integration with the original switches.

Prototyping

Here is the breadboard prototype in its final stage:

The design is build around an ATMEGA328 connected to an SD card through the SPI interface. Like in my previous audio player circuit, audio samples are played on a PWM output. The signal is filtered with an RC circuit and amplified by a LM386 to drive a 0.3W speaker.

The sound from the electret microphone is amplified by a simple transistor circuit found on Sparkfun.com and then connected to an ADC input of the microcontroller to be sampled.

The circuit is powered by a single 9V battery that provides a “high” voltage for the LM386 amplifier. A 3.3V regulator provides the digital power supply to the microcontroller and to the SD card.

I am using a 16MHz crystal for the extra speed bump despite the 3.3V voltage that would qualify this as “overclocking”.

High current draw from the SD card

One difficulty I met was having spike noise in the audio recorded by the microphone on the SD card. It appears the SD card draws a high level of current during write operations and this was affecting the stability of the microphone amplifier power supply.

Here is a capture of the signals on an oscilloscope while writing sectors on the SD card. The blue signal is the output of the microphone and the yellow signal is the input of the ADC pin:

I tried to add decoupling capacitors around the SD card VCC and around the microphone amplifier to no avail. One solution I finally found in an application note from Actel: use separate regulators for the digital and analog domains.

So I added a second 3.3V regulator to provide an AVCC power supply to my microphone amplifier and an AREF reference voltage for the microcontroller.

No more noise, problem solved.

Connection of the matrix keyboard

The keyboard of the phone is on a separate PCB including two leds. This keyboard is using a matrix configuration with 19 keys arranged in 5 columns and 4 rows. The handsfree key is surprisingly wired separately. Four separate wires allow to control 2 front leds, a green one and a red one.

The keyboard PCB was connected to the main PCB through to a 17-wire ribbon cable. I reuse this cable by soldering a 0.1” header on it.

Fitting the circuit inside the phone

Considering the project is a one-shot, I choosed to use veroboards to solder my circuits.

The big one will be the main board supporting the microcontroller, the SD card slot and a female header for the keyboard connection.

The upper-right board will be a power board supporting the two voltage regulator and the main power switch.

The lower-right board will be the analog board containing both amplifiers circuits and a slide potentiometer to adjust the speaker level. It will be connected to the microphone already molded into the case and from whom you can see the black and red wires on the picture.

The 9V battery will fit at the bottom of the case.

To ease the maintenance of the circuit, the boards will be connected together by wires secured by screw terminals.

Building the boards

Here is the power supply board:

The amplifier board connected to the power supply board:

The amplifier in action playing a sinus signal coming from my laptop audio output:

And here is the main board. The SD card slot is a holder for a microSD. It is soldered on a right angle pin header.

The main board has been cut to fit the prominent speaker magnet.

At the end everything fit together inside the case:

Wires everywhere. In fact I am not really a fan of veroboards. It is a little tedious to assemble without proper planning…

Hardware schematic

You could find the EagleCAD schematic along the source code files on the project repository: http://github.com/elasticsheep/babyphone

Coming next

The next post will details the software design side of the project. Stay tuned…

The final circuit has been built inside the phone enclosure, including amplifiers for the speaker and the microphone.

Playback and record modules are developped an tested but the application code only supports playback for the moment.

Next I need to improve the matrix keyboard driver to allow multiple key detection to trigger the record of a new sound. The key combination should be hard enough to prevent the boy from erasing existing message.

The plan has been to reuse as much of the old phone as possible : speaker, microphone, keyboard.

The prototyping began on a Teensy2 board starting from my previous WAV player project. It has now moved on an ATmega328 because USB Mass Storage is not required and I want to keep my Teensy for other projects.

Hardware is done. Software is almost done. I am now soldering the design on a veroboard to fit it inside its final case.

More details and pictures to come…

Having sold out the stock and seeing the interest for the board, I have ordered a new batch that is now available for sale.

The price at Olimex was interesting for prototyping but not for producing greater quantity. This new batch has been produced by PCBCart instead with same specification.

Order your board in the shop page.

The test boards

The first test board is the one already used for my slave test with a Teensy 2 as USB to serial adapter and power supply. This board will be the master one.

The second test board is powered by a USB connector and a 3.3V regulator. A serial connection is establish with my laptop through a Prolific PL2303 adapter. This board will be the slave one.

Slave module configuration

The slave module is powered up in command mode. Cu does not seem to work correctly anymore with the PL2303 so I use screen instead:

$>screen /dev/cu.serial 38400
AT+ADDR?
+ADDR:11:3:252002
OK
AT+UART?
+UART:9600,0,0
OK
AT+ROLE?
+ROLE:0
OK

Role=0 is for the slave mode. I keep the default 9600 baud UART speed.

The module Bluetooth address will be useful to establish the connection from the master module.

Master module configuration

The master module is powered up in command mode. The role is changed to 1 for master. The UART baudrate is set to the same as the slave module.

$>sudo cu –s 38400 –l /dev/cu.usbmodemXXXX
AT+UART?
+UART:115200,0,0
OK
AT+UART=9600,0,0
OK
AT+UART?
+UART:9600,0,0
OK
AT+ROLE?
+ROLE:0
OK
AT+ROLE=1
+ROLE:1
OK
AT+ROLE?
+ROLE:1
OK

To establish an automatic connection to a slave module, the master module must know the slave address. This is configured with the AT+BIND command with CMODE=0 (Use a predefined address).

AT+CMODE?
+CMOD:0
OK
AT+BIND=11,3,252002
OK
AT+BIND?
+BIND:11:3:252002
OK

With CMODE=1, the master can connect to any device in its transmission range, so it is a much less secure configuration.

Master/Slave automatic connection

Now that the two modules are setup, I power up them in automatic mode (PIO11 = 0).

On each module, the red leds connected to PIO8 blinks quickly. After less than 2 seconds, the green led connected to PIO9 is shining on both modules indicating that they are now paired and connected, ready to transmit data.

I connect a terminal to the serial port of each module with their respective adapter to test the communication:

The first window displays the connection to the master BT module. The second window displays the connection to the slave BT module.

The connection is successful at 9600 bauds. I also successfully tested the communication at 115200 bauds.

Soldering the module on a breakout board

The difficulty is to correctly align all the module pins to the breakout pads. The module is so light that it can moves just because of the solder surface tension.

Two rows of header are added to fit in a prototyping breadboard.

Teensy 2 USB-to-Serial profile

I use the USBtoSerial project from LUFA 101122.

I already covered how to compile this project for the original Teensy in this previous post (Testing the LUFA USB Serial with GPS data). I apply the following modifications to the makefile:

MCU = atmega32u4
F_CPU = 16000000

Here is the binary: Teensy2-USBtoSerial.hex

To connect to the virtual serial port on a Mac:

$> sudo cu –s 9600 –l /dev/cu.usbmodemXXXX

A quick loopback test (direct wire from TX to RX) confirms that the profile is correctly working.

Useful to exit cu: ~.

Connections between the Teensy 2 and the BT module

The TX pin of the BT module is connected to the RX pin of the Teensy 2, and the RX pin on the TX pin.

My Teensy 2 board has been patched with a 3.3V regulator (see Converting the Teensy2 to 3.3V). I will use it to power the BT module.

The TX pin of the BT module is connected to the RX pin of the Teensy, and the RX pin on the TX pin.

Two leds are connected on PIO8 and PIO9 to display the status of the BT link.

The PIO11 pin is used to select the boot mode:

• High => Command/Response mode where you can issue AT command to setup the module.
• Low => Slave or master automatic operation.

Module configuration

I connect the PIO11 pin to the 3.3V rail. In this mode, the baud rate is 38400.

I open a cu session in the terminal and communicate with the BT module over its serial interface:

$>sudo cu –s 38400 –l /dev/cu.usbmodemXXXX
Connected.
AT
OK
OK
OK
OK

The module sends the OK response repeatedly. Sending Ctrl-C can stop it. Then you can enter another commands.

AT+VERSION?
+VERSION:2.0-20100601
OK
AT+NAME?
+NAME:HC-05
OK
AT+ADDR?
+ADDR:11:3:252009
OK
AT+UART?
+UART:9600,0,0
OK

We can see that the module is currently configured for 9600 bauds operations with 1 stop bit, no parity.

I speedup the baudrate to 115200 bauds.

AT+UART=115200,0,0
OK
AT+UART?
+UART:115200,0,0
OK

I also change the role to slave-loop. In this mode, the module sends back all data it receives over the BT link. It is useful to check that the module can correctly receive and send data over the BT link before connecting it to your system.

AT+ROLE=2
OK
AT+ROLE?
+ROLE:2
OK

Now I power up the module with the PIO11 connected to GND to boot in autoconnect mode.

Pairing with a Mac

The connection of Bluetooth devices is handled by the System Preferences/Bluetooth panel.

The connection fails because the default passkey of the module is 1234. It can be changed with the AT+PSWD command.

The module is now successfully paired with the Mac but currently not connected.

It is recognized as a virtual serial port and corresponding devices are automatically created in the /dev directory:

$> ls /dev/*HC*
/dev/cu.HC-05-DevB	/dev/tty.HC-05-DevB

Slave-loop connection

I can now connect to the BT device and use it as a classic serial interface. In slave-loop mode, the characters are echoed back to the terminal.

$> sudo cu –s 115200 –l /dev/cu.HC-05-DevB
Connected.
ABCDEFGHIJKLM

The status of the bluetooth connection is reflected in the System Preferences panel.

Slave mode

I switch to the command/response mode and change back the role to slave:

AT+ROLE=0
OK
AT+ROLE?
+ROLE:0
OK

In this mode, the BT module acts as a full duplex serial interface. The data received over the BT link are forwarded to the its TX pin, while the RX pin incoming data are sent over the BT link.
So to test the connection I open two cu sessions. One is connected to the BT module, the other one to the Teensy 2 serial emulation. As the 2 devices serial pins are connected together, I am able to send characters on one session and receive them on the other sessions.

The first window displays the connection to the Teensy 2. The second window displays the connection to the BT module.

Go to the Shop page if you want to get one.

You can find the same board with different names and different flash memories on the net but they all are based on the same design. The main chip is a CSR BC417143 a.k.a. BlueCore4-External connected to a 8Mbit parallel Flash memory containing the firmware.

Here is the system architecture of the chip from the CSR datasheet:

The BlueCore4-Ext is a generic Bluetooth 2.0 EDR chip with a bunch of interfaces. The USB interface allows to use it in a USB BT dongle design. When integrating it in a microcontroller-based design, you could use the serial interface instead. The SPI interface allows the programming and configuration of the chip using CSR tools.
The provided firmware implements a Serial Port Profile based on a RFCOMM stack. But in theory this hardware could run other firmwares from CSR, for example a HCI stack to connect the chip as a generic BT USB dongle.

The module hardware is very small. The footprint is made to be soldered on another PCB. A serial breakout board is available with RX/TX connections and a 5V to 3.3V regulator. As I would like to tinker with the module to investigate its capabilities, I instead designed a breakout board allowing access to all the pins on a standard header.

I just ordered a batch of breakout boards from Olimex. I should receive them in a few weeks. If anyone is interested to get one, leave me a message. [Update 2011-05-06] Ordering informations are on the Shop page.

Update 2011-05-02

Here is the module datasheet provided by hongkong_electronics
BC4_Bluetooth Module Datasheet.zip

Open Silicium is a new french magazine about open source and embedded system/hardware. It is published by the editor of Linux Magazine France. It is an interesting reading with eclectic articles that does not hesitate to dig into the hardware side.

But I think some of the articles may be difficult to grasp without a background in computer/electrical engineering. It reminds me of the magazines I was reading 15 years ago trying and often failing to make sense of articles about Turbo Pascal programming, entering program from paper to the computer. When the program worked you didn’t know why, and when it didn’t work you didn’t know why either!

What I was missing was good fundamentals on software and computer engineering. But at that time, the magazines where the only source of information I had, with local libraries very poorly filled with computer programming resources.

Now that the training knowledge is widespread and easily accessible through Internet, this kind of magazine is still useful to provide insight about different environment/tools/techniques. But if you are a beginner, you need to expect digging about the subjects you are interested in on your own.

Anyway thanks to the buzz around the Teensy2 and the PSGroove projet, I got a mention in this first issue. So thanks Open Silicium and keep up the good work!

The mp3 decoding will be handled by the mpg123 application. The decoded audio playback will go through the alsa-lib userland interface that communicates with the alsa kernel subsystem.

The target hardware is the Versatile/PB platform emulated in QEMU.

System base configuration

The Builroot base configuration is the same as in my previous post:

• Target Architecture: arm
• Target Architecture Variant: arm926t
• Target ABI: EABI
• Toolchain/Kernel Headers: 2.6.36.x (I could specify a path to my kernel sources)
• Package Selection for the Target/Busybox 1.17.x
• Target Fileystem Options/cpio the root filesystem and Compression method: gzip

I select those options in the Buildroot configuration menu and then save the resulting config file in the configs directory.

$> cd buildroot-2010.11
$> make menuconfig
$> cp .config configs/versatilepb926_defconfig

The saved configuration can be directly applied from make if you want to return to a known state:

$> make versatilepb926_defconfig
#
# configuration written to [...]/buildroot-2010.11/.config
#

Adding the alsa and mpg123 support

To enable the alsa and mpg123 support:

• Toolchain/Enable large file (file > 2GB) support
• Package Selection for the target/Audio and Video libraries
  • alsa-lib
  • alsa-utils / aplay
  • mpg123

aplay is useful to check if simple WAV files can be played by the system. The Large File support is a dependency requirement from the alsa-utils package.

Adding the /dev/snd/* entries

By default, Buildroot does not add create audio device files. It uses the default device table that is located in target/generic/device_table.txt.

To add the /dev/audio and /dev/snd/* device files, I create a new device table file derived from the generic one adding the entries required by Alsa: target/generic/alsa_device_table.txt.

Then I change the selected device table in the Buildroot configuration:

• Target Filesystem options/Path to the device table
  • target/generic/alsa_device_table.txt

Here is the updated audio section of the device table:

# Audio stuff
/dev/audio	c	666	0	29	14	4	-	-	-
#/dev/audio1	c	666	0	29	14	20	-	-	-
/dev/dsp	c	666	0	29	14	3	-	-	-
#/dev/dsp1	c	666	0	29	14	19	-	-	-
#/dev/sndstat	c	666	0	29	14	6	-	-	-
/dev/mixer	c	666	0	29	14	0	-	-	-
/dev/snd	d	755	0	29	-	-	-	-	-
/dev/snd/controlC0	c	666	0	29	116	0	-	-	-
/dev/snd/pcmC0D0c	c	666	0	29	116	24	-	-	-
/dev/snd/pcmC0D0p	c	666	0	29	116	16	-	-	-
/dev/snd/seq	c	666	0	29	116	1	-	-	-
/dev/snd/timer	c	666	0	29	116	33	-	-	-

My patched file for buildroot-2010.11: alsa_device_table.txt

Sorry I don’t remember the original source from where I copied those major/minor device numbers.

Saving the updated configuration

$> cp .config configs/versatilepb926_alsa_defconfig

Copying audio files in the root filesystem

Audio files can be directly copied in the output/target/root directory of Buildroot for test purposes.

When running make again, buildroot includes those files in the CPIO archive of the rootfs.