DC blocking capacitor

We've had a few questions about the in-line capacitor on our audio player board. This is the capacitor between the PIC pwm output pin and the gate pin on the transistor amplifier. At first glance, it seems a bit counter-intuitive: we're "blocking" the output from the PIC to the speaker. What's it there for?

Well, here's the thing - the circuit will actually work without the capacitor in place.
Go ahead, try it. You can connect the output from the PIC directly to the gate on the transistor, and you'll still hear sound. It might not be quite as loud, but it'll still be an amplified signal. So what does the "blocking capacitor" do?

Consider what's happening - we're using PWM to drive a speaker.
It's not the most efficient use of the speaker, since we're not generating negative voltages, so we're only every driving the speaker "forwards" using a positive voltage. But let's ignore that for a moment!

Our PWM is creating an "average" voltage over a particular time period, to move the speaker by a certain amount. Now most digitally recreated sound waves go from minus the maximum amplitude (let's call it -5V for simplicity) and plus maximum amplitude (e.g. +5V). When there's no sound/signal, there's no voltage 0V.

But because we don't have negative values in our PWM , we're having to use a value 0-255 to represent the full range from -5 (in this example) to +5.

So -5 (the lowest possible value in the wav file) becomes PWM value zero (the lowest possible value in our PWM output). And +5 (the maximum value in the wav file) becomes PWM value 255 (the highest possible value in our PWM output).

So where the audio file is normally zero (half-way between max and min) our output PWM value is actually 128 (half-way between 0-255). When there is no audio signal, our PWM output is 128, or half-duty cycle, or (on average) 2.5V output.

Now driving 2.5v continuously through the coil in our speaker is going to cause it to heat up and over time, eventually burn out the speaker. So what we do is put a capacitor between the output pin and the gate (which in turn controls the amount of current going into the speaker).

So now, while our audio is silent, there's nothing actually coming out of the other side of the capacitor.

• When the wav signal falls, the capacitor discharges  and creates a high output.
• When the wav signal rises, the capacitor starts charging up and the "output" side falls low.
• The output from the capacitor lags the input by a single sample width.

This means that while the signal is fluctuating - ie. we're using an AC signal - the capacitor allows the signal to "pass-through" albeit one sample width behind the input. When the AC signal becomes DC (a period of sustained silence, for example) the output from the capacitor drops to zero and no voltage is passed into the speaker. The "blocking capacitor" acts like a filter - stopping DC current but allowing AC signals through.

This is a very crude method of driving the speaker, but one that works.
The downside is that where a very quiet audio signal is being played, with large gaps of silence, or very quiet background noise, the speaker is hardly active at all, and you can hear all the other "noise" in the line (the PWM carrier signal, for example).

We can hear this at the start of the song being played in the earlier video.
For the first ten seconds or so, the background sound of rain just sounds like a digital noise and you can hear the hum of the PWM signal. This is because parts of the audio signal are being treated as "rippling DC current" rather than a true AC signal. However, once the audio signal amplitude increases, a large AC signal is generated and the blocking capacitor allows all of the signal to pass into the speaker and the audio clarity improves.

Different speakers sound different

It's almost so obvious as be incredible!
Here's our PIC-based wav audio player with a cheap 15p speaker from Farnell. The difference between this and the speaker on the alarm clock is amazing! We've tried all kinds of different ways of amplifying the output but the best/loudest to date is this 16 ohm, 700hz, 90dB piezeo speaker with a humble BS170 FET transistor.

The audio in this example is much clearer than with the earlier speaker (and louder too).
Perhaps this is because rather than put the speaker in a box, we're holding it to create a cavity behind the speaker cone. You can definitely hear the speaker gain more definition between hanging loosely and being "encased in flesh"!

Interestingly, the best sound came when we created a tube effect rather than a closed box shape with the hand holding the speaker. Whether this only applies to hands, or to enclosures in general, we've yet to see.....

Another video interruption - serial audio with a PIC 16F1825

While writing up how SD cards work, and reading files using FAT16, we've also been developing our little audio board a bit further. We got as far as playing audio files from our SD card and fitting them to the alarm clocks for a tester project the other day.

We've now taken the project one stage further, and introduced serial/uart support.
So rather than play a file immediately, you can send serial commands to the audio board.

• # - send back a list of all files found in the root directory
• | - pause playback
• > - resume playback 
• \ - half current volume (max four times)
• / - double current volume (to max)

At any time you can send in a filename over serial.
If the filename is in the format xxxxx.yyy (where xxx is any string up to 8 characters and .yyy is a full stop followed by a three-character extension) the chip will search the root directory for a file with the same filename and extension.

If a file is found, it begins playing immediately.
If the chip is in the middle of playing a wav, the current wav file is stopped, the current sector is closed, and the chip plays the new sound from the start.

Note - our video is blurry (again) thanks to wonderful camera-phone technology! And trying to hold the speaker in one hand, the phone in the other, and typing at the same time ;-)

