Skip to main content
Topic: PirateScope - yet another BP oscilloscope client (Read 14321 times) previous topic - next topic

PirateScope - yet another BP oscilloscope client

Hi all,

If anybody's interested, I've written another Bus Pirate oscilloscope script.  Like hwmayer's it's written in Python, but uses the wxpython module rather than pygame to provide some GUI-ness (not Guinness - doh).  It also requires the numpy module.

The script (distribute under GPL) is attached, as are a couple of screenshots.  The first displays the triggering function with the trigger voltage level  (horizontal dashed line) and the trigger point (vertical dashed line) shown on the graph.  The second shows the spectral analysis function for a 250Hz square wave input (the higher frequency peaks are harmonics).  You can also save sampled data and the plots of this data to disk.

Anyway, not sure if this'll be useful to anybody else  (you probably all have real oscilloscopes :-) ), but I thought I'd post it here (under GPL) just in case.

Cheers,
Tim

p.s. The sampling rates quoted in the drop-down menu and the sampling times and frequencies shown on the graphs are based on hwmayer's measurement of 5720Hz for the maximum sampling rate.

Re: PirateScope - yet another BP oscilloscope client

Reply #1
Hi Tim,

Thanks for the code and effort! I liked the looks of the GUI and will try soon. One question: You used FFT for spectrum analysis, right? And one suggestion: For the next version, is it possible to show the max. frequency that we can measure? Adjusting the x-axis can be one way, or just putting a vertical dashed line would be another. Just a thought. :)

Note: Wish I had a real o-scope! Don't have one don't have access to one. :(

Re: PirateScope - yet another BP oscilloscope client

Reply #2
Cool !
I'm wondering what's the time of the sampling impulse in PIC, is it shorter than the conversion time ? If so the we could theoretically build a scope with coherent sampling and rise the bandwidth a lot. Currently I'm working on an atmega32 based scope witch would do the triggering locally and store the whole sampling window in a buffer and then transmit it via uart with lower speed than the sampling rate. How much free RAM is in BP now ? Maybe it's possible to add such buffer to BP e.g. for 500 samples (500bytes ?)

Re: PirateScope - yet another BP oscilloscope client

Reply #3
Thanks for the kind words. :)

Quote
One question: You used FFT for spectrum analysis, right? And one suggestion: For the next version, is it possible to show the max. frequency that we can measure? Adjusting the x-axis can be one way, or just putting a vertical dashed line would be another. Just a thought. :)

Yes, the spectrum is a discrete FT generated using numpy's rfft() function.  (It's actually the magnitude of the DFT, to capture both sine and cosine components on the one axis.)  The max frequency is the Nyquist frequency and is the right-hand limit of the X axis when a spectrum is displayed (here it's around 2.8kHz).

Quote
Cool !
I'm wondering what's the time of the sampling impulse in PIC, is it shorter than the conversion time ? If so the we could theoretically build a scope with coherent sampling and rise the bandwidth a lot. Currently I'm working on an atmega32 based scope witch would do the triggering locally and store the whole sampling window in a buffer and then transmit it via uart with lower speed than the sampling rate. How much free RAM is in BP now ? Maybe it's possible to add such buffer to BP e.g. for 500 samples (500bytes ?)

I think the BP's PIC24 has a 4096 byte internal buffer.  This is an interesting idea, but I'm not sure how much the development team want to modify the firmware for these (admittedly) fringe applications...

Oh, one thing I didn't mention is that the unlabeled scroll bar on the right-hand side of the graph controls the trigger voltage level.  There's an option under the view menu to display this voltage as a horizontal dashed line on the graph, but this is initially disabled.

Re: PirateScope - yet another BP oscilloscope client

Reply #4
The Bus Pirate firmware has a 4096 byte buffer we can use for whatever.  We have most of the support functions already, a 4096 byte buffered sample mode would be pretty easy, though adjustable rate could be a pain.

Would 8 bits be enough? That would double the number of samples, and also the speed of the live sampling mode.
Got a question? Please ask in the forum for the fastest answers.

Re: PirateScope - yet another BP oscilloscope client

Reply #5
Hi Ian,

I suppose we don't need the additional byte - especially as we're currently using only 2 bits of it anyway.  Personally, I think the additional sampling rate would be worth it.

As far as adjustable rate goes, it's pretty easy to implement this on the software side by dropping a few samples here and there.  I know this shortens the buffer, but 4096 is way more samples than I'm currently displaying on the window, even taking into account pre-trigger buffering.

Tim

Re: PirateScope - yet another BP oscilloscope client

Reply #6
Just to clarify, while Miniscope already provides what looks to be an awesome GUI for BP Oscilloscope activities, it is exclusively a Windows program - so I can't use it.  PirateScope was designed for Linux, although it should in principle be cross-platform.

To get it going on Debian/Ubuntu you should ensure that both the python-wxgtk2.8 and python-numpy packages are installed. That is,
Code: [Select]
sudo apt-get install python-wxgtk2.8 python-numpy

Also, if your bus pirate shows up on a different device file to /dev/ttyUSB0, you'll need to change this under File->Set Bus Pirate Device.  (There's currently no permanent config file, so you'll have to do this every time you start the program or do a search and replace in the script itself.)

Cheers,
Tim

Re: PirateScope - yet another BP oscilloscope client

Reply #7
[quote author="tgvaughan"]
Also, if your bus pirate shows up on a different device file to /dev/ttyUSB0, you'll need to change this under File->Set Bus Pirate Device.  (There's currently no permanent config file, so you'll have to do this every time you start the program or do a search and replace in the script itself.)
[/quote]

Following is the process I follow to make sure the multiple devices that use a FTDI serial chip are assigned to permanent names. This works on Ubuntu/Debian systems and should work on any Linux system that uses udev.

=======================================================================================
Adding a persistant name to a USB device, or altering permissions for that device.

1) Determining the Vendor and Product ID

  Plug in the device and run the command

