Help with Oscilloscope purchase decision. - Page 1
Forum section: electronics / testgear

author: Tomer
author_rank: Regular Contributor
timestamp: March 30, 2017, 05:04:28 pm
content: Hi, I am new here so hello to everyone.I am a student and learning electronics, I am working on audio applications such as Compressors, EQ's, PreAmps.I need your help with an Oscilloscope purchase decision.My 2 top candidates will be the Rigol "1054Z" and the KeySignt "EDUX1002A", the price difference between them is small.The Rigol gives 4 channels (I don't see that i will need more than 2)The Rigol can be "Hacked" easily for more features and bandwidth (Again, I don't need 100Mhz)Are there any other factors that i am missing? what is your suggestion?Or maybe a completely different candidate?Thanks a lot for your helpTom.

author: james_s
author_rank: Super Contributor
timestamp: March 30, 2017, 05:07:46 pm
content: You might find the FFT function useful for audio work of that nature, it may be worth looking into whether the scopes you are looking for have that and if they do, whether it works well enough to be useful.

author: Fungus
author_rank: Super Contributor
timestamp: March 30, 2017, 05:52:54 pm
content: You might want to look at the Analog Discovery instead. It's a great little device for learning electronics and has a high resolution ADC which gives really good FFTs (much better than those two 'scopes).You can also program it to output frequency sweeps and do really nice Bode plots - very handy for audio work.It's also half the price.

author: JPortici
author_rank: Super Contributor
timestamp: March 30, 2017, 05:56:59 pm
content: based on your requirements i'd say that- you don't need high bandwidth (also less bandwidth < > less noise)- you'd rather need more resolution 10,12,16 bit- you'd probably need more than two channels. for example, compressor: input, output, control.- you may need decodesbasically for resolution, i second the analog discovery

author: Fungus
author_rank: Super Contributor
timestamp: March 30, 2017, 06:09:29 pm
content: PS: Here's Dave's video:nb. That's the old version. We now have the Analog Discovery 2.

author: nctnico
author_rank: Super Contributor
timestamp: March 30, 2017, 06:31:09 pm
content: I'd also look at the GW Instek GDS-1054B. Pricewise in the same ballpark but it has 1Mpts FFT and input filtering. Input filtering is very useful to get rid of HF noise in a signal. For audio work the analog discovery also seems nice but you'll always need a PC and (AFAIK) the input ranges are limited.

author: tautech
author_rank: Super Contributor
timestamp: March 30, 2017, 08:26:06 pm
content: Quote from: Tomer on March 30, 2017, 05:04:28 pmWelcome to the forum.There's a lot of choices in the market presently and more to come.An updated version of the Siglent SDS1000X series is just a few weeks away, the SDS1202X-E.Pricing indications I have are very favourable against any existing model in the marketplace.There's mot much info out about it yet but our Dave has a prototype and is quite impressed with it.Have a hunt for X-E within the forum for bits and pieces that Dave has said of it.Mentions:https://www.eevblog.com/forum/testgear/new-siglent-sds1000x-e-oscilloscope-based-on-xilinx-zynq-7000-soc-architecture/

author: thanasisk
author_rank: Regular Contributor
timestamp: March 30, 2017, 10:24:52 pm
content: In general you either get bandwidth (benchtop oscilloscopes) or resolution bits (pc-based) - (within a reasonable price range that is!).Even for audio work you might need high(er) BW such as 100 MHz - for example if you want to study op-amp behaviour/oscillation.Some oscilloscopes reduce the sample rate to increase the equivalent resolution bits (e.g. R&S HMO1212 - it can go to 16 bits).And resolution bits should be considered together with sensitivity and front-end noise, which might matter I guess if you mess around with small-scale signals (Microphone level is -60 dBV / 1mVrms to -40 dBV / 10 mVrms ).. This is where things get complicated because there is not much information in a single place to make an informed decision.Other points:- Adequate FFT >=128kpts would be nice (with a decent update rate of course!). See Dave's FFT comparison video. I also think the Zynq-based oscilloscopes (GW-Instek models and the new Siglent - and the Red Pitaya devboard) are also very competent in this area.

author: GlowingGhoul
author_rank: Regular Contributor
timestamp: March 31, 2017, 01:12:23 am
content: Get the Keysight. It's the smoothest functioning option of those presented, and you want your tools to be as invisible as possible, not an impediment to overcome.

