HP8590E Series Option 103 Driver - Page 1
Forum section: electronics / testgear

author: Miti
author_rank: Super Contributor
timestamp: February 17, 2019, 11:38:52 pm
content: Does anybody have a card with the quasi-peak driver, option 103 for HP8590E series? I have the board but the driver doesn't seem to be installed. I've checked evilbay and the cheapest is $120 plus shipping. I understand that it is one time load and then is there so I could install it and return it, if I can find a good samaritan... I pay two way shipping.I have options 101, 102 and 130 as well. I don't think these options need drivers, do you know?I can't find manuals for them anyway. Option 103 has its own manual.Thanks,Miti

author: Miti
author_rank: Super Contributor
timestamp: February 18, 2019, 03:24:16 am
content: I was looking for EMC menus and apparently I need EMC measurements personality for that. So I'll need the EMC personality measurements card as well. Anyone? Pleaaase?

author: MarkL
author_rank: Unknown
timestamp: February 18, 2019, 02:39:16 pm
content: The EMC card comes with the QPD driver, so you don't need both.I unfortunately don't have the EMC card, but you might find this thread interesting:https://www.eevblog.com/forum/testgear/hacking-old-hp-spectrum-analyzers/msg421596/#msg421596In it, the QPD and EMC drivers were extracted from a 8591E that had the EMC personality loaded, but no longer had the EMC card. A series of GPIB commands were created so that the drivers could be reloaded into another SA when the QPD option card was moved. (I should point out in all that mess there is a gpib command "USTATE" that should make the procedure much simpler to dump and restore between SAs, but I couldn't get it to work. I still think I was doing something wrong, and eventually ended up doing it a much harder way.)You're right the QPD is a one-time load, but the EMC drivers need the physical card so it can load the various limit line profiles when selected by the user. You can still use the EMC functions without the card if you want to re-create whatever limit line profiles you need. It's not difficult; just tedious.Options 101, 102 and 130 don't need drivers. Documentation for them (and some of 103) is scattered around the User Guide.Option 103 already does the same AM/FM demod as 102, so you don't really need 102 unless you want the TV sync trigger.

author: Miti
author_rank: Super Contributor
timestamp: February 18, 2019, 10:44:41 pm
content: Thanks MarkL,That looks interesting... and complicated. I will need some time to digest it.Do you know the HP part number for the EMC card? I just want to see if I can find it anywhere and how much it costs.About Options 102 and 103, that's what I thought too. 102, I have the board but is not installed as I don't think I'll ever work in TVs, 103 is installed.

author: MarkL
author_rank: Unknown
timestamp: February 18, 2019, 11:07:48 pm
content: The card is 85712 and it could be suffixed with A, B, C, or D, depending on the version, D being the latest.Keysight still has the user manuals available. This one is for the D version:http://www.keysight.com/upload/cmc_upload/All/85712-90015.pdf

author: Miti
author_rank: Super Contributor
timestamp: February 23, 2019, 03:12:27 pm
content: Mark,What do you use to communicate with the instrument to extract/upload all those files? Hardware and software. Do you still have all the separate files extracted from your 8591e? I think the attachment that you posted in that thread is a full dump and not separate files.Thanks,Miti

author: MarkL
author_rank: Unknown
timestamp: February 23, 2019, 04:22:42 pm
content: It's an ancient AMD64 system running Fedora 11 with a National Instruments PCI-GPIB card. linux-gpib-3.2.20 is driving it.Yes, one of the postings in that thread is an SRAM image. Probably not of much use. Take a look here for the individual files for the GPIB commands (gpib-dlp-poc.tgz):https://www.eevblog.com/forum/testgear/hacking-old-hp-spectrum-analyzers/msg1029801/#msg1029801There's also a copy of the USTATE command output in the file ustate.sp2 (in the tar file) if you want to give that a try first. It would certainly be much simpler if you can get it to work. If you spot any kind of an error I made in creating the USTATE output, please let me know and I can try to fix it and re-dump it.If that doesn't work, there's a bash script called "do_cmds" which goes through all the data extracted from the analyzer and submits about 450 GPIB commands (or so) to rebuild the menus and everything else that was in the analyzer's memory, which includes the QPD and EMC drivers.

author: Miti
author_rank: Super Contributor
timestamp: February 27, 2019, 11:38:54 pm
content: Thanks Mark!To my shame, I don't have a single Linux machine but I do have an NI PCI-GPIB card installed in my Win machine. I am, however, in process of installing Linux Mint Cinnamon, I read very good things about it. I hope linux-gpib-3.2.20 works on it.My worry is.............Do you think I could mess up my instrument?I understand you pulled these files from HP8591E. I have an HP8594E. Are they compatible from this point of view? Can it overwrite some other functions/files if I make any mistake?NOOB questions....

author: MarkL
author_rank: Unknown
timestamp: February 28, 2019, 04:08:21 pm
content: Quote from: Miti on February 27, 2019, 11:38:54 pmNo Problem! You should probably go for the latest which is 4.2.0:https://sourceforge.net/projects/linux-gpib/The version I have is quite old and probably doesn't have support for more recent kernels.QuoteThere's nothing in the set of commands that will mess up your unit. That's correct I extracted them from a 8591E. I used the scripts to re-install the drivers on a 8595E, so it works across models. The worst that can happen is that it will overwrite any keydefs or other variables by the same names, but that seems unlikely.Not that the scripts touch them (if it's even possible), but hopefully you've backed up your cal constants anyway, just as standard operating procedure for theses aging SAs.

author: Miti
author_rank: Super Contributor
timestamp: March 09, 2019, 02:33:59 pm
content: Well, I have the machine, I have the GPIB software, I have the will but that's about all.I can't seem to find a step by step guide with commands on how to install everything.I'm a Win man trying to chew some mint with cinnamon. I'll have to get used to the flavour.Do I dare asking you for a guide?

author: MarkL
author_rank: Unknown
timestamp: March 09, 2019, 03:00:22 pm
content: Not sure I have enough time to write a guide, but I'm happy to step you through it.Where should we start? Do you have Mint installed? How about the Linux GPIB driver?

