Audio rate sampling on lpc1343

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Audio rate sampling on lpc1343

486 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by RPrice on Mon Nov 05 09:07:33 MST 2012
Hi,

  I'm doing audio rate sampling on the lpc1343, I have a piece of test code that samples the input and sends it back out unaltered to a DAC connected by SPI. It works fairly well but I have quiet high frequency whine that I think is due to sampling noise on the input, it looks like a square wave on the output even when I'm sampling silence (input flat at 1.5 v).

  I think the internal capacitor on the ADC isn't charging quick enough and is the source of the noise. This points to a source impedance problem on my circuit.

  My question is has anyone had any success sampling at 22khz at the full 12 bit resolution offered by the lpc1343?

Robin
0 Kudos
10 Replies

448 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by fjrg76 on Tue Nov 13 17:13:07 MST 2012

Quote: RPrice

We think the noise was on the chip itself, most likely something to do with burst mode combined with sampling while pin wiggling, though we can't rule out that better power supply regulation would help. However decoupling the power supply with an extra capacitor made no difference to the tone of the whine which makes me think it's not a power supply issue



The noise could happen because you were sampling at irregular intervals; this  is called "jitter"
0 Kudos

448 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by RPrice on Tue Nov 13 13:26:30 MST 2012
We've had major success in eliminating the whine. Instead of using the ADC in burst mode, allowing the rest of the chip to carry on doing things like sending SPI data, we put it into an empty loop while the ADC samples. By stopping other processes (like SPI or other pin wiggling) occurring on the chip during the time it takes to sample we seem to have got rid of the problem.

We're currently experimenting to see if we can run the ADC in interrupts after SPI and let the rest  of the chip carry on DSPing or if we have to keep the internal switching to a minimum while sampling.

We're hoping that we can run the ADC in parallel to the DSP using interrupts to trigger it while the rest of the chip does stuff. This gives us more DSP cycles (rather than having to just while loop when we trigger the ADC).

We think the noise was on the chip itself, most likely something to do with burst mode combined with sampling while pin wiggling, though we can't rule out that better power supply regulation would help. However decoupling the power supply with an extra capacitor made no difference to the tone of the whine which makes me think it's not a power supply issue

I would still like to know what best practice is for powering the chip given it's lack of an analogue Vref and what the difference is between the two VDDs on pin 6 and pin 29.
0 Kudos

448 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by fjrg76 on Sat Nov 10 11:55:34 MST 2012
Hi

Is your sampling frequency constant? Who is triggering the ADC conversions?

I haven't use the LPC1343, but if it can receive then it can send :D Besides, if available, you can use SPI or IIC for sending out the data.

It's hard to look for a solution if the cause is unknown, so it would be time to start "Dr. House's method"
0 Kudos

448 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by RPrice on Sat Nov 10 10:21:50 MST 2012
Hi thanks, for all this.

We think the problem is parasitic noise occuring both on the sample input inside the chip (it's fine when it goes in on the pin) and at the output of the separate DAC. We haven't followed guidelines on separating the ground plane around the clock and separating the ground planes for analogue and digital components.


Quote:
1.- Implement a simple moving average filter. It means, take some samples, say 8, and add them up, and finally divide the result by 8.

2.- Through RS232 (if possible) send your samples to your PC, save them, and then analize them using Matlab or Octave.

Finally, the DAC's output is going to be always staircase (unless the DAC resolution is infinite). That's way you must have a low-pass filter in its output in order to smooth the outgoing signal (take a look with an oscilloscope).



The oversampling option is something we're loathe to sacrifice clock cycles to.

We can't interface back with the PC because we have to test the system on the PCB and we haven't designed it with this in mind. We have a mini USB connector on the board to upload firmware but I don't think we can use this for sending serial data back while its running (I'm new to the LPC1343)

I realise the DACs output will staircase but that shouldn't manifest itself as a whine heard on steady input, this has to be parasitic noise on the DAC output caused by the LPC. I'm leaning this because when we tried hooking a heartbeat LED to a spare pin on the board so that it would light up when a certain single value was sampled by the ADC and fed it from a variable resistor we could get a steady light. Even looking at the voltage from the pin on the scope it seemed fairly stable which would indicated that the noise is occurring at the DAC.

I think it is cause by the LPC as changing the clock frequency or the ADC interrupt timer changes the pitch of the whine.


Quote:
What does your hardware look like?



The two input signals go into It's a quad op amp that biases them into the ADC's range then into an RC filter and then into ADC. Then the digital output goes to the DAC via SPI then back to the other two inputs on the quad op amp, into a headphone amplifier and out to the jacks.

The whole thing is run off a single 3V battery power supply which gets regulated but isn't filtered much. I'm a bit concerned that we haven't attempted to split the supplies in to one for the analogue and digital components. The negative rail for the op amps comes off a charge pump in the headphone amplifier.


Quote:
To start with: the Vref- should be connected to the ground plane or even better to a separate trace going to the GND input of your board. This is also where other analog grounds (analog input, opamp voltage) should go.

The Vref signal should at least be decoupled from the main 3.3V using a choke and a capacitor (I use both a normal elco plus a ceramic capacitor) and for a real ADC application I would suggest to use a separate reference source.
When just decoupling, make sure that the capacitors are places close to the pins as possible and your 3.3V source comes as close to the 3.3V regulator's output capacitor as possible.