author: kcbrown
author_rank: Frequent Contributor
timestamp: March 31, 2017, 06:18:07 am
content: If you can, you might want to wait for the new Siglent to come out and for people to review it. It looks like it may well be a good contender. It'll only have two channels, and that might prove limiting, or it might not be, depending on your needs. It'll be a 200MHz scope, however, and that might put its price beyond what you're willing to pay after considering the competition and your bandwidth requirements.If you don't need any sort of decoding, then the Instek GDS-1054 actually looks quite good, particularly for your uses (I'm presuming that 50MHz is more than sufficient for your needs), and especially because it has 4 channels. If you don't need 4 channels, you can get the 100MHz 2 channel model for $30 more (I'm going by the tequipment.net prices).Of course, the Keysight is going to be the most responsive in terms of its user interface (it's been described as behaving as if the controls are directly wired to the screen), but it's potentially the most limited for the price, particularly in the memory department (100K points for the 50 MHz educational version, compared with 10M points for the Instek). If your decoding needs are limited to i2c and UART (assuming you need or want any decoding at all), then the educational model might suit your needs just fine, though the decoding is an optional extra from the looks of it (and I've no idea how much it'll cost).At this point, there are a number of good options for rather good prices if 50 MHz will suit your needs. Looks like it's a good time to be in the market for an entry-level scope.

author: tautech
author_rank: Super Contributor
timestamp: March 31, 2017, 06:45:33 am
content: Quote from: kcbrown on March 31, 2017, 06:18:07 amYou may want to rethink that last sentence in the next few weeks.

author: kcbrown
author_rank: Frequent Contributor
timestamp: March 31, 2017, 07:25:34 am
content: Quote from: tautech on March 31, 2017, 06:45:33 amLooking forward to it!Sent from my iPhone using Tapatalk

author: Tomer
author_rank: Regular Contributor
timestamp: March 31, 2017, 07:34:39 am
content: Hi Everyone and thank you for so many good replies. it is hard for a beginner to decide, trying to make the best choice possible.From the replies, i understand the following:1) It will be a good idea to go with 4 channels. 2 channels might won't be enough for audio applications.2) Sometimes i might need a Bandwidth higher than 50Mhz.3) FFT will be an important factor.Notes:- Analog Discovery - looks really nice, but i would like to have full size scope. (and other hardware such as Signal generator).- Waiting for the new Siglent - I am a newbie, but from reading and watching around the web i learned that Siglent products release with half baked software and it takes time until the software mature.Question:How to Determent the FFT feature in a scope. what data in the spec should i be looking for ?Thank again for all your help!Tom

author: Fungus
author_rank: Super Contributor
timestamp: March 31, 2017, 08:56:37 am
content: Quote from: Tomer on March 31, 2017, 07:34:39 amThe single biggest factor is number of bits in the ADC. This is where the Analog Discovery really shines.Secondly, memory/window size. More is good.

