A/D-sampling rate?

[sioux]

Hello!

I'm working with the plugapod card, with the DSPF803 motorola processor.

I have a problem when I am about to send the A/D-converted values to my PC via the serial port. The values that appeares in my PC is a lot of blanks plus only a small amount of info integers. It is about every 16 digit that are not blank..

I am using a baudrate at 9600. I have red in the specifications of the motorola processor what sampling rate that are used and it's about 1.3 microseconds, but it seems now that it only uses a very low sampling rate because of all the blank integers above..

Regards

[RMDumse]

Just as a chain is only as strong as the weakest length, the fastest speed a program can run is limited by the slowest thing in the loop.

Yes, the A/D is very fast, and can take data in under 2uS.

However, just because the A/D can take new data every couple microseconds doesn't mean that data can be sent over a serial channel that takes 1mS (1000uS) to send a character. Depending on how you format the data, it will take at least two characters to contain the 16 bits, and more if you print in a number base.

So the weak link is the 9600 serial channel. Each character has 10 bits (start bit, eight data bits, and a stop bit), so it takes 1/9600 x 10 per bit, or, as a quick approximation, 1mS. So just the time spend in sending the data (at least 2 characters) would limit the fastest transmission to occur 500 times a second.

The situation gets worse if you include formating or other characters, like spaces, and don't forget things like carridge return and line feed.

On the other hand, if the A/D was read, and the value compared to a high limit, or a low limit, it could probably be read 500,000 times a second.

So in this case, the rate A/D readings can be sent over the serial port is much more limited by the choice of the serial port, than anything else. You could easily choose a higher baud rate. 38400 is four times faster. Or you could look for a different transfer method. For instance you could probably send A/D data across the CAN bus at nearly 100,000 readings a second (the CAN bus has a header that would be overhead) or handshake it across a parallel port at even higher rates, which would be limited by the speed of the A/D. At those rates, though, the PC would become the limiting factor.

[sioux]

Thank you for your reply.

I am still wondering though. How do I know at what time every saple that I read on the computer has been taken? If I for example would like to look at the sampled signal in matlab, it would be great for me to know what time scale in seconds that should be used.

This would be easy if I knew that every sample that I read have sampling time for example 2us. But as you described earlier this is not the case..

[RMDumse]

I suppose there are several approaches.

I often set the A/D for continuous conversion. Then, whenever I take the data, I know it is less than 2uS old.

Another approach is to take the data periodically, and use a different method, where at a given time, initiate the conversion and I grab the data.

Let's say we are still limited by the serial channel. Okay, then, we need to figure the fastest we can get data through. At 9600, we need about 1mS per character. If we send the value as a hex, we need 4 characters, or about 4mS. So if we targeted a report every 5mS period, we should be able to stay ahead. 5mS at 5,000,000 cycles per second is 1000 cycles. So heres how I might approach it.

HEX
: ADREAD ADC0 ANALOGIN HEX 4 .R ;

DECIMAL
EVERY 1000 CYCLES SCHEDULE-RUNS ADREAD

I used 4 .R to get four characters always. There is no carridge return, so this will wrap on the screen.

On the PC side, you know these messages are sent every 5mS.

A different approach would be to take the A/D reading and time stamp it. The system timer could be read to have a time stamp. This could be printed along with the A/D reading. But remember, more characters take more time.

[sioux]

thanks, this will help a lot..

[sioux]

I have tried some approaches with starting a timer on the microcontroller side, but I haven't got it function the way I want. I would like to take another approach, namely the way you described a while ago above.

My question is that I don't really understand what kind of code you wrote, and where to write it in my small C program?

I'm now using a modified version of the adc.c example program. Is it possible to use the codesegment above in this program?

Regards

[RMDumse]

The code I wrote was in IsoMax(TM) which is resident on many of our DSP boards. IsoMax(TM) is a unique language to New Micros, Inc., based on our decades of real time experience. It is a state machine based programming paradigm. Our first release has IsoMax(TM) on top of our Max-Forth(TM) language.

If you are using Small C already, your shortest path will probably be to continue in that direction. Or investigate StatiC, an IsoMax(TM) implementation on top of a C like language which Pete Gray is developing now.