Products > Test Equipment
REVIEW - Rigol DS2072 - First Impressions of the DS2000 series from Rigol
Mark_O:
--- Quote from: luchog on February 19, 2014, 06:14:51 pm ---Hello Mark_O.
--- End quote ---
Hi, Luis. Thanks for continuing to pursue this. I hope you don't interpret my comments as argumentative. I'm just trying to be helpful, and come to some understanding, along with you. I don't have a DS2000 here, or I'd hook it into one of my SPI-bus projects, and look for myself.
--- Quote ---Some more info:
- As i can see, decode is not related to trigger at all but wave forms, you can even decode in auto triggering mode in the midle of a string.
--- End quote ---
Yes, but can you do so properly? It's always possible to say, "Start here and decode what you see", but getting the Start point correct is critical. Otherwise, what you get out is garbage.
--- Quote ---- The lines i draw are in the correct place, confirmed with LA1034 LOGICPORT tool that is decoding as expected.
--- End quote ---
I'm sure they are correct, with the way you (and the LogicPort) are interpreting the stream. Does the Logicport have only two SPI lines connected, as the DS2000 does? Or does it also have a CE/CS (Enable/Select) line to help demarcate active segments?
One thing I noticed right away is that your last SPI snapshot actually has a gated CLK signal. In all the rest, it has been (or appeared) continuous. And with a continuous clock, no CE signal, and no gaps between data bytes (to trigger a resync), how would any device (or person) be able to tell where the byte boundaries were? I've written software SPI decoders before, and I couldn't figure that one out. So I wasn't surprised that the DS2000 couldn't either.
--- Quote ---- I dont know how the scope knows the start bit, anyway it is doing it in not zoomed strings any kind of trigger.
--- End quote ---
Bingo! I think that's the crux of the problem. Sure you can ignore the trigger type. And yes, the DS2000 will scrape the display memory and (try to) decode anything you throw at it. But the Start bit is fundamental. Look back at your RS232 capture. It jumps in and interprets what it sees, but flags every byte as defective. That's because you didn't use RS232 triggering, which would let it know it needed to detect Start and Stop bits, to demarcate a byte cell. Without that context, Start and Stop bits are just more data.
--- Quote ---- In SPI i trigger with CS signal, sometimes with GPIO, edge or SPI trigger with same result in zoomed string.
--- End quote ---
I'm not quite sure what you're saying here. If you mean that you're using a Select line (CS) through the ExtTrigger input, marmad has already explained why that won't work. It should! I think we all agree it would be much better if it did. Trying to decode SPI without it is problematic at best. But it doesn't.
--- Quote ---- In current string I can not trigger In RS232 mode because the scope suport up to 900Kb for trigger, the string is 2Mb.
--- End quote ---
Ah, OK. So you've exceeded the documented capability of the scope. I didn't think of that right away, because the fastest I've ever driven RS232 in any of my designs was about 1 Mbit/sec.
--- Quote ---I don`t know if any parameter is wrong, but ... decoded data don´t match waveforms.
--- End quote ---
I think the later implies the former. ;) Unless the scope is completely broken, which hasn't been reported here. Maybe it's just because you're the only one who has dug into this. :-// I don't know.
--- Quote ---marmad:
- Where in the manual you can find this? "protocol decoding should be teamed with the corresponding trigger".
--- End quote ---
I'll let marmad respond to this (if he likes), but it's been my opinion that enabling a decoder should also at least default to the corresponding trigger mode. And then let you override that, where needed or appropriate. But the DS2000 is not the only scope that gives you the flexibility to hang yourself in this way. On the scopes I've seen, defaulting to the matching trigger mode is the exception, not the rule. You're forced to redundantly set both, and I'd guess this is because they're independent options. I.e., not linked, as they should be.
--- Quote ---- After heavy use of decode function, i can asure that it is not dependant of trigger mode. Please see the new image, trigger SPI.
--- End quote ---
I don't think we can reach that conclusion at this point. For example, in your last screen shot with SPI triggering (thanks for trying that), we see a gated CLK-signal line, for the first time. AND all the data bytes are decoded correctly! Also for the first time. However, there is a 1 division skew in the decoded green boxes that I don't understand (yet). But I am curious about it.
luchog:
Thanks Mark_O, you are very scientific :).
I found, decoding is ok, the problem is the data display is shifted respect waveforms, more far from trigger event more shifted.
I think it is an cumulative error calculating the position of data to show.
May be there are more cases when this shifting is happening.
Can someone verify this?
Thanks.
Circlotron:
Okay, 200mS/div sweep, single shot, hi-res mode.
The resulting trace is pretty dull. After it is captured, if I move it even slightly to the right or left it becomes normal brightness.
The vertical sections of the blue trace are 1 pixel wide in both cases.
Not a really big deal, but maybe something Rigol should consider on their bug list.
Is anyone here actually going to send them a list of bugs?
AndersAnd:
--- Quote from: Circlotron on February 22, 2014, 11:44:17 pm ---Is anyone here actually going to send them a list of bugs?
--- End quote ---
As you can read earlier in this topic, e.g. here, the OP marmard send all bugs to Rigol via Drieg (Petr Šmíd) who owns the official Rigol distributor Silicon Electronics in the Czech Republic.
Drieg is also a member of this forum: https://www.eevblog.com/forum/profile/?u=343
Mark_O:
--- Quote from: luchog on February 20, 2014, 07:20:22 pm ---I found, decoding is ok, the problem is the data display is shifted respect waveforms, more far from trigger event more shifted.
I think it is an cumulative error calculating the position of data to show.
--- End quote ---
Thanks, Luis. That's good to know. Too often, someone will show up here and loudly proclaim that something on the Rigol is broken or malfunctioning. :scared: But when they later find that it was really OK, they quietly disappear. I'm glad you took the time to confirm that it does work, and to let us know about it.
As for the shifting, I suspect you are correct. This isn't the first time someone has noticed a peculiar offset. But after further testing, it seems to disappear, without any explanation. This is the first time I've heard someone suggest a reason for why this may be happening, to varying degrees. Distance between the trigger point and the display point may be the variable factor. I don't have a DS2000 here to test with, but you anyone here with a DS2000 could explore the possible relationship by examining packets close to, and progressively farther from, the trigger point.
EDIT: to emphasize that Luis isn't the only one who could explore this shift.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version