Tag Archives: avr

The Great [Volume] Leveler (AVR Audio Compressor)

Like many people, I have fairly diverse taste in music.  My media library holds tracks from Bach, Beethoven, Billy Joel, Bonobo, Brent Lamb, Brahms, Brian Hughes, and the Bee Gees (to name just the “B” section).  I love variety.  The trouble is, all of these different genres tend to require slightly different volume settings.  Worse still, in the case of some classical music, you can get quite a wide range of volumes within a single piece (e.g. O Fortuna).  So if I hook up my BlackBerry and set it to shuffle, I find myself having to continually adjust the volume knob – either because I can hardly hear the current track, or because my neighbors are about to come banging on my door.

Well, I’m not the first one to have this problem.  Nor am I the only one to attempt to solve it.  In fact, it’s already been solved.  As you may know, there are plenty of software solutions out there for so-called volume leveling.  But before the advent of the BlackBerry, or the personal computer, there was the analog compressor.

The Buzzaudio SOC-1.1 Compressor

The sole purpose of such a device is to compress the dynamic range of an incoming audio signal: amplifying the soft parts and reducing the volume of the loud parts (thus decreasing, or compressing, the range of the track’s volume).  It’s quite a simple thing, really.  And you can buy one of these units for between $100 and $200.  But why buy something when you can build it from spare parts? 🙂

Now for all of you comp-sci majors out there who are planning on commenting on any one of a million different audio leveling programs out there, don’t worry, I know they exist.  The trouble is, even if I leveled every single MP3 I possess, what about internet radio?  Specifically, the Pandora app for my BlackBerry?  Alright, maybe there’s a software-only solution for that too (although I haven’t found it), but you know what?  Just for the fun of it, I’m going with hardware this time.  Well, mostly.  Actually, it’s going to be a mix of analog hardware and an 8-bit Atmel AVR running some embedded C code.  Sound good?  Alright, then let’s get started!

First Prototype: Powered by LabVIEW

As frequent readers of my blog will know, I’m a big fan of the LabVIEW programming language.  I can use it to whip up fairly complex data acquisition and processing applications in a matter of minutes (examples).  Much faster than writing code for an MCU.  So I decided to use it, along with my handy Mobile Studio IOBoard and Bus Pirate, for my first compressor prototype.  Before we get into the brains though, let’s talk about the guts (and by that I mean let’s talk about the analog circuitry which will be common between the LabVIEW and the MCU prototypes).

First off, we need some way of detecting the volume of our incoming audio signal.  To do this, you could simply connect your left and right audio channels directly to your ADC inputs.  Two problems with this though.  First, unless you’ve really cranked up your source’s volume, you may only see peak signals of around 100mV.  Such small voltages will mean poor resolution.  In other words, without some type of amplification, we won’t be able to detect fine changes in the input’s volume.

To counter this, I have added two operational amplifiers (op-amps, U1) which connect, via high-pass filters, to our incoming left and right audio signals.  Each op-amp increases the amplitude of its respective signal by about 50x (click to enlarge):

Audio Compressor: Analog Stage Schematic (click to enlarge)

The purpose of those two AC-coupling high-pass filters is to remove any DC offset from the input signals.  Without these filters, we would also be amplifying that offset, such that even a 0.1V bias would saturate this first set of op-amps (which are supplied by +5V and -5V).

Once amplified, there is one more thing we need to consider.  Since audio waveforms change rapidly, and swing between positive and negative voltages, our input signal may appear to change wildly between ADC samples.  What we need then is a circuit that can smoothly follow the peak amplitude of our input signal.  Kindof like an old VU meter.

Peak Hold Circuit Results (Blue = Input Audio, Green = Output)

The amplified input audio signal is shown above in blue, while the output from our “peak hold” circuit is shown in green (this plot displays 1V/div vertically, 50ms/div horizontally).  Just how does this work, you ask?  Well, scroll back up to my earlier schematic.  The key is the two sets of diodes (D1 and D2) and 10uF capacitors (C3 and C4) you see just past the first amplifier stage.  Diodes only allow current to flow in one direction (from left to right, in this case).  Thus, when the left channel amplifier’s output is greater than the voltage across C4 plus 0.35V (due to the voltage drop across the diode), C4 will be charged to a higher voltage.  Once the op-amp’s output drops, the diode D2 prevents C4 from discharging.  Thus, it “holds” the op-amp’s peak voltage.  However, because we don’t want C4 to hold this voltage indefinitely, I’ve added resistor R15 (R14 on the right channel), which gives C4 a path through which it may slowly (kindof) discharge.  The result is the scope plot above.

Now at this point, I could’ve stopped and wired both peak voltage outputs directly to my ADCs.  However, I would then have needed to read and average two voltages within my leveling program.  Since I’m on a hardware kick, I decided to simply sum the two using an inverting summing amplifier configuration (R7, R8, R9, U2).  Because this circuit’s output is inverted (negated), I then passed the signal through a unity gain (1x), inverting amplifier (R10, R11, U2).  Now we’re ready for measurements!  By the way, in case you have as much trouble as I do remembering what all of these op-amp circuits look like, you should download or bookmark this nifty guide from TI.  I use it all the time.

Audio Compressor First Prototype (Click to enlarge)

Before I move onto the brains of the device, I should explain how I intend to digitally control volume.  Recently, I acquired a Bus Pirate and a few SPI digital potentiometers.  My plan here is to use these potentiometers (P/N MCP42010), as 256-position voltage dividers.  They will be wired in-line with each audio channel.  You can see one of them (one IC containing two pots) shown as a green box in my earlier schematic.  The output from each pot will be fed into a buffer op-amp in order to keep the outputs strong (capable of driving headphones or line inputs).  For my initial LabVIEW prototype, I will be communicating with the potentiometers via an RS232 connection to the bus pirate.