The 1343 doesn't have a separate Vref and Vref- it has VDD, VSS. We're using the FHN33 package, it asks for VDD on pin 6 and pin 29 but we can't work which is used as Vref for the ADC. Quite whether we should power the whole chip from the analogue or digital supply confuses me, I guess the main thing might be to try and separate the powersupply and ground for the chip and DAC / op-amps and potentially use two separate op-amps to eliminate cross talk (though our gain levels are really very low).

I guess try using a choke and two caps on the powersupply to the LPC?



Quote:
You might google

adc pcb layout

and a bunch of guidelines will be found. Among others I'd recommend you:

UM10375 (NXP)
AN2764 (FreeScale)
AN2321 (FreeScale)



Cheers, I think I have the UM10375 but I'll dig through the other two.

All ideas and comments are gratefully received.
0 Kudos

448 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by fjrg76 on Thu Nov 08 10:30:31 MST 2012
Hi

You might google

adc pcb layout

and a bunch of guidelines will be found. Among others I'd recommend you:

UM10375 (NXP)
AN2764 (FreeScale)
AN2321 (FreeScale)
0 Kudos

448 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by Rob65 on Thu Nov 08 04:46:27 MST 2012
What does your hardware look like?
The standard LPCXpresso board is (IMHO) not a very good platform to start doing analog stuff. You really need a stable supply to the Vref inputs of the ADC and I am not sure the LPCXpresso has those well routed (or even decoupled).

To start with: the Vref- should be connected to the ground plane or even better to a separate trace going to the GND input of your board. This is also where other analog grounds (analog input, opamp voltage) should go.

The Vref signal should at least be decoupled from the main 3.3V using a choke and a capacitor (I use both a normal elco plus a ceramic capacitor) and for a real ADC application I would suggest to use a separate reference source.
When just decoupling, make sure that the capacitors are places close to the pins as possible and your 3.3V source comes as close to the 3.3V regulator's output capacitor as possible.
Also here, use a separate trace and do not tap of the 3.3V Vdd input of your lpc1343.

I've done these things wrong myself a few times ...

Rob
0 Kudos

448 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by nkarakotas on Thu Nov 08 01:31:39 MST 2012
Hi,

I would agree with fjrg76. By sending through RS232 or saving them in sdcard and analyzing them afterwards will indicate to you that your ADC is correct. You might have a problem with your DAC code. I have done this my self and found my DAC code needed adjusting as it created an envelope on the output that you could hear.

I also get some samples when there is silence and average it out and then use it either to start sampling when audio is played or when outputting the data to the DAC as you need to know your center point.

Another good test if you haven't already done is input a sine wave 1Khz and see what you read.

Regards,
Nick
0 Kudos

448 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by fjrg76 on Wed Nov 07 22:29:38 MST 2012

Quote:

By blanking the last bit or two of the sampled input we seem to be able to reduce it which again points to noise the ADC.



It's a common practice to eliminate the least significant bit in order to reduce the noise. I might suggest you two things:

1.- Implement a simple moving average filter. It means, take some samples, say 8, and add them up, and finally divide the result by 8.

2.- Through RS232 (if possible) send your samples to your PC, save them, and then analize them using Matlab or Octave.

Finally, the DAC's output is going to be always staircase (unless the DAC resolution is infinite). That's way you must have a low-pass filter in its output in order to smooth the outgoing signal (take a look with an oscilloscope).

BTW, the LPC1343 DAC's resolution is 10 bits :D
0 Kudos

448 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by RPrice on Wed Nov 07 07:53:11 MST 2012

Quote: fjrg76

Have you placed an analog low-pass input filter into the ADC pins?



We have an RC filter on the input which I realise is a poor approximation for a brick wall filter but I don't think aliasing around the Nyquist is the problem because the whine is always present even when we feed the ADC silence.

Perhaps I should explain the circuit a bit better. We have a stereo audio input going into an op amp circuit that acts as a level shifter putting the bipolar audio signal into the 0 - 3V range of the ADC.

The output of the level shifter goes into the RC low pass (0.1uF 500R) then into the ADC. We've tried a few different filter values but we don't seem to be able to eradicate it.


Quote: fjrg76
And you always need an analog low-pass filter in the DAC's output.



We don't have one but I think the grittyness of not filtering the output is the problem as like I said we get this whine on a silent input.

By putting the chip into burst mode for a random amount of time, constrained such that it always has time to read both inputs, and randomly choosing a value of 15 or 16 for the clock divider we can turn the whine into a hiss which suggests that it is somehow correlated with the internal workings of the ADC, like the input capacitor not charging/discharging properly.

We have checked the input pins of the ADC by wiring them to an amplifier and we can't hear any noise at the input.

It seems worse on one pin than others.

By blanking the last bit or two of the sampled input we seem to be able to reduce it which again points to noise the ADC.
0 Kudos

448 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by fjrg76 on Mon Nov 05 18:34:41 MST 2012
I haven't done that yet, but it cames to my mind the thing about filtering.

Have you placed an analog low-pass input filter into the ADC pins? It would help to implement a little digital low-pass filter in your program, too.

And you always need an analog low-pass filter in the DAC's output.
0 Kudos