When you think of a logic analyzer today, you might think of a little USB probe that can measure a few signals and decoding for various serial buses. But actual logic analyzers were high-speed multichannel hardware with sophisticated ways to clock and trigger. [Tom] picked up an HP1670G on the surplus market and was impressed that it could sample 136 channels at 500 MHz. The circa-2000 machine has a front panel, but if you really wanted to use it, you wanted to use an X terminal. [Tom] shows us how that works with modern Linux software.
In X/11 parlance, the terminal is the server, and the remote computer is the client. In the old days, when people weren’t so obsessed with security, running applications from multiple clients on a single server was easy. These days, most Linux distributions have made the X/11 system little more than a display driver. Logging into a remote system usually requires some hoops. However, [Tom] went with a different approach. Using socat, he routes incoming X/11 connections to his local X server.
There’s more to it than just that. You must also assign addresses, punch holes in your firewall, and set up the right fonts. It is all there in the post.
Oddly enough, we’ve seen this logic analyzer accessed remotely before using a more traditional method. Even Windows can host an X server, by the way.
Whoa!
I thought this was about a Logic Analyzer, but the garden path is winding through
“You must also assign addresses, punch holes in your firewall, and set up the right fonts.”
It makes me wonder if it there is a pot of gold awaiting the traveler, or dragons!
B^)
I recall using a similar HP logic analyser back in 1999. I had designed a PPC CPU board and we were trying to debug some driver software. I had put Mictor connectors on the various buses, so it was simple to plug in the logic analyser. The analyser was smart enough to be able to capture all the bus signals and use that information to infer what was going on inside the PPC (on the other side of caches, etc). The analyser could mount our server drives using NFS and we would point it at the linker symbol table file so that it could match addresses with our C source (that it could also find). That meant that we could step through the captured data as both lines of assembly and lines of C displayed in different windows on our X terminal (which was an X terminal emulator running on a PC).
To find the bug, we set the analyser to trigger on the crash condition (IIRC this was a fetch from an exception vector), then we stepped backwards through lines of C until the cause became obvious.
It took a little while to set up, but I was amazed at how powerful this was for debugging.
I did a writeup on doing similar things and more (FTP file transfers, programming) on my blog: https://blog.mateijordache.info/2022/05/31/hp-1670d-notes/#more-223
I hadn’t seen any instructions about replacing the HD with a flash drive. I might do that one day.
It’s funny (and a total coincidence) that you, me, and the other blog post that I linked to at the bottom of my blog post are using 192.168.1.200 as IP address!
One of the things that tripped me up was FTP access: it doesn’t work out of the box anymore when using Ubuntu 20.04: you need to play some tricks with your firewall. I’ve since updated the blog post with that info.
I recently picked up an HP16500B (96 ch, 100MHz LA/500MHz SA + 400Ms/s 2 channel scope) on FB Marketplace for $40. Amazing device, Very nice feature is to share the trigger and do some mixed signal analysis. What I was most amazed with was the previous owner still had all the LA pods and a plethora of original grabbers, and had swapped out the internal HDD for a SSD.
Didn’t even realize it had Ethernet/X connectivity until I was running it and saw the option, and looked at the back and saw that it had an AUI port (and the 10BASET adapter in the bag of accessories). No fancy DNS or DHCP support. CRT has convergence issues, it also has an analog VGA display option.
I have one of these lab heaters too, the AUI dongle was retrieved from a box of skip divings that I had saved.
I managed to get hold of an analogue scope card and have a few other expansion cards.
Now we have OSS decoders it should be a simple matter to capture the trace output into a Pi or similar which can then decode the I2C, UART or whatever.
Something to look out for is that newer Xorg versions have disabled automatic determination of endiness. The HP16XX locic analyzer runs on a MC68020 and so the VXworks implementation is bigendian. Intel x86 (and mostly ARM) is littleendian. https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1029
I had to add the option +byteswappedclients to the Xorg server command (edit the script /usr/bin/Xorg) so that the littlendian server wold work with the bigendian client on the logic analyzer.
The HP16XX logic analyzers are ‘big endian’ because they run on the Motorola MC68020. Intel (and most ARM) systems are littleendian. Newer versions of the Xorg server disable the automatic determination of endiness (ostensibly for security).
You need to enable this capability with the +byteswappedclients option to Xorg or by adding a config file with
Section “ServerFlags”
Option “AllowByteSwappedClients” “on”
EndSection