LabVIEW Audio Compressor VI

Alright, so onto the brains!  [Insert zombie joke here]  The image above is a screenshot of my VI (virtual instrument, also known as a LabVIEW program).  As you might expect, it is quite simple.  I have a control for the potentiometers’ wiper positions, as well as indicators for the instantaneous and filtered ADC inputs.  The analog input is being provided by my old friend, the RPI IOBoard.  Its interface consists of just a few blocks on the diagram (for those of you unfamiliar with LabVIEW, what you see here is equivalent to written code):

LabVIEW Audio Compressor Block Diagram (Click to enlarge)

I have divided the program into two while loops (the large grey-border rectangles), each running at a 50ms rate.  The top loop handles communication with the bus pirate (initial bus pirate configuration I perform once, by hand, through the terminal).  This communication is quite simple, and consists of just two bytes.  The first byte is a command which tells the potentiometers to write the second byte to their wiper position registers.

The bottom loop is responsible for determining the appropriate wiper position, based on the incoming voltage measurements.  My logic is quite simple.  Perhaps you can determine it from the diagram alone?  Basically, I compute a difference between the current (instantaneous) voltage measurement and our last filtered value.  Then, if the current measurement is greater than the filtered measurement, I divide the difference by 40 and add it to the filtered measurement.  If the current measurement is less than the filtered measurement, I divide the difference (which is negative) by 240 and add it to the filtered measurement.  The result of this is that for loud sounds, the filtered measurement increases fairly quickly (within a second or two).  However, if the input volume drops, the filter will take perhaps five times longer to respond.

Once the filtered measurement has been computed, the appropriate wiper position is determined via a look-up table.  That table, when plotted, looks something like this:

Look-Up Table Graph

These values were determined empirically.  I simply listened to the circuit’s output for various inputs and adjusted the wiper position manually to achieve the best sound.  However, as you can see, it implements a log(x) function, as you might expect with an audio signal.  But rather than attempting to determine a precise formula for this function, as I am designing this for use on an 8-bit MCU, I chose the look-up table approach.

With my VI wired and ready to go, I proceeded to tune my filtering algorithm to provide leveling over the whole musical spectrum.  The results sounded pretty good.  But before I demonstrate anything, let’s talk about the final implementation using the ATMega328.

Second Prototype: Powered by Atmel

For my embedded prototype, I again chose an AVR microcontroller.  I’ve long been a fan of these chips.  They’re just so easy to work with, and quite powerful.  Implementing the SPI interface required just a few simple commands, since the protocol is natively supported by the ATMega’s hardware.  This particular chip also has a built-in, six-channel ADC, so that was no big deal either.  And since I’d already developed the algorithm and settings in LabVIEW, the most time-consuming part of this whole process was wiring up this lovely 10-segment LED bar graph.  Now I need more resistors…

AVR-Powered Audio Compressor (Limiter)

Although I would have liked two bar graph displays, I had only enough IO to fully support one of them.  So rather than just hard-coding the chip to display one value, I added a small button (you’ll notice it just to the left of the MCU, the largest IC) which allows you to select between displaying the instantaneous voltage input (VU meter mode) and the current wiper position.  This proved very helpful in debugging.

For simplicity, I’ve chosen to use the ATMega’s internally 8Mhz RC oscillator.  Timing isn’t very critical for this application, so I coded up a simple delay routine which works based on repeating an operation for a calibrated number of iterations.  I probably could’ve done a better (more generically useful) job on the look-up table too, but with only a few datapoints, I didn’t feel like spending much time on it.  Lazy me.  Anybody out there have some good code written for interpolating look-up tables? 🙂 Well, what I do have, you may download via the links at the bottom of this post.

Results

In order to demonstrate the performance of my device, I created an MP3 containing about 90 seconds of audio (music) at different volumes.  This file was played back on my laptop, whose volume setting was adjusted until the loudest sound produced just barely hit the maximum  input of the ADC.  The Audacity screens you see below show the original waveforms on the top and the “leveled” waveforms on the bottom (recorded via my laptop’s microphone input jack).  Enjoy:

As you can see and, hopefully, hear (sorry about my lousy sound card – the signal is much clearer than it sounds here) in the video above, the soft parts in the original track were amplified somewhat, while the loud parts were reduced in volume.  If not aurally obvious, I suspect the results are pretty easy to see in this screenshot from Audacity:

Audacity Demo Waveforms

Final Thoughts

Overall I think this project turned out alright.  I particularly liked the method of first prototyping with LabVIEW, the bus pirate, and my IOBoard.  This definitely sped up development of the final application and made debugging easier.  The only thing I wish is that I could use my VI to generate code for the AVR.  Such a thing is available, but only for 32-bit processors.  Oh well, maybe it’s time for me to upgrade by a few bits.

In the future, I may try amplifying the audio outputs.  Obviously, potentiometers by themselves can only reduce signals.  And that’s fine, as long as my input source is sufficiently loud on even the soft songs (because we can always cut the volume of the loud pieces).  But for even greater range, amplification would be nice.

You may wonder why I didn’t include any other adjustments, like an additional volume control, or knobs to adjust the filtering speed (these would be the attack and release knobs, which, by the way, are awesome names).  Well frankly, I wanted to keep things simple.  The point of this project was to reduce the amount of knob-turning I do.  If I left things adjustable, I’d probably be tweaking stuff all the time.  It’s just a compulsion.

Anyway, I hope you’ve enjoyed this project as much as I have.  As always, if you have questions, comments, or want help building something like this, please leave a comment!

List of Parts Used, with Prices  (Excluding Passives)

  • Bus Pirate ($29.95)
  • IOBoard (not readily for sale; you might be able to buy one off an RPI/Rose-Hulman student who doesn’t understand/care about the value of what the have)
  • MCP42010 Digital Potentiometer ($2.40)
  • TLC2272, 2.25Mhz, Rail-to-Rail, Dual Op-Amps ($1.83)
  • ATMega328 ($3.93)
  • LED Bar Graph, SSA-LXB10IW-GF/LP ($3.33)
  • LT1054, for generating the -5VDC rail ($1.62)

