Idea: Medium Speed USB Oscilloscope.

Just an idea at the moment. A (cheapish) USB oscilloscope with moderate resolution at medium speeds.

TI has two high speed (2MSPS) 16 bit analog to digital converters (ADCs), the ADS8411 and ADS8412. One is differential, the other is single ended.

A PIC 18F2550 (with USB) can read the ADC and send data to a PC for display.

2 MHZ of speed isn't that great, but its faster than a multimeter :)

Notes:

USB full speed is 12 Mbps
I guess I can sustain about 8Mbps of data through the USB, leaving 4 bits of control layer for every 8 bits of data.
At full ADC speed (2MSPS) samples would have to be limited to 4 bits resolution (and combined into a single byte?) to hit the 8Mpbs mark.
8 bit resolution = 1 million samples/s max (8mbps)
16 bit resolution = 500K SPS max (@ 8 mpbs throughput)

The ADS841x interfaces with some control lines and a 16 bit bus - a low instruction count can be used to move the value from the PORTS to the USB peripheral.

@ 48MHZ the pic does 12 million instructions/s.
@ 2 MSPS (or 2 MHZ acquisition speed, 4 bits resolution) there is a 6 instruction limit to move data from port to USB. This could be considered 12 instructions @ 4 bits because 6 instructions would just move 4 bits into a byte, other operations could be done during this time.

Comments

[ian]

I don't think PIC will be the best processor, its just what I have on hand. Sustaining 2MHZ might not work, because: 1. PIC lacks DMA, it takes 2 instructions to move the value on a PORT to a memory or register location (thats half of the 16 bit resolution, but irrelevant in a 4 bit mode). PORT->W->final address 2. 12 MIPS might not be enough to allow for USB overhead (encoding and control layers). I don't know yet, I've never implemented full speed USB where this mattered.... 3. a dsPIC might be the solution, but I'm not sure if I can program it. Further investigation is needed.

[ratmandu]

You could try an AVR. They can reach up to 1 MIP per Mhz, and some are spec'd up to 20Mhz. Though its also possible to overclock them. I also find thatthey are easier to program (can make a cable with 6 conductors and no other parts, for the parallel port).

I just got started with them, and they work great. Samples are a bit faster than microchip for me. Atmel is pretty fast about that, and they have tons of information available. There is also a free software USB implementation available from http://www.obdev.at/products/avrusb/index.html and more info at http://avrfreaks.com

[taukir000]

Yup, AVR is alot more better than PICs. You can use various usb frameworks available at the net. Just google it. You can also find more information at http://eoler.tk too.

[ian]

WINPIC800 tells me it will program all dsPICs with a JDM2. Time to hit microchip's catalog.

[DarkAngel09]

this seems like a great idea

[ideaman]

I've been thinking of doing something similar for a couple of years now (using a pic as the base for an oscilloscope), but I had been thinking of using a graphical lcd panel (with something like 128x64 resolution) and having the pic itself do the triggering, storage etc. Using usb is just as good as long as you are careful. I don't know about interrupt mode on usb devices, but I know a little bit about bulk mode. To get maximum bandwidth efficiency, you are going to have to send reasonably large packets (like 512 bytes). If it is bulk, you will need to have several 512 byte packets ready to go (because you can't directly control when you will be polled). I think the best solution, though, is to tell the pic to either do a raw capture for a large time (till memory fills up) and send it all back to the computer and let it figure out min / max / period, etc. or to have the pic auto trigger (either based on a user specified trigger level, or have the pic itself try to examine the signal for a bit before doing the actual capture). Having the pic doing anything intelligent (any trigger detection) will of course reduce the samples per second that you can handle and it will make it harder to come up with a proper capture routine, since all the execution paths need to take the same number of cycles (and you will probably want a few samples just before the trigger, so you probably can't cheat by polling for the trigger and then going to a precisely timed capture loop, the trigger detection probably needs to be part of the capture loop to maintain precise timing). One other thought is that maybe the Propellor chip from Parallax might be better. It has several cores, each clocked up to 80MHz (which presumably means they can probably capture data at around 20 million samples per second, but that's just a rough guess, I haven't worked with these chips). You could have 1 core dedicated to capture of data and another dedicated to triggering, analysis, etc. of the data as it's being captured (assuming you have a fast dual ported ram), and another core dedicated to communication (I think they have serial to usb chips that they also sell on their site which should make the task trivial but would limit throughput). You could even have yet another core dealing with a lcd panel. Just a few thoughts from someone who had a similar idea.

[enigmamkp]

<a rel="nofollow" href="http://www.semifluid.com/?p=20">http://www.semifluid.com/?p=20</a><br/>A oscilloscope there.IS there anybody made it?<br/>

[VIRON]

Why do people now use PCs as oscilloscopes? It seems a bit like using a cell phone only for the time because watches are out of style.

[bart416]

Almost everybody has a PC. A good digital oscilloscope can cost more than an expensive gaming PC. And actually for low quality oscilloscopes you can use an old sound card. Just be sure to get a circuit to limit the voltage.

[Blackross]

even the "old" analog ones are expensive...

[bart416]

You can often find them on ebay. Usually there's something broken about them but in most cases it's something you'll never need. And oscilloscopes are fairly easy in design so it wouldn't be that hard to fix a simple issue.

[Blackross]

i forgot to add there was a led O-Scope you could build out of a hand full of led's, 4017's and a few ripple counters... (radio electronics i think)

[rgbphil]

My suggestion is to look a lot lower as a start and just use the PIC, and some signal conditioning for the probes, leave aside the A/D chips for now. The bandwidth will be a lot lower however for a lot of PIC work you only need 30kHz or so. Basically avoiding having to source special A/D chips. It'll also make implementation a lot easier. Using the comparator on the PIC and an analog control to set the trigger level would be OK...that way the capture can be pretty simple. I think the main problem will be buffering the data prior to transmission....you'd have to pick a PIC with plenty of RAM. The next iteration may need to have memory chips interfaced to the A/D chips somehow. Phil