Author Topic: Open Source Oscilloscope  (Read 17521 times)

0 Members and 1 Guest are viewing this topic.

Offline jonw0224

  • Contributor
  • Posts: 20
  • Country: us
    • Jonathan's Homepage
Open Source Oscilloscope
« on: August 27, 2012, 09:04:13 pm »
I saw the Open Source Hardware section, and I couldn't resist (my first post).  I've been working on a DIY oscilloscope that is OSHW for a while. 

The idea is to keep costs down for an entry level (beginner) scope and also to keep the construction at an entry level (there is a thru hole layout and another guy contributed a surface mount layout).  Nothing fancy, just a front end, an ADC, and a microcontroller.

Check it out.

http://jonw0224.weebly.com/ppmscope.html

I enjoy the videos, Dave!  Thanks!
« Last Edit: August 25, 2014, 02:02:51 pm by jonw0224 »
Failures are finger posts on the road to achievement. ~ C. S. Lewis
 

Offline FenderBender

  • Super Contributor
  • ***
  • Posts: 1118
  • Country: us
    • The Solid State Workshop
Re: Open Source Oscilloscope
« Reply #1 on: August 27, 2012, 10:04:07 pm »
Looks very cool. Don't know much about oscilloscope design but why do you require such a big transformer, heatsinks, and cooling?
 

Offline poptones

  • Frequent Contributor
  • **
  • Posts: 711
  • Country: 00
Re: Open Source Oscilloscope
« Reply #2 on: August 27, 2012, 11:33:46 pm »
That's interesting. I'm wondering if you've now given me an inspiration as to what to do with my raspberry pi. Seems like a 500MHz cpu ought to be able to keep up with a few mhz sampling - if one can figure how to get the data into the thing. There's an spi interface, but all Broadcom has to say about that is the clock rate will be "less than" 125mhz because the i/o pads won't handle it. There's a 600mbps serial input for a camera, but data on how to use all that stuff is scarce because of Broadcom's terrible documentation.
 

Offline jonw0224

  • Contributor
  • Posts: 20
  • Country: us
    • Jonathan's Homepage
Re: Open Source Oscilloscope
« Reply #3 on: August 28, 2012, 02:12:51 am »
The published project is only part of a "all in one lab" (power supply, oscilloscope, and function gen).  The power supply is linear rated 2A at +/- 12 V and 1A at 5 V.  The cooling is classic over design.  I've been criticised for that before, but the design is really just a record of what I did not what I should have done.

The great thing about open hardware is that others build on your project.  So I really suggest looking at the contributed PCB layouts and the two redesigns (SampleScope and DSOScope).  I really love the form factor of the DSOScope and the fact that Paul made it USB powered.  I'm going to build his implementation myself just for the portability.  The SampleScope adds Linux software (that may help Pi users), uses a PIC with integrated USB, expands the buffersize, and eliminates the hardware/human interface.

I spent a good deal of time thinking about licensing and decided on GPL for the software/firmware and CC BY SA for the schematic and PCB.  GPL doesn't allow commercial sale of the software, but that is not intended to keep it from being able to be produced commercially.  I just don't want someone being charged for the software since it's a major component of the project.

Thanks for the interest and whoever gave the post stars.

-Jonathan
Failures are finger posts on the road to achievement. ~ C. S. Lewis
 

Offline poptones

  • Frequent Contributor
  • **
  • Posts: 711
  • Country: 00
Re: Open Source Oscilloscope
« Reply #4 on: August 28, 2012, 02:25:39 am »
GPL 2 allows for commercial sale. Millions of Windows DVD rippers were sold and most every one of them used a mixture of gpl and proprietary code. Home routers use gpl code. You can sell it for as much as you can get, the restriction is you have to make available the source of any code linked to gpl code.
 

Offline jonw0224

  • Contributor
  • Posts: 20
  • Country: us
    • Jonathan's Homepage
Re: Open Source Oscilloscope
« Reply #5 on: August 28, 2012, 02:33:02 am »
What about GPL 3?
Failures are finger posts on the road to achievement. ~ C. S. Lewis
 

Offline poptones

  • Frequent Contributor
  • **
  • Posts: 711
  • Country: 00
Re: Open Source Oscilloscope
« Reply #6 on: August 28, 2012, 03:36:22 am »
What about it?
 

