Having explored, somewhat, the innards of the old Tedious 644A oscilloscope, and decided that I wasn't likely to fix the trigger circuit, I spent a while browsing eBay for a Deal on a replacement.
This is a LeCroy 9374L, bought from "zseng2k3" on eBay. While it lacks the color display of its predecessor, it does have a humongous acquisition buffer: 2M points per channel! It also has a built-in printer, which works, so far as a cheesy thermal printer can ever be said to work. (I normally expect to "print" to floppy, and insert the resulting files into lab notes, either in word-processed documents or in my new TWiki.)
There are several fancy signal-processing software features installed, but I haven't figure out how to use 'em yet, apart from the FFT. Some of them are intended for testing disk drives, but I figure they may be useful for examining other sorts of communication channels.
I tried communicating with it over the RS-232 interface, having much frustration until I figured out that one of the cables I was using didn't pass all of the modem-control signals, thereby causing Scope Explorer not to see the scope. It does work, but... well, have you ever waited for a download of 2M data points, in ASCIIfied floating-point format, at 19200 Baud? Even without many significant figures? If I'm going to use the remote control, it's time for ol' Higgledy-Piggeldy Interface Bus. Guess I'll be watching for a bargain card to plug into the PCI bus.
The scope isn't the only new piece of hardware around here this week. I'm writing this on my new workstation, Perdita. She wears black (another CoolerMaster Centurion case), and is of two minds about everything (or at least has a dual-core CPU). My old workstation, Verence, is about 5 years old, wasn't exactly high-spec when he was new, and, apart from not keeping up with the demands of new stuff (like FPGA compilations) and having a bad configuration rot, had started getting decidedly unreliable of late, so I figured it was Time to procure & configure the replacement.
Perdita has a Core 2 Duo (my first Intel desktop processor in about a decade), 2GB of dual-channel DDR2-800 RAM, and, mostly for recreational purposes, an Nvidia 8600 GPU (which does have some benefit for work; I suspect that some of the trouble I'd been having with VariCAD was actually related to the OpenGL driver for Verence's Radeon). She's running a fresh install of Debian-testing (Lenny), which is almost, but not quite, configured the way I want it.
The transition from AMD/AGP/ATI to Intel/PCI-E/Nvidia was a bit of an adventure, but not too painful.
I'm not actually running 64-bit software; most of the CPU-hoggy stuff is 32-bit anyway, and I didn't feel like mucking about with a mixed environment. I did have to build a custom kernel to accommodate the Nvidia binary driver (which needed a matching source tree to build the kernel module), and, while I was at it, I turned up the interactivity features (preemption and system clock frequency).
Linux is making good use of the dual-core CPU; xosview shows the load bouncing back and forth between CPU0 and CPU1, and I can now run a highly CPU-intensive process (e.g., an autoroute in EAGLE), and go off and do interactive things in the meantime.
The fancy graphics card lets me crank up the rendering options in X-Plane... well... to reasonable settings, anyway. The results are impressive.
Sometime in the next couple of weeks, I'll be doing the long-awaited datacenter reconfiguration, and Perdita and Vetinari will both be moving to a new vent-hood cabinet under the side table.
Oh, yeah: there's an annoyance. There's an Issue between the Linux USB HID driver and the CH Products yoke, joystick, pedals, and throttle quadrant (I have the pedals and throttle quadrant, and a Logitech joystick). On booting up, the driver will recognize the device, but then apparently disable further input from it... so the device shows up, but doesn't respond to user stimuli.
The unofficial solution is to unplug and replug the device, which works, but is blatantly kludgey.
Another unofficial solution, which was been around for at least six years, is to disable a set_idle call of some sort in the driver. I found an example of this for the 2.6.8 kernel. In 2.6.21, the hid-core.c code has been much rearranged, but I found the use of HID_REQ_SET_IDLE and made it go away... and this had no visible effect, so I'm still doing the unplug-and-replug-after-reboot thing.
You'd think that, after all these years, the USB maintainers would have incorporated the patch... maybe with a condition, e.g.,
if (manufacturer==CH_PRODUCTS) dont_set_idle(dev)
Comments