 |
 |
| View previous topic :: View next topic |
| Author |
Message |
arunb
Joined: 08 Sep 2003
Posts: 492
Location: India
|
| How to achieve 100 ksps sampling rate for MCP 3208 ADC |
 Posted: Sun Aug 21, 2005 8:18 am |
 |
|
Hi,
I am trying to make a PC based oscilloscope, using a PIC, just for fun. The scope will acquire ADC samples from two channels.
Iam using a MCP 3208 , a PIC 16F628 for this purpose.
I have clarifications to make in this regard.
Time taken to to acquire one sample=60/(100*1000), which is about 10 micro seconds. Is this correct ??
Does the MCP 3208 really work at such high speeds, or do I have to look for another ADC.
My question is how do I transmit this data to the PC as fast as possible ??
Also I would like to use differential channels , where can I get the circuit for this...
thanks
arunb |
|
 |
newguy
Joined: 24 Jun 2004
Posts: 1908
|
|
| Posted: Sun Aug 21, 2005 10:59 am |
|
|
| Quote: | | My question is how do I transmit this data to the PC as fast as possible ?? |
Short answer: you don't. At least not in real time.
All modern digital scopes are basically a fast A/D, a micro, and a screen. In other words, basically what you want to build, minus the screen.
The scope's micro looks for a valid waveform that satisfies the triggering requirements, then fills its data buffer with samples. Depending on the trigger time, this may involve both pre- and post-trigger data. Once the buffer has been filled, the screen is updated. Once the screen has been updated, the process begins again.
I have a lot of experience with Tektronix' TDS210 oscilloscopes. They are a very low cost, quite robust little scope (literally!) They have a 2500 sample buffer, and a 320x240 (I think) lcd screen. This is the method they acquire data.
There are other types of scopes that use a slightly different capture algorithm. The type that comes to mind is the glitch capture scopes that can find and display fast, infrequent events. I imagine that they have two data buffers, one for filling by the A/D, the other for updating the screen, so that while the screen is being updated, the buffer can still be continuously filled.
What you should probably try to do is capture "one screen" by filling a buffer in the PIC. Once it is full, somehow send the data to the host PC, where you'll have to massage it to nicely display it and "make it pretty." Once the buffer has been "dumped", start to refill it.
I think that where you'll run into problems is with the A/D: it may be capable of 100 kSps, but I really doubt that the PIC will be able to keep up. The other bottleneck will be periodically dumping the buffer to the PC. You may be able to speed things up a bit here by employing averaging: capture x "screens" from the A/D, average them, then send them to the PC. Of course, this would only work for continuous signals, not one-shot type of events. |
|
|
sseidman
Joined: 14 Mar 2005
Posts: 159
|
| Re: How to achieve 100 ksps sampling rate for MCP 3208 ADC |
| Posted: Mon Aug 22, 2005 6:48 am |
|
|
| arunb wrote: | Hi,
Iam using a MCP 3208 , a PIC 16F628 for this purpose.
|
The 3208 is a 12-bit chip. If I recall correctly, my TDS3014, a fine digital oscope, samples at less than 12 bits. If this is correct, you may be able to kill one bottleneck by using the PIC's 10-bit on-chip A/D
Scott |
|
|
newguy
Joined: 24 Jun 2004
Posts: 1908
|
| Re: How to achieve 100 ksps sampling rate for MCP 3208 ADC |
| Posted: Mon Aug 22, 2005 7:50 am |
|
|
| sseidman wrote: |
The 3208 is a 12-bit chip. If I recall correctly, my TDS3014, a fine digital oscope, samples at less than 12 bits. If this is correct, you may be able to kill one bottleneck by using the PIC's 10-bit on-chip A/D
|
Thanks for mentioning this, I had forgotten about it. Actually, I can't remember working with any digital scope that didn't have an 8 bit A/D.
One other thing: the PIC's internal A/D can't run very fast at all. Something like maybe 10 - 20ksps. I should qualify that statement: the A/D may be capable of running faster, but the BW of the analog signal path effectively limits the sampling rate. |
|
|
arunb
Joined: 08 Sep 2003
Posts: 492
Location: India
|
| RE: |
| Posted: Mon Aug 22, 2005 9:17 am |
|
|
Hi,
Thanks for the reply..
I need to clear some points...
| Quote: | | Short answer: you don't. At least not in real time. |
I am transmitting at 57600 baud, which for two channels the approx transmission time
is 32/57600= 0.5 milli seconds. So transmission in real-time should be possible ???
Here 32 is total bits for transmission, (16 bits per sample for each channel).
Please advise whether this is correct. I could post the code if required...
Another point I want to know , does channel changing affect the sampling speed ??
thanks
arun |
|
|
ckielstra
Joined: 18 Mar 2004
Posts: 3680
Location: The Netherlands
|
|
| Posted: Mon Aug 22, 2005 10:17 am |
|
|
| Quote: | | 16 bits per sample for each channel |
As sseidman already mentioned, the MCP3208 is a 12 bit ADC, not 16 bit.
| Quote: | | I am transmitting at 57600 baud, which for two channels the approx transmission time is 32/57600= 0.5 milli seconds. So transmission in real-time should be possible ??? |
The maximum sample frequency for the MCP3208 is 100kHz.
One data sample is 12 bits.
At maximum speed the ADC will generate 100kHz * 12 bits = 1.2Mbit / second. Your 57600 baud doesn't come close.
At your baudrate you can do a maximum of: 57600 baud / 12 bits = 4800 samples / sec. maximum.
Timing is even worse because I didn't correct for the start- and stop bits.
So either increase your baudrate or use a buffer where you store data at full speed until the buffer and then stop the meassurement, then transfer the data at a slow speed to the computer. |
|
|
sseidman
Joined: 14 Mar 2005
Posts: 159
|
| Re: RE: |
| Posted: Mon Aug 22, 2005 10:32 am |
|
|
| arunb wrote: | Hi,
Thanks for the reply..
I need to clear some points...
| Quote: | | Short answer: you don't. At least not in real time. |
I am transmitting at 57600 baud, which for two channels the approx transmission time
is 32/57600= 0.5 milli seconds. So transmission in real-time should be possible ???
Here 32 is total bits for transmission, (16 bits per sample for each channel).
Please advise whether this is correct. I could post the code if required...
Another point I want to know , does channel changing affect the sampling speed ??
thanks
arun |
Digital oscilloscopes don't necessarily work in real time. An entire sweep can be sampled before it is dispayed or sent to the host. In fact, pre-triggering makes such behavior close to mandatory. In a scroll mode, something approximating real time would be desirable, but when this mode is useful, the data is usually coming in relatively slowly. In fact, a 100ms delay probably wouldn't be that noticable, but you would like to be able to update your screen while data is coming across for smooth scrolling. For what it's worth, my $4,000 TDS3014's often have jerks in the display during scroll mode. Worry about proper buffering, so you don't miss any data, but "rea-time" might not really be what you're shooting for.
Yes, at 5V, that chip will work at 100Ksamples/sec-- probably distrubuted between channels--i.e., 50ksamples/s for 2 channels, and so on.
To bring data to your PIC at that rate, you're going to have to pay close attention to your SPI drivers, and make sure they're optimized. That is, read, and understand every line of code in the 3208 driver that ships with CCS, and see what you can do to optimize it.
If communication to the host is your limiting factor, consider sending only the top 8 bits to the host. You might need to shift your data up so the MSB is full. This way, you won't need to waste time sending 4 meaningless bits, assuming that your RS232 drivers require you to operate in 8 bit chunks, and your resolution should be good enough.
I'd consider looking into the FTDI chips, and use USB instead of RS232. It's faster. There's a reason why all the commerial PC scope packages use USB. Apps that require super speedy transfer used to require SCSI, but now most, if not all, modern packages have moved to USB.
On the host side, of course, you need to write software that can poll the HID driver for the data. This is a little out of my league.
Scott |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|
FAQ 
Search
Register
Profile 
Log in to check your private messages 
Log in