Offline shebu18

  • Frequent Contributor
  • **
  • Posts: 309
  • Country: ro
Re: Open Source Oscilloscope
« Reply #7 on: August 28, 2012, 06:14:47 am »
Your project looks great, i am curious about the future development of it.


Keep up the good work.
 

Offline firewalker

  • Super Contributor
  • ***
  • Posts: 2358
  • Country: gr
Re: Open Source Oscilloscope
« Reply #8 on: August 28, 2012, 10:33:54 am »
You may use GPL v3 in order to avoid Tivoization.

Great project.

Alexander.
Become a realist, stay a dreamer.

 

jucole

  • Guest
Re: Open Source Oscilloscope
« Reply #9 on: August 28, 2012, 12:10:11 pm »
I saw the Open Source Hardware section, and I couldn't resist (my first post).  I've been working on a DIY oscilloscope that is OSHW for a while. 
The idea is to keep costs down for an entry level (beginner) scope and also to keep the construction at an entry level (there is a thru hole layout and another guy contributed a surface mount layout).  Nothing fancy, just a front end, an ADC, and a microcontroller.
http://jonathanweaver.net/ppmscope.html

nice one!  It's great also to see how one project inspires and spawns other projects!

I'm a bit of pic16f877A fan myself too;  I had a quick look through the asm source;  I have to ask, have you ever tried the free SDCC C compiler at all?   Your PC app looks to use the Codeblocks ide and I believe you can set that up to use the SDCC.  I'm guessing you used asm to squeeze every last drop out that pic, in terms of instruction cycles.

 

Offline jonw0224

  • Contributor
  • Posts: 20
  • Country: us
    • Jonathan's Homepage
Re: Open Source Oscilloscope
« Reply #10 on: August 28, 2012, 01:21:50 pm »
I used assembly because the timing in the sample routines is critical.  I spent a lot of time in MPLAB counting cycles.  I could have used a C compiler + inline assembly for the timing critical sections.

I've never heard of SDCC.  I'll check it out.  Thanks!
Failures are finger posts on the road to achievement. ~ C. S. Lewis
 

Offline Teemo

  • Regular Contributor
  • *
  • Posts: 58
  • Country: ee
Re: Open Source Oscilloscope
« Reply #11 on: January 10, 2013, 02:25:34 am »
This is really interesting project. Thanks for sharing.
I like the assembler.  Your code looks well made, I may even understand some of it.
Teemo
 

Offline poorchava

  • Super Contributor
  • ***
  • Posts: 1556
  • Country: pl
  • Troll Cave Electronics!
Re: Open Source Oscilloscope
« Reply #12 on: January 10, 2013, 01:47:09 pm »
I admire the amount of work put into that project. On the other hand I think that PIC16 or PIC18 are not the best choice. They might be fine for general control tasks (despite being a total heap of shit....), but this application requires raw processor speed and computational power. I am really impressed that you have managed to squeeze 1Msps out of something that has 5MIPS.

I think your project could greatly benefit from using a controller with hardware parallel interface like Microchips DCI or PMP. Other MCU manufacturers like NXP, ST, TI also provide hardware parallel interfaces.

 :-+ :-+ I really like the analog frontend: it is simple yet functional and has all the features it should (ac/dc coupling, attenuation, trimming and input protection).

On the side notice: using Maxim part will almost ensure that this design will not be stolen/cloned because Maxim is known for relatively easy access to samples, but terrible lead times and general problems with continuity of supply. I know of at least 4 companies that have them blacklisted for that reason :D
I love the smell of FR4 in the morning!
 

Offline branadic

  • Super Contributor
  • ***
  • Posts: 1549
  • Country: de
Re: Open Source Oscilloscope
« Reply #13 on: February 23, 2013, 09:08:26 pm »
Have you guys heard about the Welec-Projekt? There are two different open source FPGA designs available, Leon3 design (supports 2 channels with one FPGA) and the new NIOSII design (still under construction but continiously developed, supports 2 channels/FPGA and communication with a second FPGA with further 2 channels).
There is also an open source programmable/variable input stage (developed in 2010/2011) available based on the LMH6518, a pga/vga that is presently used in serveral chineese DSOs (Rigol etc.). I was one of the hardware designers for the new stage.

http://sourceforge.net/apps/trac/welecw2000a/wiki/HardwareImprovement

