EEVblog Electronics Community Forum
Products => Test Equipment => Topic started by: nealz on May 20, 2014, 01:11:11 am
-
After working on this all evening I assume I'm missing something simple. :-DD
I am decoding/triggering I2c successfully however I can only read the first 9 bytes (The data I'm sending is approximately 18 bytes).
If I reduce the horizontal I get more data but loose the decode.
How do I zoom in on the decode that I capture?
Additional the event table only shows the last packet (First 9 bytes and then a .).
Each successive packet overwrite the first (id 1) line of the Event Table.
Is this the way the event table works or am I doing something wrong?
Maybe I'm expecting to much of the Decode feature of a scope.
If approprate I'd appreciate suggestions on less then $200 I2C/SPI/RS232 decoders.
Appreciate your feedback.
FYI I'm running version 00.02.01.SP1 if it matters.
-
It decodes based on what's on screen. If you click the horizontal timebase knob you can get a zoomed in view that may work for you.
-
I am decoding/triggering I2c successfully however I can only read the first 9 bytes (The data I'm sending is approximately 18 bytes).
If I reduce the horizontal I get more data but loose the decode.
How do I zoom in on the decode that I capture?
Additional the event table only shows the last packet (First 9 bytes and then a .).
Each successive packet overwrite the first (id 1) line of the Event Table.
Is this the way the event table works or am I doing something wrong?
It would be a lot easier to help you if you posted settings/images along with your questions. I have a DS2000 (not DS1000Z) although I suspect the decoding is very similar. The number of packets you can capture is determined by the timebase and sample length settings.
Attached are 2 images made using 7Mpt sample length capturing 6 R/Ws (14 bytes - although it could be longer) - first is at 200us/div with event table displayed, second one is zoomed to 50us/div.
-
As Rigby said, the DS1074Z decodes whatever is on screen. I generally do a long capture, then press the horizontal scale knob and zoom in/scroll across to decode more.
-
Thanks Rigby, Marmad and 8086 for the reply.
Sorry for the Delay work get's in the way of Fun :) .
I attached to screen grabs of a I2C decode. The packet is 18 Bytes but I only see the first 9 Bytes.
If I change my horizontal I can see the Waveform but if I adjust the position to the right the decode stops.
I can see the rest of the waveform but not decode once the Start Bit goes off the screen (just Green Line).
-
Have you tried scrolling a little more so that you have the start of the next byte on screen and no parts of the previous byte? Does it work then?
-
I attached to screen grabs of a I2C decode. The packet is 18 Bytes but I only see the first 9 Bytes.
If I change my horizontal I can see the Waveform but if I adjust the position to the right the decode stops.
I can see the rest of the waveform but not decode once the Start Bit goes off the screen (just Green Line).
I'm still not clear on exactly what you're trying to do. Are you trying to get the decode to work on all 18 bytes while the DSO is running? Or are you capturing the data, and then stopping the DSO to examine it? Because if it's the first - it probably won't work: while running, the DSO decodes only what's after (or directly before) the trigger point and decipherable in display memory - and display memory is not detailed enough for 18 decoded bytes simultaneously. If it's the second thing you're trying to do (capture the data, stop the DSO, examine them) - then it shouldn't be a problem if you adjust your timebase and sample length correctly.
Look at the difference between my images and yours: I have STOPped the DSO after capturing 7Megs of sample data, and am zooming in - and the event table works correctly.
-
As I discovered in my review of the DS1104Z-S (http://youtu.be/SM2COQ_WxMA?t=1h36m28s), decoders are sometimes useless. No contest in compare with DS2000A series. RS232 is 50/50, SPI is doing well, but I2C is pretty useless.
Problem is: DS1000Z decodes ONLY from screen memory! If edges are washed out (too slow sweep) or there is no "start" combination on the screen (no matter what is in sample memory): decoder will fail. RSR232 will show corrupted data and I2C will simply turn off. Only SPI can show something.
Once again: DS2000A decodes from sample memory, DS1000Z decodes from display memory.
You can see it here in my video (http://youtu.be/VhuZL_PBpoU?t=46m37s) (Russian voiceover).
-
So zoom in... Or just get a BusPirate or something like that. They are very capable little things, and very inexpensive. My employer purchased a Logic-16, and that thing is pretty epic. The software is lacking in some ways, but its very capable, and *extremely* useful.
-
So zoom in...
I need to say: when DS1000Z in "zoomed" mode ("delayed sweep") it ignores everything on the upper half (where full waveform is) and decoder works only on the bottom half. And once again: if there is no "start" I2C condition on bottom half - decoder will stop. No matter what is on the upper half of the screen and in the sample memory. Totally different to what DS2000 does.
Compare here (DS1000Z) (http://youtu.be/VhuZL_PBpoU?t=51m40s) and here (DS2000A) (http://youtu.be/VhuZL_PBpoU?t=1h40s).
-
Sorry for the thread spelunking, but I just ran into an issue with I2C decode on my DS4014...
I've got I2C trigger and decode working directly after the scope triggers on some data. However, in "delayed sweep" mode, when I zoom in to show more detail, the waveforms update as expected, but the decode doesn't. I.e., it shows the decode data using the initial capture timebase, not the timebase for the waveform display. Same for scrolling back and forth horizontally. I've reset the scope and the behavior is still there. It's really annoying!
The only work-around I've found is to tweak one of the decode trigger levels after updating the timebase. This forces it to recalculate the decode info. Is there some way to get the scope to recalculate the decode automatically?
-
Is the DS1000Z really only decoding from screen memory and not from sample memory?
How come the implementation between DS1000Z and DS2000A is that different?
Both have a big sample memory.
Maybe this can be configured somewhere in a menu? Or maybe the new software would fix this?
I was really going to decide on buying a DS1000Z (or maybe even a MSO1000Z) as it seemed to handle everything for my needs, just a lower B/W, sample rate and sample memory.
Maybe the MSO1000Z is better in this respect?
How to check this? Can it be verified from the user manual, before I buy any of the scope?
-
A couple related things:
1. On my DS2072 using RS232 I can decode (ASCII, Binary, Hex, and Decimal) in real-time. If I change the time base to the point where the decode values are too small to render in the green decoder boxed and then change from Run to Stop I can expand back out and see the decoded values for a fairly long capture no problem. Maybe this is something the 2000 series does that the 1000 and 4000 series don't do, or maybe it's just something that works on the RS232 - but perhaps not on I2C.
2. Speaking of I2C (and SPI), I haven't figured out how to probe and examine and generally learn to use I2C (and SPI). Anyone have any easy entry level methods of learning to examine, decode, and generally get a handle on I2C and SPI? I have seen a few boards that might provide a testbed for learning. Here is one I came across (I can post others if anyone is interested):
http://www.totalphase.com/support/articles/200473206-I2C-SPI-Activity-Board-User-Manual (http://www.totalphase.com/support/articles/200473206-I2C-SPI-Activity-Board-User-Manual)
-
Is the DS1000Z really only decoding from screen memory and not from sample memory?
How come the implementation between DS1000Z and DS2000A is that different?
Both have a big sample memory.
Maybe this can be configured somewhere in a menu? Or maybe the new software would fix this?
I was really going to decide on buying a DS1000Z (or maybe even a MSO1000Z) as it seemed to handle everything for my needs, just a lower B/W, sample rate and sample memory.
Maybe the MSO1000Z is better in this respect?
How to check this? Can it be verified from the user manual, before I buy any of the scope?
Apparently it should be possible to switch the decoding source. On my DS1074Z, there is an option (you need to scroll down the right decode menu and it is under Settings, I believe) where you can select the source - by default it decodes from the screen and according to the manual, it should be possible to change it to decode from the entire capture memory. However, for me the option is always greyed out and I haven't found a way to enable it yet.
Jan
-
http://www.batronix.com/pdf/Rigol/UserGuide/DS1000Z_UserGuide_EN.pdf (http://www.batronix.com/pdf/Rigol/UserGuide/DS1000Z_UserGuide_EN.pdf)
Page 175, it is the "DataSrc" option. For me it is always set to "Trace" and greyed out, so I cannot change it.
-
I am about to buy a DS1074z, if someone can clarify the DataSrc thing...
-
Maybe someone who already owns a DS1074Z or MSO1074Z can post this on the Rigol support forum? This way we can get feedback if they consider this as a bug, and if there will be a fix coming soon.
Myself am going to order very soon an MSO1074Z, or an MSO2072A. Still doubting about which one is the best, but most likely it will be the MSO1074Z, as 100 MHz (after possible upgrade) would be enough for my current applications.
But I really want confirmation that feature wise both scopes are as good. It should only be better in B/W and in Sample rate, but not in feature set, if I am correct.
-
Same for me, deciding between DS1074 or DS2000A serie... need to be set on my choice by the end of the day. For doing digital stuff, with from time to time maybe some analog.
If I understand well,
DS2000A:
2 channel
more g/sample
more b/w
8 inch screen
less bug (like this data source thing)
can decode CAN (not a big deal, for simple thing, like I2C and RS232, scope are great, but with more complicated protocol, better to use a true logical analyser and use scope to check signal integrity)
more button and knob (knob for each channel)
better GUI (subjective, not sure about that statement)
harder to hack
DS1000Z:
more channel (4)
the problem with data source for decoder
7 inch screen
less button/knob
GUI not as good as DS2000A
easier to hack
Also, any info on the connectivity of the scope with a function generator from rigol? which scope can connect to which waveform generator model?
-
These oscilloscopes support triggering on the decoded data, right? In order for that to happen without a lot of dead time, the decoding has to happen during decimation which could be related to why one can only decode the display record although that does not explain its other limitations.
Maybe marketing and product segmentation triumphed over engineering again.
-
But I really want confirmation that feature wise both scopes are as good.
They're not. So you won't get the confirmation you desire.
It should only be better in B/W and in Sample rate, but not in feature set, if I am correct.
You're not correct, and I'm unsure why you think it "should" be so? There has been a huge amount of discussion here in this Forum over the last year, and the fact that there are significant feature differences between the two is well established.
That's actually one of the factors that makes picking one over the other more difficult. It it were simply that one is higher performance, at a higher price, with two channels... and the other lower performance (but still good), except with 4 channels AND cheaper, it would be much easier. But go back and read comments from folks like ElectroFan and others, who started out with a 1000, switched to a 2000, and were happy they did. See their reasons why. And I'm sure some moved in the other direction, because 4 channels were more important to them (as it would be for me).
I don't recall all the Feature differences that I've written about in numerous posts here, much less all those that others have written about. But off the top of my head, the 1000-series claims to support HD Video, but defines HD as 480P. The 2000 actually does 720 and 1080 (i.e., real HD). The 2000 claims to decode SPI, but with only 2 channels, really can't. The 1000 does. They both do segmented captures, however there are time stamps on the segments with the 2000, but none on the 1000. The 2000 can post-process segments to compare them, and identify those that deviate by X%, and quickly jump between them. The 1000 can not. They each have their own set of bugs, and annoyances. But seemingly less so than the 4000-series.
There are a number of other differences, but that should be enough to demonstrate that a simplified comparison will miss many factors.
-
Suggest you keep your 1074z as an oscilloscope and use a Saleae or something like it.
Doing any real serial data stream analysis is a pain with a small screen and a bunch of buttons, but the scope is quick and essential for checking signal quality and basic framing.
That's what I am doing with my 1074..
-
These oscilloscopes support triggering on the decoded data, right? In order for that to happen without a lot of dead time, the decoding has to happen during decimation which could be related to why one can only decode the display record although that does not explain its other limitations.
Maybe marketing and product segmentation triumphed over engineering again.
Yes, the DS1074Z can trigger on I2C or SPI data. It is a bit fiddly, but you can trigger on things like start condition, stop condition, missed ACK, address or data packet content ...
In order to trigger on something you don't need to decode the entire memory - just keep looping trying to decode the samples as they are coming in. So I don't see why there should be a big delay.
-
Suggest you keep your 1074z as an oscilloscope and use a Saleae or something like it.
Doing any real serial data stream analysis is a pain with a small screen and a bunch of buttons, but the scope is quick and essential for checking signal quality and basic framing.
That's what I am doing with my 1074..
I don't like the little USB logic analyzers too much. I have the Open Bench Logic Sniffer, it works fine, but the workflow is a PITA. You have to record the data until the memory is filled and only then you can have them decoded/analyzed. There is no real time decoding, which is often useful. Also you have to restart the capture from scratch manually if you want to continue decoding. I haven't used the Saleae one, but from the reviews I believe it is a similar type of analyzer.
On the Rigol I can set the decoding up, set the trigger to normal mode and have every packet decoded as soon as it arrives. Much faster if all I need is to check whether e.g. keyboard data are arriving over I2C correctly - with the logic analyzer I would have to arm the capture, pray that it doesn't trigger on some spurious edge or spike (as there is no sophisticated triggering on it) and then hit a key on the keyboard to generate the signal I want to capture. And then spend some time setting up the decode to actually see the data :( Granted, most of these are probably usability issues of the SUMP client software, but the lack of the real time capture/decoding and primitive triggering (only bit transitions and some basic bit patterns) is a hardware limitation. On the Rigol I could just keep hitting the keyboard keys - the decoding is much faster and the capture is re-armed automatically when I am in normal trigger.
Not to mention that the scope is all the time on my bench, ready to be used. The logic analyzer has to be wired up, the software set up, all in all it is worth taking out only if I need more than the 4 channels that I have on the Rigol, which is rarely the case. Also being able to see the shape of the signals coming in is handy - you don't have that with the logic analyzer (well, the new Saleae ones can do it, but then you don't have proper probes ...)
-
In the thread above there is an indication that there are many differences between DS1074Z and DS2072A in terms of features.
But these differences are caused by the software.
Strictly speaking, the DS1074Z should be able to do everything that the DS2072A can do, just less B/W and sample rate.
In the current SW implementation there is much differences, but for me it is hard to believe that Rigol would not be able to make all DS2072A features available in the DS1074Z.
The HW in the DS1074Z is good enough to support all of the DS2072A features!
In fact it even has 4 analog channels. If they would just make the software feature complete, this would be the best scope out there if you don't need more than 100 MHZ B/W.
-
In the thread above there is an indication that there are many differences between DS1074Z and DS2072A in terms of features.
But these differences are caused by the software.
Strictly speaking, the DS1074Z should be able to do everything that the DS2072A can do, just less B/W and sample rate.
In the current SW implementation there is much differences, but for me it is hard to believe that Rigol would not be able to make all DS2072A features available in the DS1074Z.
The HW in the DS1074Z is good enough to support all of the DS2072A features!
In fact it even has 4 analog channels. If they would just make the software feature complete, this would be the best scope out there if you don't need more than 100 MHZ B/W.
You are making some sweeping statements/assumptions here. :o
Be ready for all the replies to the contrary. :box:
-
In the thread above there is an indication that there are many differences between DS1074Z and DS2072A in terms of features.
But these differences are caused by the software.
Strictly speaking, the DS1074Z should be able to do everything that the DS2072A can do, just less B/W and sample rate.
In the current SW implementation there is much differences, but for me it is hard to believe that Rigol would not be able to make all DS2072A features available in the DS1074Z.
The HW in the DS1074Z is good enough to support all of the DS2072A features!
In fact it even has 4 analog channels. If they would just make the software feature complete, this would be the best scope out there if you don't need more than 100 MHZ B/W.
You are making some sweeping statements/assumptions here. :o
Yes, no kidding. Along with a whole lot of wishful thinking.
Be ready for all the replies to the contrary. :box:
Well, I'm not sure it's worth the trouble. Apparently, he has no concept of product differentiation, and that a manufacturer may have valid reasons NOT to make the feature sets identical. Regardless of how hard that is for him to believe. Or the fact that while they are similar, they don't have exactly the same hardware, and thus may be more limited in capabilities.
What he should be saying is "I don't understand", because he doesn't. Or that he finds it disappointing. That's certainly a valid sentiment, that many of us could get behind. Instead he's making proclamations of how he thinks things should be, because that would be his preference. He started out by claiming they were the same, then when corrected, shifts to they should be. :-//
I'd certainly like it if Rigol added CAN decode to the 1000Z-series, but they've specifically told me they won't. And lack of time-stamps on segmented captures on the 1000Z is something I've been told they can't add. Probably some internal architectural detail they're not about to share.
Saying "it's just software", and "it should be able to", and "it is hard to believe" just demonstrates a lack of understanding of how things work in the real world. And is a denial of the reality of the limitations of products that exist.
When we evaluate and discuss the variety of scopes that are out there, we explore what their capabilities actually are. That's a learning process, but it let's us weigh the pro's and con's, and select which unit is most appropriate for our specific needs. The needs aren't the same for everyone, so neither will the devices selected be. Making suggestions to manufacturers about features or capabilities we'd like to see supported is appropriate. As is criticism of limitations we feel unnecessarily reduce their value to us. However, insisting that "strictly speaking", things should be such and so, helps no one, including the person trying to decide which unit is right for them. Who, as a result, winds up never making any choice at all.
-
You have a valid point about product differentiation, and that they deliberately are not releasing the features.
Regarding limitations on the hardware side, I have a hard time to understand honestly.
The scope has A/D converter on the input. The moment the signal is sampled and available in digital memory, you can basically do everything with it what you want, if you have a decent processor architecture.
CAN is just a matter of releasing support for it.
Time stamps should be the same, as they have a reference clock.
-
Regarding limitations on the hardware side, I have a hard time to understand honestly.
The scope has A/D converter on the input. The moment the signal is sampled and available in digital memory, you can basically do everything with it what you want, if you have a decent processor architecture.
Man, look at photos and read descriptions about the insides of the 2 DSOs. They use different A/D converters (the DS1000Z is quad-interleaved), different processors, and, IIRC, the DS1000Z uses one FPGA for post-processing, while the DS2000 uses two. They're NOT the same hardware - and won't run the same software features at the same speed - which is another reason Rigol doesn't try to offer identical features.
Plus, you're discounting one of the HUGE main hardware features of the DS2000 - the spring-loaded Navigation knob. Without that, being able to record and investigate ~60k segments - as well as just moving through Delayed Sweep waveforms - would be a major pain in the ass (not to mention just setting certain variables without it).
-
Yes, the architecture is different of course.
It would be too slow to offer all software features with one FPGA probably, and that's why it comes with a reduced feature set.
The discussions here have been about the need of 4 channels. But if most of the work is digital, then the solution might be to go for MSO2072A? Then you have 2 analog channels, and 16 digital channels. The SPI decoding would be done by the logic analyzer, and no need to sacrifice any of the analog channels.
Maybe I should just go for an MSO2072A. That is, if they make the current SW stable in that version.
-
I know this is an older thread, but I could not find any more current thread on the topic. I have a MSO1104Z which I was looking to use for some quick decoding and confirmation, vs pulling out and connecting a dedicated logic analyzer. I ran into this same issue discussed above where, the DataSrc is only on trace and greyed out, so this makes decoding almost useless as I can never see more than a few bytes at a time, have to keep scrolling horizontally as bytes shift through the event log. Zooming out to get more bytes visible on the screen results in the decoder starting to just show 0's. I noticed as long as the horizontail timebase is under 100ms the decoder is on, if you try to view more than 100ms it will automatically turn off, but in practice I cannot even decode 1ms of data on the screen.
-
Yep, you have to zoom in and decode, it will only do a screen's worth. The event table is therefore pretty much useless.
If you have an idea what you're looking for the serial trigger can be useful, but I wouldn't bet my life on it consistently triggering. That's not a statement that it doesn't work, it does, I'm just not convinced it works all the time.
-
Scopes are scopes. Logic analyzers are logic analyzers. If you dont need realtime visualizing and you just want to capture and decode, get a Saleae and live happy.
-
Scopes are scopes. Logic analyzers are logic analyzers. If you dont need realtime visualizing and you just want to capture and decode, get a Saleae and live happy.
Well, that's one (extremely simplistic) opinion.
What about those who don't "just"? Those who need or want BOTH realtime visualizing, AND the ability to capture and decode longer sequences? They need a device that does things right. Which apparently is NOT the MSO1000z series, which has dumbed-down some functionality to the point of being worthless. That doesn't mean that all MSO's are so limited.
[And BTW, I have used a Saleae, and there were many ways I didn't just "live happy" with it. In fact, it was quite poor. So it's no panacea, as you have implied.]
-
well the Saleae is perfect for what I do. I don't need realtime but I do need to be able to write my own protocol decoders and I need to capture arbitrary lengths of data. So, yeah the Saleae is useful for me.
I wasn't trying to imply that it is a perfect solution for everyone, because nothing is a perfect solution for everyone, and everyone knows that.
Regarding the MSO1000Z - you get what you pay for, I guess. How many pieces of test gear can you cram into one inexpensive body before you wonder if it all really works like you imagine it will?
The decoding limitations of the M/DS1KZ are known. They were known before the MSO1KZ line came along.
-
I understood going into the purchase there were limitations to the built-in logic analyzer of this lower end oscilloscope, however I did not anticipate that the functionality would be so heavily crippled. I made an assumption that I would be able to decode the captured memory, the manual specifically described the function of decoding from trace as default, not as the only choice… there is an event table and payload screen which further suggests you will be looking at more than a few bytes. I don’t think my assumption/expectations were unreasonable.
I picked up an MSO2072A yesterday which so far does exactly what I expected from it as a logic analyzer, and the ribbon cable is much nicer than the MSO1000Z one.
-
well the Saleae is perfect for what I do. I don't need realtime but I do need to be able to write my own protocol decoders and I need to capture arbitrary lengths of data. So, yeah the Saleae is useful for me.
I wasn't trying to imply that it is a perfect solution for everyone, because nothing is a perfect solution for everyone, and everyone knows that.
Regarding the MSO1000Z - you get what you pay for, I guess. How many pieces of test gear can you cram into one inexpensive body before you wonder if it all really works like you imagine it will?
The decoding limitations of the M/DS1KZ are known. They were known before the MSO1KZ line came along.
When you are getting a design up and running or if there is a repair a scope with protocol decoding is an excellent tool. Once up, a device like a Saleae is ideal for getting your software up to snuff. There are scopes that can do both but there is always cost to consider.
I personally consider a Saleae a protocol decoder and not a logic analyzer. It is however a very good protocol decoder and useful tool for a programmer.
-
I understood going into the purchase there were limitations to the built-in logic analyzer of this lower end oscilloscope, however I did not anticipate that the functionality would be so heavily crippled. I made an assumption that I would be able to decode the captured memory, the manual specifically described the function of decoding from trace as default, not as the only choice… there is an event table and payload screen which further suggests you will be looking at more than a few bytes. I don’t think my assumption/expectations were unreasonable.
I'd agree with everything you said, 100%. (emphasis added)
I believe those are expectations that anyone evaluating the unit would share, based on tech materials that are available.
-
The shortcomings mentioned have been mentioned as being present on the DS1000Z series in the software decoding of signals captured on the analog channels, and this limitation is precisely why I purchased my first Saleae device. I mentioned it in the huge Rigol I2C decoding thread that contains all the rigol hacking info. No one made a stink about it then, and yeah, I don't know why. It is a pretty huge limitation.
-
Sounds like Saleae are having issues, prices going up.
-
Sounds like Saleae are having issues, prices going up.
Yeah. Shame because they have really good stuff. If this helps them get back in black I'm on board.
-
I posted this over in the DS1000Z wishlist thread and thought I would duplicate it here. I hope you do not mind
I had asked Rigol about the Decode working on screen only and was informed the DS1000Z series has very little FPGA space left.
I would assume if that is true they are keeping their Limited resources for bug fixes not features and I would assume they are looking across the whole product line which includes the MS01000Z as well. So while implementing the decode may work on a base DS1000Z the MSO1000Z would run out of space so that makes the feature something that can not be implemented.
From a support POV if this is true it would be a nightmare. If they implemented the better decode on the DS1000Z but did not on the MSO1000Z I know I would be upset because I paid more for scope with LA capabilities so to have the support in the DS but not MSO would upset users so Rigol would be in a bad position. Best stance as a company is to fix bugs but not add features that can not be supported across the whole line of the supported boards.
Thats mine opinion FWIW based on a simple reply from Rigol, take it for what it's worth.
I do say that the decode function is not worth buying if this is the case.