A while ago, I bought an HP 1652b logic analyzer. It’s a great machine, and works very well for my purposes (monitoring address and data bus for SNES memory usage) and I’m sure it will be invaluable in future projects, especially anything including parallel or serial data transfer. However, the only way to get data off of the analyzer is printing to a dot matrix printer/plotter through an antiquated RS232 or GPIB port. Those aren’t really common or useful anymore, but hopefully that does mean we can capture the data as a digital image for keeping around on our PC. This is a short documentation of my research and application process on creating an adpater to capture the signal on my PC.
We need to know some information first:
- How is the analyzer talking to the printer?
- What are the hardware level specs involved in that communication?
- How can we convert that to a computer-readable data?
How is the analyzer talking to the printer?
Conveniently, HP manuals are very easy to find, even for old equipment like this. Fortunately, there is a site dedicated to this instruments alone, hp1652bmanual.com. From the service manual, we can find that the printer can output printer code (something we’ll need to look into later) in either HPGL (HP Graphics Language) or ESC/P (Epson printer control language). HPGL can be output on the HPIB/GBIP port, and ESC/P can be output on the RS232 port. Here is a easy decision: The RS232 port is a serial port, whereas GPIB is parallel. Since USB is a Universal Serial Bus, that means we won’t ideally have to do any sort of conversion between data types of the signal when trying to get it into the computer (creating room for error). Additionally, GPIB cables are expensive (because they can be considered lab equipment, I guess?). RS232 cables are pretty standard computer cables (and I already have a few) so we’ll be using that. Let’s set the analyzer to be talking in ESC/P to the printer, by using the RS232 port.
RS232 is a well defined standard for serial communication. From the standard specifications, we have the following lines summarized from bb-elec.com:
- RXD, for receiving
- TXD, for transmitting
- RTS, request to send
- CTS, clear to send
- DSR, data communications equipment ready
- DTR, data terminal equipment ready
With some lesser used ones omitted, the last four are used for hardware level handshaking to verify that the sender has the data ready and the receiver isn’t processing anything. However, our PC is much faster than a printer (probably several magnitudes) so we shouldn’t really need to worry about if the PC will have it’s hands full during receiving. And since we’re not sending anything to the analyzer, we don’t need to worry about that either, leaving us with just the transmitting line. Convenient! If you wanted to create a universal adapter, you can bring those other lines along for later, as they’re almost identical to connect to our interface.
The specifications for RS232 also define the voltages used to transmit the data. RS232 lines have the logic levels (an interpreted 0 or 1 by the computer) defined as +/-15v, although the signal can vary a bit from those values (the HP has +/-11V found from a multimeter, but I’ll use +/-15V for consistency with the standard). We’ll return to this once we know what the logic levels are for USB communication. Something to note is that idle voltage on RS232 is low, meaning -15V.
How does a computer talk to USB peripherals?
Now that we know how the analyzer talks, we want to see how the computer talks, since we want them to communicate (even if it’s only one-sided). Similar to RS232, USB is a very well defined standard with lots of documentation. a USB port has the following lines, along with power (+5V) and ground:
- D-, data minus signal, sometimes seen DM
- D+, data positive signal, sometimes seen DP
- ID
D- and D+ are communications lines. The port also allows us to draw 5V, which is nice for powering ICs and other components. The last line is an ID line, which can be used to identifying which device is ‘host’. We don’t really need this, but it can be used for other ‘smarter’ devices.
So, since we want to talk on 0/5V levels with the computer (often referred to as TTL, or transistor-transistor logic) and the analyzer is working at -15/+15V, we’ll need a logic level converter to both step down the receive signal voltage and boost the transmit signal voltage from the PC. Another consideration is that idle on TTL logic is high, meaning +5V. If you remember from earlier this is the opposite of RS232, which idles low at -15V. This means that we’ll not only need a logic level converter, but we also might potentially need to invert the signal so that the bits received are correct. This could also be done in software if needed, but it’s much cleaner to just correct this on a hardware level.
A quick search for RS232 TTL logic level converter brings us to the perfect chip, a MAX232. A lot of the pertinent information is just on the first page of the datasheet. This is a dual converter IC (we’ll only be using one of the converters) with external charge pump capacitors for boosting up to the RS232 voltage, and an inverter to talk on the full range (+/-15V). It also inverts the TTL signals, so the correct signal is received. The IC is powered off a single 5V supply, which we can hijack from our USB line. So, if we connect up the analyzer and the computer using this chip, can we communicate between RS232 and TTL? Not yet. Since we’re communicating over serial, it’s extra important that we know when a bit is sent, so we can store it and get ready for the sent bit on time. With independent clocks in both devices, this is impossible to manually set up. Additionally, we need a way for the computer to read the information, through a driver or some firmware.
Turns out, this has already been worked out by people a long time ago. The answer can be found in UART, or universal asynchronous receiver/transmitter. This protocol uses a common transmit speed between the two devices in bitrate/second (baud) and does some handshaking to get both devices synchronized for data transfer and receiving. As it works out, there are a number of ICs that can do this for us, and not only handle all the UART communications, but the TTL communications as well.
FTDI seems to be the premiere manufacturer of these chips, and make many different types. We just need a basic one, since we’re not trying to do anything with ultrafast communication or some other special case. I decided on the FT232R. This isn’t a chip only used for RS232 communication, it just seems the product number matches. The benefit of using the FTDI chips is that the drivers are universally available. So, if you just buy the chip, wire it up and connect it to your PC, your computer will be able to read information from the device. Very nice! This means we don’t have to get a programmer to put code onto the device or design our own drivers and firmware for communicating with the PC.
Since I do a lot of MCU work, I already had one of these UART-TTL converters, so I’m just going to use that. You should note that it is rare to find these ICs in a DIP package, so you will probably need to design a breadboard adapter or the like if you’re just prototyping, like me, or just buy one of them. They’re only a few bucks from China if you don’t mind the wait.
So, how are we going to wire everything? From the datasheets on the two ICs, it seems pretty straightforward. Basically, we’re just going to set up the MAX232 for standard operation, and then connect all the parts together. The MAX232 does require a few external capacitors to be hooked up for the charge pumping and signal inversion for normal use. Depending on the RS232 side voltage, the capacitors need different values. The MAX232 I had around was designed for +/-10V operation, and uses a few 1uF caps, and a 16V tolerance should be fine. The MAX can then be connnected to the power rail.
The FT232R setup is easier, as the as it only requires a resistor (Read the datasheet!). Then, the Tx and Rx lines can be connected to the MAX232, and D+ and D- to the USB cable. Connect the FT232R to the power rail and make sure the grounds are properly isolated. This shouldn’t be a big issue, since for me, both of the devices are grounded to the same outlet, but in the case that one or the other instruments aren’t earthed or there is any sort of bias, you wouldn’t want to send current to one of the instruments inadvertently.
Voila! Sending a signal shows communication on the other end. After searching for a bit, the software I ended up using to receive the information was Serial Printer Logger, used for exactly this purpose- a software to capture the data meant for a legacy printer. However, it does seem that our adventure ends here: while I can receive the information, the formatting is for the old Epson PCL format.
Remember earlier when I said we should check out printer control languages? Printers used to contain hardware memories where fonts and programs for the printer commands were stored. However, that means that if we want to build a software to do this, we need to emulate the same way that the printers would work. This includes creating a program that can account for the thousands and thousands of commands that are included in the very extensive Epson ESC/P documentation. In reality, we don’t need to emulate all of the commands, but we would need to know exactly which ones we need- and it would be a very specialized software, just for our instrument. Building a general case software based on the full documentation of ESC/P would be a better program, but an incredible (maybe impossible) task. So, let’s check if anyone else has done that.
There seems to be a few options for doing this sort of conversion from PCL to a visible, readable format: two that are extremely expensive for this sort of project at >$500, and a cheaper alternative called RetroPrinter, which is some program you can load to a Raspberry Pi with a custom Centronics connector and store the captured data as PDF. Seeing as I already have the hardware built, I tried to build their code, but I couldn’t seem to compile from source correctly, both on Windows or on my Linux machine. Until I can get this to work, I think the project has to stop here.
At the very least, we learned some information about RS232 and TTL standards, serial communication, and reading datasheets for hardware components. The biggest thing I took away from this is that everything is designed to be used. It’s easy to think that electronics components, or PCBs, or whatever, is only meant to be used by professionals. People design things for other people to use! The ease and availability of datasheets is proof that anyone can do this, just some base knowledge is necessary. If you want to make something, just start somewhere! The tools are laid out for you, and all you need to do is think about how to connect them best for your needs. This is true for almost everything, not just electronics. A little bit of research and you can be on your way to making things for yourself and for other people, and if you create ways for others to see your work, you’re contributing to the global pool of ideas.
That being said, let me know if you have any ideas on how to process the output code from this! I went in head first, not realizing that I would have to process the code at some point to make the image or document.