author: Miti
author_rank: Super Contributor
timestamp: March 10, 2019, 03:06:14 am
content: Linux Mint 19.1 Cinnamon is installed, the driver is not. Driver manager shows "No proprietary drivers are in use".

author: MarkL
author_rank: Unknown
timestamp: March 11, 2019, 10:24:00 pm
content: I've downloaded Linux Mint and I'm going to install it into a VM.It looks like someone has put the GPIB drivers in this Mint repository:https://community.linuxmint.com/software/view/gpib-modules-sourceI've honestly never used Mint before, but you could give that link a try.Give me a day or two to get Mint installed and I'm sure I can be a bit more informative. (Not to say Mint is the wrong choice. I think it's a great choice but I just don't have any experience with it.)

author: Miti
author_rank: Super Contributor
timestamp: March 12, 2019, 02:22:35 am
content: Mark,I can't ask you to make that effort for me. If you think it has any value for you, please do it, if not...Every time I tried to play with Linux, I hated it, something didn't work for me or it was too cumbersome. I'm a Win guy and I don't think that's gonna change.About the link that you recommended, I get this (attached).Probably it requires registration.

author: MarkL
author_rank: Unknown
timestamp: March 16, 2019, 08:45:41 pm
content: Well, if you're used to "click on this thing to install", you're not going to like this post. Below are my notes on how I installed it from source. The whole package may be sitting in a repository somewhere in easy-to-use click-on-it format, but I'm unfamiliar with the Mint world. Anyone is welcome to jump in to point it out.I'm certain I'm not representing Mint and other recent distributions very well at all. Try not to hate Linux too much based on how I do things (read: entrenched in old ways).First, a caveat: After several attempts, I did manage to install Mint 19.1 inside a VirtualBox VM. So, I can get everything to build and install, but I can't verify it working with an actual NI or other card.You'll need the latest source package (4.2.0) from here:http://sourceforge.net/projects/linux-gpibEverything is done from a terminal window. Here are my notes (step through it line by line; don't try to cut and paste the whole thing at once). Get this working first, and then we can go to the next step of the perl/bash scripts which do the actual dumping of the EMC/QPD drivers to the SA.Code:# Extract archive from sourceforge.#tar xf linux-gpib-4.2.0.tar.gz# Extract the two archives inside the archive# (thats just the way they packaged it)#cd linux-gpib-4.2.0tar xf linux-gpib-kernel-4.2.0.tar.gztar xf linux-gpib-user-4.2.0.tar.gz# Need this package before we get started...#sudo apt install libelf-dev# Build and install the kernel modules#cd linux-gpib-kernel-4.2.0./configuremakesudo make install# Build and install the user libraries#cd ../linux-gpib-user-4.2.0./configuremakesudo make install# Do a bunch of things as root...#sudo bash# Put 2 lines in the library search path#echo /usr/local/lib > /etc/ld.so.conf.d/local.confecho /usr/local/lib64 >> /etc/ld.so.conf.d/local.confldconfig# Load the kernel driver for the card. If it's the NI PCI-GPIB,# the driver is tnt4882. If you're using something else the list is# (probably) in /lib/modules/4.15.0-20-generic/gpib.#modprobe tnt4882# Check that it loaded. Not exactly sure what this version prints# out but you should see some statements from the NI driver in the# kernel log.#dmesg | tail -30# Start with the supplied template and configure your card. The# default in the template is the ni_pci card, so you might not need# to do anything.## System default editor is xed, but anything is fine.#cp util/templates/gpib.conf /etcxed /etc/gpib.conf &# Now you should be able to initialize the card. chmod sets# global rw permission on the gpib interface. Be more restrictive# if you want.#/usr/local/sbin/gpib_config --minor 0chmod a+rw /dev/gpib*# Check for more kernel messages as a result of the gpib_config.# There shouldn't be any errors.#dmesg | tail -30exit # get out of root shell# At this point you should have a working gpib installation.# Try to talk to the SA with the ibterm utility. My 8595E is set# to address 18.#ibterm -d 18# Example output:## Attempting to open /dev/gpib0# pad = 18, sad = 0, timeout = 10, send_eoi = 1, eos_mode = 0x0000# ibterm>*id# HP8595E# ibterm># ibterm: Done.

author: Miti
author_rank: Super Contributor
timestamp: March 17, 2019, 12:22:51 pm
content: Thanks Mark!Where should the two folders, "linux-gpib-kernel-4.2.0" and "linux-gpib-user-4.2.0", be located when I send all these commands? Can I leave them in the "Downloads" or I have to move them somewhere else? It doesn't seem to work directly from the Downloads folder.Also, do I have to be root?

author: Miti
author_rank: Super Contributor
timestamp: March 17, 2019, 12:43:46 pm
content: I guess part of it worked, even though I see some errors. Please see attached.Up to "cp util/templates/gpib.conf /etc" where it cannot find a directory.

author: MarkL
author_rank: Unknown
timestamp: March 17, 2019, 04:08:19 pm
content: You almost had it. There was a "cd\" that you entered right before the "sudo bash" that put you in the wrong directory.So, start in the directory "linux-gpib-user-4.2.0" and become root with the "sudo bash" command, if you're not already root. You can tell if you're root because the prompt will end with "#".Copy the supplied config file "gpib.conf" to the directory "/etc" with:cp util/templates/gpib.conf /etcAnd pick up from there.The answer to your previous question is it doesn't matter where you do all this. If you untar the archive in the Downloads directory, that's fine. If you were going to use Linux for the longer term, you would organize your sources under one directory, like /usr/local/src, but I wasn't going to get into the extra detail of system admin here. The goal is to get the GPIB working.And the other question, you do have to be root for some things. You generally want to minimize those operations to only what's absolutely necessary, like installation. You can do all the builds as a regular user."sudo CMD" does CMD as root, and "sudo bash" gives you a shell so you can do a bunch of things in a row as root. You can use "exit" or ctrl-D to exit the root shell.

author: Miti
author_rank: Super Contributor
timestamp: March 17, 2019, 08:04:16 pm
content: Hat off Mark!I have it working...

