low sampling rate with adc

[tux21]

i have to get around upto 900 Hz signal in MATLAB for which i use adc0808 with 8051 AT89S52

i use uC pin to generate clock of about 230kHz for adc. when i use 4 D flipflops to divide 11.0592MHz clock of uC by 16 and give it to adc it doesn't work(given like this in Mazidi book)

Now, i am able to get enough sampling rate for sine waves upto 50Hz but above that i get distorted conversion most likely due to undersampling as in figure attached . I have configured the uC to continuously operate the adc and send values to pc via serial port.

baud rate is set at highest possible 57600. matlab collects these binary values and stores in its serial port inputbuffer (1 MB) from where i read them to plot.

My problem is i am not able to get sufficent sampling rate for signals above 50Hz when i test with a sine wave generator.

The sampling rate is not controlled by me.
Plz help. I attach the assembly code with comments as well

 

[tux21]

any suggestions?

 

[tux21]

Can this adc deal with audio signals.Can anyone test it?
plz tell me i have to complete urgently

 

[55pilot]

plz tell me i have to complete urgently

A class deadline?

---55p

 

[tux21]

no way
i am not in a class

i think its some delays in adc config at higher frequency clock

 

[(*steve*)]

If the data is being sent by RS232 and there is no buffer between the ADC and the UART then the max number of samples you'll see is about 600 per second. You will see some lower frequency aliased signal if you try to capture any signal with a higher frequency than about 300 Hz

Why do people want to transfer signals from ADC's via RS232? Same class?

 

[tux21]

thanks
but how did you arrive at the figure 600 per second?
you may be right because i remember once hearing about it

also if baud rate is 57600 bits per second for only one way transmission, that means 7200 bytes or samples are supposed to be transmitted per second fron adc to uart via uC ?

 

[(*steve*)]

Sorry. Assume 10 bits per 8 bit byte for RS232 (can be up to 11.5).

You should see around 5700 samples per second. 900 Hz would look a bit rough, but should work.

I would start looking at the actual data rate I was seeing and see if it is the speed you expect.

With a 230kHz clock for the ADC, how fast do you expect data to be fed to the UART? What happens if the ADC tried to send data to the UART faster than it can send it? Is there handshaking? What happens if the buffer on the UART overflows? Can the computer handle the data at that speed? Does it try to use handshaking to slow it down? Are you losing data?

 

[tux21]

i cheched with matlab, the usb to serial conv. i use is giving correct baud rate of 57600 when i transmit simply ascii value '2' from uC to pc

 

[(*steve*)]

i cheched with matlab, the usb to serial conv. i use is giving correct baud rate of 57600 when i transmit simply ascii value '2' from uC to pc

Fine, but...

With a 230kHz clock for the ADC, how fast do you expect data to be fed to the UART? What happens if the ADC tried to send data to the UART faster than it can send it? Is there handshaking? What happens if the buffer on the UART overflows? Can the computer handle the data at that speed? Does it try to use handshaking to slow it down? Are you losing data?

(maybe the uC has its own UART (quite probably), but most of the same questions need answering.

Especially these: Can the computer handle the data at that speed? Does it try to use handshaking to slow it down? Are you losing data?

 

[tux21]

i think i could finally get something. i connected the ALE pin i.e 30th pin of 8051 as clock to adc0808. Its suppose to give 1/6th of 11.0592MHz ie.like 1.8432 Mhz. But adc max clock is specified as 1.28Mhz :-?. Also i have connected pin 31 to Vcc.

First i tested pain single character sending to matlab from uc and found to time it took to fill a large InputBufferSize and concluded that it was more than 5000 samples which is close to the theoretical 57600/10=5760. So my usb-> serial was okay.

Then i minimized all the delays in the adc operations. used timer instead of loop delays. It turns out adc0808 is not that slow. It will do adc faster than the uart can send samples to pc. No special delays were required between setting ALE,SC,OE,ADDRESS etc. But the high clock was a must. I have also not used any timer and serial interrupts. Just get adc value in accumilator, put in SBUF and monitor TI flag.
This method gives me around 4500 samples/sec. the 4 q flip flop method in mazidi will not work as the input from crystal is insufficient to drive the Flipflops.

Also keep sufficent InputBufferSize in matlab serial around 50MB. This is not good for audio signals, but for ECG,EEG,EMG etc it will do.
Attached picture of 800 Hz sine. Multiply the circles in a period with
time period 2ms to get sampling rate.

i'll come with if more trouble comes.

ps. also adding 800Hz sine , spline interpolated to triple sampling rate in matlab

 

[(*steve*)]

So it's fixed? I gather the problem was to do with your technique of generating delays?

 

[tux21]

Yes, earlier it was adc which was slow, now its UART

if anyone know how to get 115200 baud rate in 8052 plz tell with 11.0592 mhz

 

[tux21]

Done!
now i am at 115200 baudrate using 11.0592 crystal and timer2. getting around 7200 samples/sec. i think adc is the limiter this time

fig without interpolation

 

[tux21]

Great!

now i am able to get out around 11,200 samples/sec from the ADC+uC combination. Earlier i used to do adc then wait for TI to set and clear it i.e wait for frame to be transmitted.

JNB TI,$ ;WAIT FOR SERIAL TRANSMISSION
CLR TI

But now i can omit the above wait for Tx to happen and directly go to obtaining the next adc value to be Tx
The trick i found is to initialize serial Transmission in the beginning itself just once with

MOV SBUF,#'0' ;INITIALIZE Tx

before starting anything else. Once this is done adc and uart transmissions can be done without any delays between them ;->

Note that i am using 1.8Mhz as my clock for adc0808 from ALE pin

 

[tux21]

well that trick doesn't work. it got higher because of overlap of adc and uart Tx times

 

[(*steve*)]

Handshaking is there for a reason

There may be delays caused by handshaking (betwen the UART and the PC), and depending on the UART you may need to wait until the character is sent completely before giving it another. Does your UART have a buffer (not a 1 character buffer, say a 16 character buffer)? I seem to recall a UART with a part number like 16550 (from memory) that was used because of this very feature. But that was long ago when the internet was steam powered..

 

[tux21]

i can make use of 256 KB of 8052 ram. But how will that help? If rate of filling the bufferis larger than emptying it will ultimately fill up.

 

[(*steve*)]

yes, your data rate must exceed the sampling rate by some amount to allow for external handshaking or other stuff that might reduce the speed of the data stream. Otherwise, if it falls behind it can't catch up. The buffer has to be large enough to hold all that excess data until it can be sent.