The PWM carrier signal generates a hum which is much more noticeable in the video than in real life, but in a future revision, we'll look to remove this using a low-pass filter or capacitor across the speaker terminals.

At present we're playing raw (headerless) PCM wav files.

The frequency is hard-coded to 22khz and all sounds are played in mono at 8-bit. This requires the sounds to be prepared before copying them to the SD card. A future revision will be able to play different types of wav files, but for now, we've a single-chip, low-cost, low component-count audio player board which works with all SD cards we've tried it with!

A short interruption for a demo

Here's a quick movie showing our final audio player actually being used in a final product.
The PIC has been programmed to read a value from eeprom, increase it by one, rollover back to zero once a certain value is reached, and use this value to decide which sound to play.
In doing this, we can get our alarm clock to play a different sound each morning!

The original alarm clock mechanism has been kept the same - when the alarm time is reached, the clock mechanism pulls a line low. We use this as the ground for our board, so that it is switched on an off by the alarm clock mechanism (the mechanism keeps the line low for about 15 minutes after passing the alarm time). By doing this, we're conserving the batteries, since the entire circuit is only every powered for about 30 minutes each day (once for 15 mins in the morning, once in the evening, unless the alarm on/off switch has been moved to disconnect the ground rail from the circuit).

Playing audio with a PIC 16F1825 microcontroller and SD card

It's taken literally weeks to get right, but finally, we've got a working example of how to play a raw/wav file from an SD card using a PIC16F1825 microcontroller.

In a departure from previous projects, we've had to put our favoured Oshonsoft compiler to one side and learn how to use Sourceboost C compiler. This is because the 16F1825 isn't supported by Oshonsoft, and we're using this micro because
a) it has loads of RAM and ROM (compared to similar chips in the same price range)
b) it runs at 32Mhz from an internal oscillator (we need plenty of clock cycles to keep the sound playing)
c) of course, it's cheap

Rather than spend time writing about each and every frustration we had during this project (and there were plenty!) we decided to get the thing working, then write up what's going on - there's nothing more frustrating than reading how someone did something, only to get to the end to be told "it didn't work, so don't you do it like this in future".
One of the biggest hurdles was moving from software to hardware periperhals.
Had we a super-fast processor, we'd probably have bit-banged everything (i.e. done all the interfacing  - PWM and SPI - through software) but we needed the data to keep flowing without interruption so that the sound played smoothly, so we had to use hardware SPI and hardware PWM. This isn't always as straightforward as the datasheets suggest!

This is the first of a multi-part post.
We're going to, first of all, interface with a SD card via SPI. Once we've got this interface working, we're going to investigate how FAT works and finally, read some files off the disk.

The first thing to do is hook up our PIC and SD card.
This particular PIC has registers which allow you to move the pins around (e.g. put the SPI output onto different pins) so there are probably lots of different ways you can hook things up. But this is how we did it, and it works ;-)