Code: [Select]
lsusb

ie:

[tt:]Bus 002 Device 002: ID 051d:0002 American Power Conversion Uninterruptible Power Supply
Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 001 Device 023: ID 0403:6001 Future Technology Devices International, Ltd FT232 USB-Serial (UART) IC
Bus 001 Device 008: ID 0424:2504 Standard Microsystems Corp. USB 2.0 Hub[/tt:]

The device I am interested in is the FTDI device, since I know this is the USB to serial device installed.

2) Now I need to find out the unique ID for this device, since many products use the FTDI chip for USB->serial conversion. To do this, you need to look in the '/var/log/messages' file for the message printed by the kernel when it added the device.

Code: [Select]
tail /var/log/messages

[tt:]Sep 22 19:15:41 athalon kernel: [368961.864982] USB Serial support registered for FTDI USB Serial Device
Sep 22 19:15:41 athalon kernel: [368961.865204] ftdi_sio 1-1.2:1.0: FTDI USB Serial Device converter detected
Sep 22 19:15:41 athalon kernel: [368961.865283] usb 1-1.2: Detected FT232RL
Sep 22 19:15:41 athalon kernel: [368961.865286] usb 1-1.2: Number of endpoints 2
Sep 22 19:15:41 athalon kernel: [368961.865288] usb 1-1.2: Endpoint 1 MaxPacketSize 64
Sep 22 19:15:41 athalon kernel: [368961.865290] usb 1-1.2: Endpoint 2 MaxPacketSize 64
Sep 22 19:15:41 athalon kernel: [368961.865292] usb 1-1.2: Setting MaxPacketSize 64
Sep 22 19:15:41 athalon kernel: [368961.865656] usb 1-1.2: FTDI USB Serial Device converter now attached to ttyUSB0
Sep 22 19:15:41 athalon kernel: [368961.865675] usbcore: registered new interface driver ftdi_sio
Sep 22 19:15:41 athalon kernel: [368961.865677] ftdi_sio: v1.5.0:USB FTDI Serial Converters Driver[/tt:]

This tells us that the device is currently assigned /dev/ttyUSB0

3) Once we have the current device ID, we can look at it in more detail and see what the serial number of the product is:

Code: [Select]
udevadm info -a -n /dev/ttyUSB0|grep serial


[tt:]    SUBSYSTEMS=="usb-serial"
    ATTRS{serial}=="A700eLPP"
    ATTRS{serial}=="0000:00:13.2"[/tt:]

You can look at the output in more detail, but the line that is of interest to us is the first line:

ie: ATTRS{serial}=="A700eLPP"

4) We have to now make a couple of command decisions.

        a) what owner/group to use
        b) what permissions to use

Since the device is going to be for my unique use, I will use my information. This is user=fixer, group=fixer.

5) With all the above information, we can create a UDEV rule for assigning this device each time it is plugged in.

Local udev rules go in /etc/udev/rules.d on ubuntu systems

Code: [Select]
'cd /etc/udev/rules.d'

'vim 99-local.rules

insert the line:
[tt:]SUBSYSTEM=="tty", ATTRS{idVendor}=="0403", ATTRS{idProduct}=="6001", ATTRS{serial}=="A700eLPP", SYMLINK+="buspirate", OWNER="fixer", GROUP="fixer", MODE="0660"[/tt:]

save the file and then plug in the device.

6) Testing!

Code: [Select]
ls -al /dev/ | grep ttyUSB*

