EEVblog Electronics Community Forum
Products => Test Equipment => Topic started by: dc101 on April 03, 2014, 03:17:34 am
-
Just wanted to post a real quick video showing the MDO3000 decoding I2C. I'll be heading back to the Design West / EE Live show tomorrow if anyone has any burning requests for quick tests on the MDO. http://youtu.be/koSLJQzPl1g. (http://youtu.be/koSLJQzPl1g.) The decoding seems way faster and more responsive than my old MSO2000b although Tektronix said decoding was still software based.
-
Just wanted to post a real quick video showing the MDO3000 decoding I2C. I'll be heading back to the Design West / EE Live show tomorrow if anyone has any burning requests for quick tests on the MDO. http://youtu.be/koSLJQzPl1g. (http://youtu.be/koSLJQzPl1g.) The decoding seems way faster and more responsive than my old MSO2000b although Tektronix said decoding was still software based.
Fixed the link for ya
https://www.youtube.com/watch?v=koSLJQzPl1g (https://www.youtube.com/watch?v=koSLJQzPl1g)
-
Lol thanks man, see what happens when I have to use my ipad instead of my laptop?
-
Just wanted to post a real quick video showing the MDO3000 decoding I2C. I'll be heading back to the Design West / EE Live show tomorrow if anyone has any burning requests for quick tests on the MDO. http://youtu.be/koSLJQzPl1g. (http://youtu.be/koSLJQzPl1g) The decoding seems way faster and more responsive than my old MSO2000b although Tektronix said decoding was still software based.
Thanks, but your link 404's for me. Ah, I see the problem. The period ending the sentence is attached the the URL. I removed it in my quote above.
[and Miguel fixed it before I finished. I must be slow. :) ]
Question: what good is very fast updating of the protocol strings? At a certain point, it's all just a blur, and you can't read it, or glean much info from it.
What am I missing?
(I do protocol analysis almost every day, but most of it is post-op of a capture. And not live.)
-
You're absolutely correct that you can't watch it real time (and get useful info), but you can set the trigger to any number of protocol events or payload data. So if your scope is so slow that it can only decode every 4th or 5th packet then it might take a while for it to find and trigger on the specific packet/data you are interested in if it's even able to find the packet.
-
Question: what good is very fast updating of the protocol strings? At a certain point, it's all just a blur, and you can't read it, or glean much info from it.
One advantage, I would guess, is that because the scope can do the decoding very quickly, it should be able to trigger on specific infrequent conditions (like I2C address or data packet bits) with a lower risk of missing that infrequent packet between waveform updates. I'm guessing that a scope that can't keep up live like that Tek or the Agilents might miss more potential trigger points. But I agree just watching the blur of data fly by doesn't seem helpful.
-
Thanks, guys. Those are good answers.
The blur in that video reflects that fact that it's triggering on every packet (or trying to). But by selectively triggering on, say just "I2C Writes to a specific address", that could provide valuable real-time feedback. Because the filtering would reduce the update rate substantially.
I'm guessing that a scope that can't keep up live like that Tek or the Agilents might miss more potential trigger points.
Well, the Teks use software decoding, but the Agilents have been hardware for some time. So of all the decoding scopes, they're the least likely to miss triggers.