Stepstones to construct simple digital oscilloscope? - Page 1
Forum section: electronics / beginners

author: dds
author_rank: Contributor
timestamp: September 18, 2012, 09:35:22 am
content: Please, don't flame me, I'm newbie and a dreamer, but I would like to know what knowledge/steps are required to build digital oscilloscope with LCD screen, like this project from germany :http://www.mikrocontroller.net/topic/228997?(I'm clueless about German language).Thanks!

author: ejeffrey
author_rank: Super Contributor
timestamp: September 18, 2012, 09:49:17 am
content: A lot. Nothing in it is too complicated, but is requires a fair bit of work in a number of different areas -- analog, digital, software, VHDL, mechanical, and UI to make a usable DSO. It is definitely not a good beginner project. Also, some of the parts you want (like display drivers and CPUs) may not be easily available on the open market and may not have documentation available unless you are a major customer.

author: Nermash
author_rank: Frequent Contributor
timestamp: September 18, 2012, 09:51:16 am
content: Simple, ask Mike to do it

author: dds
author_rank: Contributor
timestamp: September 18, 2012, 10:12:15 am
content: Quote from: Nermash on September 18, 2012, 09:51:16 amWho's Mike?

author: psycho0815
author_rank: Regular Contributor
timestamp: September 18, 2012, 10:36:08 am
content: Without translating the whole thread,According to it you basically need:An analog input circuit. Theres a schematic in there looks quite complicated..Fast ADCs, obviously.A way to read and save the data from the ADCs, in this case a fpga is used.And then a microcontroller of some sort which reads the data from the RAM and displays it.And of course some kind of UI.The most critical parts apparently are the analog input stage and the adc, which makes sense.But this is definitively not a beginner project, and i seriously doubt it's gonna be cheaper than say a RIGOL DS1052E even without taking the working hours into account.If your more interested in the learning experience maybe have a look at the XProtolabhttp://www.gabotronics.com/development-boards/xmega-xprotolab.htmIt's an atmel xmega based mini oscilloscope. I don't have one my self, but they provide the complete schematics and sourcecode, so it seems like a nice opportunity to play around with and see how an dso works. Only 200kHz Bandwidth, though.

author: kripton2035
author_rank: Super Contributor
timestamp: September 18, 2012, 10:51:40 am
content: you can first try to understand how this simple one works ?http://semifluid.com/2006/08/21/pic18f2550-ks0108-graphical-lcd-oscilloscope/

author: poodyp
author_rank: Regular Contributor
timestamp: September 18, 2012, 12:13:45 pm
content: So this got me thinking about how I could make a ridiculously simple digital oscilloscope and I really want to see if it would work...Take an LM3914, feed that to 10 10bit latches, then use a decade counter triggered by a 555 astable to scan the latches to one by one latch the output of the 3914. Absolutely worthless with not even 4 bit resolution, doesn't even have a trigger, but totally dead simple.I think you could actually make it somewhat useful by using an opamp to work as a trigger by resetting the decade counter at a certain voltage, make the timebase specific and adjustable with a rotary switch to select a specific frequency for the 555, and a rotary switch to select a resistor divider for the 3914.Any thoughts?EDIT:I built it in a simulator, it's a mess, and it runs like crap, but I think it looks pretty cool.