For testing, we've driven the speaker through a BS170 FET on the ground line. This isn't the best way to do it and in the final version we'll use a proper amp (like a LM386 or TS922) but it's good enough for now! Note that putting the transistor to ground does give a slightly better/louder signal than putting it on the powered side (but both will work).

Now before we get started, we need a couple of header files and some "serial comms helper functions" - these are functions we'll use to write messages back to the PC so we can see what's going on inside that little black box!

#ifndef _SD_H_
#define _SD_H_

#include "common.h"
#define SD_BLOCK_SIZE 512

Boolean sdInit();
UInt8 sdSpiByte(UInt8 byte);

Boolean sdReadStart(UInt32 sec);
void sdNextSec();
void sdSecReadStop();

#endif

This is our sd.h file

#ifndef _COMMON_H_
#define _COMMON_H_

#include

typedef signed char Int8;
typedef unsigned char UInt8;
typedef unsigned char Boolean;
typedef unsigned long UInt32;
typedef unsigned short UInt16;

#define inline

#define true 1
#define false 0

void log(UInt8);
void fatal(UInt8 val);
#define P_LED portc.2

#endif

This is our common.h file

And in the main file, main.c, we need a few functions to get us started.

#include "common.h"
#include "SD.h"

#define FLAG_TIMEOUT            0x80
#define FLAG_PARAM_ERR            0x40
#define FLAG_ADDR_ERR            0x20
#define FLAG_ERZ_SEQ_ERR      0x10
#define FLAG_CMD_CRC_ERR      0x08
#define FLAG_ILLEGAL_CMD      0x04
#define FLAG_ERZ_RST            0x02
#define FLAG_IN_IDLE_MODE      0x01

#pragma CLOCK_FREQ 32000000
#pragma DATA _CONFIG1, _FOSC_INTOSC & _WDTE_SWDTEN & _PWRTE_ON & _MCLRE_OFF & _CP_ON & _CPD_ON & _BOREN_OFF & _CLKOUTEN_OFF & _IESO_OFF & _FCMEN_OFF
#pragma DATA _CONFIG2, _WRT_OFF & _PLLEN_OFF & _STVREN_ON & _LVP_OFF

void UARTInit(){
      //
      // UART
      //
      baudcon.4 = 0;      // SCKP      synchronous bit polarity
      baudcon.3 = 0;      // BRG16      enable 16 bit brg
      baudcon.1 = 0;      // WUE      wake up enable off
      baudcon.0 = 0;      // ABDEN      auto baud detect
     
      txsta.6 = 0;      // TX9      8 bit transmission
      txsta.5 = 1;      // TXEN      transmit enable
      txsta.4 = 0;      // SYNC      async mode
      txsta.3 = 0;      // SEDNB      break character
      txsta.2 = 0;      // BRGH      high baudrate
      txsta.0 = 0;      // TX9D      bit 9

      rcsta.7 = 1;      // SPEN serial port enable
      rcsta.6 = 0;      // RX9 8 bit operation
      rcsta.5 = 1;      // SREN enable receiver
      rcsta.4 = 1;      // CREN continuous receive enable
     
      spbrgh = 0;      // brg high byte
      spbrg = 51;      // brg low byte ()
     
      apfcon0.2=1;      // tx onto RA.0            
}

void UARTSend(unsigned char c){
      txreg = c;
      while(!txsta.1);
}

void UARTPrint(char *s){
      while(*s) {
      UARTSend(*s);
      s++;
      }     
}

void UARTPrint(char c){UARTSend(c);}

void UARTPrintNumber(unsigned long n){
      unsigned long k=1000000000;
      while(k>0) {
            UARTSend('0'+n/k);
            n%=k;
            k/=10;
      }
}

void UARTPrintLn(char *s){
      UARTPrint(s);
      UARTPrint("\r\n");
}

