The other day, Make:blog mentioned the new 5.0 release of Eagle. Cadsoft Eagle is the most popular circuit design and layout software among DIY'ers, and the program I use in all my projects. Today I designed a project with Eagle 5 and journaled my favorite updates. I also tested compatibility with the current and beta versions of Eagle3D, a 3D circuit board rendering program.
Eagle 5 installs to dedicated version 5 directory -- the new version won't overwrite a previous install. You still have full access to your original stuff if anything goes wrong.
When I start Eagle 5 it attempts network access; this might be an auto updater or license checker. It didn't complain when I permanently blocked access.
All my old schematics and circuit board files from Eagle 4.16r2 load in the new version. The board layout editor got a minor makeover with "web 2.0" pastel color shades.
Say goodbye to the awkward ALT+Backspace undo, because Cadsoft joined the rest of the world and standardized on CTRL+Z!!! Need I say more? Oh happy day!
Eagle now has right-click context menus in the schematic editor and the board layout editor. While context menus are ubiquitous (does your browser have it?), previous versions of Eagle pretend the right mouse button doesn't exist.
Another great feature is the properties editor. Component or connection properties can be configured in one place. These features were previously scattered over dozens of menus and icons.
Eagle3D 1.05 compatibility
Like a Firefox upgrade, it's important that all your favorite Eagle add-ons are compatible with the new version. For me, that's the ultra-cool 3D rendering script, Eagle3D. The 3D renderings that accompany my projects are made with Eagle3D 1.05, but I'll also test a new 1.1 beta version with Eagle 5.
First, I installed Eagle3D 1.05 in the same folder as Eagle 5 (C:\Program Files\EAGLE-5.0.0\Eagle3D). I also installed POVray (try MacMegaPOV for Mac) to render the files created by Eagle3D. If you're not familiar with how to use Eagle3D, or run .ulp files with Eagle, see the Eagle3D documentation and this illustrated tutorial.
I loaded a circuit board file and rendered it using the Eagle3D .ulp file intended for Eagle version 4.1. It worked normally, and generated a POVray compatible file.
New users often run into this error when rendering the their first Eagle3D .pov file with POVray: Parse Error: Cannot open include file tools.inc. File: C:\ ... DIYLife.com - MSP430 voice recorder - vc.pov Line: 117 Parse Warning: Check that the file is in a directory specified with a +L switch or 'Library_Path=' .INI item.
This means that POVray can't find the Eagle3D component libraries. You need to add Eagle3D to the POVray search path:
Open POVray and make sure you have a .pov file open.
Go to tools->edit master povray.ini. Povray.ini opens in a text editor.
Add the path to your Eagle3D files at the very bottom of povray.ini. This is the folder where Eagle3D was installed earlier. I added this line to the end of my poyray.ini, but use your own install location: Library_Path="C:\Program Files\EAGLE-5.0.0\Eagle3D\povray"
My board rendered perfectly after this minor configuration change.
I deleted my old Eagle3D folder and copied the new version to the same location. If you use a different location, update the Library_Path you specified in povray.ini. Be careful not to include multiple search paths for different versions of Eagle3D, the result will be unpredictable.
The interface of version 1.05 and 1.1 are nearly identical. The new version optionally generates SVG formatted vector graphics.
Eagle3D 1.1 generates a list of components it wasn't able to match to the 3D parts library. This is a helpful new feature that will help diagnose why certain parts don't render correctly.
Functionally, the new version performs similarly to version 1.05. It didn't render any more parts on my test board than the last version. The new version (above, right) excludes the water background, and I don't know how I feel about this yet -- the old background (above, left) was getting tired, but white is a bit jarring.
Verdict
I'm tentatively using the new versions of Eagle and Eagle3D. They've been solid for a few days, and backwards compatibility seems good. The new features in Eagle 5 make it much easier to use and more intuitive for beginners. Both versions of Eagle3D are compatible with Eagle 5, but I highly recommend the new 1.1 beta version. Eagle3D 1.1 is several years newer than its predecessor, has a larger parts library, and generates helpful reports.
Salvaging electronic parts is a must for any DIY'er. You save big on shipping charges, and recycling is good for the environment. Hack-a-day dissected an old computer mouse and found some useful components.
What useful parts are inside an outdated PC mouse? There are a bunch of sensors and buttons, including rotary encoders that can be used to measure movement in robotics projects. My favorite find is the microchip that glues the sensors to a computer. Learn about all these parts in detail, in the how-to.
Hack-a-day doesn't delve into the proper techniques for removing parts, but there are a ton of tutorials that can help you get started. It's possible to remove many parts with a simple soldering iron and an absorbent copper braid, called solder wick. Many use a solder sucker to vacuum solder away from parts, or a special desoldering iron. Surface mount chips can also be removed, but they may require the gentle embrace of 400 degree air from a hot air rework station, or the crude gust of a heat gun.
This article continues a series about building a DIY digital audio recorder. Inspired by this microcontroller audio project [via], I set out to build a simple digital recording device. I chose Texas Instrument's MSP430 microcontroller for this project because it's fast (16 MHz), it's cheap ($1), and it's very low power. Read the first part, the second part, and the third.
In the first few segments I developed a digital audio recorder prototype that plays raw audio files from an SD card. This time we finish up the introductory segments by recording audio to the SD card. Before the audio can be recorded by the microcontroller, it has to be prepared by a small amplifier. Read on to learn more about working with microphones and recording audio with a microcontroller.
Preparing raw microphone output for sampling This project uses a small, common electret microphone to convert audio to an electrical signal. These are the cheap microphones found in most PC headsets. The microphone output must be amplified and zeroed before it can be recorded with the MSP430. This is done with an operational amplifier, or op-amp. The op-amp amplifies the tiny, oddly centered audio signal into a full range signal based on 0 volts. The diagram shows the original signal (blue) and the amplified, full range signal outputted by the op-amp (red).
I'm not much of an analog designer, so may I refer you to any of these tutorials on op-amps if you need more info: wikipedia, a flash tutorial, opamp basics.
The op-amp design I used came directly from TI's digital audio recorder application note slaa123 [pdf!] (page 3). TI's design uses a TI TLV2252 dual op-amp. We only need one, so I substituted a single channel TI TLV2221 op-amp. I used the circuit and values from the TI app note, but substituted the 2K/.01uf low-pass audio filter I chose in part II. The TLV2221 is only available in a surface mount package. If you want to do an all through-hole version of this project, consider a TLV2252 based design.
Sampling an audio signal We'll use the MSP430's on-chip analog-to-digital converter (ADC) to measure the audio signal. The ADC is a pin that measures analog voltages. Measurements taken by the ADC are recorded as a fraction of a voltage reference (Vref). In the prototype, the voltage reference will equal that of the circuit -- 3.3 volts.
The smallest voltage change that can be measured by the ADC is denoted in bits. An 8 bit ADC measures voltage on a scale of 0 to 255. A reading of 127 (127/255=50%) from the ADC represents ~1.65 volts (0.50 * 3.3 volt reference). The diagram shows the relationship between bits, voltage reference, and measurements taken by the ADC.
The MSP430F2012 has a 10 bit (0-1024) ADC, while the F2013 has a higher-resolution 16 bit (0-65535) ADC. The higher resolution ADC could, in theory, be used to capture better audio.
Gotcha -- The prototype design is unproven and bound to have problems. Here's a big one! Most ADCs, including the Microchip PIC, ATMEL AVRs, and even the MSP430F2012, can use the circuit power supply as the ADC voltage reference. An internal switch, manipulated from software, determines the reference source. I planned to use this feature to measure the op-amp output, which is scaled to the 3.3 volts used in the circuit. The F2013, despite my assumptions, does not appear to have an internal Vref connection to the chip power supply. The F2013's internal Vref comes from a precision 1.2 volt reference. An external voltage reference can be sourced through pin 5 (P1.3), where a LED currently connects. Future designs should take this limitation into account, and connect the F2013 Vref pin directly to the power supply.
My work-around was to remove the LED and solder a fly-wire from the power pin to the Vref pin. An external Vref is used if SD16REFON and SD16VMIDON are both cleared to 0, according to page 24-4 of the MSP430F2xxx Family User's Guide [pdf!]. This didn't work for me.
Next, I calculated a voltage divider to cut the op-amp 3.3 volt output to 1.2 volts - this helped to some extent.
Eventually, I messed around enough to destroy the MSP430. In desperate need of a break, I removed the dead MSP430F2013 and replaced it with a F2012. The F2012 has only 10 bits of ADC resolution, but is able to use the chip supply as a voltage reference.
Test audio capture (example firmware 4) NOTE:unlike the previous firmware, this is intended for the MSP430F2012!!! The example program samples audio from the microphone and puts it immediately in the PWM duty cycle register. The result is a useless "middle man" that echoes everything heard by the microphone.
This project is based on the firmware from my last article. A timer triggers an alarm (an interrupt) 8000 times per second. An ADC measurement is started each time the alarm sounds. The ADC measurement isn't ready immediately - it takes a few cycles for the conversion to be readable. We don't need to worry about this period, because the ADC will trigger it's own interrupt when the measurement is complete. A single line of code in the ADC interrupt service routine copies the ADC measurement to the PWM duty cycle register.
As you can see in the video, everything I play into the microphone can be heard from the powered PC speakers. There's no direct audio path from the microphone to the speakers -- the sound is first sampled, and then output on the PWM. This simple concept can be used in different ways to create custom digital audio effects and real-time audio distortions.
Recording to a SD card (example firmware 5) The whole series of articles comes down to this moment -- it's time to save audio samples to the SD card. Like last time, a MMC/SD card library from TI takes care of accessing the SD card. The original TI library requires a 512 byte block of memory to hold a whole SD card sector, but the F2012/3 chip only has 128 bytes of RAM. A low memory version of the write routine is possible if we write the bytes into the sector sequentially. I broke the write function into three smaller functions that:
mount a sector for writing,
send a single byte to the SD card, and
starts the sector save and unmounts the sector.
If we only write a single byte to the card at a time, a full 512 byte cache is unnecessary. This is the same technique I used to read from the card in Make a talking MSP430 microcontoller.
The example firmware builds on the existing projects. A timer generates an interrupt 8000 times per second. Ten seconds of audio is recorded immediately after the circuit is powered. For these ten seconds, each timer interrupt begins an ADC measurement. Upon completion, the ADC triggers an interrupt that stores the audio sample in a buffer and sets a flag. This flag triggers code in the main program loop to write the byte to the SD card. After ten seconds (80000 samples, 157 sectors), recording stops.
Next, the recorded audio is played in a loop. As in the previous project, each timer interrupt (8000 per second) copies a sample from the SD card to the PWM duty cycle register.
Sector switching and management is handled in the background by the sdRead() and sdWrite() functions. Every 512 bytes the sector is switched -- the old sector is closed and the next sector is mounted. If you use these functions, pay close attention to the setup steps that prepare the card for a sequential read or write. Set the start location to read or write in the flashDisk and audio variables, and manually mount the start sector.
NOTE: The SD card is used as a cheap and handy source of flash storage. Audio data is recorded to the SD card in a raw format. Audio files will not appear if you put the card into a memory card reader and attach it to a PC. The MSP430F2012/3 lacks the resources needed to implement a full FAT file system. The raw data can still be viewed and extracted with special disk tools, such as HxD.
The example program starts recording audio at the beginning of the SECOND sector of the SD card (sector 1). The first sector (sector 0) will be used to record the length of the file in the final digital audio projects. The reserved sector provides 512 bytes for meta data, allowing us to delineate the flash storage space into multiple audio clips.
Continuing... Next time, I'll finish up with the MSP430 by designing a complete digital audio recording experimenter's board. The final project joins everything from the previous four articles with an amplifier chip that drives a small speaker.
Prototype This project uses the digital audio recorder prototype from Make a singing MSP430 microcontoller. I replaced the original F2013 with a F2012. The only difference between these chips is the type of ADC: the F2012 has a 10 bit ADC, the F2013 has a 16 bit sigma delta ADC.
The microphone amplifier prototype is included in the project archive. The circuit was designed with the freeware version of Cadsoft Eagle.
Parts list
Op-amp: U1 - TLV2221 (surface mount, SOT23-5L). TLV2211, and TLV2231 would also work.
Overview Read the previous article in this series for the fundamentals of microcontroller audio. Learn about basic MSP430 connections and programming in the MSP430 primer. This week we'll use the tiny, inexpensive MSP430 microcontroller to play audio from a SD card.
Playing an audio file In the previous project, I used the MSP430 pulse-width modulator (PWM) to generate simple tones. The PWM duty cycle changed the frequency, and thus tone, of the generated signal. The signal is cleaned by a simple audio filter, and amplified by powered PC speakers. Hear it in this video clip from the previous article:
Each value generates a different frequency. If we change the values about 8000 times a second (8KHz) we can reproduce telephone quality audio.
8 bit audio (each sample requires one byte) at 8KHz requires 8000 bytes of data per second. 16 bit audio, the quality associated with CD players and PCs, requires twice as much data per sample (16 bits or 2 bytes) -- 16 kilobytes/second.
With 2K of internal flash, the MSP430 can store about one-quarter second of audio. External memory is needed to store any meaningful amount of audio. There's no better source of cheap storage than flash memory chips. A raw flash memory chip would be a special order item, but you probably already have some flash memory -- SD cards! These cards are ubiquitous in digital cameras and low-end MP3 players.
Working with SD cards NOTE!!! We are going to use the SD card as flash memory. It will not have a full (FAT) file system, and can not be read on a PC by the usual methods. It will not be possible to drag and drop a raw audio file to the card and read it with the MSP430, nor will it be possible see recordings from the file browser on a Mac or PC. Special disk tools provide access to the raw disk, but a full FAT file system implementation is too big for the tiny microcontroller. The F2013 has 128 bytes of RAM and 2 kilobytes of flash. A workable FAT implementation requires 1024 bytes of RAM and several kilobytes of flash program space.
The prototype design accesses the SD card using the simple SPI protocol. SPI is a simple three wire interface that allows a microcontroller to read and write data from external chips. If you want the dirty details on how the SD card works in SPI mode, read some of these tutorials [Tutorial 1, Tutorial 2]. A source code library from TI provides easy access to the disk without writing our own initialization and read/write routines (mmc.c/mmc.h in the project archive).
SD card storage is divided into 512 byte chunks called sectors. A full 512 byte sector must be read or written at once. The MSP430F2013 has only 128 bytes of RAM -- not enough to hold a whole sector for random access. We can still read/write each byte in order, as it's needed. This method will suffice as long as each byte is read or written sequentially.
Playing an audio file is as simple as reading a byte from the SD card and writing it to the PWM duty cycle register.
Converting audio to a raw format My 'hello world' audio clip comes from the intro to my videos. I converted the clip to an 8KHz .wav file with Audacity and then saved it to raw text file with the free version of Switch, as described here.
Start Switch, and add your desired files to the queue by clicking "add files".
Now set the output format to ".raw", and then click "Encoder Options". Set the encoder format to "8 bit unsigned", sample rate to "8000", and channels to "mono".
Now click convert and the raw version of the audio files are created.
The raw text version of the audio file is included in the project archive.
Imaging an SD card The MSP430 isn't powerful enough to deal with a file system, so we need the audio to start exactly at the first sector the of SD card. A simple copy->paste operation would put the file on the SD card according to the rules of the PC file system. To avoid this, we image the file directly onto the card. This will be familiar if you've ever 'imaged' a CD .iso file, say, for a bootable Linux live CD. I used DiskImage 0.9 from Durban.
Imaging the audio file onto a flash card was pretty easy with DiskImage. I put the SD card in a USB flash card reader and attached it to the USB port. I opened DiskImage and it detected the card as a logical and physical volume.
It's crucial to deal with the disk directly, rather than through the file system. All operations should be done to the listings under "Physical drives - raw drive, independent of partitions" box.
Find the physical partition that represents your SD card - it's easy to identify the correct physical drive because it should be type "Removable" and the correct size (in my case 14MB). Be sure you don't overwrite your actual hard drive, this utility can easily do that!!!
Click on the correct drive to highlight it.
In the "With selected item do" box, click the "Import from file" button. Click yes, and type "i agree" after you verify that the correct disk is selected. Click yes again.
Next, DiskImage prompts for the file that will be imaged onto the disk. Choose the raw audio .txt file outputted earlier.
With the raw audio imaged onto the SD card, we're ready to play it from the MSP430. Take the SD card out of the computer and put it into the card holder on the prototype.
This article continues a series about building a DIY digital audio recorder. Inspired by this microcontroller audio project [via], I set out to build a simple digital recording device. I chose Texas Instrument's MSP430 microcontroller for this project because it's fast (16 MHz), it's cheap ($1), and it's very low power. Read the first part, and the second part.
This week we'll progress towards a digital audio recorder by playing audio files from a SD memory card. First, we'll convert an audio file to a raw format and image it directly to a SD card. Then, we'll interface the SD card with the MSP430 and play an audio file. See it in the video:
Next time we'll extend this basic circuit to include a microphone and audio recording capabilities.
Read on to learn more about generating audio with a microcontroller.
Firmware The example program is included in the project archive. The example software is written using the demo TI/IAR Kickstart C compiler.
SD card access The example firmware starts reading the SD card at the first sector. It reads one byte at a time over the SPI interface and places the byte in the PWM duty cycle register. When the end of a sector (byte 511) is reached, the next sector is immediately loaded and initialized so that the next byte is always ready when needed.
The example firmware will copy bytes from the SD card to the PWM register until it reaches the sector defined by the variable flashDisk.lastSector. At the end of this sector, the program begins again at the first sector.
The value to use here is determined by the number of sectors consumed by the audio file. The example audio file consumes 58,447 bytes. The SD card is arranged into 512 byte sectors, so the file ends at sector 115 (sector numbering starts with 0). Update this value if you are working with a custom audio file:
flashDisk.lastSector=115; //last sector (512byte block) where file is stored on flash...
Playback rate The playback must match the sampling rate of the audio file, or the audio will sound too fast or too slow. Since I sampled audio at 8KHz, the PWM duty cycle register should be updated with a new value 8000 times each second. I appropriated the watchdog timer (WDT) from the MSP430 to sound an alarm (an interrupt) 8000 times per second. When the timer interrupts, a bit of code copies the next byte from the SD card to the PWM duty cycle register.
The timer runs on the calibrated 8 MHz internal clock. The WDT is set to trigger every 512 counts of the internal clock (8MHZ/512), or 15,625 times per second. This is about twice as fast as we need, so the interrupt routine uses a switch that updates the audio only once every other interrupt, or 7,812.5 times per second. Not exactly 8000 samples-a-second, but the internal oscillator will vary with temperature and age anyway. Using the internal crystal keeps the design simple and the part-count low.
If you're after tighter tolerances, consider using a watch crystal on the P2.6/7 pins of the MSP430 as the timer clock source.
When the MSP430 is not copying audio to the PWM, it enters a loop that continually checks if a new audio byte should be loaded into a single byte buffer. The buffer ensures that data is available when it's needed, and that audio quality isn't effected by delays in reading data from the SD card. A ton of power could be saved by entering sleep mode between interrupts, we'll look at this again in a future article.
Say Hello In the video you can see the basic firmware functions. First, a breakpoint set at the timer shows how the audio is only updated on every other byte. If we move the breakpoint inside this switch, the debugger stops every time the audio changes. Next, execution halts each time 512 bytes are read from the SD card and the sector changes. A final breakpoint halts execution each time the sector resets to 0. Next time The next article will be the final functional enhancement to the digital audio recorder. We'll extend this basic circuit to include a microphone and audio recording capabilities.
Prototype Circuit For complete details of the prototype, see the previous article in this series. This week's firmware is in the project archive.
This is my second article about building a DIY digital audio recorder. Inspired by this microcontroller audio project [via], I set out to build a simple digital recording device. I chose Texas Instrument's MSP430 microcontroller for this project because it's fast (16 MHz), it's cheap ($1), and it's very low power. Read the first part here.
This week we'll progress towards a digital audio recorder by generating simple tones with the MSP430 microcontroller. We'll use the MSP430's pulse-width modulator to generate an audio waveform, and clean it up with a simple low-pass filter. The signal won't be strong enough to drive a speaker directly, but it'll work great with a cheap set of powered PC speakers.
Next week we'll expand on this basic circuit to play audio recordings from SD memory cards.
Read on to learn more about generating audio with a microcontroller.
Salvaging 
This article continues a series about building a DIY digital audio recorder. Inspired by 
_thumbnail.jpg)
Make liquid soap from bar soap
More do-it-yourself wedding centerpieces
Construction Chronicles -- Stain, seal, and protect your deck
_thumbnail.jpg "Making and using a facial mask")