author: MarkL
author_rank: Unknown
timestamp: March 17, 2019, 08:51:12 pm
content: One thing you should be aware of is that the gpib drivers are not loaded and initialized automatically on boot. Each time you will need to do:sudo bashmodprobe tnt4882# wait a few seconds here/usr/local/sbin/gpib_config --minor 0exitOne you get everything working manually, you can put the gpib startup commands in the file /etc/rc.local, which is executed each time the system boots:Code:sudo bash# You can cut and paste the following, from the "cat" up to the# "chmod". Note this wipes out any previous content in /etc/rc.local,# but this file doesn't exist in a fresh Mint install. Use a text editor# for future changes to it.#cat << EOF > /etc/rc.local#!/bin/shexec > /tmp/rc.local.log 2>&1echo "Loading gpib driver (configuring in 5 seconds)..."modprobe tnt4882(sleep 5echo "Configuring gpib driver..."/usr/local/sbin/gpib_config --minor 0chmod a+rw /dev/gpib*) &EOFchmod +x /etc/rc.localexitThe output from the gpib initialization (and any other commands you add in /etc/rc.local) will be placed in /tmp/rc.local.log. If the gpib driver is not loading on boot, look in /tmp/rc.local.log for clues. And you can always try loading it manually as per the above.(Before anyone says it, I already know /etc/rc.local is an antiquated way. It works just fine in this situation.)

author: Miti
author_rank: Super Contributor
timestamp: March 17, 2019, 10:53:14 pm
content: Ok, I did and it works, I can send commands right after Mint starts.Now I'm ready for the next step of the perl/bash scripts, but before that, Is there a way to backup everything that's in my SA just in case something goes wrong?

author: MarkL
author_rank: Unknown
timestamp: March 18, 2019, 04:48:25 pm
content: Before you do anything, if you haven't done it already, backup up your calibration constants. I posted recently about it here:https://www.eevblog.com/forum/testgear/hp-8594e-spectrum-analyzer-at-last-i-own-a-decent-spec-an/msg2140066/#msg2140066As for what might already be in memory, you can press RECALL --> Catalog Internal --> CATALOG ALL to show what DLPs (programs) and variables are in there. CATALOG REGISTER will show states and traces, and CATALOG ON EVENT will show event commands.You can also do the same thing via ibterm. Below is an example of what ibterm returns on an empty 8595E. To check for the same things you need to examine prefixes "*", "on*", and "reg*" (this is all described in the programmer guide).Code:ibterm -d 19Attempting to open /dev/gpib0pad = 19, sad = 0, timeout = 10, send_eoi = 1, eos_mode = 0x0000ibterm>cat *INTERNAL: 6994 238070ibterm>cat on*ON EVENTS:ONEOS UNDEFINEDONSWP UNDEFINEDTRMATH UNDEFINEDONCYCLE UNDEFINEDONDELAY UNDEFINEDONMKR UNDEFINEDONSRQ UNDEFINEDONTIME UNDEFINEDONPWRUP UNDEFINEDibterm>cat reg*ST/TR REG:ST1 UNUSEDST2 UNUSEDST3 UNUSEDST4 UNUSEDST5 UNUSEDST6 UNUSEDST7 UNUSEDST8 UNUSEDTR0 UNUSEDTR1 UNUSEDTR2 UNUSEDTR3 UNUSEDTR4 UNUSEDTR5 UNUSEDTR6 UNUSEDTR7 UNUSEDTR8 UNUSEDTR9 UNUSEDTR10 UNUSEDTR11 UNUSEDTR12 UNUSEDTR13 UNUSEDTR14 UNUSEDTR15 UNUSEDTR16 UNUSEDTR17 UNUSEDTR18 UNUSEDTR19 UNUSEDTR20 UNUSEDTR21 UNUSEDTR22 UNUSEDTR23 UNUSEDTR24 UNUSEDTR25 UNUSEDTR26 UNUSEDTR27 UNUSEDTR28 UNUSEDTR29 UNUSEDTR30 UNUSEDTR31 UNUSEDTR32 UNUSEDTR33 UNUSEDTR34 UNUSEDTR35 UNUSEDTR36 UNUSEDTR37 UNUSEDTR38 UNUSEDTR39 UNUSEDTR40 UNUSEDTR41 UNUSEDTR42 UNUSEDTR43 UNUSEDTR44 UNUSEDTR45 UNUSEDTR46 UNUSEDTR47 UNUSEDTR48 UNUSEDTR49 UNUSEDTR50 UNUSEDTR51 UNUSEDTR52 UNUSEDibterm>It's normal to have some "ST" or "TR" entries. It only means someone in the past stored the SA state or trace data. If you have a bunch of stuff returned from the "*" prefix, someone might have loaded a driver. Or less common, if there a few entries someone may have written their own DLPs for it.I will followup with the perl stuff.