A really useful open source DSO needs something the present market can't offer. It can use the sources that have already been developed in the Welec project such as the FPGA design and hardware components.

My suggestion is: Back to the Tektronix mainframe time but with the features you can get today, so that you can configure a DSO for your special needs. This concept was one of the best in time, strange that it was never introduced again. You have to pay much money for a beast that can do it all instead of seperating the requirements into reasonable modular function blocks to lower costs.

Some features could be:

- up to 6 or 8 slots for different needs
- a nice big TFT (with touch control?)
- "high speed/high impedance" slot: up to 350MHz, real 10bit adc resolution (in HiRes Mode up to 12bit?), >1GSps
- "medium speed/resolution" slot: a few hundred kHz up to some MHz with 16bit and a few MSps
- "high resolution/low noise" slot: up to ~100kHz, a few hundred kSpS up to MSps
- "high speed/50?" slot: for high speed repetitive signal aquisition up to the GHz range

I wonder if I'm alone with my ideas?
Metrology Meeting 2020 on 06.06.2020
 

Offline ivan747

  • Super Contributor
  • ***
  • Posts: 2020
  • Country: us
Re: Open Source Oscilloscope
« Reply #14 on: February 25, 2013, 01:05:06 am »
That's interesting. I'm wondering if you've now given me an inspiration as to what to do with my raspberry pi. Seems like a 500MHz cpu ought to be able to keep up with a few mhz sampling - if one can figure how to get the data into the thing. There's an spi interface, but all Broadcom has to say about that is the clock rate will be "less than" 125mhz because the i/o pads won't handle it. There's a 600mbps serial input for a camera, but data on how to use all that stuff is scarce because of Broadcom's terrible documentation.

That leaves us with a parallel interface, something like this:
http://www.digikey.com/product-detail/en/ADS830E/ADS830E-ND/272011
 

Offline IanM

  • Contributor
  • Posts: 8
Re: Open Source Oscilloscope
« Reply #15 on: March 13, 2013, 08:26:42 pm »
Thanks for this. Loving this OSHW stuff.
 

Offline Teemo

  • Regular Contributor
  • *
  • Posts: 58
  • Country: ee
Re: Open Source Oscilloscope
« Reply #16 on: March 27, 2013, 01:34:54 am »
I saw the Open Source Hardware section, and I couldn't resist (my first post).  I've been working on a DIY oscilloscope that is OSHW for a while. 

The idea is to keep costs down for an entry level (beginner) scope and also to keep the construction at an entry level (there is a thru hole layout and another guy contributed a surface mount layout).  Nothing fancy, just a front end, an ADC, and a microcontroller.

Check it out.

http://jonw0224.tripod.com/ppmscope.html
Hello jonw0224,
Can you descibe briefly the communication protocol you are using between PIC and PC?
 

Offline jonw0224

  • Contributor
  • Posts: 20
  • Country: us
    • Jonathan's Homepage
Re: Open Source Oscilloscope
« Reply #17 on: March 27, 2013, 06:05:52 pm »
 I'm going to keep it at a high level (not explain line by line, just hit the big points).

The firmware initializes and then listens for messages from the PC (either on the parallel port which is actually i2c over the pins on the parallel port, or serial port depending on the status of the PAR/SER pin).

The format of the is a single byte command (PC to PIC) with a single byte response (PIC to PC) and then the message either PC to PIC or PIC to PC.

The commands are as follows:

Configuration Send
------------------
PC to PIC: CONFSEND (B'11111001' or D'249') (one byte)
PIC to PC: Response (B'11011110' or D'222') (one byte)
PIC to PC: Buffersize (two bites, currently always D'256')
PIC to PC: ConfigLoc1 (one byte)
PIC to PC: triggerDelay1:triggerDelay2:triggerDelay3 (three bytes)
PIC to PC: sampleRate1:sampleRate2 (two bytes)
The PIC then waits for the next PC command

Configuration Receive
---------------------
PC to PIC: CONFRECIEVE (B'11111010' or D'250') (one byte)
PIC to PC: Response (B'11011101' or D'221') (one byte)
PC to PIC: ConfigLoc1 (one byte)
PC to PIC: triggerDelay1:triggerDelay2:triggerDelay3 (three bytes)
PC to PIC: sampleRate1:sampleRate2 (two bytes)
The PIC then accepts the configuration and samples the waveform accordingly