Downloads

Explaining the XMega XPlained (Dev. Board)

About two months ago, Atmel announced a smart new set of AVR development boards, the XPlained series.  One of these boards (which I’ve just recently purchased for $30) boasts a shiny new AVR XMega microcontroller.  What?  An XMega you say?  Why yes, haven’t you heard?  Come now, they’ve been around for fully three years at this point.  Well, don’t worry if this is fresh news, you’re not alone.  For some reason, adoption of the powerful new XMega MCU has been slow amongst hobbyists.

The XMega Xplained (click for high-res goodness)

When Atmel introduced their new XMega series of AVR microcontrollers back in 2008, I was pretty sure they’d be a quick sell.  Even in spite of their unavailability in DIP packaging, and this cheesy marketing video.  But sadly, a quick search of Hack a Day currently yields only four articles containing the term “XMega” (versus more than three hundred articles for “ATMega”).  I guess change is hard.  And yet, it’s really not.

The XMegas utilize the same AVR core as the ATMegas, and are fully supported by the free AVR-GCC compiler and AVR Studio (obviously, I guess).  Plus, you can still use your trusty AVRISP mkII programmer to load code onto an XMega.  In other words, the tool-chain is unchanged.  So, with a few register name changes, code from an ATMega will run perfectly well on an XMega.  Sadly though, the XMegas and ATMegas are not pin compatible, so you won’t be able to solder a new XMega onto your Arduino.

Alright, so for those of you keeping track, I guess I’ve now listed three strikes against the XMega which may help to explain its present unpopularity: no DIP packaging, no pin compatibility with the ATMegas, and changes to register names (plus the addition of new registers for new features).  Oh, and odd marketing tactics.  By the way, as a side note, it could be argued that the XMega register scheme is better than that of the old ATMegas.  They’re making good use of structs, so that you now address a port’s direction using PORTX.DIR, rather than DDRX.  And you output to that port using PORTX.OUT.

But let’s now take a look at the data in favor of the XMegas, yes?  To do that, we’ll compare the ATMega1280 (utilized on the Arduino MEGA) against the ATXMega128A1 (utilized on Atmel’s new XPlained development board):

Feature ATXmega128A1 ATMega1280
FLASH Memory 128KB 128KB
Max CLK Speed 32Mhz (PLL) 16Mhz
EEPROM Size 2KB 4KB
RAM Size 8KB 8KB
Voltage Range 1.6 – 3.6V 2.7V – 5.5V
ADC 16, 12-bit, 2Msps 16, 10-bit, 76.9Ksps
DAC 4, 12-bit, 1Msps N/A
USARTs 8 (one supports IrDA) 4
Hardware Encryption 128-bit AES, DES N/A
Timers 8, 16-bit 2, 8-bit and 4, 16-bit
Current Draw, 1Mhz, 1.8V 365uA 500uA
Event System Yes No
Price $10.20 $16.13

Not bad, right?  I’d say the XMega wins this round.  It’s faster, provides substantially better analog to digital conversion, offers digital to analog conversion (in other words, analog outputs – a feature not available on any ATMega), hardware-based encryption (again, not found on any ATMega), lower power consumption, and, wonder of wonders, a lower price.  I’m quite impressed (for what that’s worth) and am particularly excited about putting these new analog features to the test.  In fact, as I mentioned, I’ve just received my XPlained development board and have already written a quick test program to do ADC → DAC pass-through.  But I’ll describe my experiences with the XPlained board a bit later (spoiler alert: they weren’t all pleasant).

So what precisely does the new XMega series offer that makes it, in my opinion, such a substantial improvement over the ATMega series?  Let’s talk speed for a moment.  The old ATMega topped out at 20Mhz, at least officially (though overclocking is possible, as seen in the Uzebox gaming system).  But furthermore, there is no way to adjust the system clock on the fly (although you can, of course, adjust peripheral clocks).  You’d have to make fuse adjustments with an external programmer.  With the new XMega series, you can adjust the system’s clock frequency at run-time.  Both a 2Mhz and a 32Mhz internal RC oscillator are provided, plus a PLL which allows for clock multiplication (1x, 2x, 3x, …, 31x).  According to application note AVR1005, you can even use the PLL to increase the clock speed of your peripherals to a maximum of 128Mhz.  This might be useful for generating high-resolution PWM signals, for computing precise time intervals (think range-finders), or for just blinking an LED really really fast (although perhaps not this fast).  Man, I could’ve used this on my MS thesis

Another neat feature of the XMega series is the brand new event system which allows for high-speed signaling between peripherals.  This is not a communications bus in the traditional sense.  It’s actually more like a set of, shall we say, “personalized” interrupts sent between features.  Event signals can be sent quite rapidly – in no more than two clock cycles – and don’t require the CPU to be active.

The XMega Event System

The XMega’s event system opens up a whole new world of possibilities.  With it, you could tie a set of 16-bit counters together to form one highly-accurate 32-bit counter.  Or, how about this application note example:

You could use one event to synchronize two modules. For instance, you could use a pin change event to do an ADC conversion and an input capture on the Timer/Counter to get exact time-stamps for each conversion.

For more details on the event system, see the “Getting Started with XMega” application note AVR1005 or the “Getting Started with the XMega Event System” note AVR1001.

First Impressions of the XMega XPlained Dev Board