author: MarkL
author_rank: Unknown
timestamp: March 18, 2019, 07:20:48 pm
content: Ok, so far so good. Here are my notes on the perl pieces, again in pseudo cut and paste format.I'll repeat my caveat that I'm not able to try everything on a Mint installation since it's only running in a VM with no access to real gpib hardware. It works up until the point where it actually has to talk to the SA. My notes after that are taken from an older Linux installation running Fedora 11 with an NI PCI-GPIB, but running the exact same perl scripts presented here.Code:# It seems that the perl bindings are not installed by default.# Go back and do them.#cd linux-gpib-user-4.2.0/language/perlmakesudo make install# Add the home/bin directory to the search path permanently,# and create a bin directory to use.#echo 'export PATH='~/bin:'$PATH' >> ~/.bashrc. ~/.bashrcmkdir ~/bin# Go get the rest of the scripts.#cd ~/Downloadswget http://www.employees.org/~markl/gpib-perl-v0.3b.tgzwget http://www.employees.org/~markl/gpib-dlp-poc.tgz# Extract them both...#tar xf gpib-perl-v0.3b.tgztar xf gpib-dlp-poc.tgz# Move only what we need into the new bin directory. There's a lot# of other stuff in the archive. Explore and use later, if you want.#cd gpib-perl-v0.3b/binmv gpib gpib-lab-lib.pl sp spq ~/bin# Do some stuff as root...#sudo bash# The gpib installer, by default, puts the gpib configuration file in# /usr/local/etc/gpib.conf, and not /etc/gpib.conf, where I had you# put it. Nothing looks at /etc/gpib.conf. Get rid of it.#rm /etc/gpib.conf# Append the SA configuration to the real gpib.conf. If your SA is# not address 18, you'll want to adjust this. You can also use a text# editor to add these lines.#cat << EOF > /usr/local/etc/gpib.conf/* HP 8595E */device {name = "sp"minor = 0pad = 18eos = 0x0atimeout = T30s /* needed for slow print response */}EOF# Leave root...#exit# At this point perl programs should be able to talk to the SA.# Try this:#spq "*id"# You should get the same response as ibterm:## HP8595E## If not, stop here. The next step will not work.## If ok, you should be able to dump the EMC/QPD driver to the SA.#cd ~/Downloads/gpib-dlp-poc./do_cmds# Long output here, and it will take a minute or two, but that should be it.# The SA should now have a copy of the EMC and QPD drivers.## "do_cmds" checks for errors after each command submitted to the SA. If you# see any errors, something didn't work, and some part of the drivers will# be incomplete and not work even though there may now be menu buttons for# them.#I've attached the output from the "do_cmds" script, as well as a couple of before and after screen shots of what you should see. This was done to an 8595E that had it's memory wiped via CONFIG --> Dispose User Mem.

author: Miti
author_rank: Super Contributor
timestamp: March 18, 2019, 11:54:33 pm
content: Something didn't go wellCode:miti@miti-System-Product-Name:~$ ibterm -d 18Attempting to open /dev/gpib0pad = 18, sad = 0, timeout = 10, send_eoi = 1, eos_mode = 0x0000libgpib: ibBoardOpen failed to open device filelibgpib: No such file or directorylibgpib: error in is_cic()!ibterm error: open failed- EDVR 0: OS erroribdev erroribterm: Abortedmiti@miti-System-Product-Name:~$ spq "*id"libgpib: ibBoardOpen failed to open device filelibgpib: No such file or directorylibgpib: error in is_cic()!libgpib: ibfind failed to get descriptorexit value cannot find gpib device "sp" at /home/miti/bin/gpib-lab-lib.pl line 405.miti@miti-System-Product-Name:~$

author: Miti
author_rank: Super Contributor
timestamp: March 19, 2019, 01:19:05 am
content: Ok, I fixed it. Apparently cat command overwrites the conf file. I copied it again and ibterm works.Code:miti@miti-System-Product-Name:~$ ibterm -d 18Attempting to open /dev/gpib0pad = 18, sad = 0, timeout = 10, send_eoi = 1, eos_mode = 0x0000ibterm>*idHP8594Eibterm>ibterm>cat *ibterm>cat*INTERNAL: 4830 238062C_ONLV 34ibterm>cat on*ON EVENTS:ONEOS UNDEFINEDONSWP UNDEFINEDTRMATH UNDEFINEDONCYCLE UNDEFINEDONDELAY UNDEFINEDONMKR UNDEFINEDONSRQ UNDEFINEDONTIME UNDEFINEDONPWRUP UNDEFINEDibterm>cat reg*ST/TR REG:ST1 CF: 1.65 GHz SP: 10.00 kHzST2 CF: 1.65 GHz SP: 20.00 kHzST3 CF: 1.45 GHz SP: 2.900 GHzST4 CF: 1.45 GHz SP: 2.900 GHzST5 CF: 1.45 GHz SP: 2.900 GHzST6 CF: 1.45 GHz SP: 2.900 GHzST7 CF: 1.63 GHz SP: 10.00 kHzST8 CF: 1.45 GHz SP: 2.900 GHzTR0 TL: 07:55:52 FEB 23, 1999TR1 TL: 17:34:55 SEP 14, 2001 17:36:57 SEP 14, 2TR2 TL: 17:34:55 SEP 14, 2001 17:36:57 SEP 14, 2TR3 TL: 07:55:53 FEB 23, 1999TR4 TL: 07:55:53 FEB 23, 1999TR5 TL: 07:55:53 FEB 23, 1999TR6 TL: 07:55:53 FEB 23, 1999TR7 TL: 07:55:53 FEB 23, 1999TR8 TL: 07:55:53 FEB 23, 1999TR9 TL: 07:55:53 FEB 23, 1999TR10 TL: 07:55:53 FEB 23, 1999TR11 TL: 07:55:53 FEB 23, 1999TR12 TL: 07:55:54 FEB 23, 1999TR13 TL: 07:55:54 FEB 23, 1999TR14 TL: 07:55:54 FEB 23, 1999TR15 TL: 07:55:54 FEB 23, 1999TR16 TL: 07:55:54 FEB 23, 1999TR17 TL: 07:55:54 FEB 23, 1999TR18 TL: 07:55:54 FEB 23, 1999TR19 TL: 07:55:55 FEB 23, 1999TR20 TL: 07:55:55 FEB 23, 1999TR21 TL: 07:55:55 FEB 23, 1999TR22 TL: 07:55:55 FEB 23, 1999TR23 TL: 07:55:55 FEB 23, 1999TR24 TL: 07:55:55 FEB 23, 1999TR25 TL: 07:55:55 FEB 23, 1999TR26 TL: 07:55:55 FEB 23, 1999TR27 TL: 07:55:56 FEB 23, 1999TR28 TL: 07:55:56 FEB 23, 1999TR29 TL: 07:55:56 FEB 23, 1999TR30 TL: 07:55:56 FEB 23, 1999TR31 TL: 07:55:56 FEB 23, 1999TR32 TL: 07:55:56 FEB 23, 1999TR33 TL: 07:55:56 FEB 23, 1999TR34 TL: 07:55:56 FEB 23, 1999TR35 TL: 07:55:56 FEB 23, 1999TR36 TL: 07:55:57 FEB 23, 1999TR37 TL: 07:55:57 FEB 23, 1999TR38 TL: 07:55:57 FEB 23, 1999TR39 TL: 07:55:57 FEB 23, 1999TR40 TL: 07:55:57 FEB 23, 1999TR41 TL: 07:55:57 FEB 23, 1999TR42 TL: 07:55:57 FEB 23, 1999TR43 TL: 07:55:57 FEB 23, 1999TR44 TL: 07:55:57 FEB 23, 1999TR45 TL: 07:55:58 FEB 23, 1999TR46 TL: 07:55:58 FEB 23, 1999TR47 TL: 07:55:58 FEB 23, 1999TR48 TL: 07:55:58 FEB 23, 1999TR49 TL: 07:55:58 FEB 23, 1999TR50 TL: 07:55:58 FEB 23, 1999TR51 TL: 07:55:58 FEB 23, 1999TR52 TL: 07:55:ibterm>ibterm: Done.miti@miti-System-Product-Name:~$ spq "*id"exit value cannot find gpib device "sp" at /home/miti/bin/gpib-lab-lib.pl line 405.miti@miti-System-Product-Name:~$Perl doesn't work though.

