Skip to main content ↑ ↓
Topic: BusPirate oscilloscope (Read 34214 times) previous topic - next topic

BusPirate oscilloscope

Hey,

I've created a simple python script which is able to draw plots from ADC measurements.
Unfortunately I've noticed that single ADC measure is quite slow so it's hard to say that this is working like a real oscope.
Is it possible to modify the firmware so the measurements were taken faster ?
UART 115200 baudrate  would probably let maximum measurable frequency to be about 3kHz in realtime.

See more here: http://hwmayer.blogspot.com/2010/09/bus ... cript.html

Re: BusPirate oscilloscope

Reply #1 –
Nice job!

I can make a new ADC mode that just spits out the readings non-stop until you send a command. Would that be helpful?
Got a question? Please ask in the forum for the fastest answers.

Re: BusPirate oscilloscope

Reply #2 –
The ADC in this PIC has a maximum speed of 500 kHz, but, as you note, the UART bandwidth is the bottleneck.  You might be able to write some interesting firmware which sets some sort of trigger, records samples at full speed (possibly with lossless data compression), and then downloads the snapshot at a lower rate over the UART.  Of course, if you're writing your own firmware then you could potentially change the USB endpoints to handle higher rates.

Re: BusPirate oscilloscope

Reply #3 –
Quote
I can make a new ADC mode that just spits out the readings non-stop until you send a command

This would be a good quick fix for now. But how fast will the readings be send ?

Quote
The ADC in this PIC has a maximum speed of 500 kHz, but, as you note, the UART bandwidth is the bottleneck.  You might be able to write some interesting firmware which sets some sort of trigger, records samples at full speed (possibly with lossless data compression), and then downloads the snapshot at a lower rate over the UART

I was thinking about something like a local buffer ( i suppose that there is one used for logic analyzer SUMP) which would be filled at defined speed after a local trigger (e.g rising edge or voltage level trigger) engage the measurement. Then plain data would be transfered by UART and whole thing repeats. This would give similar effect to a real oscilloscope which only displays part of the whole "timeline" so there is no need to send all data in real-time as probably only some part of it would be used.

Re: BusPirate oscilloscope

Reply #4 –
The readings would be sent at the max speed possible.
Got a question? Please ask in the forum for the fastest answers.

Re: BusPirate oscilloscope

Reply #5 –
Ok
It would be great if you could add such mode.
Could you prepare a firmware compilation with those modifications for me ?

Re: BusPirate oscilloscope

Reply #6 –
I'll add this and post a nightly for you on Monday.
Got a question? Please ask in the forum for the fastest answers.

Re: BusPirate oscilloscope

Reply #7 –
Here's a firmware to test. I tesdted in a terminal, and this seems to work. New command 10101 (0x15) sends data as fast as UART will allow. It waits until each byte is done so there's no time distortion from the buffer.

Another possibility would be a 2024 byte sampling o-scope that goes faster and dumps all the samples at once.
Got a question? Please ask in the forum for the fastest answers.

Re: BusPirate oscilloscope

Reply #8 –
That would probably be a better option, since 2k samples is actually fairly decent, the sample rate is much more limiting in this case. Still, it will never be close to a real scope.

Re: BusPirate oscilloscope

Reply #9 –
I've improved my script so it's now working much better.
It now uses new ADC mode. I've estimated that the data rate is about 5720 samples/second, what theoretically should give maximum measurable frequency at about 2.5kHz
In practice aliasing is noticeable at about 1kHz.
I've added a trigger which can sync on rising/falling slope

USAGE:
 f - trigger on falling slope
 r - trigger on rising slope
 s - trigger off
 key_up      - trigger level++
 key_down - trigger level--
 9 - time scale++ (zoom out)
 0 - time scale-- (zoom in)
 q - QUIT

Re: BusPirate oscilloscope

Reply #10 –
Nice! Thanks for sharing, I'll add it to the wiki too. This feature will go into the next release.
Got a question? Please ask in the forum for the fastest answers.

Re: BusPirate oscilloscope

Reply #11 –
FYI, In case anyone else is wondering the discussion has been split to a separate topic Use FT232 clock for PIC and higher speeds?

It's a bit confusing that the forum software sent "topic reply" notifications, that seemed to coincide with the split.  Of course when you click it, there are no new messages and no notification of the split.   Ian posted a message that he was going to split the topic and that the split was done but those both wound up in the new topic.

Re: BusPirate oscilloscope

Reply #12 –
Sorry about that. There's no current official location/documentation for the o-scope script, so I broke the other conversation off. I though it left a redirection post, maybe that's only when I move a whole topic.

@hw - may I put your usage instructions and screenshot on the wiki (that means a CC-BY-SA license)? May I add the script to the Bus Pirate SVN scripts folder (what license)?

I started a page here:
http://dangerousprototypes.com/docs/Bus ... cilloscope
Got a question? Please ask in the forum for the fastest answers.

Re: BusPirate oscilloscope

Reply #13 –
sure, you can add it and use on GPL license, just keep some info about me in the script header.

Re: BusPirate oscilloscope

Reply #14 –
Thanks! I added it to the SVN here with your header, the GPL, a link to this thread, and the usage info.
http://code.google.com/p/the-bus-pirate ... cilloscope

I also added an image and usage info the docs wiki.

Please let me know if there's anything you'd like me to change.
Got a question? Please ask in the forum for the fastest answers.