ไม่สามารถเล่นวิดีโอนี้
ขออภัยในความไม่สะดวก
DS1000z I2C Decoding and Triggering (covers DS1054Z, DS1074Z, DS1100Z, MSO1074Z, MSO1104Z)
ฝัง
- เผยแพร่เมื่อ 18 ม.ค. 2015
- How the Rigol DS1000Z series oscilloscope I2C decode and triggering options work.
Covers the DS1054Z, DS1074Z, DS1104Z, MSO1074Z and MSO1100Z, both with and without the signal generator (-S designation).
Thank you for this tutorial. I have learned a lot from this video. As you mentioned it, the video fits perfectly for DS1074Z, as well.
Thx, learned more from your 23 min video then I have since I got the scope 4 months ago!
Thanks for the great video! I know it's a few years old now, but I just bought a new DS1054Z and really like it. It has its limitations but it's very economical and serves very well for what it is. I'm very happy with it.
I've had mine for about a year or less. I did learn that instead of cranking the trigger point back to the default (center), you can just press the selection knob (in this case the trigger 'level') down twice quickly and it resets. Works with at least the horizontal, vertical and trigger and a few more.
You're not clumsy, the menus for the bit items is one I've never gotten used to. As it displays the state of the bit, so 'feel' like you want to 'select' it, like the other menus and it goes to the next option instead. It hoses me up every time I try and use that.
I also noticed you had the same problem when I 'zoomed' out to get more view, the tables got hosed. Glad you cleared that up.
Take care :)
Jack
Good video.
I have a DS4024, which _should_ be a much higher-end unit, and yet I found the same issues with SPI decoding. It's bad enough in many situations that I have to use a USB based logic analyzer to see the real data, and just use the scope to look for signal problems. I really can't trust the decoder.
Glad to see the I2C trigger works on the 1000z. I'll need to use that soon.
Great stuff, thanks a lot!
Instead of the fiddly knob just select and press either of the upper or lower arrow buttons ;-)
That's very nice to know
Good tutorial - thank you
Hello
Im trying decoding i2c on PS2 keyboard but decode not work on a Full version Rigol 1054z.
Decoding only rs232 and spi
Good stuff!!
Very good demo!
I don't understand why they don't fix this "digital sampling rate" issue in the firmware upgrade. There does not seem to be any fundamental problem in implementing it correctly.
Is regol ds1102e z able to decode spi data? I m going to but ds1102e z.
Please help me to select right dso for spi decoding in regol.
If someone read my comment & know about coding please answer.
Thankyou
What I see is the bad decoding is a consequence of a too low sampling rate, look at your SDA channel and clearly you can see some pulses are messed up. Try to trigger using a smaller time span
Willy Gutirz thanks for your comment. The problems are threefold. Firstly, irrespective of ADC sampling rate, the decode subsamples that, there is a menu item that shows you its actual subsampling rate used for decode which is lower than the ADC sampling rate. Secondly, it doesn't always decode correctly despite there being a clear I2C start sequence. Thirdly, it only decodes what can be shown on the screen, not what's in the memory. If you have one of these scopes, try it for yourself.
"Jiggery Pokery" I'll have to start using that.
Thanks for this tutorial! Did you find why it didn’t decode that stuff at the start? Was it the signal / the trigger ?
I'm confused. Nothing new there. You can zoom into the storage buffer and decode a single byte so there is enough data to decode. It is not like you lost bandwidth/did not record the full waveform. So why the artificial bandwidth limit on the decoder when you try to scan the entire waveform. This seems like a software issue that could/should be resolved by Rigol. Do we need to sick Dave on them again? I just got my 1074 and the decoding was one of the reason I bought it. Having this work would seem to be a requirement not a convenience. Now the rant box. Sorry got carried away. Thanks for the awesome video. Jim
pugleo Yes it's a bit of a disappointment that the serial decode is limited, I guess they wanted to have a speedy UI. On an Agilent scope I have it will decode up to 32Mpts but it is very slow if you do that, it's useless in real time as a result, so you need to be judicious by switching it on after the acquisition.
The trigger level resets to zero, which is not the best. I was speaking of the horizontal and vertical, but many have the double press option... :)
Did they fix the decode bug with a firmware update? And is this scope still worth picking up for a beginner hobbyist in 2021?
Hello, great video. Maybe there is a way to put all info in USB and then analyze it in PC with software? This looks like time consuming procedures.
Hi, I have RIGOL DS1054Z and KINGST LOGIC ANALYZER LA5016, but is fast if I use LA5016 and my PC
I didn't know I2C was tristate. What's all that garbage in the signal?
would the Ultra Vision s/w be of any help to search the entire buffer for data occurrences ?
and , a matter that is not so clear to me right now ... and that's when you get the decoded
info ... is it then the user's desire to reverse engr that data and come up with the commands
in the language that led to it ?
once i had a HP z80 logic analyzer. that had a probe
clip over the 40 pin cpu and could capture the addresss 'n data lines and decode it all
into assembly language instrustions out of the 158 set of z80 commands. this let
you follow the action to better understand what the code was trying to do
lastly ... does the coder of I2C have any choice in the 400k clock rate ? if it could be slowed
down to 100k then the 1054's 1M sample rate would have a 10:1 over-sample for improved acc'y
Great walk through of the decoding functionality of the Rigol scope. I'm trying to decide which scope I want to be my first scope. I'm doing both I2C and SPI bus work so the decoding is really neat. I see you do this with the analog probes, so the question is if I really need the 16 digital channels in the MSO version (other than having to sample more than 4 channels of course). Any input on this?
Also, did you find out why it decoded wrong in the beginning of the sweep?
Thanks for a great video, and for any input on my decision!
Arnljot Seem It depends on your application. Personally, I only rarely use the digital channels, but most of my stuff is on serial buses. I did do some work with parallel LCDs a few months ago, but that needed more than 16 channels, so I used a LogicPort for that I've had for many years.
You might be better off getting a cheap logic analyser. They are better than the Rigol for this and are MUCH cheaper.. They work with the software from leading companies too
So i wonder if they fixed it in the firmware yet (5 yrs on ). If not then the decoding functionality is totally worthless and I’d never use it. It has to be accurate all the time. If I have to know what it should be to verify it did it right then what’s the point of even having. I guess I’ll stick to just the voltage trace and that’s it.
Maybe if the waveform was sharper it would work better? Did you try with smaller pull-up resistors?
Thanks for your comment. The rise time is in spec (300ns) for a 400kHz I2C clock, at 140ns when using NXP's own I2C 30%/70% as the rise time parameters. Note that the DUT doesn't actually have any problems, it's being used here for the demonstration.
Triggering off the badly decoded packet works perfectly and consistently.
I did just now try reducing the SCL & SDA pull-ups from 4.7k to 2.2k, leading to a 30%/70% rise time of 76ns, well within spec, with the probes in situ. The bad decode still happens I'm afraid (irrespective it has always decoded fine on an Agilent 54831d with the 4.7k resistors).
Again, thanks for the feedback.
Nezbrun Well...drawbacks of a software decode...
Still for the price I don't think you can get a better scope.
I'm thinking of a new scope. Is the I2C bug bad enough to pass on Rigol and get a Siglent in your opinion(s)?
yea, this is the issue, he never mentions the signal, and I see some spikes in the "undefined" region of the latch ~1.8V that's a coin flip for the decoder to get right and is hardly the fault of the decoder
Why you didn't use the digital channels?
Because most people don't have the MSO optoon.
@@nezbrun872 Thank you.
This is the only weak feature of this otherwise fantastic series of scopes.
Shouldn't be too hard to correct in software, should it?
I mean seriously, just break all those analog samples down to a digital time table and you have it in a hand full of bytes.
Curious why it is that way…
@@helmut666kohl Because there's precious few samples that are held on the screen (which is what they use for decoding). To use the much larger sample buffer RAM (12m) instead of the screen they would need dedicated decode hardware which would be too expensive for this range of scopes. It would be interesting to see how much slower a software based version of this RAM decode would be however. I'd bet that most users of this scope would live with a slower but more accurate decode that utilises this method. I'm going to assume they tried this and it was *too* slow.
@@Ziplock9000 Yeah sure, they always work off the screen buffer or whatever. But that's why I said: convert those 12M of samples into a binary file and you are done!
I don't need the bytes in real time, but a converting finished recording is simple. The same scope with some extra parts does 16-bit logic analyzing.
My main concern is that right now it will give you false readings instantly. Not good.
@@helmut666kohl "convert those 12M of samples into a binary file and you are done! I don't need the bytes in real time" The scope already does this, check the manual.
"The same scope with some extra parts does 16-bit logic analyzing." So it's not the same scope then is it if it's hardware is different.
"My main concern is that right now it will give you false readings instantly. Not good." It's a budget scope. Things like real-time hardware decoding and logic analysis are on more expensive ranges of scope.
John Michael Stock this scope does incredible things. Making an analyzer that doesnt fail at reading some bits correctly should be a give.
Wow just stumble on your chanel. I know it is an old video but can you do the same test with the sigrok s/w at sigrok.org. Just to see If you'll get the same errors?
A couple of things you do not seem to fathom: 1) Rigol uses a software-based decoding technique; and 2) I think the Rigol would decode that just fine if you gave it a chance! You zoomed out soooo far, for capture then expect to zoom in and get pristine data. Also the Agilent uses hardware decoding for serial protocols, while Rigol uses software. I think you need to go with your Agilent. Are we supposed to be impressed that you stooped to Rigol for this review? Methinks not. Know your instrument.
Thank you for your comments.
The Rigol is my field scope, so I use it reasonably frequently. Are you aware that, unlike other scopes, the Rigol sub-samples the buffer, and even then will only decode the sub sampled part of the buffer that's on the screen?
Tek for example use software decode and they don't sub-sample like the Rigol does.
Have you experience of the Rigol's decode yourself? If you have, then I suggest you do a video yourself showing how well it works.
For the money, the Rigol is superb value, but like any other scope, including top brands like Keysight, Tek, R&S and LeCroy, there will be odd bugs, and as you say, you have to know your instrument. As you know yours so well, be so kind as to post your own video on how well your Rigol 1000Z's serial decode works, and demonstrate how well you know your instrument,
You may be correct -- I thought you were zooming out too far, then using Delayed Sweep to zoom in, for the Rigol sw to decode properly. Right now, I only have the DS1052E -- getting an MSO2302A shortly. No videos planned.