void UARTByte(unsigned char b){
      const char *hex="0123456789abcdef";
      UARTPrint("0x");
      UARTSend(hex[b>>4]);
      UARTSend(hex[b & 0xf]);
}

void UARTLog(char *s, unsigned short iv){
      UARTPrint(s);
      UARTPrint(" ");
      UARTPrintNumber(iv);
      UARTPrintLn(" ");
}

void fatal(UInt8 val){            //fatal error: flash led then go to sleep
      UInt8 i, j, k;

      for(j = 0; j < 5; j++){     
            for(k = 0; k < val; k++)
            {
                  delay_ms(100);
                  P_LED = 1;
                  delay_ms(100);
                  P_LED = 0;
            }
           
            UARTLog("Error",val);
           
            delay_ms(250);
            delay_ms(250);
      }
     
      while(1){
            asm sleep
      }
}

We'll be calling on these functions a lot, so it's good to get them down good and early!
They should be pretty self explanitory if you're familiar with the C language; the things to look out for are the PIC internal registers used to set up the hardware peripherals.

UARTInit( ) is where the hardware UART/serial comms is set up.
We've put the serial TX pin onto pin RA.2 because we're using a PicKit2 (clone) to program our PIC. Why does this matter? Because if we use the same pins for serial data as we do for programming, we can also use the built in serial/UART tool built into the PicKit2 software without having to change any wiring!

PicKit2 in UART mode

PicKit2 in programming mode

It just so happens that in data mode, pin4 on the programmer is used for receiving serial/UART data (RX). In programming mode, pin4 on the programmer is programming data (PGD). The programming pin on the PIC is RA.0 (pin 13). By putting the UART TX pin onto RA.0 in the UARTInit function we can leave the programmer connected and simply flip between programming and UART/serial modes in the PicKit2 software.

Hardware requirements for 22khz audio with PIC microcontroller

We've spent quite some time looking into different implementations of playing audio from an SD card. There are quite a few out there, using both PIC and AVR (atTiny) . Rather than just use some existing code (although we're not ruling that out completely) we've been thinking about how to implement audio playback on a microcontroller.

At first, it seems quite straight forward: get a byte or two of data from an SD card, send to a PWM routine and make a speaker vibrate. The numbers involved don't sound too shocking either - until you start to look into them.

For example:
An audio sample recorded at 8-bit, 22khz requires the variable voltage on the speaker to change 22050 times per second. That's not a bit deal. Is it? We've millions of clock cycles and need to vibrate a speaker tens of thousands of times a second. No problem! Surely?

We're running our microcontroller at a maximum of 16Mhz (because the max supply voltage is 3v - for USB and 5v designs, you can go much higher, but at relatively low voltages, the maximum oscillator value is affected. The maximum speed you can run a low- to mid-end PIC at about 3v is 16Mhz). With an 8-bit PIC, the operating frequency is fosc/4 (i.e. one instruction takes 4 clock cycles). So running at maximum speed, from a 3v (2xAA battery) supply our PIC can do 16/4 = 4MIPS (million instructions per second).

That's still not shoddy.
But when we consider that we need to change our speaker voltage 22050 times per second, we must divide 4 million by 22050. Which is 181.4
So every 181 clock cycles, we need to change our speaker frequency.
And changing the PWM speed will eat into these precious clock cycles.
Which means we're going to end up with actually very few clock cycles for reading the data from the SD card.

Conclusion -
We may end up down-sampling our wavs to 11khz or lower to get a reasonable playback sound. Or we might just have to move over to AVR/atTiny and "borrow" some existing code!

Alarm clock project - playing WAV files with a PIC microcontroller

An interesting project has come up as a fund-raiser for BuildBrighton members - to "hack" some alarm clocks and modify their behaviour so that instead of playing a single sample when the alarm sounds, one of up to seven different sounds can be played.