Data Send
---------
PC to PIC: DATA (B'11111000' or D'248') (one byte)
PIC to PC: Response (B'11011100' or D'220') (one byte)
PIC to PC: 256 samples (256 bytes)
PIC to PC: dataConfig (one byte)
PIC to PC: channel1offset (always D'0') (one byte)
PIC to PC: channel2offset (always D'0') (one byte)
PIC to PC: triggerLevel (one byte)
The PIC then waits for the next PC command

To sample the waveform, the PIC sets up the appropriate configuration and either start sampling immediately (in the case of no trigger) or sets up the trigger interrupt and loops indefinitely waiting for a trigger event.  The PC can interrupt the PIC while it waits for a trigger by sending a Break Trigger message.

Break Trigger
-------------
PC to PIC: BREAK (B'11110011' or D'243')
PIC to PC: Response (B'11011100' or D'220')

This allows the user interface to continue to be responsive.

After the trigger event occurs, the PIC waits a time specified by triggerDelay1:triggerDelay2:triggerDelay3 and then selects the frequency sample mode based on configLoc1 and samples all 256 samples according to the mode.  I'm going to address a common question.  If you look at the interrupt routine, you will notice that I do not save the program context and I do not return from the interrupt.  This is because I control the interrupt enable bit so that the interrupt only occurs when I am listening for a trigger event.  The side effect is that eventually the PIC overwrite the eight address stack, however there are no ill effects because I do not pop the stack (unless I've pushed the stack again).  For more on this, check out ww1.microchip.com/downloads/en/DeviceDoc/33023a.pdf section 6.2.5.

After all samples are gathered, the PIC awaits the next PC command.

Conversely, the PC operates on a timer (variable set in the program, defaulting to 10 Hz refresh rate).  The code that executes on the timer gathers the last set of samples, updates the PIC configuration, and then redraws the screen.  While it redraws, the PIC is sampling.

Now, I'm going to describe the configuration bytes:

configLoc1:
-----------
bit7: triggerslope, 1 is positive slope, 0 is negative slope
bit6: trigger enable, 1 is enabled, 0 is no trigger
bit5: clockfreq, 1 is 20 MHz, 0 is 4 MHz (this is always 1)
bit4: channelbit, 1 is channel 2, 0 is channel 1
bits 3 thru 0: frequency mode, described below.

frequency mode:
0: 1 MHz, single channel
1: 833 kHz, single channel
2: 625 kHz, single channel
3: 417 kHz, single channel
4: 250 kHz, single channel
5: sampledelayed, single channel, sample rate is 5e6/(18+7*sampleRate1:sampleRate2+3*sampleRate1
6: 5 MHz, equivalent time sampling, single channel
7: 2 MHz, equivalent time sampling, single channel
8: 417 kHz, dual channel
9: 250 kHz, dual channel
10: 192 kHz, dual channel
11: sampledelayed, dual channel, sample rate is 5e6/(26+7*sampleRate1:sampleRate2+3*sampleRate1).  channel2 is sampled 1.2 uSec after channel 1.
12 thru 15: unused/invalid
Note: equivalent time sampling is expected to be used with the trigger enabled set.

triggerDelay:
-------------
cycles = a + 3*triggerDelay3 + 770*triggerDelay2 + 197122*triggerDelay1
t = cycles*4/20e6
For the equivalent time sampling, a = 23
For all other sample modes, a = 14

dataConfig:
-----------
bits 7 thru 6: Channel 1 gain.  B'00' = 1, B'01' = 2, B'10' = 5
bits 5 thru 4: Channel 2 gain.  B'00' = 1, B'01' = 2, B'10' = 5
bit 3: Channel 1 coupling.  1 = AC.  0 = DC.
bit 2: Channel 2 coupling.  1 = AC.  0 = DC.
bit 1: Unused, set to 0
bit 0: Unused, set to 0

I will share that some of these things are going to change in future releases to allow for feature additions, but this applies to version 1.2 of the firmware.

I hope this was helpful.

Jonathan
Failures are finger posts on the road to achievement. ~ C. S. Lewis
 

Offline Gert Kotze

  • Contributor
  • Posts: 6
Re: Open Source Oscilloscope
« Reply #18 on: October 07, 2013, 10:35:12 am »
I will certainly give this one a go and build it up for  myself.
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf