HP 1670D notes

I have finally gotten around to setting up the logic analyzer I picked up locally to replace the HP 1652B. It’s a really nice instrument- 136 digital channels, LAN connectivity, keyboard and mouse support, internal mass storage, and some other nice features. Here are some notes on how I set up and used some of the features- they are generally not well documented and there are some modern upgrades we can do to make working with it easier.

LAN connectivity

Ethernet jack comes standard on this analyzer. However, due to some conveniences of modern life; it’s not immediately obvious how you are supposed to make this work. For example, it does not support DHCP, so you have to manually assign it an IP outside the range of auto-assigned addresses. This is easy enough- just open the LAN settings in the system menu and set it to a free IP address. You do need to check your router to make sure that you’re not taking an address that is reserved or already in use. Do make sure to set the port to TP (twisted pair, i.e. ethernet) instead of BNC (for thin-lan).

I am not sure if there is any nuance to picking an IP out of your local range so that you could access the analyzer remotely- out of fear of doing anything happening to the harddrive inside, I set it for local access only (192.168.1.200, as my DHCP address range ends at 192.168.1.155). Likewise, I set the gate to the local address of my router, which inside my network is 192.168.1.1 (which I think is just a standard practice). The name doesn’t matter as much; unless you want to edit the hosts table on all your computers it’s a lot easier to reference the analyzer by IP in my opinion.

If you want to put the used IP address in your DHCP region but not have it be taken by other devices, you can set up a DHCP reservation on your router- all you need to provide is the desired restricted address, and the MAC address of the analyzer. This you can find by connecting the analyzer and searching the network; but you can also get it from the “Show LAN Connections” menu.

FTP file transfers

Once you have it networked, you can put and get files from the analyzer over the FTP protocol. Supposedly, the analyzer also supports NFS mounting as an external drive over the network, but I think modernization of the standard has made it incompatible with such an old instrument- I was unable to make it work on MacOS 12.3- which, as a side note- FTP no longer comes standard with Mac. You can get it back by installing it via brew install inetutils (also comes with telnet, another supported transfer method for the analyzer that I could not make work).

So, you can open the FTP session via a terminal: ftp 192.168.1.200– and off you go!

As per the LAN User’s Guide, there are two accounts on the analyzer that you can log into: CONTROL and DATA- neither of which have passwords. CONTROL is the account used for submitting commands to the internal socket parser of the machine for configuring it and starting measurements and the like. There can only be one person logged into the control user at any one time. The DATA user has the same access to all the files but has read-only access, and there can be multiple users logged in at the same time.

You can use get to retrieve a file from the current working directory, or put to put a file on from the directory you opened the FTP session from:

ftp > get screen.tif
ftp > put localProgram remoteProgram

Internal file structure

The analyzer has some interesting features regarding file structure and how to retrieve data. On the root of the system (where you log into) there are a few directories: system, status, and slot_a. You can navigate around inside the instrument with ls (list files) and cd (change directory) in order to get to where the files you want are stored. Some notable locations are:

• system/disk/hard/system
  • This is where the self tests and extra modules are kept and loaded during startup. For example, the symbol utility lives here, along with some other inverse assemblers and other useful things. I will include a filedump of the contents from my analyzer at the end; copying this into any compatible analyzer should allow for self testing and enabling some extra features.
• system/program
  • This is a file that is constantly read by the command parser socket and will execute any commands in a file placed here. This is how you programmatically control the analyzer, as opposed to through the UI.
• system/graphics/screen.tif
  • This is a dynamic file that stores a screenshot of the current display on the analyzer.
• slot_a/data.asc/<analyzer name>/
  • This is where text files of the data collected by the analyzer live. These are dynamic files in memory, so not written to any disk yet, but still can be retrieved via get.

Note that the disk is not formatted in a typical fashion. As discovered by HP16500B Experiences, the drive has no partition table and is byte-swapped. Unlike the 16500 series, the 1670 series analyzers boot from onboard flash memory; and so the only material stored on the drive are the self test files, some custom modules, and other user saved files. Because of this, I don’t really think it’s worthwhile to save an image- you can always just reformat another disk if yours gets corrupted. The only important data to save (and transfer over later) are these files stored in system/disk/hard/system- which I have gathered and will attach as a file at the end of this post. Also in this folder is the custom fonts that you will need if you want to be able to run the remote X11 window system- otherwise the UI will crash when loading screens with text.

System

system/disk/ is a directory where the normal files are kept. These are all things that are stored on the internal mass storage, both on the floppy and on the spinning drive. The floppy obviously is used for files that you want to load/remove from the instrument, but at the same time, the size limit of floppies as well as their slow write speed make this a poor choice for most actions when the analyzer has such a large memory depth- most saved datasets will not fit on a floppy.

In the system/graphics directory, there are also a set of dynamic files that are generated upon request. In this folder, all of the graphics you can collect are related to the display on the screen. Make sure to set the file type to binary in order to collect a binary image (as opposed to some other ascii-encoded file), which will get opened as a file with the proper extension. For example:

ftp > bin
Set file type to Image.
ftp > get screen.tif

Will produce a picture like this in the directory that you started the FTP session from:

system/program is a file that is read and executed by the analyzer and is how you programmatically interface with the instrument.

STATUS

According to the programming manual, you can read some information out of here to understand the current state of the triggers, run mode, etc. I have not really done any digging into here since my use of the analyzer has been generally topical so far.

SLOT_A

This is where the memory of the logic analyzer lives. In here, there are two main areas: data.raw and data.asc. The data.raw is a binary format file that contains all of the experiment information; completely unformatted. I have tried to retrieve data out of here but I am not sure how to post process this in order to retrieve the full dataset as reconstructed in data.asc (the ascii processed dataset). However, data.raw is very quick and easy to transfer out of the analyzer. There is information in the Programmer’s User Manual about how the data is formatted and how to reconstruct datasets from the binary dumps, but it is a bit out of the scope of my work.

data.asc is actually a directory that contains a folder for each analyzer machine that you have setup in the configuration; and each of those folders contain ascii tables with all of the data collected in the way that you would visualize it on the analyzer. I have had a lot of trouble in retrieving this data as it’s a dynamic file and not stored on disk- something about the transfer gets interrupted while moving it. My main workaround has been to save the dataset to the disk via the UI on the analyzer, and then transfer the saved data from disk to my local computer for viewing and post processing.

Programming over FTP

Programming the analyzer is pretty straightforward and for measurements that you want to run that involve more than 1 or 2 pods, you should be using programming to configure the analyzer machines. It is very quick and easy to do, standardized SCPI, easy to modify and keeping the configuration text files around is cheaper on memory than storing the analyzer configuration file as saved by the instrument.

After writing a configuration file, you can just upload the file to the System directory under the name program (note that the file you are uploading has to be located in the directory that you opened the FTP session from):

ftp > put YourProgram /system/program

Anything dumped into this file is processed line by line by the command parser socket on the analyzer; and terminates after it is done. You can use this to do any number of configurations or measurements with the analyzer- you can also do this line by line by sending lines of text via echo to that file location; but you might as well just write a text file that contains what you want to send for posterity. For example, here is a small program that I wrote that configures an analyzer machine, sets the triggers, parallel decoding, and then finishes on a desired screen (the listing screen). To setup this measurement by hand would probably take the better part of an hour if using the front panel UI, even longer if without keyboard and mouse.

:SELECT 1
:MACHINE1:NAME 'TEST'
:MACHINE1:ASSIGN 8,7,6,5,4,3,2,1
:MACHINE1:TYPE STATE
:MACHINE2:ASSIGN NONE
:MACHINE2:TYPE OFF
:MACHINE1:SFORMAT:MASTER J, FALLING
:MACHINE1:SFORMAT:MASTER K, OFF
:MACHINE1:SFORMAT:MASTER L, OFF
:MACHINE1:SFORMAT:MASTER M, OFF
:MACHINE1:SFORMAT:REMOVE ALL
:MACHINE1:SFORMAT:LABEL 'ADDR',  POSITIVE, #H0, #HFFFF, #HFFFF, #H0000, #H0000, #H0000, #H0000, #H0000, #H0000
:MACHINE1:SFORMAT:LABEL 'DATA1', POSITIVE, #H0, #H0000, #H0000, #HFFFF, #HFFFF, #H0000, #H0000, #H0000, #H0000
:MACHINE1:SFORMAT:LABEL 'DATA2', POSITIVE, #H0, #H0000, #H0000, #H0000, #H0000, #HFFFF, #HFFFF, #H0000, #H0000
:MACHINE1:SFORMAT:LABEL 'MSEL',  POSITIVE, #H0, #H0000, #H0000, #H0000, #H0000, #H0000, #H0000, #H0000, #B0000000000001111
:MACHINE1:SFORMAT:LABEL 'NCFG',  POSITIVE, #H0, #H0000, #H0000, #H0000, #H0000, #H0000, #H0000, #H0000, #B0000000000010000
:MACHINE1:SFORMAT:LABEL 'IRQ',   POSITIVE, #H0, #H0000, #H0000, #H0000, #H0000, #H0000, #H0000, #H0000, #B0000000011100000
:MACHINE1:SFORMAT:LABEL 'DMAR',  POSITIVE, #H0, #H0000, #H0000, #H0000, #H0000, #H0000, #H0000, #H0000, #B0000001100000000
:MACHINE1:SFORMAT:LABEL 'DMAG',  POSITIVE, #H0, #H0000, #H0000, #H0000, #H0000, #H0000, #H0000, #H0000, #B0000110000000000
:MACHINE1:SFORMAT:LABEL 'RWLH',  POSITIVE, #H0, #H0000, #H0000, #H0000, #H0000, #H0000, #H0000, #H0000, #B1111000000000000
:MACHINE1:SFORMAT:LABEL 'FLAG0', POSITIVE, #H0, #H0000, #H0000, #H0000, #H0000, #H0000, #H0000, #H0001, #B0000000000000000
:MACHINE1:SFORMAT:LABEL 'DCLK',  POSITIVE, #H0, #H0000, #H0000, #H0000, #H0000, #H0000, #H0000, #H0002, #B0000000000000000
:MACHINE1:SFORMAT:LABEL 'BULK',  POSITIVE, #H0, #H0000, #H0000, #H0000, #H0000, #H0000, #H0000, #H0003, #HFFFF
:MENU 1,1
:MACHINE1:SYMBOL:REMOVE
:MACHINE1:STRIGGER:CLEAR ALL
:MACHINE1:STRIGGER:TERM A, 'NCFG','#B1'
:MACHINE1:SLIST:REMOVE
:MACHINE1:SLIST:COLUMN 1, 'ADDR',  HEXADECIMAL
:MACHINE1:SLIST:COLUMN 2, 'DATA1', HEXADECIMAL
:MACHINE1:SLIST:COLUMN 3, 'DATA2', HEXADECIMAL
:MACHINE1:SLIST:COLUMN 4, 'BULK',  BINARY
:MACHINE1:SWAVEFORM:REMOVE
:MACHINE1:SWAVEFORM:INSERT 'ADDR', OVERLAY
:MACHINE1:SWAVEFORM:INSERT 'DATA1', OVERLAY
:MACHINE1:SWAVEFORM:INSERT 'DATA2', OVERLAY
:MACHINE1:SWAVEFORM:INSERT 'BULK', OVERLAY
:MENU 1,7

Doing something like this is handy because you can configure the instrument quickly, without needing to save the large-ish configuration files. However, the configuration files are nice because you can save them as the autoload configuration for the machine once you are in the throes of some measurements. I recommend to write a program like this for configuration until you are happy with the ways the triggers are set- this is a lot easier to debug than running around in the menus in the UI. Once you are happy, then you should save it as the configuration file and set as autoload for the analyzer. You can also use this command parser socket to start the remote X11 session as I’ll touch on later.

X11 remote session

This was primarily the reason I was interested in picking up the HP1670D, after the LAN features. Supposedly, you can open an X11 server on your local machine, and then use the HP1670D to send a remote window- which comes with mouse and keyboard passthrough- to control the instrument over the network.

And it’s not just supposed! I was able to control the analyzer over the network from my laptop (made in 2021!). The fact that these computers are interoperable over a span of 35 years is really amazing and a testament to the forward thinking of the engineers when they designed this equipment. I was really blown away the first time I opened it. Of course, there are some catches to setting this up the first few times and not everything will sail smoothly right away.

However, there are a few things you have to get right before it will work. Most of these are on the end of the computer you are using to access the analyzer.

Installing the fonts

For some reason, the analyzer uses a set of custom fonts, for some reason or another. Because of this, any menus where the keyboard or other input pop up, the connection (and instrument) will crash. There is a file stored at system/disk/hard/system/readme.txt that contains information about these fonts and how to install them, however most people in 2022 are not using Unix or MS DOS anymore, so the instructions are a bit useless.

The two fonts are lg165.bdf and sm165.bdf , stored in the same directory as the readme. You can use FTP to retrieve these (or grab them from my upload of the system directory at the end of the post). Once you have them on your computer, you can convert them to a font file that your computer can use and then leave them in a font directory that your X11 server can find. For Linux, this is pretty straightforward; you can put them where all the rest of your fonts are (at least if you’re still on X- I don’t know how Wayland handles X servers/windows and the fonts used in them). I am on Mac lately- so I am using XQuartz as my X server- which has it’s own fonts directory. On Unix based systems, there is an easy way to convert these fonts- you can just use the system utility bdftopcf to convert them to the pcf font files you would normally use; you can then leave them in the fonts directory.

Allowing connections from network clients

I feel like I was able to do this easy-mode because I am on Mac- but it was not too bad. Within XQuartz, in the preferences there is an option for allowing network clients to connect. However; the analyzer does not have any way to provide the access-control keys needed for a secure connection. This does not really matter though since we are only operating the analyzer over the local network and the traffic is not exposed to the internet (I am not a security wizard and I am not worried about people intercepting this data, but I may be wrong about the safety of this method).

After enabling network connections, you have to add the analyzer to the list of X hosts that are allowed to open windows on the server:

+xhost 
+xhost 192.168.1.200

You can use the first one to allow any X client on the network to open a window (“screen”) on your X server. The second option allows a client with the specific address to open windows; this is more secure. If you have added the analyzer to your hosts table, you can use the hostname instead of the IP address. You do have to run this xhost command every time after restarting the X server, unless you add this to your startup configuration files.

Opening the X screen over the network

Once the network connections are ironed out and allowed, you should be able to open the window on your computer by selecting “Connect” from the system IO menu on the XWindow controls on the analyzer (make sure you set the IP of the desired system on the analyzer, or else it won’t know where to open the window.) If this doesn’t work, then you did something wrong.

If it does work, then you can also play with opening the X window over the network, so that you don’t need to be next to the analyzer to control it. You can do this by sending an xwin request to the command parser socket:

xwin on,'<IP address of the computer to display the window on>:0.0'

You can send this over telnet or you can include it in a program that you upload via FTP to the analyzer. You would send this command to the ‘program’ file that we used earlier to communicate with the instrument. I saved this line as a small file (named startx) that I just send over to the analyzer whenever I need to see what is happening on the screen:

ftp > put startx /system/program

Upgrading the internal hard drive

The hard drive shipped with this era of HP analyzers is a 3.5″ PATA Quantum series drive. For the 1670D; the drive is 500MB- which is generally plenty enough space. Some of the largest records I have collected on here come to about 30MB or so, which makes removing them via floppy impossible but still feasible across the network. However, it’s an old drive, very loud, high power consumption, and prone to failure soon; seeing as it’s now coming up on 35 years old. Something nice about PATA interface drives is that you can modernize them relatively easily via upgrading to a compactflash drive- the small(ish) ones used in some older cameras. These are cheap and easy to get, solid state, and use much less power with no sound at all. You can get interface cards to hook them up to the 40 pin IDE cables, and then you just need a power cable adapter to be good to go. This was inspired by a post I saw on the internet.

A constraint of the operating system used on the HP1670 series analyzers means that you are limited to a maximum drive size of 2GB. So; you can’t go higher than this; but again why would you want to? The data is useless on the analyzer and it’s always going to be better to pull it off and do post processing on a modern computer- the acquisition is the only thing the HP can do better than the other tools around us.

I picked up a PATA to CF adapter off Amazon ($8 at time of writing) and then just used a CF card I had picked up from Goodwill a few years ago. For the power connector, I just clipped one from an old computer I had- the power connector inside the HP has a sort of ‘push’ and slice way that you can just add wires into the connector without soldering or anything like this. However I will note- the pinout may not be standard. I just had matched the coloring of the wires – yellow to yellow and red to red, with matching grounds- and promptly smoked the first CF card that I put in (swapped +5V and +12V rails, who would imagine!). The recommendation here is to use a meter to confirm that you are wiring any connector correctly, even if you just buy one- the HP may not be standard, I don’t know. After booting, you can format the card, reboot and should pass the hard disk check on startup. I did try at first with a larger 4GB card, but like mentioned above- it sees the drive but formatting will fail- it can’t properly map and use any disk larger than 2GB.

The new drive boots much faster and has given me a much smoother experience in using the analyzer. I would recommend that for the cost, you should do this upgrade even if you only use the analyzer once or twice a year.

Cable and pod pinout

Taken from an accessory manual (01650-63203). Note that there are two (?) clocks on each cable- although, when put into the flying probe adapter, the pins on both ends are not used. The ground lead is attached for the signal ground of clock 2 (ground lead is single ended). I am not sure what the second clock would be used for- you can only configure one clock per pod in the software.

Note that there is available a 5V power supply on the cable. The manual notes that the maximum current deliverable is 330mA per cable (between both 5V supplies). The manual recommends to not connect this to the system. If you do connect it, I would probably recommend that you implement a current limiting circuit in order to prevent wrecking your cables- they are more expensive than the instrument at this point.

When I picked up the 1670D it came with 10 of these adapters so that you can just plug in the cable to the system under test via a 2×5 connector. I like these a lot; although if you aren’t the one designing the board this will almost never be useful to you. I did make a Kicad footprint and symbol for this for use in schematics, and found an appropriate through hole, right angle, and surface mount version of a connector you can use as a receptacle for this probe.

System Files

Here is a zipped folder of all the files that you should put in the system/disk/hard/system folder on the analyzer. This includes a few inverse assemblers and OMF utilities, the Symbol utility, full self tests, and a few other things that I am not totally sure about (system.map?). Make sure to retain the folder hierarchy as you move the files over- you can use mget and mput to receive/send multiple files over FTP at once, but I found that doing this often times caused the action to fail or produce corrupted info. FTP also does not work with moving over directories- you need to move the files over one by one. You can create new directories on the analyzer over ftp with the mkdir command. I would recommend to move them over one by one, as boring as that is. I recommend to just burn the attached image to a disk and use that. I had problems with the state compare and self test functionality after copying over just the files.

I will try have got an image dump of my 2GB drive so that you can just flash a new CF card with that and not have to worry about moving files over, but the folder I include here could be helpful if you just needed to repair one file or something.