ADC (audio sampling) and PWM (audio playback)

[MrNobody]

Still saying this sounds way more difficult than it needs to be.
dsPIC33F will do 40MIPs, and its 16-bit instruction set and DSP core is way more efficient per instruction. So if you need power that is it.

An Si3000 codec is pretty much stock. That's like $2. It'll be a microphone preamp, software adjustable, and a headset amp (although it's a pretty weak one actually). Maxim-IC's "DirectDrive" is the BEST headphone driver, they have codecs which have it and they have basic analog amp chips with it.

DirectDrive is where they use a charge pump to make a -Vdd and it's got an output that swings close to the rails with a high current capability. Then you can hook up a speaker without having to use differential mode OR large coupling caps and you still get +/- Vdd swing off of even 3.3V, which is nice- no separate regulator.

BTW, I don't know if you noticed this or not, but the Nyquist limit doesn't eliminate signals over Fsamp/2. Those components, if present, produce noise in the ADC data. And a simple RC filter does not have a sharp enough cutoff for this, there are some 2-stage active filters people often use. In general a codec chip will not need this hardware because they use oversampling- the ADC samples at a very high rate and they use a digital decimation filter to kick it down to the 8khz voice sampling rate.

I gotta note that making the filter costs about as much as just using the codec...

I would love to get that chip.. but here in Malaysia, i dun think that chip is easily obtainable.. I may have to order it from overseas.. US$2 is equivalent to $7 and that is excluding the shipment cost.. Shipment itself is maybe $10 to $20 more so eventhough the chip is cheap, but the total cost is alot more expensive..

 

[MrNobody]

Hmm.. i need some thoughts on buffer size..
I mean.. lets say i build 2 modules (each module consist of PIC18F4620 with ENC28J60). One PIC (PIC_1) will capture voice data and then send it to another PIC (PIC_2) through ethernet and another PIC_2 will play the voice out.. At the same time, the other PIC_2 also capture a seperate voice data and send to PIC_1 to be played out.. Kind of like full duplex VoIP..
Is there a general rule of calculating the buffer size or buffer time..? Is buffer time of 200ms ok for acceptable communication..?

8 bits sampled at 8kHz = 64000 bits (per second)
Buffer of 200ms --> 0.2 * 64000 = 12800 bits (per 0.2 seconds)

Later, this module will also be communicating with a computer running the VoIP software which I will be writting..

That wouldn't be heavy on PIC18F4620 running TCP/IP stack with other functions would it..?

 

[Oznog]

Well, by 200msec the conversation might already be awkward, esp 200ms x2. Conversations are sensitive to delays, it gets weird when you say something and there's a delay in the answer.

But you've probably noticed buffer underruns would suck, and starting with zero delay underrun may happen. And if we stall the DAC and extend the buffer to a "large" amount early on because of a temporary lag, can we ever get that buffer latency back down?

 

[MrNobody]

Well, by 200msec the conversation might already be awkward, esp 200ms x2. Conversations are sensitive to delays, it gets weird when you say something and there's a delay in the answer.

But you've probably noticed buffer underruns would suck, and starting with zero delay underrun may happen. And if we stall the DAC and extend the buffer to a "large" amount early on because of a temporary lag, can we ever get that buffer latency back down?

Thanks Oznog.
Sorry for the late reply.. Didnt realise that you have repled..
Hmm.. why 200ms buffer will cause 200ms x2 delay..?

If we stall the DAC and extend the buffer to a "large" amount early on, won't that cause the initial delay to be significantly larger than following delay..?

As for the latency, if we decrease the buffer time, that would improve the latency right..?

Hmm.. generally speaking, what is the prefered/allowable delay time..? 100ms..?

 

[amrish_deep]

How to acheive 10000samples/s

The acquisition time is complicated, if you're trying for the absolute maximum sampling rate! - but at 10,000 samples per second (100uS per sample) you don't need to get so involved.

Hi Nigel,

We are using the following code to read the adc value from the PIC using Internal clock frequency.

for(i=0;i<50000;i++)
{
a = read_adc();
printf("%lu",a);
}

The above code snippet takes > 200s to execute and I am unable to acheive the sampling rate of around 10,000 samples/s. Is this the right way to sample analog signals using PIC?

*** We are using PIC to perform ADC on sound waves sensed using microphone.

-Amrish

 

[Nigel Goodwin]

Using C is crippling your speed for a start - and where is printf sending the data, and how long does that take?. The problems aren't so much sampling time, but what you do with the data afterwards.

 

[amrish_deep]

Re How to acheive 10000samples/s

Using C is crippling your speed for a start - and where is printf sending the data, and how long does that take?. The problems aren't so much sampling time, but what you do with the data afterwards.

To give a gist about our project,
We are building a Motor Speed Detecting circuit using
1. PIC - 16F877
2. Microphone
3. Matlab (Serial Interfacing PIC with PC)

The Microphone is connected to the PIC through a differential amplifier. The noise from a motor is sensed using this microphone.PIC then serializes the data to my PC via a 'RS-232 USB Adapter'. We will be plotting a FFT based on the microphone output data in Matlab and after correlating the the dominant frequency to the Motor's angular velocity, we will send back the processed data to the Micro-controller which displays the data using the LCD.

Using PIC is mandatory and the problem arises with the rate of sampling/transmission I guess. We need around 50,000 sample data at a sampling rate of at least > 5000hz .

The Data Sheet of the PIC clearly indicates that this sampling rate is easily achievable. But when I transmit the data to the PC using printf as I had mentioned earlier, I am able to achieve a modest sampling rate of ~ 100 data/second.

We assume that the slowness is because of the transmission between PIC and PC (RS232-USB Adapter). Is there any other efficient way to transmit the data (other than the printf?) is there any other suggestions which you can make in this regard?

-Amrish

 

[Nigel Goodwin]

To give a gist about our project,
We are building a Motor Speed Detecting circuit using
1. PIC - 16F877
2. Microphone
3. Matlab (Serial Interfacing PIC with PC)

The Microphone is connected to the PIC through a differential amplifier. The noise from a motor is sensed using this microphone.PIC then serializes the data to my PC via a 'RS-232 USB Adapter'. We will be plotting a FFT based on the microphone output data in Matlab and after correlating the the dominant frequency to the Motor's angular velocity, we will send back the processed data to the Micro-controller which displays the data using the LCD.

Using PIC is mandatory and the problem arises with the rate of sampling/transmission I guess. We need around 50,000 sample data at a sampling rate of at least > 5000hz .

The Data Sheet of the PIC clearly indicates that this sampling rate is easily achievable. But when I transmit the data to the PC using printf as I had mentioned earlier, I am able to achieve a modest sampling rate of ~ 100 data/second.

We assume that the slowness is because of the transmission between PIC and PC (RS232-USB Adapter). Is there any other efficient way to transmit the data (other than the printf?) is there any other suggestions which you can make in this regard?

printf seems the worst possible way you could try and transfer the data - you just need some serial output routines, preferably using the internal UART in the PIC. There are assembler examples in my tutorials (the last RS232 one uses the UART), it should be simple to convert to C if required (although the entire program would be trivial in assembler, as it's very simple).

Do you have a real serial port you can use on the PC?, serial to USB conversion is often really, really slow - the USB overheads severely limit the data transfer speed. USB is designed for continuous data, not the byte at a time method that serial uses. Supposedly some modern ones are faster, but the older ones are limited to about 9600 baud by the USB overhead.

 

[kchriste]

Sounds like it would be easier to do the FFT on the PIC and forget about the PC altogether.
It would be easier/quicker with a dsPIC, but you can still do it with other non DSP PICs:
**broken link removed**

 

[Nigel Goodwin]

Sounds like it would be easier to do the FFT on the PIC and forget about the PC altogether.
It would be easier/quicker with a dsPIC, but you can still do it with other non DSP PICs:
**broken link removed**

If you check the PICList there's an audio spectrum analyser, and the article with it says the MicroChip routines don't work.

Easier to do it on the PC, the PIC part then is trivial and easy.

 

[kchriste]

Funny, I got their code to work on a dsPIC running at 8Mhz. A 256 point FFT took 6ms to execute. I've never tried the non dsPIC (AN542) code though. Either way, the OP is going about sensing the motor speed the hard way. There are much easier ways, such as a shaft encoder, to determine motor speed.

 

[Nigel Goodwin]

Either way, the OP is going about sensing the motor speed the hard way. There are much easier ways, such as a shaft encoder, to determine motor speed.

Presumably it's a school, project - so has to be done the most difficult way possible?

 

[kchriste]

Usually I sniff them out sooner. Maybe I'm coming down with something?