Today I got my new (rented) scope in the mail. It’s an Agilent MSOX3014A with RS232 option. It’s got 4 analog and 16 digital channels, with a 4Gsps capture rate and 100Mhz bandwidth (no need to spend up to twice as much for the max 500MHz unit, which is nothing more than a license upgrade anyway…).
(sorry for the grainy iPhone image…)
Here you can see the new scope, my old scope, and the project under development with some of the probes hooked up. Here’s a shot of the scope in action, screenshot from it directly to a USB flash key:
This shot shows a lot of the features I that made me get this scope. In this shot the screen is split into zoom mode, with 10us/div on top and 1us/div on bottom. I can change the scale on the bottom and scroll it within the larger region at will, and it’s got all the data there at full resolution (2GS/s as shown). The green trace is half of the RS-485 bus, while the pink trace is the math channel showing the differential result of that and its mate, after almost 100ft of lamp cord ;-) D1 (cyan) and D0 (red) are the digital inputs hooked to the digital side of the bus controller. S1 shows the RS-232 decode of that bus. The really neat trick is that I’m actually triggering on the serial data, specifically 0x66. You can see the orange triangle at the top of the two windows lining up with the end of the byte. Since 0x66 happens to be the trigger byte for the end of the packet preamble in my design, what you see is preamble to the left and actual data to the right
I’ve even got the trigger output of this scope hooked up to a channel on my older TDS224, which allows the exact same waveform timings to be shown on the other scope at the same time ;-)
The scope also has a high-speed USB interface, which will allow me to set up, capture, and retrieve data from a Python script on my computer. Since I have code already in place that will take a byte-stream in CSV format (so far from the Salaea Logic analyzer dump), it should be almost trivial for me to take the info from this scope and produce a human-readable packet dump. The question is whether I can actually trigger and transfer data fast enough for every frame. I suspect not, but that’s what the digital channels are good for: use a spare trace I/O on the board to signal a timeout or other bus condition, and go from there.
Only problem so far is that the thing’s got a decent-sized fan, which means both noise and heat ;-(