Alright, well let’s get down to business here.  As I mentioned earlier, I’m now the proud owner of a brand new Atmel XMega XPlained development board.  I was putting in an order with Digi-Key the other night when I thought to search for XMega products (yes, shame on me, I haven’t tried them out until now).  I found just one, but it was precisely what I was looking for: low cost ($30.16), USB-powered, and covered in blinking lights (well, nine of them anyways).  So of course I bought it.  I mean, it’s not quite as much of a steal as the $4.30 TI Launchpad, but even at $30, I didn’t even bother to do research before adding it to my cart.   I just figured it would work.  🙂  Bad idea, I know…

So what did I get for my money?  A pretty padded box and the board itself.  Nothing more.  No documentation whatsoever, only a printed messages on the outside of the box requesting I go online for any required drivers and data.

XMega Xplained Unboxing

Now the lack of paper is fine with me; if Atmel wants to save some trees, good for them.  I’d have gone online for datasheets and schematics anyway.  My only gripe here is that Atmel’s site isn’t all that easy to navigate.  In fact I don’t think I ever located a link to the ZIP file associated with AVR1927 (instead I just crossed my fingers, manually typed in the assumed link, and bingo).  But maybe I’m just bad at the internet.  Well for the sake of centralization, here are a few URLs I found helpful when getting started:

The XMega XPlained comes pre-programmed with a cute little application that blinks its nine LEDs and plays different sounds (drums, trumpets, etc. – just one- or two-second clips) when each of the eight different buttons are pressed. And I’ve got to say, the little speaker actually impressed me with its sound quality.  It’s not exactly a M-Audio studio monitor, but it’ll probably hold its own against a speakerphone.  And it’s certainly not being driven by square waves; they’re making good use of the XMega’s analog outputs (DACs).  So what else does the XPlained offer?  Well, here’s the official list:

  • External memory (8MB SDRAM, MT48LC16M4A2TG)
  • Atmel AT32UC3B1256
    • Communication gateway
    • Programmer for Atmel AVR XMEGA
  • Analog input (to ADC)
  • Analog output (from DAC)
    • Mono speaker via audio amplifier
  • Digital I/O
    • UART communication through USB gateway
    • 8 mechanical button switches
    • 8 LEDs (plus one bi-color LED)
    • 8 spare analog pins
    • 24 spare digital pins

Programming the XPlained using FLIP

So the pre-loaded software entertained me for about sixty seconds, after which my desire to reprogram the board overcame my fascination with lights and sound effects.  I didn’t have my AVRISP mkII handy (left it at work again), so I started by looking into reprogramming via the board’s USB connection.  The first thing I needed was a driver for the virtual COM port (Windows 7 did not recognize the XPlained), a single INF file:

USB CDC Driver (Virtual COM Port) – required for USART communications.

I was pleased to find that the instructions provided in the “Getting Started” guide (AVR1927) for using the Flexible In-System Programmer (FLIP) for RS232 programming were quite simple.  I downloaded and installed FLIP via this link.  I also had to import an XML configuration file (provided here), although it sounded like this file should have been included in the latest FLIP installer.  But before adding this file to <Install Directory>Flip 3.4.xbinPartDescriptionFiles, I received an error stating that “the device does not exist” when using BatchISP (the FLIP command line utility).  I also attempted to use the FLIP GUI directly, but for some reason the RS232 communication option was greyed out.  No problem though, I simply threw the programming commands given in the instructions into a simple batch file:

batchisp -device ATXMEGA128A1 -hardware RS232 -port COM25 -baudrate 115200 -operation onfail abort memory flash erase f blankcheck loadbuffer c:xmegatestdefaultxmegatest.hex program verify start reset 0

pause

I’ve highlighted the elements you’ll want to change when using this file.  Including that pause command causes the command window to wait for you to press a key before closing, that way you can take a look at the results of your programming attempt:

FLIP (BatchISP) Command Line Programmer

So using BatchISP (FLIP) worked just fine for me.  The whole programming process took a bit longer than I would have expected (maybe 20 seconds), but it’s not terrible.  The one catch is that you have to unplug the XPlained board, and then plug it back in while holding down switch SW0, every time you want to reprogram.  This is required in order to activate the bootloader.  Doing this gets old fast, and it didn’t seem to please my computer (it would occasionally freeze for a few seconds when the device was quickly plugged back in).  But there is an easier way; keep reading…

Programming the XPlained using the AVRISP mkII

So based on the literature I’ve run across, it seems the preferred means of reprogramming (and debugging) an XMega is via JTAG using either the AVR Dragon ($50), the AVR JTAGICE mkII ($300), or the Cadillac of debugger/programmers, the AVR ONE! ($600 – perhaps this is the reason for the exclamation point).  The new XMega series uses the PDI (Program and Debug Interface) programming interface (as opposed to ISP).  However, it is possible to use the AVRISP mkII programmer (though you cannot use it for debugging), which costs just $35.  And if you’ve done anything with AVRs in the past, you’ve probably got one of these hanging around (I should note that the original AVRISP, the one with the DB9 port, will not work with the XMega series).

Now, to get your AVRISP working with the XMega Xplained, you’ll need to create a simple pin adapter.  You cannot connect directly to the board as the pins are arranged for a 10-pin JTAG connection (I guess Atmel really wants you to use JTAG).  However, you’ll only need to connect four of the six pins present on your AVRISP, as shown in this diagram (found on page 9 of the XMega “Getting Started” guide, AVR1005):

AVRISP Pinout Comparison

These pins can be found on the XPlained’s JTAG connector, as shown in the schematics:

XMega XPlained JTAG Connector

Once you’ve made these connections, you can use AVR Studio to reprogram your device as usual.  Well, almost.  First, you need to make sure it’s fairly up-to-date (I used version 4.18, build 700 with success, but you might go straight to AVR Studio 5, which I’ve also tried with success).  You’ll then need to manually specify the ATXMega128A1 before programming or adjusting fuses.  Plus, and this is key, you’ll want to disable the JTAG interface by using AVR Studio to clear the JTAGEN bit on the fuses tab.  If you don’t, your programming may or may not be successful.  I actually got into an interesting cycle where alternate programming/read events would fail.  I’d perform one operation successfully, but on the next I’d see “Entering programming mode…FAILED.”  But disabling the JTAG interface took care of this issue.  And doing so does not prevent you from re-enabling JTAG later, or from using BatchISP (though you may need to reload the bootloader if you’ve erased it, which may be found in this ZIP).