author: MarkL
author_rank: Unknown
timestamp: March 19, 2019, 01:41:03 am
content: Oops sorry about that. Glad you figured it out. Cut and paste from the VM is not working, so a lot of that is re-typed. I made a mistake on the cat. It should be >> to append (a single > overwrites):cat << EOF >> /usr/local/etc/gpib.conf/* HP 8595E */device {name = "sp"minor = 0pad = 18eos = 0x0atimeout = T30s /* needed for slow print response */}EOFI think you're close. The error you're getting is that the perl script doesn't know what device "sp" is. The above defines it.It doesn't look like you have anything to speak of in memory. You have a variable C_ONLV which is also in the EMC/QPD drivers and is 1.11654114713E3. I don't see anything in the package that uses it, but do_cmds is going to set it.

author: Miti
author_rank: Super Contributor
timestamp: March 19, 2019, 01:42:08 am
content: I edited the conf file manually and I have communication. It doesn't work, however. Please see attached.

author: MarkL
author_rank: Unknown
timestamp: March 19, 2019, 01:54:26 am
content: Ok, add your current directory to the search path:echo 'export PATH='.:'$PATH' >> ~/.bashrc. ~/.bashrcThat's why it can't find "parse_a". Try ./do_cmds again.I don't know what's going on with the error check. I'll have to look at this tomorrow. I think some characters might not be getting printed. What is the output of:spq CMDERRQ | xxd -g 1

author: Miti
author_rank: Super Contributor
timestamp: March 19, 2019, 01:57:10 am
content: Quote from: MarkL on March 19, 2019, 01:54:26 amIt is:00000000: 0d 0a ..

author: MarkL
author_rank: Unknown
timestamp: March 19, 2019, 02:08:54 am
content: I think it should be working, but the error check is failing maybe due to some changed behavior in the new version of bash.Edit do_cmds and change this line near the top:if [ "$res" != $'\x0d' ]; thento this:if [ ! \( "$res" == $'\x0d' -o "$res" == $'\x0d'$'\x0a' \) ]; then

author: Miti
author_rank: Super Contributor
timestamp: March 19, 2019, 02:18:31 am
content: I changed the line and still fails. Perl_new is after changing the line.

author: MarkL
author_rank: Unknown
timestamp: March 19, 2019, 02:29:48 am
content: All kinds of old syntax...In parse_a, change this:shift $[$OPTIND-1]To:shift $((OPTIND - 1))Looks like the forum made a total mess out of my other fix. Maybe you caught it. The line is supposed to be:Code:if [ ! \( "$res" == $'\x0d' -o "$res" == $'\x0d'$'\x0a' \) ]; thenthe "code" tag seems to preserve the backslashes.

author: MarkL
author_rank: Unknown
timestamp: March 19, 2019, 02:36:30 am
content: And in parse_a get rid of these two lines near the top:Code:# default options always givenargs[i++]="-l"I apologize for all the old junk in these scripts.

