Open Source Oscilloscope - Page 1
Forum section: electronics / general

author: jonw0224
author_rank: Contributor
timestamp: August 27, 2012, 09:04:13 pm
content: 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.htmlI enjoy the videos, Dave! Thanks!

author: FenderBender
author_rank: Super Contributor
timestamp: August 27, 2012, 10:04:07 pm
content: Looks very cool. Don't know much about oscilloscope design but why do you require such a big transformer, heatsinks, and cooling?

author: poptones
author_rank: Frequent Contributor
timestamp: August 27, 2012, 11:33:46 pm
content: 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.

author: jonw0224
author_rank: Contributor
timestamp: August 28, 2012, 02:12:51 am
content: 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

author: poptones
author_rank: Frequent Contributor
timestamp: August 28, 2012, 02:25:39 am
content: 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.

author: jonw0224
author_rank: Contributor
timestamp: August 28, 2012, 02:33:02 am
content: What about GPL 3?

author: poptones
author_rank: Frequent Contributor
timestamp: August 28, 2012, 03:36:22 am
content: What about it?

author: shebu18
author_rank: Frequent Contributor
timestamp: August 28, 2012, 06:14:47 am
content: Your project looks great, i am curious about the future development of it.Keep up the good work.

author: firewalker
author_rank: Super Contributor
timestamp: August 28, 2012, 10:33:54 am
content: You may use GPL v3 in order to avoidTivoization.Great project.Alexander.

author: Unknown
author_rank: Unknown
timestamp: August 28, 2012, 12:10:11 pm
content: Quote from: jonw0224 on August 27, 2012, 09:04:13 pmnice 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.

author: jonw0224
author_rank: Contributor
timestamp: August 28, 2012, 01:21:50 pm
content: 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!

author: Teemo
author_rank: Regular Contributor
timestamp: January 10, 2013, 02:25:34 am
content: 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

author: poorchava
author_rank: Super Contributor
timestamp: January 10, 2013, 01:47:09 pm
content: 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

author: branadic
author_rank: Super Contributor
timestamp: February 23, 2013, 09:08:26 pm
content: 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/HardwareImprovementA 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 rangeI wonder if I'm alone with my ideas?

author: ivan747
author_rank: Super Contributor
timestamp: February 25, 2013, 01:05:06 am
content: Quote from: poptones on August 27, 2012, 11:33:46 pmThat leaves us with a parallel interface, something like this:http://www.digikey.com/product-detail/en/ADS830E/ADS830E-ND/272011

author: IanM
author_rank: Newbie
timestamp: March 13, 2013, 08:26:42 pm
content: Thanks for this. Loving this OSHW stuff.

author: Teemo
author_rank: Regular Contributor
timestamp: March 27, 2013, 01:34:54 am
content: Quote from: jonw0224 on August 27, 2012, 09:04:13 pmHello jonw0224,Can you descibe briefly the communication protocol you are using between PIC and PC?

author: jonw0224
author_rank: Contributor
timestamp: March 27, 2013, 06:05:52 pm
content: 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 commandConfiguration 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 accordinglyData 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 commandTo 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 slopebit6: trigger enable, 1 is enabled, 0 is no triggerbit5: clockfreq, 1 is 20 MHz, 0 is 4 MHz (this is always 1)bit4: channelbit, 1 is channel 2, 0 is channel 1bits 3 thru 0: frequency mode, described below.frequency mode:0: 1 MHz, single channel1: 833 kHz, single channel2: 625 kHz, single channel3: 417 kHz, single channel4: 250 kHz, single channel5: sampledelayed, single channel, sample rate is 5e6/(18+7*sampleRate1:sampleRate2+3*sampleRate16: 5 MHz, equivalent time sampling, single channel7: 2 MHz, equivalent time sampling, single channel8: 417 kHz, dual channel9: 250 kHz, dual channel10: 192 kHz, dual channel11: 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/invalidNote: equivalent time sampling is expected to be used with the trigger enabled set.triggerDelay:-------------cycles = a + 3*triggerDelay3 + 770*triggerDelay2 + 197122*triggerDelay1t = cycles*4/20e6For the equivalent time sampling, a = 23For all other sample modes, a = 14dataConfig:-----------bits 7 thru 6: Channel 1 gain. B'00' = 1, B'01' = 2, B'10' = 5bits 5 thru 4: Channel 2 gain. B'00' = 1, B'01' = 2, B'10' = 5bit 3: Channel 1 coupling. 1 = AC. 0 = DC.bit 2: Channel 2 coupling. 1 = AC. 0 = DC.bit 1: Unused, set to 0bit 0: Unused, set to 0I 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

author: Gert Kotze
author_rank: Newbie
timestamp: October 07, 2013, 10:35:12 am
content: I will certainly give this one a go and build it up for myself.