For more details on programming and debugging an XMega, see this article (and actually, check out all of these “Getting Started with XMega” articles, they’re quite good).

A First Test of the Analog I/O

Now I think I’ve stated this already, but again, I’m pretty excited about the new analog I/O offered on the XMega series.  In particular, the 12-bit digital to analog converters (DACs) open up a whole new world of options.  I mean, there are all sorts of applications out there that might benefit from an on-chip DAC: function generators, analog power supplies, audio processors, lighting controls, you name it!

So the first bit of code I wrote for my XMega is a simple ADC → DAC pass-through.  It’s a touch long to include in this post (because of all the comments), but please feel free to download it here.  The code takes an analog input on ADCA1 (PORTA1, pin 96) in the 0-2.1V range and outputs a proportional analog signal on DAC0 (PORTA2, pin 97) in the 0-3.0V range.  Here’s a screenshot of the results taken using my RPI IOBoard and LabVIEW interfaces.  The bottom graph (red line) shows the sine wave signal being generated by the IOBoard and connected to the XMega’s ADC input.  The top graph (white line) shows the scaled sine wave being measured at the XMega’s DAC output:

XMEGA ADC-DAC Pass-through Test

You may be wondering: why the difference in input and output voltage ranges?  Well, here’s one additional problem I see with the XMega: Vcc (max 3.6V) is not directly available for use as a reference for the A to D conversion, only Vcc/1.6V (which is 3.3/1.6 = 2.0625V, in this case).  Now you can select AVcc (typically tied together with Vcc, perhaps via a filter) as a reference for the DACs, although according to the hardware datasheet, both ADC and DAC reference sources are limited to AVcc-0.6V, or 2.7V on a 3.3V source (which is what you get on the XPlained development board).

Now in testing these specifications, I have found the ADC limit to be fixed as stated, although when I’ve selected AVcc as the reference for the DACs I’ve seen max outputs reach just over 3V.  Honestly, I don’t know what prevents the XMegas from using Vcc as a reference, as this is commonly done with ATMegas.  Oh well!  You just may need to throw in a voltage divider and/or op-amp to compensate.

One other issue I noticed was noise in the ADC signal when measuring values near 0V.  This could be an issue with how I’ve setup my code, or with some other aspect of my hardware.  But you can see this effect in the slightly garbled low points of the sine wave shown in white in the above screenshot.  I guess the bottom line is that I’ll need to play around with this a bit more.  (NOTE: I believe we have solved this issue; it is a problem with the XMega chip itself.  The solution is to use a lower (e.g. 1V) reference for the DAC.  See comments section below.)  Apparently there are also calibration registers for the ADC, and some pretty advanced tweaks you can make.  Take a look at this page on configuring and tuning the XMega ADCs – it’s been a great help to me already.

Conclusions

Overall, I’m cautiously optimistic about the XMega and the XPlained development board.  I’ve encountered a couple of minor issues, and the list of problems in the errata section of the datasheet is frighteningly long.  I should also point out that a previous version of the XPlained, the XPlain, apparently had quite a few more serious issues.  You’ll find references and pictures of the XPlain if you do a bit of Googling.  I’m not sure who’s still selling it, but I can tell you that despite the picture and the name, Digi-Key is shipping the newer XPlained, not the old XPlain (this is where I got mine).

So I still say that the XMega a great leap forward by comparison with the ATMega series.  The only question left is what to do next?

I’ve been thinking about going further with this ADC-DAC application and creating an audio compressor and volume control.  You see, I’ve got this cheap portable speaker that I use with my Blackberry for listening to MP3s.  The trouble is, there’s no remote, and each track seems to play at a slightly different volume.  So I’m thinking of using the XMega to receive IR signals from a remote and then adjust the volume accordingly (by scaling the ADC result before sending it to the DAC).  And at the same time, it could automatically adjust volume, based on the incoming audio signal, within a certain range.  This is called compression.  My setup would require a bit of analog work to get the signals into the correct voltage ranges before and after processing, but a couple of op-amps would likely do the trick without much work.

That said, I’m open to other ideas.  Has anybody out there got suggestions for projects?

Home Sweet Garage

Alright, I think it’s about time for this silly article on plasma arc waste disposal to get knocked off the top of my site, don’t you?  It’s just fluff, honestly.  Filler.  And I’m tired of looking at it.  So how about a post on a real project for a change?  Sound good?  Great.

First though, a quick gripe.  I hate waiting for parts to arrive.  Specifically “last” parts.  Like that final DigiKey order, or in my case, a shipment of PCBs from Advanced Circuits.  You see, I now have everything I need to complete this really exciting new device I’m designing at work, except for the PCBs.

Assorted parts, but no PCBs...

And not having boards is kindof a show-stopper.  So I’m crossing my fingers and hoping that Advanced Circuits gets them shipped out early, as they so often do (because they’re totally awesome).

But let’s get down to business.  If you happen to have been reading my blog about six months ago, you may remember that I recently moved to the middle of nowhere Waterloo, Iowa to start working for John Deere.  Now prior to moving here, finding a place to live has been, for me, frustrating.  “Oh, here’s a place that’s nice, but it’s too far away,” or, “That’s way too expensive,” or, “Uh, what’s that growing on the ceiling?”

Not so this time.  Deere actually provided a relocation assistant to show me several nice places around town.  All I had to do was tell her what I was looking for and BAM, there we were.  Plus, the cost of living in Iowa is virtually zero.  So here I am, renting a lovely townhouse, about ten minutes’ drive from work.