The clock hardware looks simple enough - three AA batteries are used; one single battery keeps the mechanical clock mechanism moving, and the other two are wired in series and connected to a sound playing device whenever either the alarm time is reached, or the user presses a button on the clock casing:

We're looking to reuse as much of the hardware as possible and this looks perfectly possible - with the exception, perhaps, of the simple PCB with black epoxy blob hiding what's going on! We're going to have to guess at how the clock alarm works, but it's not unreasonable to suspect that there's a microcontroller on-board, powered by the 2xAA batteries, which is waiting for a low signal on an input pin. When this input signal is received, the controller wakes from sleep, plays a sound then goes back into sleep/suspend mode.
The simple on/off slide switch breaks continuity between the low signal from the clock mechanism when in the off position (so you can turn the alarm off at weekends, for example) and the push button simply connects in parallel to the alarm mechanism - so the user can activate the sound just as if the alarm time had been reached on the clock.

With these assumptions in place, we're looking to replace the sound playing device with one of our own. Because a number of these clocks will be required, cost is an important consideration - though as is complexity of the circuit/software, as this will be a group project.

With all this in mind, we're proposing a PIC based solution (of course) using a DAC (digital-to-analogue converter) with the different sound samples stored on a regular SD card (read back via SPI).
There are loads of mcu-based sound players on the 'net, but many require expensive "wave shields" or third-party code libraries; we're after a solution that we can fully control ourselves, is not subject to restrictive licencing, is easy to understand and cheap to implement. That means building something from scratch....

To kick off with, we need to understand how we're going to play a sound.
Sound is generated when a speaker fluctuates backwards and forwards by varying amounts. Sounds can be represented by a "sound wave" and it is these "waves" that we're looking to capture and digitize so we can play them back on demand,.

To digitize a sound, we need to approximate the sound wave as a number of numerical values:

