protocol analyzer

3 Articles

You Can Run BASIC On An Old HP 4592 Protocol Analyzer

April 28, 2024 by 10 Comments

What do you do when you find an ancient piece of test gear and want to have fun? Well, you can always try getting BASIC running on it, and that’s precisely what [David Kuder] did.

The HP4952A Protocol Analyzer actually looks a lot like an old computer, even if it was never meant for general-purpose use. The heart of the machine is a Zilog Z80 CPU, though, so it shares a lot in common with microcomputers of its era.

Among other hacks, [David] worked to get Microsoft Basic-80 running on the machine. Initially, he was only able to get it up and running on the display, with no way to read the keyboard, disk, or access the serial port. Eventually, by diving into the nitty-gritty of the machine, he was able to at least get the keyboard working along with some basic BASIC programs. Usable memory is just 8KB, but you can do a fair bit with that when you’ve only got a 32×16 display for output anyway!

It’s a neat hack and one that was extendable to the HP4957A as well. We’ve seen similar machines on these pages before, too! If you’ve got your own neat retro hacks on the boil, don’t hesitate to drop us a line!

[Thanks to Christopher Zell for the tip!]

Finding USB Bugs The Hard Way

October 20, 2019 by 17 Comments

Sometimes debugging just doesn’t go the way you want it to. When USB problems arise, you can usually use a protocol analyzer to find the issue causing trouble. For [Paul Stoffregen], it was only the first step in a long process to find the culprit.

Procotol Analyzer

The complaint that came up was from a customer whose 2 port USB hub wasn’t working on their Teensy 3.6. The hub had been tested on Linux, Mac, and Windows, so it made sense to test what was different about the Teensy. Furthermore, all other USB hubs worked on the Teensy. As it turns out, these weren’t the most helpful assumptions to make when finding the bug.

Any protocol analyzer can be used, for instance the Beagle480. The way it works is by passing through USB communication, making a copy of the communication coming in and out, and sending it to the PC.

 

Normally, the analyzer has a small buffer memory and must sustain fast data flow. Unfortunately, this can occasionally cause software lockup. From what could be gathered from the verbose printing, USB descriptors were found for the hub. As it turns out, the faulty hub was a Multi-TT type hub, while most others are single TT (transaction translator).

Fixing Software Lockup

Since it was necessary to get the rest of the descriptor data, fixing the software lockup was the next step. Writing in a panic function – a breakpoint of sorts – into the code allowed the USB host’s power to terminate, and stepping through the program revealed that while the 2 port hub was initially being read, some issue arose afterwards.

As it turns out, the issue relied on USB split transactions, used only between USB hosts and hubs. Communication happens by tokens, which begins with a SPLIT-START token.

 

As it turns out, the issue was that the tokens weren’t being sent in the correct order. The other hubs seemed to be handle this nevertheless. By applying a fix to the C++ code of the bad hub, which had previously not been implementing the data structure for accessing register properly, the hub was able to work again.The hub appeared to be rejecting bad token, which was causing the issue in the first place.

All in all, while I’m sure this had to be a head scratching experience, at least it gives us some insight into the low-level design of USB communication.

GlScopeClient: A Permissively-Licensed Remote Oscilloscope Utility

May 30, 2019 by 26 Comments

One of the most convenient things about modern digital oscilloscopes is that you can access the recorded data on a computer for later analysis, advanced protocol debugging, or simply the convenience of remote capture. The problem is that the software isn’t always ideal. Vendor-supplied utilities are typically closed-source and they try to nickel-and-dime you for every a-la-carte protocol and/or feature. The open-source options come with their own issues, from performance-limiting designs, to incomplete features, to license constraints. Faced with these issues, [Andrew Zonenberg] decided to take matters into his own hands and create glscopeclient, a permissively-licensed open-source remote oscilloscope utility.

The eventual goal is to allow you to do remotely anything you would normally do using the scope’s front panel, plus capture and analyze data on the computer side. The code uses a modular architecture that allows for various backends to talk to different scopes. At the moment, the only backend fully implemented is for LeCroy scopes, although this is enough to demonstrate the power of the idea. The obvious “gl” in the name gives away the secret — the code uses OpenGL for rendering, which allows for some very fancy graphics at high frame rates.

Behind the slick look, however, are some serious debugging tools. Protocol analyzers include USB, UART, JTAG, eye pattern analysis, plus FFT-based spectra with waterfall displays. The code is in GitHub, and most of the announcements and discussion seem to happen on [Andrew]’s twitter account, which you can follow @azonenberg. It’s a work-in-progress, but a serious one, and something we’re going to keep our eyes on.

You can check out a video of the program after the break.

Now, if you want to literally talk to your oscilloscope, we covered that, too.

Continue reading “GlScopeClient: A Permissively-Licensed Remote Oscilloscope Utility” →