Now, nothing’s ever perfect, and this place is no exception.  For instance, it’s got a nice single-car garage with an opener, but there are two problems.  First, the remote control has terrible range.  My landlord warned me about this, but explained that I just needed to find that “sweet spot” for it in my car.  But this thing is kindof a brick and looks rather like some RadioShack project box.

This really is a garage door opener.

The second problem is lighting.  The garage door opener does have a single light bulb which comes on when the unit operates, but it’s pretty anemic.  This isn’t helped by the fact that the inside of the garage is almost all dark wood, either.  Plus it seems to take a few seconds for this light come on, and it only stays on for a few seconds afterwards.

So in Iowa, winters are long, dark, and cold.  Not unlike a mine shaft, I imagine.  But I like light.  So I took a trip to Home Depot one weekend, and for about $50 (those motion-detecting switches are kindof steep) solved problem number two quite simply.

Let there be light!

Yep, that’s a Lutron motion-sensing light switch, wired into an extension cord, and a simple reflective lamp fixture.  And it’s all just clamped to the top of a set of shelves I already own.  Easy peasy.  And it works like a charm.  The switch has two little pots to control sensitivity and on-time.  Which is great, because I love adjusting things.  So now I can pull into the garage, catch those last few minutes of Wait Wait, Don’t Tell Me, and then hop out and voilà, let there be light.  And I saw that it was good (enough).

Now for a while, I lived with problem number one without much complaint.  I had to be in my driveway before the remote would trigger the opener, but it wasn’t a huge deal.  Then for some reason, it routinely started failing me.  My car actually had to be within a few feet of the door for it to open.  And more than once I had to get out of my car (heaven forbid) and wave the remote around in front of it.  I replaced the battery, but this made no apparent difference.

So again, one weekend I decided I’d had enough and sat down at my workbench to sort out the problem.  I popped the project box remote open and started probing.

A very simple garage door opener

To make a long story short, I discovered that the transmitter was simply broadcasting a repeating pulse train via (I believe) amplitude modulation.  Somewhere in the 800kHz range, although I don’t have equipment capable of measuring such high frequencies with any sort of precision.  I can tell you that the DIP switches you see control the sequence of the transmitted pulses to match a particular receiver.

Get on board the pulse train!  Woo woo!

Since I know virtually nothing about RF amplification, and didn’t want to risk damaging the remote, I decided to piece together my own remote from components I had lying around.  Here’s what I used:

Transmitter:

  • SparkFun 315Mhz ASK transmitter module ($4)
  • AVR ATTiny13 8-bit, DIP8 microcontroller ($2)
  • 5V Regulator
  • 9V Battery
  • Protoboard
  • Button

Receiver:

  • SparkFun 315Mhz ASK receiver module ($5, discontinued)
  • Olimex AVR-MT-128 development board ($75)
  • 12V wall-wart power supply

Now the precise components specified here aren’t really too important.  I used what I had.  I would recommend the RF transmitter and receiver though (except that the receiver has been discontinued).  These are both pretty amazing for the price; I got them a number of years ago and haven’t yet put them to much use.  But they’re fantastically simple.  Just apply TTL-level serial data to the input of the transmitter, and watch it appear at the output of the receiver.  That’s it.  No configuration/setup required.  The only complication is that there is no error checking.  So you’ll need to be clever about dealing with the occasional garbage data.

So how does this all work together then?  Well, when you press the button on the prototype remote, the 9V battery is then connected to the transmitter module and the MCU (via the 5V regulator).  The MCU then sends out a slew of bit-banged (since the ATTiny13 has no hardware UART) serial data to the transmitter, which then sends it wirelessly to the receiver.

Now this is a garage door opener!  Well, sortof...

The receiver then sends this data to the ATMega128 (on the AVR-MT-128 dev board), which does have a hardware UART.  If the received data is correct, a relay on the dev board is quickly closed and then opened again.  The relay terminals are wired up in parallel with the door open/close button inside the garage.  Thus, the action of the relay simulates a real button press and causes the garage door to open/close.

The receiver

That’s it.  Again, pretty simple, right?  The receiver, since it’s got an LCD display, also indicates how many times the door has been actuated (either opened or closed).  This was a comforting feature during initial testing, because it allowed me to determine whether or not my garage had been opened at any unexpected time.

Sophisticated, yes?Well I’ve been driving around with this silly protoboard taped to my center console for about two months now.  It’s been working great; I can now operate my garage door reliably from the street (a distance of probably 50′), and this little gadget has made for such a nifty conversation piece that I might just leave it in protoboard form.  I mean, a small enclosure would be nice and stuff, but…

Seriously though, if you have any cheap and cheerful ideas for housing the transmitter in a more elegant and robust manner, do let me know in the comments.  By the way, at this point in a post I’d usually provide links to my code, but I’m not going to do that this time.  I’d rather not make it too easy for the tech-savvy thief to break into my garage, you know?  Yea, I’m probably just being paranoid, but still.  Lots of crime in Iowa you know. 🙂

Now ultimately I’d like to extend the functionality of my device so that it automatically opens and closes the door when I come and go.  If you’re curious about how that might be done, take a look at one of my older posts on the subject.  Thanks for reading though, and feel free to pose any questions below!

The Mechatronics TVIP (+Video)

MechatronicsToday’s post is going to be a trip down memory lane for me.  The TVIP or Thrust-Vectoring Inverted Pendulum was my very first real engineering project in college.  My good friend Alex and I constructed it almost five years ago, during the second semester of our freshman year at RPI.  We actually started designing the system during our very first semester.  However, the bulk of our work was performed for an independent study in the [former] RPI Mechatronics lab during the spring of 2006.  By the way, in case you’re wondering, the RPI Mechatronics lab closed down when Dr. Kevin Craig decided to leave RPI for Marquette University.  Of course, he took most of the lab with him, and now runs the Multidisciplinary Mechatronics Innovations lab at Marquette!