author: Electro Fan
author_rank: Super Contributor
timestamp: April 13, 2017, 07:17:25 pm
content: Kind of late to this thread and have been away from EEVblog for a while so just getting caught back up on scopes. I'm a pretty happy Rigol MSO2072 hobby user but I'm not wedded to any make or model.If you were thinking about a birthday gift for a 2nd year college EE student, which of the entry scopes might be preferred among the Rigol 1054Z, the EDUX1002A, the GW Instek GDS-1054B, the impending Siglent, or perhaps some other model. It would be nice to stay at $400 or lower but if there's a reason to spend somewhat more it's worth considering. FWIW, the student already has an Analog Discovery 2.The goal is not to solve every EE problem with this scope but to provide a good first experience with a personal scope (I'm pretty sure the university has better gear in the labs - maybe Agilent 2k/3k models). My theory is that more hands-on time might lead to more/faster/better learning, and some fun. I know it's a somewhat open-ended and subjective question but any thoughts/recommendations are welcome.Thanks

author: Electro Fan
author_rank: Super Contributor
timestamp: April 13, 2017, 07:36:29 pm
content: Just saw this "Logic Analyzer Comparison" regarding scopes vs. Digilent AD, LAs, etc. Might be interesting for beginners, new users, or others.- Checkout the other videos by tomtektest, lots of interesting videos....

author: james_s
author_rank: Super Contributor
timestamp: April 18, 2017, 05:14:23 pm
content: Quote from: Electro Fan on April 13, 2017, 07:17:25 pmThe Rigol seems to be really well liked around here, and it's compact for a standalone instrument, possibly an important consideration to a college student. You probably won't go too wrong with any of the ~$400 DSOs as long as you don't get some no-name brand that nobody has heard of. None of them are stellar instruments but none of them seem to be turds either. It's really pretty amazing what you can get brand new for 400 bucks these days.

author: Pitrsek
author_rank: Regular Contributor
timestamp: April 18, 2017, 07:36:28 pm
content: Hi,for your audio stuff, no scope can touch a decent sound card. So for audio FFT, THD plots, eq transfer functions and other stuff, buy a decent sound card + make yourself nice front end(levels control,protection,etc.). Two completely different tools. You are buying scope to see the "fast" stuff. If you can wait, I'd wait for X-E Siglent. Once it's out you can decide weather its good enough or you'll by EDUX. Hopefully there will be some more progress on EDUX hacking as well. For me Rigol is not an option due to user interface - it's lagy. I had 2072 for a test, it drove me nuts. 1062 was absolutely ok in this regard, dunno why they messed new ones up....I'm shopping for a new scope for my home workshop - waiting for X-E. Then I'll decide.

author: Keysight DanielBogdanoff
author_rank: Unknown
timestamp: April 18, 2017, 09:08:31 pm
content: We've had really good feedback on the 1000 X-Series FFT capabilities, I think it's one of the places it shines compared to other cheap scopes I've used.

author: snoopy
author_rank: Frequent Contributor
timestamp: April 19, 2017, 01:21:57 am
content: Is the Keysight like the Rigol and only does protocol analysis on the display contents rather than what's in the capture memory ? I find this an annoying limitation of the Rigol and limits it somewhat !!

author: fonograph
author_rank: Frequent Contributor
timestamp: April 19, 2017, 03:43:51 am
content: Siglent 1000 x-e have lowest noise front end of the three,1 million bin fft,big memory a no hacking required,it comes at 200mhz with decode and segmented memory straight out of box,for 425 eur its best.The rigol have crap front end and keysight have worst of the worst no name chinese capacitors in psu,but keysight software is superior to rigol/siglent,lot less bugs.

author: chrisalbertson
author_rank: Newbie
timestamp: April 19, 2017, 07:08:18 am
content: You might end up with multiple scopes. Buy the entry level DSO. The Rigol 1054z that you were looking at is not bad but also for audio you could use more bits and lower sampling rate. Do you already have a studio grade USB audio interface? My USB interface does 96K samples per second at 24 bits per sample on two channels it has about a 100db dynamic range. These are pretty standard specs for an audio interface from companies like Focusrite or MOTU. I can use this to drive a software scope on my iMac. I can run a useful FFT and display multiple scope screens on a 27" LCD screen. But I do need to keep the Rigol scope as my audio interface is limited to audio frequencyI the software in the link below. Look at the screen shots. No readably priced DSO oscilloscope can draw images like this:http://www.faberacoustical.com/apps/mac/electroacoustics_toolbox/Having both is good. But I also own a 1980's vintage Tektronix analog scope. You can find these now for under $100. Actually with an analog scope and the PC software scope you'd be set. Unless you need to look at digital stuff

author: Keysight DanielBogdanoff
author_rank: Unknown
timestamp: April 19, 2017, 05:14:12 pm
content: Quote from: snoopy on April 19, 2017, 01:21:57 amYes, the InfiniiVision Oscilloscopes do decoding on the display data. A scope that does decode on the entire trace will generally take a hit to update rate and possibly even UI responsiveness.

author: rsjsouza
author_rank: Super Contributor
timestamp: April 19, 2017, 05:44:35 pm
content: Quote from: Keysight_DanielBogdanoff on April 19, 2017, 05:14:12 pmThat is something I never quite understood from the critics detracting the brands that decode only what is displayed, as my understanding is similar to Daniel's, especially for the multi-MB storage scopes. Also, how useful it is to show decoded data while displaying "real-time" waveforms? I usually gather a specific stream of data and perform post-analysis by navigating on the scope memory. If a frame is outside of the displayed area, I simply use the horizontal delay to frame it more appropriately and get the decoded data - well, one improvement would be if the decoder actually decoded, say, twice or four times the size of the display size, so you wouldn't have invalid data in the edges of the displayed area.BTW, I am genuinely curious (I may not be thinking about other usage scenarios).(edited for clarification)

author: nctnico
author_rank: Super Contributor
timestamp: April 19, 2017, 06:20:49 pm
content: Quote from: Keysight_DanielBogdanoff on April 19, 2017, 05:14:12 pmI think you better rephrase that because a scope which decodes only what is on screen is rather useless because you can't zoom in on the bits very easely. The decode will dissapear once the start of the message is outside the display area. From my own experience with an Agilent DSO7000 the decoding fills a seperate memory during an acquisition cycle. This means you have to have decoding enabled & setup properly before doing an acquisition and you can't change the decode settings for an existing acquisition. DSOs which do decoding on the actual waveform data are more flexible in this regard.

author: Fungus
author_rank: Super Contributor
timestamp: April 19, 2017, 07:22:30 pm
content: Quote from: rsjsouza on April 19, 2017, 05:44:35 pmI'm with you. DSO serial decoding is useful for checking the baud rates, signal integrity, etc. If you're using it to debug long exchanges of data then you're doing it wrong.(use printf() on one of the devices for that, or get a $10 logic analyzer)

author: nctnico
author_rank: Super Contributor
timestamp: April 19, 2017, 07:27:09 pm
content: Quote from: Fungus on April 19, 2017, 07:22:30 pmBuzzzz... wrong. I guess you never needed to look for a problem where a message gets corrupted every now and then. You can only find those with deep memory and the cause usually is only visible in the analog domain. So that $10 logic analyser is only going to tell you the bits ain't right (which was already obvious) but not what the cause is.

author: rsjsouza
author_rank: Super Contributor
timestamp: April 19, 2017, 09:33:41 pm
content: Quote from: nctnico on April 19, 2017, 07:27:09 pmDespite I don't do much decode (thus my limited usage scenarios), I agree with you that the world is analog and a LA will only tell you the partial truth.However, in the scenario you highlighted wouldn't it be more efficient to store the long record and let the oscilloscope search for a specific decoded pattern (if it has such capability)? Or perhaps have a feature where the decoder can match a pattern and trigger the oscilloscope? In both cases I suspect this starts to move towards more expensive solutions (or even a LA).In case negative, and you need to look yourself for the pattern on the oscilloscope display, I can see what you describe below as being a limitation:Quote from: nctnico on April 19, 2017, 06:20:49 pmDespite this, I wouldn't necessarily say "useless", but perhaps more difficult as I mentioned before:Quote from: rsjsouza on April 19, 2017, 05:44:35 pmI think there has to be some sort of tradeoff between how much memory is decoded and the oscilloscope processing power. Granted, some more advanced models have Intel processors that may execute this at a split second, but an embedded processor on a lower cost oscilloscope will most probably have to compromise (UI, decoder, math, FFT, etc.), don't you think?Quote from: nctnico on April 19, 2017, 06:20:49 pmI would have guessed this would help enhance the breadth of the decoding range, but perhaps not. Thus my previous hypothesis of:Quote from: rsjsouza on April 19, 2017, 05:44:35 pm

author: nctnico
author_rank: Super Contributor
timestamp: April 19, 2017, 09:50:00 pm
content: Regarding triggering on a pattern: in most cases you don't know what the problem is so you can't really trigger on something you don't know.Decoding the full memory can give you a list with all decoded messages in an acquisition. This usually can be saved to a CSV file which can be processed on a computer to (for example) find specific or malformed messages quickly using search features of Excel (or a similar program).

author: james_s
author_rank: Super Contributor
timestamp: April 19, 2017, 10:19:14 pm
content: This is where having two instruments or a mixed signal instrument can be nice. Use the scope to check for signal integrity, use the logic analyzer to capture and decode the data. In most cases you don't really need to know what the data is in order to see that it's garbled, distorted by ringing, noise or of the wrong amplitude.

author: mikeselectricstuff
author_rank: Super Contributor
timestamp: April 19, 2017, 11:14:45 pm
content: Quote from: nctnico on April 19, 2017, 06:20:49 pmI think you are mistaken in your understanding - the display is re-rendered from the acquisition data if you zoom, so you can take a long acquisition and zoom in and decode any part of it, with resolution limited only by the sample rate.

author: kcbrown
author_rank: Frequent Contributor
timestamp: April 20, 2017, 01:12:51 am
content: Quote from: nctnico on April 19, 2017, 06:20:49 pmIt's immensely important to distinguish between acquisition-time decoding and display-time decoding. You can have display-time decoding of the entire acquisition when the scope is stopped while having acquisition-time decoding of only the displayed portion (or some slightly larger amount).It's also very important to distinguish decoding-based triggering from the decoding that is shown on the display. The triggering might well do just barely enough to meet the triggering conditions, while display would require full decoding (though I have a hard time imagining how the two would differ in practice).Usually, when you're looking at decoded data in such a way that you're interested in more than just what's on the screen at the time, you're doing so with the scope stopped. There's no good reason for not decoding the entire acquisition under those conditions, and there's nothing that says that you have to compromise the waveform update rate for it. I can understand why you might want to limit decoding to the displayed portion of the waveform during capture, particularly if your trigger conditions don't involve that decoding, but that's no longer valid once the scope is stopped.

author: snoopy
author_rank: Frequent Contributor
timestamp: April 20, 2017, 02:45:52 am
content: Quote from: Keysight_DanielBogdanoff on April 19, 2017, 05:14:12 pmHi DanielI can only speak for the Rigol scope but recently I had to debug a bit banged SPI flash ROM programming system. The problem with the Rigol is even though you can capture a lot of the SPI data and zoom in on it, as soon as the start frame (ie nCS goes low) moves off the screen as you pan through the data the decoding switches off which kind of defeats the purpose. Because of this I have ordered a cheap USB logic analyzer which will hopefully overcome this issue. BTW I managed to get the thing going but the scope was not as useful as I thought it would beI was wondering if the Keysight scope is an improvement on this as the high acquisition rate would not of helped in this situation.BTW People using the Rigol for protocol analysis I found the delayed triggering and zoom was much more useful than changing the timebase and panning the data contents using the horizontal position control because it allows you to trigger at the left side of the display and zoom in around the trigger point much more easilycheers

author: Fungus
author_rank: Super Contributor
timestamp: April 20, 2017, 08:45:15 am
content: Quote from: nctnico on April 19, 2017, 07:27:09 pmHow exactly are you going to trigger on that to be able to look at the problem?(me? I'd do it by sending a short message over and over and using pass/fail - a longer serial decode wouldn't make any difference to that)

author: nctnico
author_rank: Super Contributor
timestamp: April 20, 2017, 08:58:36 am
content: Quote from: Fungus on April 20, 2017, 08:45:15 amNot. Just capture as much data as possible (segmented recording) and post process on a PC to find the garbled message. It may help though to have some information so only certain messages are captured to reduce the amount of data.QuoteUnfortunately that doesn't always work. Sometimes it is a specific message which can cause a device to misbehave every now and then. At some point I had to deal with a problem where a message went wrong once every 30 minutes to an hour.

author: Fungus
author_rank: Super Contributor
timestamp: April 20, 2017, 09:11:39 am
content: Quote from: kcbrown on April 20, 2017, 01:12:51 amI'm half with you on this one: This is the way oscilloscopes would behave in a Utopia.OTOH oscilloscopes aren't really designed internally for this sort of programming pattern and I can see why they don't do it.(are there any oscilloscopes that do?)If the problem is consistent/repeatable then I bet you can solve it with a DSO that only decodes what's on screen (even if it it isn't the ideal tool for the job). If it isn't consistent/repeatable then I don't see how more decoding would help.

author: Fungus
author_rank: Super Contributor
timestamp: April 20, 2017, 09:20:00 am
content: Quote from: nctnico on April 20, 2017, 08:58:36 amWas the problem in the analog domain?

author: nctnico
author_rank: Super Contributor
timestamp: April 20, 2017, 10:22:40 am
content: Quote from: Fungus on April 20, 2017, 09:20:00 amYes. A logic analyser would not have caught this problem:What happens here is that an I2C device is stretching the clock to make the I2C master wait but the I2C master doesn't care.

author: Fungus
author_rank: Super Contributor
timestamp: April 20, 2017, 10:40:54 am
content: Quote from: nctnico on April 20, 2017, 10:22:40 amFun times.Still, a DSO with "whole buffer decode" wouldn't have helped much either.

author: nctnico
author_rank: Super Contributor
timestamp: April 20, 2017, 10:48:56 am
content: Quote from: Fungus on April 20, 2017, 10:40:54 amWrong conclusion. The Agilent scope I used has all the segments decoded in the list display which means it has decoded the entire memory (8Mpts in this case). This was necessary to find the malformed message.

author: snoopy
author_rank: Frequent Contributor
timestamp: April 20, 2017, 11:32:26 am
content: Quote from: nctnico on April 20, 2017, 10:22:40 amJust set to trigger on a runt pulse ?

author: GeorgeOfTheJungle
author_rank: Super Contributor
timestamp: April 20, 2017, 11:45:00 am
content: Quote from: nctnico on April 20, 2017, 10:22:40 amWhat's causing that funny step?? BTW, nice scope that Agilent!

author: Fungus
author_rank: Super Contributor
timestamp: April 20, 2017, 11:53:36 am
content: Quote from: nctnico on April 20, 2017, 10:48:56 amIf it's only wrong "once every 30 minutes to an hour" then you need to trigger on it with a DSO. How does that work?

author: Fungus
author_rank: Super Contributor
timestamp: April 20, 2017, 12:01:45 pm
content: Quote from: GeorgeOfTheJungle on April 20, 2017, 11:45:00 amAn I2C device stretching the clock and the master ignoring it.I think this particular bus is breaking the I2C specification: If any slave can do clock stretching (ie. hold the clock line low to slow down the master) then a master isn't allowed to actively drive the bus high (the only way a signal can go half way up is if the master is putting out a high voltage while a slave is trying to pull it down).Quote from: snoopy on April 20, 2017, 11:32:26 amWould probably have worked - look for a pulse that doesn't rise all the way up.

author: rsjsouza
author_rank: Super Contributor
timestamp: April 20, 2017, 12:05:40 pm
content: Quote from: nctnico on April 19, 2017, 09:50:00 pmAh, so you are saying you don't scan for errors in the oscilloscope screen, but instead do post-processing on a PC. That is what I would think it is easier. In theory the Rigol could do the same if you perform a "zoom out", which will allow the decoder to work, and then save all this data. I will try this at a later time.Quote from: james_s on April 19, 2017, 10:19:14 pmThat is always my discomfort of having protocol decoding on a pure waveform oscilloscope - is this simply trying to shoehorn a non-target functionality into an instrument designed for another purpose? Obviously that the more features the merrier, but if they negatively impact the core functionality of the equipment than it should be left to more specialized brethren in the product line. All in all, I think it is already a feat on a very low cost to account for such advanced functionality, let it be on screen or on the buffer.Quote from: kcbrown on April 20, 2017, 01:12:51 amOk, so I agree with you in theory but, as I mentioned before, if the decoding process takes too long to scan through the entire buffer due to processing limitations, then I suspect the UI may be perceived as "slow" (you never know, it is hard to please everyone). Obviously that you can get a more powerful oscilloscope with an Intel processor in it, but that is certainly not entry level anymore.Quote from: snoopy on April 20, 2017, 02:45:52 amOh, so I see you already tried this with the Rigol. I will see what happens with the method you described on the DS4000. Thanks for sharing the procedure!Quote from: nctnico on April 20, 2017, 08:58:36 amI agree with nctnico here - sometimes the sequence of bits on the wire is what triggers and error (transmission losses, ringing, etc.), not the line itself.(couldn't yet read the rest of the post. Thanks for the discussion and OP, please apologize for hijacking the thread.)

author: snoopy
author_rank: Frequent Contributor
timestamp: April 20, 2017, 12:32:53 pm
content: Quote from: rsjsouza on April 20, 2017, 12:05:40 pmIt's not until you use the scope in situ that you really find out its limitations. Perhaps there is a way around it but for decoding long lengths of data packets I kind of think not from the experience I've had with the Rigol DS1054Z to date. I'd like to try out the keysight under the same test conditions to see if it has the same limitations otherwise the logic analyser that I have ordered may do the trick and get me out of trouble in future scenarioshttp://www.qdkingst.com/en/products/LA5016cheers

author: Fungus
author_rank: Super Contributor
timestamp: April 20, 2017, 12:48:35 pm
content: Quote from: snoopy on April 20, 2017, 12:32:53 pmLeaving aside for a moment the philosophy of decoding "long lengths of data packets" on a DSO, it's not difficult to line up the start of a byte/packet with the left edge of the screen. If you can manage that then decoding works perfectly on that screen of data.OTOH, if you really do this sort of stuff ll day long then a logic analyzer is the way to go. You get gigabytes of capture memory, easy text searching (mouse and keyboard FTW!), you can put data packets in a 'list' view, there's all sorts of advantages.The Saleae devices also have analog inputs which are displayed on screen perfectly aligned with the digital channels. It doesn't make them DSOs but I'm sure a lot of the people posting here could think of a use for them.In short: Use the right tool for the job.

author: nctnico
author_rank: Super Contributor
timestamp: April 20, 2017, 01:17:25 pm
content: Quote from: snoopy on April 20, 2017, 11:32:26 amIn hindsight that could have been a solution but when starting doing the troubleshooting I had absolutely no idea what to look for. The only information I had was that an I2C device was giving the wrong information when a certain register was read. The problem might as well have been that the wrong register was read. So to get to the cause of the problem I wanted to see the I2C signals surrounding the operation which lead to reading the wrong value.

author: kcbrown
author_rank: Frequent Contributor
timestamp: April 20, 2017, 04:58:53 pm
content: Quote from: Fungus on April 20, 2017, 09:11:39 amIt depends entirely on whether or not the acquisition memory is available at scope stop. Frankly, it almost has to be, because you can zoom and pan on that same data (I can envision implementations that would implement zooming and panning in hardware, but I very much doubt that such scopes are in the same class as the ones that tend to have the kind of problems we're talking about here).So with that in mind, the designers have to choose where on the span between two points to put their implementation: decode of the entirety of memory (so that decoding need only be done once), or decoding of only what's on the screen (which means that decoding has to be re-done every time the view is changed).Keeping in mind that the "window" here means the section of the waveform that begins at the left screen edge and ends at the right screen edge, a proper hybrid approach to that, which would get you guaranteed correctness with minimum memory usage, would be to scan backwards from the start of the window and find the packet start indicator (protocol dependent, obviously), then note that location, then decode from there to the end of the window. If the window start changes so that it's before the previously recorded packet start indicator, then you go through the above process again. If the end of the window moves forward, then you need only decode from where the end of the window was previously to the new window end, since you'd already decoded the data in the other direction. If you find a new packet start indicator, then you note that as well. When that new packet start indicator falls off the left edge of the window, you can discard everything before it.If you don't find a packet start indicator before the beginning of the window, then you can revert to screen-only decoding.QuoteNo idea, but since we're talking about software decoding, there isn't anything in principal or in practice (that I'm aware of) that would prevent it.QuoteThat depends entirely on how much there is between the packet start indicator and the problem area. The problem with screen-only decoding is that the packet start indicator has to remain on the screen no matter how much data there is between it and the problematic area. That could well be so much data that you simply can't display it.

author: Fungus
author_rank: Super Contributor
timestamp: April 20, 2017, 05:20:48 pm
content: Quote from: kcbrown on April 20, 2017, 04:58:53 pmNope. Ithasto be done in hardware because of the enormous amount of data.The acquisition memory will be on one bus. Data is fed to it via DMA direct from the ADC.Also connected to that RAM ss some sort of FPGA/ASIC which takes data from there and copies it to another buffer, scaled to fit the number of pixels visible on screen (depending on your timebase). It will also do the sin(x)/x interpolation, etc. There's no way this scaling/interpolation could be done in software on a cheap CPU, data can be coming in a 1GS/s even on low-end oscilloscopes.This secondary buffer is all the main CPU has direct access to, not the original sample data. This is the reason most calculations are done "on screen".It's not impossible to process the whole of sample memory but it would either have to be done in batches on the main CPU or directly inside the FPGA/ASIC.Quote from: kcbrown on April 20, 2017, 04:58:53 pmApart from (eg.) trying to access the 24MB of sample memory in 1200 byte chunks (on a DS1054Z).In principal it could be done - they did something like it for the DS1054Z's improved FFT.In practice it doesn't seem like anybody is. Not for serial decoding.I'm thinking it would be too slow.Math: If the system is designed to update four traces on screen at 60Hz then we're talking about 240 buffer accesses per second. To decode 24Mb of RAM needs 2000 accesses, that's 7 seconds for the decode. People here would be having a party laughing at it.Yes, the decodecouldbe done in the FPGA/ASIC but that assumes there's enough gates left over and they bothered to do it.

author: nctnico
author_rank: Super Contributor
timestamp: April 20, 2017, 05:47:17 pm
content: Quote from: Fungus on April 20, 2017, 05:20:48 pmUtter nonsense!

author: Fungus
author_rank: Super Contributor
timestamp: April 20, 2017, 05:59:21 pm
content: Quote from: nctnico on April 20, 2017, 05:47:17 pmIt's true! I read it on the Internet.eg.http://debugmo.de/2013/03/whats-inside-tektronix-dpo5034/The "display memory" in that block diagram is what the CPU has access to, not the "memory".

author: nctnico
author_rank: Super Contributor
timestamp: April 20, 2017, 06:27:00 pm
content: And you believe that is the only way to make a digital oscilloscope?

author: Fungus
author_rank: Super Contributor
timestamp: April 20, 2017, 06:39:44 pm
content: Quote from: nctnico on April 20, 2017, 06:27:00 pmWhat do you mean "only"? A few seconds ago it was "Utter nonsense!"Of course it's not the only way, but it's a very sensible way, especially on a budget device where you have to keep chip costs down.I guess you can unify the two memories into one but that'll drive up the cost of the RAM chips and memory controllers.

author: james_s
author_rank: Super Contributor
timestamp: April 20, 2017, 06:44:48 pm
content: There are multiple different architectures that can and have been used in digital scopes, they all have advantages and disadvantages, some are geared toward a specific use case while others are more general purpose. Which is "better" is a subjective matter.

author: Fungus
author_rank: Super Contributor
timestamp: April 20, 2017, 06:49:27 pm
content: Quote from: james_s on April 20, 2017, 06:44:48 pmI'm sure.The only point I'm trying to make is that the decoding CPU doesn't necessarily have access to the sample data, that doing a full-memory serial decode on a device that isn't designed for it could be a programming nightmare.

author: james_s
author_rank: Super Contributor
timestamp: April 20, 2017, 06:52:33 pm
content: I would say that it's a feature that a sensible modern scope ought to be designed for though. If the capture memory is separate from the CPU RAM it should be possible to transfer the entire capture RAM into CPU RAM for additional processing. IMO if it's going to bother to do protocol decoding, it ought to do so on more than what is displayed on the screen at once.

author: Electro Fan
author_rank: Super Contributor
timestamp: April 20, 2017, 07:22:21 pm
content: Quote from: nctnico on April 20, 2017, 10:22:40 amSorry if I missed it, but what model Agilent scope made the decoder view in the image you posted? Thx

author: Fungus
author_rank: Super Contributor
timestamp: April 20, 2017, 07:56:19 pm
content: Quote from: james_s on April 20, 2017, 06:52:33 pmOf course!All we need is to persuade them todoit.

author: nctnico
author_rank: Super Contributor
timestamp: April 20, 2017, 08:20:14 pm
content: Quote from: Electro Fan on April 20, 2017, 07:22:21 pmA DSO7104A (but it has moved on to a new owner).

author: GeorgeOfTheJungle
author_rank: Super Contributor
timestamp: April 20, 2017, 08:40:46 pm
content: Quote from: nctnico on April 20, 2017, 08:20:14 pmAnd what have you put in its place? If you don't mind me asking?

author: kcbrown
author_rank: Frequent Contributor
timestamp: April 20, 2017, 08:48:57 pm
content: Quote from: Fungus on April 20, 2017, 05:20:48 pmI certainly don't disagree with this. But see below.QuoteThat isn't something thatpreventsit. And remember, the situation here is when the scope isstopped. And especially if the implementation is done in the way I described, you'd be accessing chunks backwards starting with the one immediately prior to that of the display, and accessing only those chunks sufficient to arrive at the packet start location, then moving forwards from there, and saving the decoded values (along with their locations) so that you can easily display them should the user decide to pan/zoom.QuoteThat's exactly my point. There isn't anything thatpreventsthem from implementing correct decoding. And I'd argue that it's not necessarily uneconomical to do so either since it's just software -- it takes some additional time, but it only has to be done once.QuoteWhy in the world would it be too slow if you only do it when the scope is stopped??It's a different matter altogether if the scope is running. In that case, you can just do on-screen decoding and be done with it. It might not be correct, but at that point there are real tradeoffs that you can't get away from.QuoteYeah, and it would also require additional memory that the FPGA/ASIC would have to write data and position information to. I was thinking a strictly software-based approach. Having hardware support opens up a lot of possibilities.

author: Fungus
author_rank: Super Contributor
timestamp: April 20, 2017, 08:58:17 pm
content: Quote from: kcbrown on April 20, 2017, 08:48:57 pm...assuming there's enough spare RAM to store all the decoded data along with its position on the timeline, etc.How much serial data+position could 24Mb of samples actually decode to? What's the maximum?Data is one byte, position would need 3 bytes. I'm thinking it could be a megabyte or more of data in total if you set the timebase to worst case.

author: kcbrown
author_rank: Frequent Contributor
timestamp: April 20, 2017, 10:20:55 pm
content: Quote from: Fungus on April 20, 2017, 08:58:17 pmSorry, I meant that the programming only has to be done once. It was a comment about the engineering resources needed to pull it off (and if you architect it properly, then you can make it easily adaptable to future architectures).QuoteWell, the scope is stopped. If the timebase is such that you wouldn't be able to display the decoded data, then you might not bother to do the decoding at all (until, of course, the user changes the timebase such that decoded data would be possible to show). That tends to pretty severely limit the circumstances in which a decoding pass would be necessary.If, on the other hand, you have a scrollable list that you're overlaying on the display, then you might have to deal with that problem.For modern hardware, a megabyte of memory is nothing. The memory for this doesn't have to be SRAM or anything special like that -- it's just general-purpose RAM for the CPU. Modern ARM-based SBCs havegigabytesof RAM these days. Even the DS1054Z might have enough in total for that (looks like the processor has a 32M RAM chip hanging off of it, the SK Hynix H5PS5162GFR:https://www.skhynix.com/product/filedata/fileDownload.do?seq=1909).

author: snoopy
author_rank: Frequent Contributor
timestamp: April 21, 2017, 12:57:15 am
content: Quote from: Fungus on April 20, 2017, 06:49:27 pmI believe it is changed in the Tek mdo3000 scopes where decodes and search occur across the whole sample memory and not just what's on the screen, that is why the Tek will take sometime to complete decodes after a new triggercheers

author: MrW0lf
author_rank: Frequent Contributor
timestamp: April 21, 2017, 11:10:00 am
content: Quote from: snoopy on April 21, 2017, 12:57:15 amSurely you can gate to screen, zoomed area or cursors? In case if want check surroundings only if spotting something interesting around (trigger point) can stop and change gate to full record.Dunno why opinion that full-mem decoding scopes have only option to decode all (which is inevitably bit slow)Another option - not decode at all on-the-fly, and then enable full record (or gated) decoding on stop.Get luxurious event table over hundreds of MB with analog voltage stats for each packet etc...IMHO this whole battle DSO vs DMO (data mining oscilloscope) is weird. Like comparing DSO and multimeter. Of course simple instrument is better/faster for simple task. But cannot do complex task at all...

author: Fungus
author_rank: Super Contributor
timestamp: April 21, 2017, 01:13:54 pm
content: Quote from: MrW0lf on April 21, 2017, 11:10:00 amI get the feeling that if the 'scope manufacturers give people a full memory decode they'll just start saying things like, "Wahhh! It'ssucha pain to have to scroll through the data by twisting a knob in zoom mode, why can't we have a vertical list view? CSV dump? Automatic search for bad signals?"It'll never end.

author: nctnico
author_rank: Super Contributor
timestamp: April 21, 2017, 01:19:45 pm
content: Quote from: Fungus on April 21, 2017, 01:13:54 pmMy GW Instek GDS-2204E can do all that so I'm not complaining and I'm sure it is not the only oscilloscope with such features.

author: MrW0lf
author_rank: Frequent Contributor
timestamp: April 21, 2017, 01:22:40 pm
content: Quote from: Fungus on April 21, 2017, 01:13:54 pmIf?! 128MB of mixed analog/digital with database-like interface. Including search/sort by packetvoltages:Seems I have to continue my Pico 2000 review sometime. Strangely limited perception of modern budget scope powers is...

author: nctnico
author_rank: Super Contributor
timestamp: April 21, 2017, 01:41:14 pm
content: IMHO Pico should change their UI so it can work with a touch-screen and create an Android version so you can connect your scope to a tablet. I have used a Picoscope a couple of times many years ago and it didn't inspire me to buy one. Needing to mess around with the mouse to adjust something made using it way too tedious.

author: Fungus
author_rank: Super Contributor
timestamp: April 21, 2017, 01:47:12 pm
content: Quote from: nctnico on April 21, 2017, 01:41:14 pmYep, I get that their software is powerful but I just don't think having to use it via a PC for thebasicstuff is good.Maybe they could make another USB box with knobs and buttons on it.

author: MrW0lf
author_rank: Frequent Contributor
timestamp: April 21, 2017, 02:02:27 pm
content: Quote from: nctnico on April 21, 2017, 01:41:14 pmI agree that going touch is inevitable. They are trying to go in this direction with new "big buttons" in taskbar etc. However for me as oldschool PC user this whole touch business does not compute. Microscopic movement of wrist with "tuned" laser mouse vs waving hands around... what next - throwing stones at cyborgs trying to "communicate" with them?Due to my line of work I'm chained to PC 8+ hours a day... cannot image how tiresome would be poke (and clean) screen all the time. Plus touch is extremely inaccurate. In "old days" playing Quake you got so good that could basically hit individual pixels with rail gun, on the run... So dunno, think its very personal / cultural thing and depends on persons background and task at hand. I'm not saying that DMO with classical PC interface is for everyone and every situation. Would not climb comms pole with it... Maybe only fix tiny USB scope at the top of pole, or maybe robot-DUT and enjoy the show from safe place over LAN/WiFi extender.

author: rsjsouza
author_rank: Super Contributor
timestamp: April 21, 2017, 08:05:17 pm
content: Very interesting discussion about the protocol decoding.Out of the whole discussion I gather that, in practice, to have access to a well-round decoding feature the low entry bench oscilloscopes such as the DS1054Z or others are not the way to go. Only the more expensive models such as the GDS2204E and the DSO7104 have a complete decoding in memory. Not a surprise given the low-entry have more processing constraints.Pico seems to have better options in this regard - no wonder, as the embedded hardware does not have to spare its time to process the User Interface. That and the fact they have "the world" to do whatever they can with the incoming data.Just like having a capacitance meter in a regular DMM - limited when compared to a real LCR but good for the occasional quick check - the limited decoding has its place in low entry bench scopes. We only have to be aware of that.Similarly to other facts of life, you must make a choice between cost and how well a feature is implemented... No surprises here.

author: kcbrown
author_rank: Frequent Contributor
timestamp: April 21, 2017, 08:16:56 pm
content: Quote from: nctnico on April 21, 2017, 01:19:45 pmIt can automatically search for bad signals? That's quite a nice capability if that's the case.What's the WFM/s rate difference between when you have full memory decoding turned on and when you have it turned off?