There are two important values when converting sound to digital values - bitrate and sampling frequency. These are terms that get thrown about quite a lot, but few people actually understand what they mean! In our example, we need to divide our sound wave up into a number of (vertical) slices.
This is the sampling frequency - how often we approximate the shape of the graph every second.
Common sampling rates are 44.1khz (CD quality), 22khz (tape quality), 11khz (radio quality) and 8khz (telephone quality). (A brief description of sampling can be found here - http://en.wikipedia.org/wiki/Sampling_rate)

Now we've divided our sound wave/graph into vertical slices, we need to assign a value to each "slice". The precision of these values is called the "bitrate" - i.e. the number of bits used to represent each slice of the graph.

For our sound playback, we're going to use 8-bit samples and 22khz frequency (half the quality of CD quality sound). This should give a reasonable playback quality, given that we're only using very cheap hardware and a transistor and cheap speaker to actually play the sound(s). We decided on 8-bit sound samples to keep things nice and simple in the microcontroller (the PIC micrcontroller range(s) we like to use - 16F and 18F - are 8-bit microcontrollers).

The sounds will be converted into 8-bit, 22khz format - using some software like Audacity (http://audacity.sourceforge.net/) and the raw sound data downloaded onto an SD card. The card will be connected to our PIC so that when we want to play back a sound, we give the SD card a byte/register value starting point and simply stream the data back off the card in a single SPI stream, one byte at a time (most SD cards support SPI as a legacy/fallback format).

If we're playing an 8-bit, 22khz sound file, this means that 22050 times per second, we need to read a single byte value from the SD card, convert this value into a variable voltage, and send it to the speaker (e.g. where the byte from sound wav is half value - 128 or 0x80 - this represents half the waveform amplitude so we want to set the output voltage to half of maximum). This all sounds fairly straight-forward so far. Where it gets complicated is getting this digital value out as an (analogue) voltage:

Audio out using PWM:

A microcontroller pin can take one of two states - high or low. This equates to full voltage and no voltage. There's no easy way of providing "roughly half voltage". One way to fake it, is to use "pulse width modulation". This basically means flicking an output pin on and off really quickly so that the average output voltage can be increased and reduced over a specific time period

If we connect our speaker to an output pin, add a smoothing capacitor then flick the output pin on and off really quickly, we should hear a sound. By changing the ratio between on and off, we can change the overall voltage level coming out of the pin (helped by the smoothing capacitor) and therefore change the sound played by the speaker.
PWM is a cheap way of creating a variable output voltage from a single output pin.


Audio out using a DAC (digital-to-analogue converter)

Another option would be to send our wavform value to a dedicated DAC chip. Simply put, you send your 8-bit value to a DAC and a variable voltage is presented on the DAC_Out pin. So if you send the value 128 (0x80 in hex) which is half the max value, you get 2.5v (or whatever half the supply voltage is) on the DAC_Out pin. Similarly, the value 64 (0x40) sees a quarter of maximum (1.25v) on DAC_Out and the value 192 (0xC0) three-quarters of a maximum (3.75v).

Most DAC chips consist of a simple resistor ladder which causes the output voltage to change, depending on which pins in the value-to-convert are high or low:

A lot of DAC chips support different interface methods - some are parallel (you connect your mcu outputs to each individual bit of the value to be represented) but most support some form of serial interface - either SPI or I2C. Although we can generate variable voltages through our PIC output pin using PWM, offloading our digital-to-analogue conversion to an external chip does provide some important benefits, even if it means introducing extra hardware.

The most important benefit is that we're saving clock cycles (as well as reducing code size).
Generating PWM means our PIC is doing a lot of work, looking after when the output pin needs to go high, when it needs to go low, and how often this should repeat in order to get an average voltage which matches the value in our waveform "slice". As we increase the sampling frequency (number of vertical slices) so the more work the PIC has to do, keeping track of all this PWM data.

Let's say we want to convert the value 128 (0x80) to a variable voltage, and we're reading sound samples recorded at 22khz. This means that we're changing the PWM rate 22050 times every second. But we can't just send a single pulse high and a single pulse low for equal time to generate our PWM value of 128 (50% on, 50% off) once every 1/22050th of a second. We need to send this value loads of times within our 1/22050th second window. All this means that our PIC is doing a lot of work just generating PWM signals - we still have to leave enough time to read data from our SD card in-between generating on/off output signals. Even with something as big as a 20Mhz crystal, the PIC would struggle to play anything above 32khz samples.

By offloading the analogue voltage to a DAC, the PIC is freed up to get on with other things.
The playing of a wav file is reduced to "read a byte, send it to the DAC" and repeating this once every 1/22050th of a second (in fact, we'll probably read a few bytes into a buffer but the theory is the same). Because of this, we're not only simplifying the code required, we can even run it on a low-end PIC (something like a 16F628A) from it's internal RC oscillator and do away with the need for a high-speed crystal. This in turn reduces current consumption and extends battery life since the PIC is running at a lower speed. It may even be possible to play higher-quality 44.1khz samples with such a simple code routine.

For this little project we'll be using

Microchip's MCP4902 8-bit SPI DAC
PIC 16LF628A (low voltage)
Cheap SD or SDHC card
Audacity sound editing software

The software's downloaded and installed, the wav files edited and everything is on order. All we're waiting for now is the postie to bring everything and we can get cracking!

EDIT - November 2012: We got this working using a PIC16F1825 and have written up how it works in a series of blog posts, starting here

Audio triggering device

After another late night at BuildBrighton, Harry and I finally got a working version of his audio triggering device. It's following the requirements from this earlier post and I think we've pretty much covered everything that was asked for.



It's not the prettiest thing to look at, but it does function as requested:







The device is yet another PIC-based 18F2455 USB/HID device.

The state of the device is reported back to the host PC over USB, as well as the audio input level (after being converted through the built-in A-to-D convertor).



Although relatively straight forward to design, we did have problems with one little bit, but it turned out to be a major headache and took a few hours to resolve. The problem we hit was the input voltage level was in quite a low range - not more than about 1 volt. This meant that when put onto an A-to-D pin that converts voltages from between 0V-5V into a value in the range 0-255, our input values were only ever in the region of 0-50 (20% of 5V ~ 20% of 255). Complicating things further, the audio in from the PC had a background noise level, so instead of a value range of 0-50, we were getting a value range of about 30-80.



But this was only at absolute peak volume, which didn't really occur very often, so our input value range hovered around a relatively low 30-50. If we turned the volume up on the PC, to get a higher peak voltage, we also increased the background hiss, so the value range went up to 50-80, but the size of the range didn't actually increase.



Although this relatively small range did create a working trigger threshold, we were uncomfortable about it being so narrow. We didn't want to mess about with op-amps and extra components, so set about finding a way of increasing the voltage range on the A-to-D output.



The answer was to provide an alternative reference voltage onto pin RA3 on the PIC (also labelled VREF+). To achieve this, we put the wiper of a potentiometer onto the input pin and connected the other two pins to power and ground (creating a voltage divider and allowing us to create a variable reference voltage of 0V-5V)







Another addition to the circuit was to include a 0.1uF capacitor in series with the left and right audio inputs. The idea being that as we're detecting white noise rather than regular, relatively smooth speech or sound, the wild fluctuations in the input voltage can be negated through the use of the capacitor. As we get a spike in the input voltage, this can charge the capacitor and when the white noise voltage level goes low, the input signal into the PIC can be sustained.



In practice this worked well, and coupled with the variable reference voltage gave us input values of 0-200+ but meant that after the audio was stopped, the input on the analogue pin retained a relatively high value. We added some "bleed" resistors across the capacitor pins of about 10K, so that when the audio signal is removed, the capacitors discharge relatively quickly (after about a second) and the input signal always returns to zero.







Frustratingly, we also spent about an hour trying to solve a problem that wasn't really present. With the extra capacitor in place, we noticed that there was a slight delay between starting the movie off (that contained the white noise soundtrack) and the device recognising the noise and triggering it's outputs.

After an hour of changing capacitor values, altering resistor values, changing analogue reference voltages, introducing software thresholds and so on, we unplugged the device and listened to the soundtrack as the movie played.

Sure enough, after hitting "play" on the movie player, the images moved instantly, but the sound only came in a fraction of a second later - the problem wasn't with the device at all, but the movie player software used to start and stop the audio signal!



Here's the latest, updated schematic, including last night's changes:



Audio Input Circuit_v2

note some input/output pins may have changed from the original design

Audio level triggering device

This is Dr Harry Witchel. A doctor no less. He's a scientist specialising in Neuroscience and Psychobiology. We've always found stuff to do with thinking and the brain to be quite fascinating (hey, this isn't called Nerd Club for nothing!) so were thrilled when one of us met up with him recently to discuss helping out with a project he's working on.



The full brief is here but the basic idea is this:

Harry needs a device that he can connect to the audio out of a PC and will trigger a number of outputs when it detects a loud sound. The threshold volume of the input sound needs to be selectable via a potentiometer or similar rotary dial. The same device needs to display what is happening through a series of coloured LEDs and have a number of operational modes selectable through a series of buttons.



It's just crying out for a microcontroller.

And not just any microcontroller, but our old friend the PIC 18F2455.

Using a number of analogue-to-digital pins, digital inputs and outputs and a few discrete components, we could even create a USB-compatible device that can display exactly what is going on, in a nice onscreen display - not just a few twinkling LEDs!



Here's Harry's original spec with our comments in red:

Specifications for Audio Trigger





Here's the first version of the circuit diagram to acheive what he's after:

Audio Input Circuit



We're hoping to have a working version of this circuit (on a breadboard at least) in time for next Thursday's BuildBrighton meeting. More details (and photos) will be posted here in good time.....