Why do I bring this up now?  Five years later?  Well as I’ve mentioned before, I’ve been doing a lot of job interviewing lately.  During interviews, the TVIP seems to come up pretty frequently.  It’s still a great example of the work I did while employed in the Mechatronics lab.  And I’m still pretty proud of this rickety old thing.  I consider it to be quite an accomplishment, particularly for a pair of college freshmen.  🙂

So what exactly is the Thrust-Vectoring Inverted Pendulum?  Well, like many Mechatronics lab projects, it’s a demonstration of control systems, mechanical dynamics, electronics, and modeling.  To be more specific (and simple), it’s a big aluminum pendulum with a scary-looking propellor attached at the end.  A diagram should help explain:

Thrust-Vectoring Inverted Pendulum (CAD Model)

What you see there is a dual A-frame, about three feet tall, supporting a horizontal shaft to which a pendulum is connected.  That shaft is suspended by a pair of bearings.  An optical encoder is used to detect the angular position (angle θ) of the shaft and pendulum.  At the end of the pendulum, the propellor and motor are attached to a geared DC servo motor, which is used to vary the direction (angle φ) of the propellor’s thrust.  Hence the term thrust-vectoring (plus, five years ago, it sounded really cool).

Now the purpose of this setup was to demonstrate the control of an unstable system.  Thus, our goal was to vary the direction and magnitude of the propellor’s thrust in order to swing up the pendulum and then balance it in its inverted, unstable position.

This was accomplished by using two separate control loops, both implemented within LabVIEW.  The first controller was responsible for swing-up (since the propellor could not produce enough thrust to pull the pendulum straight up).  As you’ll see in the video below, the swing-up algorithm was essentially a proportional controller with an excessively high gain.  This actually caused the system to go into unstable oscillations.  That sounds pretty bad, doesn’t it?  But it’s exactly what we wanted.  Just like a child on a playground swing, our proportional controller caused the pendulum to swing higher and higher.  However, instead of continuing to let the system oscillate unchecked, once the pendulum started to close in on its balance point, LabVIEW switched the output over to a PID control loop.  The job of this second controller was to catch the pendulum and then hold it, as closely as possible, in its verticle, inverted position.  How about a video before I go on?

Now that video was taken at the conclusion of the Spring 2006 semester.  You’ll notice that the pendulum still oscillates slightly (plus or minus about eight degrees) when inverted.  This was due to an improperly tuned PID controller.  We did improve that performance somewhat over the next year or so.  During my later employment in the Mechatronics lab, I wrote up a paper that, unfortunately, never made it to publication.  It contains a bit of the more serious math on modeling and control I didn’t really understand when Alex and I first designed this system.  You’ll find a link to this paper at the end of my post.

The Details

So just what makes this thing tick?  Well, the motor and propellor are pretty standard fare for RC electric planes.  Of course that doesn’t make them any less scary.  Running this thing indoors produced a lot of noise, and you had to keep clear of the pendulum while it was operating (lest you lose a finger).  The propellor and motor were connected to a standard geared DC motor which was actually capable of rotating 360 degrees.  This presented another safety hazard; if the positioning motor rotated too far, the prop would begin biting into the aluminum pendulum.  Amazingly, in two years of operation, this never happened.  But it could have.  Control of this positioning motor was accomplished by a third PD control loop within LabVIEW.  Angular feedback was given by an optical encoder.

Now we really should have bought a commercial, heavy-duty hobby servo in order to vector the thrust of our prop.  This would have likely been safer and easier.  But what did we know back then?  Ultimately we solved the safety issue by replacing the propellor with a ducted fan.  It didn’t quite produce as much thrust, but you didn’t have to worry about how to grab the pendulum in the event of a control/electronics failure.

The New Thrust-Vectoring Inverted Pendulum

And speaking of electronics failures, we did have a couple of frightening moments during our initial testing.  The speed of the propellor motor was governed by a power MOSFET.  Twice, that FET failed during operation; in both cases it failed by shorting.  The result?

Instantaneous full-power thrust.

Pretty scary stuff, particularly since we first powered the prop motor using a 12V lead-acid battery.  However, we also eventually replaced that battery (which you see in the video above) with a dedicated high-current power supply (the box with the RPI sticker).

Now as I started to mention earlier, both the propellor and positioning motors were driven by microcontroller-produced PWM signals wired into power transistors.  We used a microcontroller (MCU) for PWM generation because the NI data acquisition (DAQ) hardware we had available at the time could not generate these signals.  Instead, it produced analog outputs which were fed into the ADCs of our MCU.  The MCU (an AVR ATTiny13) then produced PWM signals whose duty cycles were proportional to those analog inputs.  Fortunately, the DAQ hardware we had could easily process our two quadrature encoder inputs into angular measurements.

Well I’ll leave the rest of the details to the paper linked below.  If you’re interested in how to model this system mathematically, as well as how to implement the various controllers described here, have a read!  I think you’ll find my test in characterizing the viscous damping of the ducted fan rather interesting.  If only I’d had Eureqa back then…  Oh, and I’ve also included MCU source code for the ADC-PWM conversion:

Paper: A Mechatronics Case Study: Thrust Vectoring and Control of an Unstable System
Schematic: GIF Image (Also available in the paper)

Feel free to make comments or ask questions in the comment section.  Thanks!

Fun with Failure

Have you ever come up with a neat idea?  An idea for some really useful sort of device?  And then you find out that it is, at least for now, a physical impossibility?