author: free_electron
author_rank: Super Contributor
timestamp: September 18, 2012, 03:19:16 pm
content: I call bullshit. Nothing do-it-yourself.From the pictures it is clear he used a recycled tds210 including the frontpanel ( plastic body) , the panel with the buttons and rotary encoders and the lcd display as inspiration. The location of components is identical. He may have modified the electronics of the pushbuttonpanel , or drawn his own but it is a tds210 copy/mod.Also look at the screenshot. That is an exact tds 210 clone, including positioning and the way menu options are highlighted...Someone on the forum already called the striking similarities out ( no it wasn't me, until today i never saw this ) and the guy acts in 'wonderment'.. " really it looks like a tds210 ?' .. I swear i made it out of bits of recycled plastic foam... Sure...As for the rest most of the real 'hard" stuff is dome in the fpga. With hard stuff i mean the things that need to be done fast and interlocked in time. Ie the actual sampling and processing of the samples. The fpga formats the tracedata in such a way that the microcontroller has almost nothing to do.The lcd display used is a selfscanned monochrome display. These things behave like an old tv. They have a horizontal reset, vertical reset, horizontal clock , vertical clock and 1 data pin. Just like an old tv , you reset both hor and vert and start clocking hor. Every clock writes one pixel on line 0. After 320 clocks you trigger the vert clock and writing continues, just like an old tv would scan the tube (albeit the lcd is progressive and not interlaced )Old home computers like apple 2 , zx81 and others had no display controller. A 16khz clock drives an interrupt and the interrupt processor simply spits out the next pixel. Easy to do , even with a 1MHz cpu.Of course, there are endless hours involved in tweaking all this stuff out so it is still impressive he pulled this off. This is not something you do in a few days. There is a lot of work involved, but nothing really hard. Its a matter of combining the right techniques and some cleverness.Of course, if you don't know the techniques to begin with and have to come up with them ... That's another story.Looks like there is another trick involved. The pcb behind the display has , besides the processor ( in a real tds210 this is a motorola 68000) a static ram. The long skinny chip with the issi logo is a 32k static ram. One trick would be that this is the actual video memory. The fpga blasts the trace data , including graticule, in there using a dma like mechanism , the cpu touches the pixels for the menus and the rest is then hardware scanned, or interrupt scanned from this ram to the display.Another advantage of this kind of lcd is that they are very slow. Even though you are responsible for the refresh , you can refresh them at like 10 frames a second. Non eed for 50 frames a second like a tv... So this gives a lot of processing time to both cpu and fpga to fidlle around in the sram

author: Unknown
author_rank: Unknown
timestamp: September 19, 2012, 04:18:26 pm
content: Quote from: free_electron on September 18, 2012, 03:19:16 pmI'm looking to build a digital oscilloscope module as my next project, so basically researching and soaking up info at the moment. The plan is a sample rate of 10Mhz but if the concept works, I'm planning of trying to interleave it to get a better sample rate.

author: M0BSW
author_rank: Frequent Contributor
timestamp: September 19, 2012, 04:38:48 pm
content: Quote from: ejeffrey on September 18, 2012, 09:49:17 amGlad you said not a beginers project, otherwise I'd have to go back to Crystal radio's receivers and audio filters, phewwwwwwwwww

author: AndyC_772
author_rank: Super Contributor
timestamp: September 19, 2012, 06:11:30 pm
content: Quote from: free_electron on September 18, 2012, 03:19:16 pmAww, come on, just because someone's gutted a Tek to provide a box and a convenient front panel, that hardly disqualifies the project. It's got its own power supply, processor, front end and display driver; adding a new, completely DIY front panel would just make it uglier.I think it's a pretty cool achievement. I've been thinking about having a go at making a really decent portable (ie. smart phone sized) scope, as there aren't any out there at the moment, and projects like this make me feel that maybe it's not such a massive undertaking after all.

author: T4P
author_rank: Super Contributor
timestamp: September 19, 2012, 07:25:39 pm
content: There are lots of handheld scopes but they are all total crap and let's face it ...you don't have nearly enough room to pack a >30V input circuitry in a handheld scope but if you can write better software and implement proper touchscreen i have absolutely no issues with that, of which the chinese still can't get right!All their handheld and pen scopes have only a few buttons which means it's a nightmare to scroll through the menus

author: AndyC_772
author_rank: Super Contributor
timestamp: September 19, 2012, 07:38:24 pm
content: For my purposes, I have no particular need for high voltage isolation. 99% of the work I do is on safe, low voltage, current limited circuits. For the rest I'll use a full sized bench scope - preferably someone else's.It's the software that puts me off, really. I'm a hardware engineer, so I'm confident that I could probably design an acquisition circuit, FPGA, frame buffer, processor, power supplies and so on - all of which would have the potential to work very effectively together. There's a lot of work to do to get it right, but it's all-or-nothing in this area IMHO. Designing another toy scope would be completely pointless.On the software side, though, I can just about stretch a PIC18 to its limits but would probably need some help on the UI and other higher level features.Anyone know a really good, but currently under-employed, professional software engineer in the south of England?

author: Unknown
author_rank: Unknown
timestamp: September 19, 2012, 07:51:08 pm
content: Mike from MikesElectronicStuff has done great little review and tear-down of one of the cheapo Chinese scopes. very interesting stuff! I have the same Altera fpga in a basic dev board i'm planning to use as the basis for my scope.

author: Unknown
author_rank: Unknown
timestamp: September 19, 2012, 08:10:02 pm
content: Quote from: AndyC_772 on September 19, 2012, 07:38:24 pmSurely UI is the easiest part? would this be open-source?

author: free_electron
author_rank: Super Contributor
timestamp: September 19, 2012, 08:23:26 pm
content: Quote from: AndyC_772 on September 19, 2012, 06:11:30 pmin that german article he claims to have made the front panel from pieces of plastic that he carved using a box cutter knife .... and he also claims to have made the keypad / encoder from a recycled casio calculator...that's what i call bull. the positioning of everything is identical to a tds210.and if that doesn't convince you : look at the lcd screenshot the entire screen layout , soft buttones etc is identical to a tds210. he;s got a tds210 , or had one ...Now , back on track.making a scope out of an a/d fpga and cpu is not that hard work. the most time will sit in the menuing system and data visualisation. the real critial aspect is the input stage.the block in the fpga is pretty simple. make a level detector for the trigger ( value larger than for rising edge or less than for falling edge , you can add a hysteresis for two samples if you want). this is simple combinatorial logic.the rest is a counter that increments address lines to a ram and copies the data from adc to ram.You can pull a lot of trickery here. Let's assume you will use a 320x240 pixel display. and 8 bit adc gives you 256 values. you only have 240 , but that is fine.... vertical a scope only has ... 8 divisions, not 10... so , lets assume 24 pixels per division (3 bytes) , which gives us exactly 192 pixels vertical. anything outside that we clip off. leaves 40 pixels... 8 at the top for a top menu bar (1 byte) , 40 (5 bytes) at the bottom for a bottom softmenu bar. this means we only need vertically 8x3 bytes for the trace , 1 byte for top bar and 5 bytes for bottom bar ( or you could do 2 bytes top , 4 bytes bottom bar.it is easy for the fpga , while data is coming on to select the correct address in ram and actually drawy the lines , including the graticule ( graticule is driven by the same counter and creates a pattern that is logically or-ed with the trace data.this is a few pages of verilog code. not hard. you can use the internal ram in the fpga to store the dataA second block scans this ram and sends the contents to the lcd. in an fpga it is easy to use a dual port or even multiport ram.i would use a 3 port ram.1st port : write trace and graticule from frontend. you include wo coutners for cursors. the cpu sets the counter .2nd port : write text and info from cpu. since these screen locations are different from trace data there is no contention risk.3rd port : read only port. this scans the ram to the lcd.the cpu will be sleeping half of its time. all it needs ot do is look for keystrokes or rotary encoder actions and change the cursor counter and trigger valuessampling speed is controlled by fpga. a matter of throwing in a divider.the fpga can easily perform the clipping on the incoming data.

author: AndyC_772
author_rank: Super Contributor
timestamp: September 19, 2012, 08:53:46 pm
content: The one feature I'd most want is, unfortunately, one which would make the hardware appreciably more complex - but would also lift the product well above the toy scopes that already exist and work this way.I'm talking about the ability to acquire waveforms at a much faster rate than the display is updated, and to display an intensity graded trace more like an analogue scope. This is the one feature which, for me at least, marks the difference between a toy scope and a serious professional tool. After all, the reason a scope is used at all is to see what a signal is doing, and the clearer and more representative the image the scope can display, the more useful a tool it becomes.My bench scope is an early one which had this feature, and it can be turned on and off with a button on the front panel. The difference, especially for noisy or unstable (ie. interesting!) signals can be quite striking, and I simply wouldn't bother to design a scope at all if it couldn't do this.It makes the design of the scope much more difficult, though. The frame buffer now needs to have many bits per pixel rather than just one, and the logic needs to do a read-modify-write for each acquisition in order to increment the brightness of the appropriate pixel. It needs some additional memory bandwidth to dim the entire display every so often so we don't get infinite persistence.I'm fairly sure that means an external DDR memory in order to get enough capacity and bandwidth. On the plus side, having made the leap to external RAM, it would be relatively straightforward to have a frame buffer per channel plus an overlay for the UI, and to combine them at the point where they're driven out to the LCD.

author: Bored@Work
author_rank: Super Contributor
timestamp: September 19, 2012, 09:26:12 pm
content: Quote from: jucole on September 19, 2012, 08:10:02 pmNo, UI is hard. At least a good one. The work needed to make a good UI is typically vastly underestimated, although since at least 30 years there is a good general estimate for what effort it takes to make a UI. Although in the particular case I would lower that estimate a little bit relative to the other parts.Don't believe me that making a good UI is hard? Just look around you. You are probably just looking at a rubbish graphical UI. The GUI of Simple Machines. It is version 2.0.2 and it is still rubbish. And it is just some forum software, you would think it is trivial to get it right. Need more rubbish? Minimise your browser and open a random desktop application on your compute. There is a large chance you are greeted with a rubbish GUI.

author: poptones
author_rank: Frequent Contributor
timestamp: September 19, 2012, 09:31:13 pm
content: That 4.99 Arm based dev board mentioned here in another thread has a 12 bit 4MHz ADC on it with dual S/H circuits. Seems like that could be the basis of a 2MHz bw, dual trace scope dead easy. Either use USB interface or add a LCD, it has plenty of pins to drive interface stuff.

author: free_electron
author_rank: Super Contributor
timestamp: September 19, 2012, 09:49:56 pm
content: Quote from: AndyC_772 on September 19, 2012, 08:53:46 pmThat's exactly what you would do with that multiport ram approach. You an blast the ram as fast as you can. the lcd refresh can run slower.now, to get 'digital phosphor' look you can easily do the following: (you will need 1 byte per pixel though)if a sample is taken and a pixel needs to be turned on : add a value to the byte stored. ( a pixel is 'on' if the byte content > 128 and off if less than 128 so you only need to look at the MSB of the byte to determine on or off )the fpga takes the content of the byte and 'adds' a fixed number. FPGA's can do this addition at breakneck speeds you wouldn't even know it is happening. whenever a sample is low you subtract a constant from the byte.this way you get a variable persistence. you'll have to play with the constants to get the 'afterglow' you want.now if you have a grayscale display you can use the whole byte to control the intensity of the pixel....another trick would be to only 'add' or 'subtract' the constant if the delta between the curent sample and the previous sample is large enough.if the delta is not large enough you add or subtract a small constant driven by the sample clock. this creates a self-decaying afterglow.a cpu would have to do a read-compare add/subtract-write operation. probably a numbe rof clockticks.and FPGA does this in 1 clocktick.If you have a multiport ram you can make a look-ahead system.in FPGA's both data in and data out of a ram are simultaneously avaialble. so you can write: x <= x +1. this will execute in 1 clocktick.if you are riding on the edge of timing you can create a look ahead by fetching x' 1 clocktick early . you would use a dualport ram and have the second addressbus ride 1 position ahead. you latch that data in a temporary hold register and use that to send through the adder. your timing would be purely defined by the speed of the combinatorial adder. In a cyclone III the gate popagation is in the order of 430 picoseconds.... if you use the hardcoded arithmetic blocks you can easily punch the adder to 300MHz or beyond.I have a cyclone III clocked at 48MHz ( from a Cypress 63013 USB processor ) and use the internal pll to create an internal clock of 480Mhz ( fastest speedgrade) . I can do arithmetic ( pipelined ) in that fpga at a rate that isn't even possible with a 2Ghz cpu. for every byte that goes in the calculated result flows out a few clockticks later.

author: Unknown
author_rank: Unknown
timestamp: September 19, 2012, 10:37:30 pm
content: Quote from: Bored@Work on September 19, 2012, 09:26:12 pmhehe I actually work as a graphic artist / designer for a software company, so thoughtful UI is not hard to me, it's my day job; but a lot of the time like you rightly say it's completely overlooked and completely underestimated in the design process. Mike's video of the pocket scope I posted earlier shows how a potentially almost half-useful scope becomes useless with bad UI.There's some great info in this thread; lots to go on; and the "analogue" intensity effect is a great feature!

author: AndyC_772
author_rank: Super Contributor
timestamp: September 20, 2012, 06:35:56 am
content: Thanks free_electron, some good ideas there. (BTW I'm fluent in VHDL and have been designing with Altera FPGAs for years).The multi-port RAM idea is perfect for this application, but I just don't think there's enough capacity in affordable FPGAs. For example, the Cyclone IV EP4CE55 has barely enough internal RAM to do 640x480 at one byte per pixel, but still costs over US$100. The project won't stand that sort of cost, sadly. A smaller device might be able to drive a lower resolution display, but then the benefit of the detailed waveform display starts to be lost. I don't like grainy, low res screens.Separate synchronous dual-port SRAMs are expensive too. That's why I picked commodity DDR (probably DDR2 or 3) as the most likely suitable candidate in terms of cost, capacity and bandwidth - but then, of course, you lose the multi-port capability.That means you're back to having to read, modify and then write back data for each acquisition, and you lose a lot of bus cycles on the memory interface that way because the DDR protocol only really works efficiently for burst transfers. You know which column is going to require an update but not which row, so you'll never be accessing consecutive memory locations (except when reading out to display on the LCD, but that's a tiny proportion of the overall number of accesses).I guess you could store a complete sweep's worth of acquisitions in the FPGA's internal RAM, then go off and do all the read-modify-writes to the external DRAM before acquiring again. That would still be better than one sweep per LCD refresh, but would still leave the scope 'blind' for as long as it takes to update the frame buffer.What's really needed is fast, inexpensive, dual-port SRAM. Not sure it exists, though.

author: Mechatrommer
author_rank: Super Contributor
timestamp: September 20, 2012, 04:51:42 pm
content: Quote from: jucole on September 19, 2012, 10:37:30 pmgraphic artist / designer is different from GUI programmer. the former is to make a program looks beautiful like madonna with shiny jewelries. GUI programmer is to make a program functional, slap the graphic in and make some codes, you may choose multiprocessing event based environment, or simple state machine based single processing environment, both can be hard as number of state/event is increased. i will agree with BaW, making a functional GUI is as dedicated as making a functional circuit hardware. the difficulty between both will only depends on which area you spend your time most at.

author: Unknown
author_rank: Unknown
timestamp: September 20, 2012, 06:17:45 pm
content: Quote from: Mechatrommer on September 20, 2012, 04:51:42 pmWell. you're probably right! a 2x20 LCD UI with 4 buttons and a few custom LCD characters written in C is not exactly a professional GUI programmer; it's more of a wannabe! ;-)https://www.eevblog.com/forum/projects-designs-and-technical-stuff/kiln-controller-project/So I'm very interested in a scope project to do next because it's more complex than a kiln controller both in hardware and software and GUI design or whatever you want to call it. Also using a graphic display you could do some really cool stuff, for example when you zoom-out of the signal, instead of the crappy way that Chinese scope GUI did it, you'd write some custom bi-linear re-sampling code to shrink on the width, so when it displayed you'd see nice areas of dense frequencies vs areas of sparse, instead of a crap block of white or even worse. Also do you need 256 colors for the analogue effect? what would 4, 5 or 6 bits look like? I would want to know before I'd designed the hardware, so I'd write a UI mockup in whatever programming language was suitable to test.

author: Mechatrommer
author_rank: Super Contributor
timestamp: September 20, 2012, 06:39:26 pm
content: Quote from: jucole on September 20, 2012, 06:17:45 pmit depends on how big and nicely shaped your state machine (GUI) when you draw it on paper. if it looks like one straight line then its not much of trouble. but if it looks like a flower or many flowers then be prepared to lose some hair. i'm thinking GUI like rigol's et al where you have menus, interrupts (usb, triggers etc), zoom mode and back again to normal mode etc. i have a GUI project for my 3" lcd qeueing up in my brain right now. i still unable to get the states flow right on paper, its been few weeks now. when i get the flow right, then the graphics should be easy.

author: Unknown
author_rank: Unknown
timestamp: October 12, 2012, 10:11:06 am
content: I've just ordered a 320x240 2.4" tft lcd module with touch for some scope ui experiments.

author: EEVblog
author_rank: Unknown
timestamp: October 12, 2012, 01:02:54 pm
content: Quote from: poodyp on September 18, 2012, 12:13:45 pmIt's been done and published, or something close to that. IIRC with an 8x8 LED display matrix, and I have the magazine somewhere.Someone I know also a schools project way back in the 80's with the same project.Can dig these out of the archives if interested.My old DSOA design is pretty simple and does not require any micro or FPGA:http://www.alternatezone.com/electronics/dsoa.htmDave.

author: andyturk
author_rank: Frequent Contributor
timestamp: October 12, 2012, 10:30:16 pm
content: Quote from: dds on September 18, 2012, 09:35:22 amHey, don't listen to all these wet blankets!Get yourself a microcontroller with ADC, a display an just build something. You can probably create an oscilloscope "of sorts" in a week's time depending on what's lying around on your bench and how comfortable you are with the software end. And, as one noob to another, I think it's a fine project to dive into.It may not replace a real scope for actual work, but you'll certainly learn a lot.

author: Mechatrommer
author_rank: Super Contributor
timestamp: October 13, 2012, 08:22:11 am
content: designing simple low BW diy dso simple GUI is fine, will teach us and take our time alot. i've been thinking about the same. but when we aiming at something commercial like 1GSps, calculating the cost, i think i'll just buy existing on the market. try outrunning the nano crap is possible, but not the existing entry level like rigol.

author: Unknown
author_rank: Unknown
timestamp: October 14, 2012, 09:21:51 am
content: Many thanks for the DSOA post - it's a great learning resource! I really like the MkI schematic because it's about on my level atm and it looks hand-drawn? In the pc software, was timing an issue clocking the nibbles out, in that perhaps the pc tried to clock too fast for the chips?