Hi Mark_O, Thanks! I was definitely being serious and your reply was outstanding.
You're welcome. I'm glad your question wasn't tongue-in-cheek, and my reply was useful.
I've been trying to gain a better understanding of the practical capabilities and limitations of the decode functions on the DS2000 series for a while now and your reply is the most definitive discussion of this topic I've seen.
I'll admit that when you're trying to make a buying decision based on anticipating what you might need, to handle things you haven't encountered yet, it can be difficult. Especially when you're getting started. "
What do I chose? What do I chose?"
I've also been trying to figure out the 2 decode button layout and like you have been trying to decipher the manual and other documentation.
I was kind of hoping that someone who actually has a DS2000 would jump in and tell me I was FOS
, and that the limitations implied by the manual were not present in the scope itself.
I had just about decided that the DS2000 was the right scope given that most of my work initially will probably be RS232 and I2C with SPI as the likely 3rd decode protocol I'd like to work with. I realize that SPI would be (much) better with 4 channels but I was thinking maybe the DS2000 get the job done to some extent in "workaround mode"
Well, it's certainly possible to "work around" many limitations in your test instruments. All of us have done it at one point or another, and some of us have to do it every day. But just because you can finagle things around doesn't mean that you'd want to, or it would be a productive solution. Let me illustrate the problem with half-SPI on the DS2000 with a very specific example (analogy) that's probably closer to home for you, and may be easier to grok.
When you're working on a system with an RS232 comms channel, you're monitoring RX and TX lines. You may be looking at Requests or Commands on the TX, and seeing the replies on the RX. The two are pretty closely tied together, and being able to see the specific response to the specific request may be fundamental. Now imagine if you could only hear (see) half the conversation. You could either monitor outbound requests, but not see what was being sent back. OR you could see responses, not knowing what request they were relating to. AND you could
not see the time-interval between the two. Does that slow you down any? How much fun will you have moving your probes around, to check RX and then TX, one at a time?
That's what's going on with SPI on the DS2000. You only get to see half the conversation at one time, because one of your two available channels HAS to be used for the Clock. On a SPI bus, the CPOL and CPHA are critical (polarity and phase), because they determine when to sample the data bits. That leaves only one channel for data, yet there are two (MISO and MOSI, similar to RX and TX). Not only can you not see both sides at the same time, you also can't see the timing relationship between them. To me, that's like working in the dark. And why I was hoping the DS2000 had an undocumented capability (missing from the manual) to use the Ext.Trig for say, Clocking, leaving Chan1 and 2 open for MISO/MOSI. Not having the 4-th channel (a Select line, for CS or SS) will certainly be detrimental on a multi-slave SPI bus, but that at least you can find ways to work around (have the other slave devices shut-up). With the DS1000Z, you don't have to.
That's why it seemed like a bit of a stretch to me for Rigol to claim that the DS2000 even handles SPI. Sure, it can trigger on it (and handle CPOL and CPHA), and decode the bit-stream to turn n-bits into bytes or words... for one half of the comms. But that's pretty crippled, in my book.
...you and Marmad and others have me wondering if 2 channels will become a notable limitation sooner than later. The DS2000 seems like a pretty good step up from the DS1000Z in several respects such as waveforms per second, memory, screen size, and maybe the big Nav dial too but maybe those are worth giving up for the 2 extra channels on the DS1000Z.
That's one area where I think you and many others are making a fairly big mistake. There's no doubt that the DS2000 IS a good step up from the 1000Z in many key performance metrics. It's an excellent device. Greater bandwidth, higher sample rates, deeper memory, etc. But unless you're a "more is
always better" kind of guy, you have to put that into some perspective. Do you really
need 200 MHz? Or would 100 MHz be enough? The answer isn't the same for everybody, but even the lower specs of the 1000Z, coupled with 4-channels, would be incredible for many, many users. Especially hobbyists or beginners. And 4-channels at under $600? Are you nuts? That was simply unheard of. There's a reason you don't see very many 4-channel scopes out there... until recently they cost an arm and a leg, and they simply weren't an option for anybody without deep pockets. That doesn't mean we didn't want to have one!
And cursed our bad luck the minute we needed to have channel #3 in a test setup.
I don't think I'll be needing to work with 2 different protocols at once...
You probably won't, at least not right away. But consider that if you'll be doing any embedded systems work, or working on devices that are uProc-controlled, there's often a lot of internal communicating going on between subsystems (a huge amount of I2C and SPI, in my experience). And being able to see the interactions between two separate comms channels will sometimes be fundamental to finding your problem. Even just monitoring ONE internal comms bus, the minute you need to see and coordinate it with any other external signal you come up short.
And if you're doing your own embedded-systems development work (as opposed to trouble-shooting existing systems), one thing you may find exceptionally useful is to have your micro emit your own trigger pulses at specific points, as markers, to flag when some condition or event has occurred (or the interval where it's active, as a Gate signal). No digging through a long trace trying to find a correlation, you flagged it yourself in your code, triggered on it, and can see what's happening at the exact spot, as well as the timing. How do you do that when you have only 2 channels, and they're already tied up? You don't.
How does having twice the bandwidth you needed, or 10x the memory depth you needed, or being able to oversample 5x higher than required help you out there?
...but I understand your views with respect to SPI and triggering/signal correlation and I appreciate the time you took to type out specifics. I hope you will be up for adding more thoughts as they come to you. Thanks again, EF
Well, this was a bit more. Enough for one posting. Possibly more later, as time allows.
Home
Help
Search
Login
Register