I had just such a neat idea this week.  At least, I thought it was a neat idea.  You see, for the past few weeks, I’ve been traveling around the country interviewing for various different jobs.  One of these jobs is with John Deere in Waterloo, Iowa.  Now for those of you who don’t know, it gets cold up in Iowa.  Their average January temperature is a mere 16°F.  I was imagining myself leaving work after a long day, going out into the cold, and then shivering in a very cold Jeep Liberty (my car) for the drive home.  So I’ve been thinking, wouldn’t it be nice if I could somehow heat my car while it’s outside?

A Solar-Heated Jeep?

Well, I don’t want to run a heater using my car battery, for obvious reasons.  However, I have this nifty 90W solar panel that I’m not really using at the moment (although it is acting as a glorified cellphone charger, and has been put to good use in the past).  Perhaps I could mount this to the top of my Jeep and use it to run a small heater.  My only question – would 90W be enough power to effect a substantial (20-30°F) temperature rise?

Initially, my gut feeling said no.  For one thing, from experience I know that my 90W photovoltaic (PV) panel will never produce 90W if mounted horizontally on the roof of my car.  Even on a perfectly clear and sunny winter day, it won’t be getting strong, direct sunlight.  So perhaps I could expect 60W at best, but on a cloudy day I might see less than half of that.  But more importantly, on a sunny day, wouldn’t I already be trapping more than 90W via my windows and the greenhouse effect?  Because if so, this effect has never produced a particularly warm interior.

Of course there’s only one way to answer these questions.  Science!  Particularly, the study of thermodynamics.  I’ve taken a couple of courses on the subject, but I still had to refer to my book for this formula, derived from the first law of thermodynamics:

An equation for the rate of temperature change for an object at a given power input/output.

This says that the rate of change of an object’s temperature (dT/dt) is equal to the power (P) absorbed or released by that object divided by its mass and its specific heat.  So for my first experiment, I decided to heat the interior of my Jeep by idling the engine and turning the heat to full-blast.  I then hopped out and remotely measured the interior temperature during cooling.  How did I accomplish this?  I temporarily re-purposed my Doom Box, which now contains both a LM34 temperature sensor and an XBee wireless transceiver.  Here’s a snapshot of the latest PCB revision, powered by an ATMega644P MCU:

Doom Box PCB (Rev3)

So here’s what the temperatures looked like during my first test.  The yellow vertical line below indicates when the engine was shutdown and cooling began:

Test #1 Graph

I should note that the Jeep’s temperature measurement was filtered by a 40 second (eight sample) moving average filter implemented within LabVIEW.  Also, the internal temperature sensor was placed on the floor in front of the back seats.  Exterior temperature measurements were taken manually using a digital thermometer and are represented by a linear trend-line shown in red above.

So during this test, my jeep was outdoors, parked in the shade, from 3-5PM.  You’ll notice that during this time the exterior temperature dropped by about ten degrees as the sun started to set.  However, the temperature inside the Jeep dropped slightly faster, as you would expect.  There was also very little wind during this test.

Now to apply the formula!  The drop in temperature between t = 4000s and t = 6000s is easily determined from the graph: 4.7°F or 2.6°C.  The trick is in determining values for mass and specific heat.  For this first test I decided to simply approximate the mass of air and metal within the car.  I calculated that the Jeep contained about 4kg of air at a cp of 1005J/kg-K as well as about 20kg of steel (e.g. in the seats and wheel) at a cp of 490J/kg-K (it’s pretty interesting to note that air has a higher specific heat than most metals).  I decided to ignore small pieces like plastic and seat stuffing, as well as everything under the hood (an assumption which proved later to be somewhat stupid).

So plugging all of that into the equation above yields a power loss of just about 18W.

Well now, eighteen watts is pretty surprising.  I wasn’t expecting losses to be that low for an interior-exterior temperature difference of 25°F.  This called for a second round of testing.  This time, I moved my Jeep into an insulated, closed garage.  Doing this allowed me to get rid of temperature variations due to solar radiation and wind.  It also prevented rapid changes in exterior temperature.  I then inserted a controllable heat source (an old laptop) into the car, located a few feet away from my interior temperature sensor.  The laptop was configured in such a way as to draw about 46W via a 120VAC inverter.  In theory, this level of power should have raised the Jeep’s internal temperature by about 12°F per hour.  Did it?  Well, I think the graph below speaks for itself:

Test #2 Graph

Yep, that’s definitely a failure.  It turns out that an input of 46W could only raise the car’s interior temperature to about five degrees (F) above ambient.  So the bottom line is my 90W solar panel isn’t going to have much of an effect.

So what went wrong with that first test?  Why did I calculate the need for only 18W?  Two reasons.  First, I didn’t account for all the residual heat in the engine compartment.  This helped keep the Jeep’s interior temperature higher than it would have been otherwise.  I likely also underestimated both the mass and heat capacity of the car’s interior.  In my defense, it’s not exactly an easy thing to determine.  In thermodynamics classes, you get problems about isolated, well-defined blocks of aluminum and ideal, constant heaters.  In reality, you get an ill-defined mixture of materials and variable heat sources.

Just out of curiosity, I used the first few minutes of my second test to make a better guess at the Jeep’s mass and specific heat.  In five minutes (300s), the temperature rose by about 0.7°F or 0.4°C.  Assuming this rise came only from heat input by the laptop, the term mcp = 34,500J/K.  That’s actually not too far from my initial guess for the first test, which worked out to 13,800J/K.  What this likely means then is that in my initial outside test, the Jeep was losing about 45W instead of just 18W.  But I’m also guessing that a lot of heat was still coming in from the engine compartment.

Anyway, I hope these results aren’t too confusing.  I’m not making any guarantees about the correctness or validity of my methods or assumptions.  What I’m really trying to say here is that you’ll need a lot more than 90W of PV panels to heat your car’s interior.  That, I can say with confidence.  I’d love to hear comments on this, particularly if you’re an expert in thermodynamics!  Where have I gone wrong here? 🙂