[tt:]lrwxrwxrwx   1 root root             7 2010-12-06 17:40 buspirate -> ttyUSB0
crw-rw----   1 fixer  fixer       188,   0 2010-12-06 17:40 ttyUSB0[/tt:]

WooHoo!! IT WORKS!!

As you can see, the original device is still there, but now it is owned by my user and in my group. There is also a symlink name that I can now use in any scripts or configurations that may be specific to this device.

You can use any username or any group name that you want in the udev rule. You can also alter the permissions.

For example, if I want one of my web pages to read a set of coordinates from a GPS reciever,

The apache server on ubuntu runs as the www-data group by default. So the udev rule would become:
[tt:]SUBSYSTEM=="tty", ATTRS{idVendor}=="0403", ATTRS{idProduct}=="6001", ATTRS{serial}=="A700eLPP", SYMLINK+="gpsdongle", GROUP="www-data", MODE="0660"[/tt:]

I have removed the 'OWNER' parameter as it is not needed and changed the group to the one that apache belongs to.

=======================================================================================

Hope this helps the Linux users out there.

--
Fixer

Re: PirateScope - yet another BP oscilloscope client

Reply #8
Thanks Fixer!  I actually already have udev set up to assign /dev/bus_pirate in the way you describe, but thought it'd be best to assume /dev/ttyUSB0 in the version I posted above.   If you'd like to change the default used by PirateScope, modify line 421 of the script:
Code: [Select]
self.port = '/dev/ttyUSB0'
(In future I may add configuration file support.)

Thanks again for the useful info.

Re: PirateScope - yet another BP oscilloscope client

Reply #9
Just for giggles, I've created a PirateScope github repository. Any future updates will be posted there.

Re: PirateScope - yet another BP oscilloscope client

Reply #10
I added a link to your GIT in the wiki.
Got a question? Please ask in the forum for the fastest answers.

Re: PirateScope - yet another BP oscilloscope client

Reply #11
Not exactly a client, so maybe I am in the wrong location.  Musing.

Today, just encountered 3D graphics as a function that can be inbedded with GSP + ARM by TI. As a common waterfall display of FFT results that could be a natural to show a spectrogram.

Then all of the interest in SCOPE aspects clicked in. The Precision Analog (AP) system of my application interest also is keeping general lab and instrument applications in mind.  This could eventually play into SCOPE solutions in a couple of ways. The high resolution A to D function in the present definition can sample a single source at about a half million samples per second continuous.  It you are observing a repetitive event or sampling at slower rates you could display the amplitude versus time AND its 3D spectrogram of frequency versus time versus amplitude (a waterfall display). That could be produced by some reprogramming of a common AP board configuration.  Presently available hardware choices could permit that sample rate to be increased, if that were useful.  That will take time to emerge.

Re: Re: PirateScope - yet another BP oscilloscope client

Reply #12
Hello all,

I'm pretty new to the whole bus pirate thing.  I'd like to try using PirateScope as an oscilloscope, but I have no idea how to know what leads I should be using.  My projects have been pretty simple so far and I'm trying to just start out with a simple blinking LED.  What leads should I be using and why?

I see in the PirateScope code that I should be using the ADC lead, but that presents me a different question: When looking at the ribbon of probes, how do I know what's what?  Should I be referencing this?
http://dangerousprototypes.com/2010/01/ ... e-sticker/

Thanks.

Re: Re: PirateScope - yet another BP oscilloscope client

Reply #13
G'day GranitePenguin,

The pins to use are ADC and GND.  (See http://http://dangerousprototypes.com/docs/Bus_Pirate_I/O_Pin_Descriptions for a full description of the Bus Pirate pins.)  Note that the BP was not designed with this use in mind, so there are some pretty severe restrictions on what you can do.  A very important thing to remember is that the voltage difference you apply between ADC and GND should be no greater than 5 or 6V -- any larger and you'll risk damaging the BP.

Hope this helps,
Tim

p.s. Just saw your github post, glad to see you got everything working eventually under OS X!  If you don't mind, I'll incorporate your tips (with acknowledgement) into the README at some point.

Re: Re: PirateScope - yet another BP oscilloscope client

Reply #14
Tim,

Thanks for the quick response.  I did find the ADC stuff while looking through the source code, and then it was just a question of figuring out what color goes to what pin.  I've got it working and reading like I'd expect. 

The voltage diff shouldn't be a problem.  Most of the stuff I'm doing is small-scale Arduino, so the max I'd be likely to see is about 5v.  I'm still learning a lot of this, and this will tide me over for quite a while until I can justify a real oscope.

You are welcome to add my OSX stuff, too.  I'll see if I can flesh it out a bit more for you.  I just hope it doesn't all crater if/when I upgrade to 10.7.  I'll just have to move to the linux box if that happens :-)