author: Miti
author_rank: Super Contributor
timestamp: March 19, 2019, 02:43:32 am
content: I getCode:miti@miti-System-Product-Name:~$ cd ~/Downloads/gpib-dlp-pocmiti@miti-System-Product-Name:~/Downloads/gpib-dlp-poc$ ./do_cmds--- trdef Q_TRA (xfer) ---reading from stdinread 809 bytes./do_cmds: 9: [: closing paren expected--- trdef Q_TRA (define,mov) ---./do_cmds: 9: [: closing paren expected--- trdef Q_TRB (xfer) ---reading from stdinread 809 bytes./do_cmds: 9: [: closing paren expected--- trdef Q_TRB (define,mov) ---./do_cmds: 9: [: closing paren expected--- trdef Q_TRC (xfer) ---reading from stdinread 809 bytes./do_cmds: 9: [: closing paren expected--- trdef Q_TRC (define,mov) ---./do_cmds: 9: [: closing paren expected--- trdef _ONE (xfer) ---reading from stdinread 809 bytes./do_cmds: 9: [: closing paren expected--- trdef _ONE (define,mov) ---./do_cmds: 9: [: closing paren expected--- vardef _ADF ---./do_cmds: 9: [: closing paren expected--- vardef _AMPEND ---./do_cmds: 9: [: closing paren expected--- vardef _AT ---./do_cmds: 9: [: closing paren expected--- vardef _AUI ---./do_cmds: 9: [: closing paren expected--- vardef _AVAMP ---./do_cmds: 9: [: closing paren expected--- vardef _AVFRQ ---./do_cmds: 9: [: closing paren expected--- vardef _AVGF ---./do_cmds: 9: [: closing paren expected--- vardef _AVLIM ---./do_cmds: 9: [: closing paren expected--- vardef _AVLMF ---./do_cmds: 9: [: closing paren expected--- vardef _BOXIDF ---./do_cmds: 9: [: closing paren expected--- vardef _CHS ---./do_cmds: 9: [: closing paren expected--- vardef C_ONLV ---./do_cmds: 9: [: closing paren expected--- vardef _CPYRGTF ---./do_cmds: 9: [: closing paren expected--- vardef _DBNS ---./do_cmds: 9: [: closing paren expected--- vardef _DREF ---./do_cmds: 9: [: closing paren expected--- vardef _DSPAD ---./do_cmds: 9: [: closing paren expected--- vardef _DSPF ---./do_cmds: 9: [: closing paren expected--- vardef _FA ---./do_cmds: 9: [: closing paren expected--- vardef _FALG ---./do_cmds: 9: [: closing paren expected--- vardef _FASV ---./do_cmds: 9: [: closing paren expected--- vardef _FB ---./do_cmds: 9: [: closing paren expected--- vardef _FBLG ---./do_cmds: 9: [: closing paren expected--- vardef _FBSV ---./do_cmds: 9: [: closing paren expected--- vardef _FFAA ---./do_cmds: 9: [: closing paren expected

author: MarkL
author_rank: Unknown
timestamp: March 19, 2019, 02:53:04 am
content: Can you post the first 20 lines or so what you have in do_cmds?That should not be an error. I did try it.

author: Miti
author_rank: Super Contributor
timestamp: March 19, 2019, 02:56:38 am
content: Here they are:Code:#!/bin/shSP=spSPQ=spqcheck_err(){res=$($SPQ "CMDERRQ")if [ ! \( "$res" == $'\x0d' -o "$res" == $'\x0d'$'\x0a' \) ]; thenecho "********** CMDERRQ: $res **********"fi}### trdeftrdefs=$(cd var_a && grep -l '^#A' *)# echo trdefs $trdefsfor i in $trdefs; doecho "--- trdef $i (xfer) ---"# use trace C to transferecho -n "TRC" > tmpcat var_a/$i >> tmp$SP - < tmpcheck_errecho "--- trdef $i (define,mov) ---"$SP "TRDEF $i,401; MOV $i,TRC;"check_errdone

author: MarkL
author_rank: Unknown
timestamp: March 19, 2019, 03:06:30 am
content: This is rather strange.I didn't notice Mint (and maybe other recent distributions) are using dash for their system shell. The systems I have all use bash.So we better call for bash explicitly. On the first line of do_cmds and parse_a change "/bin/sh" to "/bin/bash". Then give it a shot.

author: Miti
author_rank: Super Contributor
timestamp: March 19, 2019, 03:12:43 am
content: It worked!!Thanks a lot Mark. Sorry to keep you awake so late...

author: MarkL
author_rank: Unknown
timestamp: March 19, 2019, 03:14:52 am
content: Great! Have fun with the EMC and QPD! And goodnight!

author: Miti
author_rank: Super Contributor
timestamp: March 19, 2019, 03:19:42 am
content: Quote from: MarkL on March 19, 2019, 03:14:52 amThanks, I will...Quote from: MarkL on March 19, 2019, 03:14:52 amAre you kidding me? Time to play...

author: Miti
author_rank: Super Contributor
timestamp: March 19, 2019, 10:58:42 pm
content: I wanted to post some pictures with my SA's newly added menus but then I thought, can I capture the screen from HP8594E through the GPIB? I think technically it should be possible but then, probably, this model may be too old for that.

author: MarkL
author_rank: Unknown
timestamp: March 20, 2019, 01:04:48 am
content: Quote from: Miti on March 19, 2019, 10:58:42 pmAbsolutely it can do screen captures. It's one of the main uses of GPIB even in old equipment.Now that Linux has done its work for you, you might want to go back to windows. There's a very nice package here that is popular:http://www.ke5fx.com/gpib/readme.htmIt supports your NI PCI-GPIB card.Of course I have my Linux way of doing it, if you want to experience some more crufty old code.

author: Miti
author_rank: Super Contributor
timestamp: March 21, 2019, 02:22:30 am
content: Excellent tool, thanks Mark!I played for half hour at work with an HP8591E and GPIB-USB-HS.I couldn't figure out how to take a screen shot though. Maybe I will play a bit more tomorrow if I have time.

author: Bicurico
author_rank: Super Contributor
timestamp: March 21, 2019, 04:57:33 am
content: https://vma-satellite.blogspot.com/2019/02/vma-simple-spectrum-analyser-version.htmlhttps://vma-satellite.blogspot.com/2019/03/vma-spectrum-analyser-for-hp-8590.htmlRegards,Vitor

author: MarkL
author_rank: Unknown
timestamp: March 21, 2019, 07:12:06 pm
content: Quote from: Miti on March 21, 2019, 02:22:30 amIt looks nice but windows only (although some people have had success running it in wine).It would appear that 7470.exe would do a "screen capture" for you. And I put that in quotes because the 8590 series and a lot of this older equipment emit HPGL, which is a vector drawing language where the original target was a plotter. 7470.exe interprets the HPGL commands and makes a raster image out of it.

author: Bicurico
author_rank: Super Contributor
timestamp: March 21, 2019, 09:03:38 pm
content: Hi MarkL,I have briefly looked at your scripts and what I understand is that you use some GPIB commands to list (CAT) the files and then transfer them back and forth.I was considering hacking a Windows tool to replicate this, so that I don't have to struggle with Linux, but I don't understand exactly how/what you are doing.Could you please elaborate on this:- how do you extract a file from RAM memory of the HP- how do you send a file- how do you know which files to copy/move- wouldn't it make sense to backup ALL files to PC, in order to be able to restore all of them in case the battery runs out? I could imagine writing a tool that does a CAT* and then extracts each file individually...Thanks!@Miti:From what I understand, spectrum analyzers don't send the whole screen over GPIB, they rather just send the samples that compose the current spectrum sweep. It is the local PC software that then mimics the screen based on this trace. At least that is what my software does (among other things). This means you won't get the menu items, etc.At this point I did not understand if the HPGL data is only output through the parallel port or if it can be read out over GPIB. That would be cool, as you could indeed, as already said, draw the vectors on a bitmap.Regards,Vitor

author: Bicurico
author_rank: Super Contributor
timestamp: March 21, 2019, 09:23:35 pm
content: I am just reading the Programmer's Guide.I seem to have understood that one can actually create programs inside the device memory, in order to carry out tasks - much like a macro.This can be associated to a soft-menu button!Cool stuff!And I now understand why it is better to have to script language, as each command of the macro is send as an individual GPIB command.Icould easilyam going towrite a small tool that uses the Keysight Connection Expert and sends the contents of text files containing such programs.This HP 5894E is a cool device...Regards,Vitor

author: MarkL
author_rank: Unknown
timestamp: March 21, 2019, 10:24:26 pm
content: Quote from: Bicurico on March 21, 2019, 09:03:38 pmTake a look at this post:https://www.eevblog.com/forum/testgear/hacking-old-hp-spectrum-analyzers/msg1021445/#msg1021445That describes how I extracted items out of the analyzer's memory. In that same thread, this post also points to a tar file:https://www.eevblog.com/forum/testgear/hacking-old-hp-spectrum-analyzers/msg1030583/#msg1030583If you haven't already done so, download it and take a look at the files in notes/. It has some additional explanations of the procedure.And yes, it would make sense to have a tool. As I've said in many posts, there is a command called "USTATE" that I was never able to get to work. It is supposed to do exactly what you want and create an archive of all the DLPs, KEYDEFs, traces, etc etc in the analyzer's memory. Maybe you can give it a try before heading down the much more difficult path that I took. The backup procedure with USTATE would be trivial if you can make it work.

author: Bicurico
author_rank: Super Contributor
timestamp: March 21, 2019, 10:35:39 pm
content: I have downloaded your TAR quite a while ago! Thanks, by the way!I played with the USTATE command and extracted everything using the Keysight Interactive IO to send the command and IO Monitor to actually capture the data.I imagine that this data needs to be treated as binary data (individual bytes).I will look into that.My question: how/when did you realize that the upload of the captured file did not work? I am asking because I obviously don't want to corrupt the memory of my unit...The manual says:"The contents of user memory can be restored by executing USTATE followed by the A-blockdata retrieved by a previous “USTATE?;” command."So this means that one needs to send the exact same data back, but how are the control characters dealt with?Again, the manual gives an example in HP Basic (or what ever that is):ENTER 718 USING "#,-K";User$"-K" allows control codes to be treated as characters.Attached is my dump.Regards,Vitor

author: MarkL
author_rank: Unknown
timestamp: March 22, 2019, 01:16:31 am
content: It does need to be 8-bit clean on both input and output, I know that much for sure.The first four bytes are "#A<LEN1><LEN0>" where LEN1 LEN0 form the 16-bit big-endian length of bytes to be read in by the analyzer (the so-called A-block format). The USTATE captures I've done always have valid lengths that match the length of the GPIB transfer, so I'm thinking it's something with the playback.When I playback the USTATE output, it dies almost immediately and starts reporting errors and other garbage in the title area on the screen. It doesn't get near reading in the majority of the data.I've done binary I/O with other devices with my GPIB scripts, so I'm fairly confident it's not the scripts. I haven't done the next step of clamping a logic analyzer on the GPIB interface to verify the exchange.I also haven't tried pacing the output going to the analyzer to slow it down, but I think that would be unnecessary since GPIB, by its very protocol, is a three-way handshake to prevent buffer overruns due to one side not being ready. But if anything, it might be useful to track down exactly where it dies.The USTATE capture you posted doesn't look valid to me. It doesn't have the #A header, and it seems to be lacking data in the range of 0x00-0x20 which I see a lot in the USTATE dumps I have. Something is probably not being 8-bit clean.

author: Bicurico
author_rank: Super Contributor
timestamp: March 23, 2019, 02:12:39 am
content: Hi,I made some progress: I added a new tab in my "VMA Simple Spectrum Analyser for HP/Agilent 8590 Series" software.I tried to make the backup/restore with USTATE command work, but ended up deleting the whole user memory...I have a backup, but when I try to upload it, I get a checksum error.On the bright side, I can do a catalog and I can upload files created on the built-in "editor". Save/Load is yet to be implemented.Also, I am figuring out how to write DLP and softmenu shortcuts. Wrote my first script to quickly set my favourite frequency ranges:Code:FUNCDEF C_ATV,@FA 100MHZ;FB 680MHZ;@;KEYDEF 1, C_ATV,%CATV BAND%;FUNCDEF D_VBT,@FA 742MHZ;FB 766MHZ;@;KEYDEF 2, D_VBT,%DVBT BAND%;FUNCDEF F_M,@FA 88MHZ;FB 108MHZ;@;KEYDEF 3, F_M,%FM BAND%;Uploading this will create three USER MENU entries, each calling a DLP that just sets start/end frequencies.Regarding my lost USER memory space: it contained what I imagine was some personality card with tools. There was for instance a tool to show the RAM battery location. It was just a picture.From my backup I can see the ASCII part with the DLP. I am not missing anything terribly important, but it would be great if I could restore that. Does anyone know what exactly this was? The backup is attached, but obviously it is not 100% OK.There were some calibration routines, CPU test routines, etc.Going to bed now...Regards,Vitor

author: Bicurico
author_rank: Super Contributor
timestamp: March 23, 2019, 10:08:57 am
content: Woke up and checked the MSB and LSB and they match the exact file size.One of the errors so far was that I forgot the final ;.But it still doesn't work. I think there is some final CrLf missing or similar. Transmission always leaves the device waiting for more bytes or gives a wrong checksum error.Had to leave for the day but I am still believing I might reload my backup to the device.Regards,Vitor

author: Miti
author_rank: Super Contributor
timestamp: March 23, 2019, 12:52:51 pm
content: I've "cat"in one .txt file all the instructions from Mark that helped me transfer the EMC personality into my HP8594E with option 103, using Linux Mint 19.1 Cinnamon and NI PCI-GPIB card. I've also attached the modified scripts that worked for me.Thanks for the effort Mark!Enjoy!

author: MarkL
author_rank: Unknown
timestamp: March 23, 2019, 02:40:43 pm
content: Quote from: Bicurico on March 23, 2019, 10:08:57 amThe USTATE you posted in the zip file does not appear to match in length. The length inside ustate.txt is 0x4ac2 == 19138, but the length of the file itself is 19711.I also get a CRC error when trying to load your file, and it wiped out my user memory.But looking at the contents of your file, I agree you haven't lost anything of consequence. It seems to be leftovers from some kind of semi-automated calibration and health checks for the SA itself. There's lots of unlocking of service level routines (CF-2001HZ), and I see a bunch of undocumented calibration commands. It's probably a good thing it didn't run.It's possible that buried in these undocumented commands is a way to automate backup of the calibration constants which, AFAIK, the only official way to back them up is to manually write them down.Also, in re-reading more about the USTATE command, it does not back up everything in user memry. It gets almost everything, but does not includes setups saved by the user (and maybe something else I've missed?). It only captures what's explicitly listed in the programmer manual.I was able to do a very simple test of clearing memory, setting a variable, dumping via USTATE, clearing memory, and restoring via USTATE. The variable came back correctly. So, this verifies with a reasonable amount of confidence that my GPIB scripts are working. I'm beginning to think that maybe something is just plain broken with USTATE, or maybe the problem is it doesn't work with DLPs or some other structures loaded from a card, perhaps on purpose.

author: MarkL
author_rank: Unknown
timestamp: March 23, 2019, 02:47:52 pm
content: Quote from: Miti on March 23, 2019, 12:52:51 pmThanks for consolidating all that!The biggest problem all along was that I didn't realize we were using the wrong shell in Mint. All those syntax errors would have been accepted by bash since it still recognizes the obsolete syntax. Cleaned up now the hard way, but live and learn!

author: Bicurico
author_rank: Super Contributor
timestamp: March 23, 2019, 10:05:46 pm
content: Quote from: MarkL on March 23, 2019, 02:40:43 pmOh dear! I hope you did not lose anything important...I have been playing further with the USTATE command and I am not able to make it work, even after downloading the current state with just 3 DLP and 3 KEYDEF.It seems to me that the 8590 is doing some control character transformations that are inconsistent with Keysight. Like CrLf to \n or "%" to ",".Also, it is strange that FUNCDEF sends a DLP with a certain syntax, but doing DLPNAME? returns that DLP with a slightly different header and footer (first 5 bytes need to be ignored and the closing ";" is missing).I decided to abandon the use of USTATE. I find it to be too dangerous: you wipe out the whole RAM in a split second and I am not even sure what could happen if you manage to upload a corrupt dump. I don't want to risk ending up corrupting the CAL data...So I implemented so far the CAT function that lists the catalog into a list box. Here you can select DLP or KEYDEF and download them into the built-in editor. The software restores the correct headers. You can then upload the file again or save it locally.I need to do the routines to download KEYMAP and variables (not sure what other filetypes I need to contemplate).Once that is done, there will be a button to download all supported filetypes into a local folder and another button to upload all files in the selected local folder.I think this is what you are doing with Python under Linux.Anyway, no more USTATE for me...Regards,Vitor

author: Bicurico
author_rank: Super Contributor
timestamp: March 23, 2019, 10:22:42 pm
content: Here is the "S_CAP" program, which I restored manually.Code:FUNCDEF S_CAP,@$;ANNOT OFF;GRAT OFF;BLANK TRA;CLRDSP;MN0;CSIZE 1,1;PU;PA; 200, 50;PD;PR;110,70;90,0;0,-70;-25,0;0,-15;25,0;0,-40;-200,0;0;55;PU;10,-50;TEXT%o%;PU;150,100;TEXT%o%;DRAWBOX 250, 35, 265, 25,5,5;CSIZE;PU;PA; 125, 135;PD;PR;55,0;70,-100;4,10;-4,-10;-15,5;PU;PA;120,200;TEXT%Verify Super-Cap Voltage%;PU;PA;120,190;TEXT%========================%;PU;PA;-10,170;TEXT%- Lift the edge of the shield on%;PU;PA;-10,160;TEXT% the memory board.%;PU;PA;-10,150;TEXT%- Touch the test fixture probe to%;PU;PA;-10,140;TEXT% the square pad of C1 on the%;PU;PA;-10,130;TEXT% memory board.%;PU;PA;-10,120;TEXT%- The LED in the%;PU;PA;-10,110;TEXT% test fixture must%;PU;PA;-10,100;TEXT% light for the board%;PU;PA;-10,90;TEXT% to PASS.%;PU;PA;-10,80;TEXT%- Press ENTER when done.%;HD;EP;MPRST;MN1;@;In only draws the pic of the memory board and shows where the testpoint is.The interesting part of the code are the non-documented commands on the end, which wait for the ENTER key to be pressed and return to regular spectrum mode.I am honestly fascinated by the fact that you have a whole script-language inside the 8590 Series. It even features a built-in editor and this is why there is a keyboard port!I am now realizing I should be posting this in the hacking old HP spectrum analyzer thread...Anyway, my conclusions so far are:1) Do NOT use the USTATE command to upload a dump! It will mess up user memory2) Do USE the USTATE? command, as you get an almost complete dump and you can use Notepad++ to extract the individual DLP files and restore themRegards,Vitor

author: MarkL
author_rank: Unknown
timestamp: March 23, 2019, 11:19:08 pm
content: I agree with your conclusion not to use USTATE. It's losing situation. I was not aware that if it failed it wiped out everything. That's pretty bad.I didn't lose anything important. The analyzer only had the EMC/QPD drivers loaded and I reloaded them in about a minute. I should probably verify my calibration constants with the paper backup after trying to load your USTATE.QuoteMore or less. I did it with Perl, but the implementation is not generalized enough to grab *everything* in memory. I had a very specific goal in mind, so things I could see that were not used in the EMC/QPD driver, like ONEVENTS, were not handled. The scripts are fairly well documented as to all the oddities I found in parsing and playing back the various definitions. You'll need to do the same.Yeah, let's take further discussion over to the hacking thread...https://www.eevblog.com/forum/testgear/hacking-old-hp-spectrum-analyzers/msg421596/#msg421596

author: Bicurico
author_rank: Super Contributor
timestamp: March 24, 2019, 06:34:20 pm
content: @Miti: Would you mind running my software to download your internal memory? This should generate one single text file with the whole EMC Personality...PM me if interested.Regards,Vitor