The Tektronix 1180x Screen Capture Utility (“TSC”) is a program that allows easy screen captures from a Tek 11802 oscilloscope using the serial port interface. It will likely work with any Tek 11800 series and perhaps even 11400 series scope, although I don't have these to test (...and the need for such a utility on, e.g., the 11801 is lessened as this model can directly output TIFF files).
Besides the obvious motive to be able to document waveforms without needing to grab a camera, I used this program as a learning exercise for the wxPython GUI toolkit. I mention this in that, while the program is “fast enough,” it's definitely not “screaming fast” and this is largely a result of Python as the programming language – interpret languages still seem noticeably slower than good compiled languages!
Configuring your scope consists of (1) connecting a regular cable between your PC and the scope (this is a “straight-thru” cable – the scope is DCE) and (2) configuring the Utility->RS232C Parameters and Utility->Hardcopy screens. The RS232C parameters screen should end up looking like this:
The important bits are the baud rate, stop bits, parity, and flagging (aka, handshaking) – the rest doesn't really matter. (In fact, PCs seem to be fast enough these days that everything still works if you turn flagging off completely.)
Set the hardcopy parameters to look like this:
The important bits here are Printer, Direction, Data Format, and Output Port. The “binary compacted” data format was chosen because it produces the fastest possible screen dumps; if you inadvertently select another format TSC will likely just ignore the scope or possibly spew out an occasional error message. The “horizontal” direction was chosen arbitrary – supporting both is a straightforward addition to the program, but I didn't have need for it; if you inadvertently select it TSC will issue a warning when you press “hardcopy.” Finally, “screen format” is largely a matter of preference: Any except “Reduced” will work -- some are a little more detailed than others, some are a little faster than others. See the “Trivia” section below for details on why you shouldn't chose “Reduced.”
The program was written to be largely self-explanatory in its use. After physically connecting your 'scope to your PC, you proceed as follows:
Use the drop-down box to select the serial port you're using, or type in a device/port name manually. If you use manual entry, you need to cause the box to “lose focus” before your change will be acknowledged – just hit tab or click on another control. The port name you enter will be saved between program runs. The drop-down box is pre-loaded with typical Windows and Linux port names for your convenience.
The “status” line should change to read, “Waiting for header...” Once it does, press the scope's “HARDCOPY” button and you should be the scope's screen dump slowly appear in the “Screen Capture” window.
If you don't like the colors being used, click one of the “Pixel Color” buttons; these will be saved between program runs as well. When you make a change, the program will update the colors in the Screen Capture window, but in a rather naive manner: Any pixel that was the “old” color will be changed to the “new” color, which isn't correct if you had more than one pixel value mapped to the same color. In practice this isn't expected to be a real limitation (in fact, I doubt most people would have ever noticed this behavior in the first place).
At any point you can click the “Copy Image to Clipboard” button so that you can paste results into, e.g., Microsoft Word, GIMP, etc. (For some reason on Linux you can't directly paste into OpenOffice Writer, although if you first paste into GIMP and tell GIMP to make a copy you'll then be able to paste into OpenOffice).
That's all there is to it! Enjoy, and let me know if you find any bugs...
---Joel Koltner
zapwire-fun@yahoo.com
Bug #1 in Tek's hardcopy output routines: Selecting “Reduced” for the screen format causes the scope to claim it's sending a 552x704 pixel bitmap when in actuality it sends a quarter-sized, 276x352 pixel bitmap. This confuses TSC and you'll get sort of an interlaced/doubled display and – eventually – an error message when the scope doesn't finish spitting out as many pixels as it claimed it would. I didn't figure I'd ever want a “reduced” output, so I didn't bother trying to work around this.
Bug? #2: When using the “BinHex Compacted” data format, what apparently should be CR/LF line separators (0x0A, 0x0D) are instead received as follows:
“EOL String” Setting |
Output Character(s) |
CR/LF |
0x83, 0xC4 |
CR |
0x49 |
LF |
0x69 |
LF/CR |
0x9B, 0x2E |
I expect this an artifact of the compression routines getting invoked when they shouldn't be.
If you select one of the uncompacted output data formats (“BinHex” or “Binary”), the scope's serial port spits out ~1800 bytes/second when the port is set to 19,200bps – entirely respectable. Annoyingly, there's a major throughput hit in when switching to “BinHex Compacted” -- you obtain only ~700 bytes/second! This performance reduction appears to be almost entirely due to how quickly the scope can compact the data, as switching to “Binary Compacted” only outputs ~380 bytes/second! (The actual data rates are somewhat dependent on just what's being displayed on the screen.) The long-and-short of this is that setting the scope's bit rate to 19,200 doesn't buy you anything (perhaps this explains why Tek's default is 9600bps), and complex screen dumps will always take about a minute.
I'd love to find some of the designers of this classic scope to discuss just how this classic instrument came about. These days the 11802 is more than two decades old, but it still holds great value for those interested in performing very high-speed time domain measurements on a budget.