EEVblog Electronics Community Forum
Products => Test Equipment => Topic started by: Miti on February 17, 2019, 11:38:52 pm
-
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
-
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? ;D
-
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/#msg421596 (https://www.eevblog.com/forum/testgear/hacking-old-hp-spectrum-analyzers/msg421596/#msg421596)
In 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.
-
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.
-
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 (http://www.keysight.com/upload/cmc_upload/All/85712-90015.pdf)
-
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
-
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/#msg1029801 (https://www.eevblog.com/forum/testgear/hacking-old-hp-spectrum-analyzers/msg1029801/#msg1029801)
There'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.
-
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? :palm:
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....
-
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.
No 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.
My worry is.............Do you think I could mess up my instrument? :palm:
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....
There'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.
-
Well, I have the machine, I have the GPIB software, I have the will but that's about all. :-DD 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?
-
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?
-
Linux Mint 19.1 Cinnamon is installed, the driver is not. Driver manager shows "No proprietary drivers are in use".
-
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-source
I'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.)
-
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.
-
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-gpib (http://sourceforge.net/projects/linux-gpib)
Everything 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.
# 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.0
tar xf linux-gpib-kernel-4.2.0.tar.gz
tar 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
./configure
make
sudo make install
# Build and install the user libraries
#
cd ../linux-gpib-user-4.2.0
./configure
make
sudo 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.conf
echo /usr/local/lib64 >> /etc/ld.so.conf.d/local.conf
ldconfig
# 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 /etc
xed /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 0
chmod a+rw /dev/gpib*
# Check for more kernel messages as a result of the gpib_config.
# There shouldn't be any errors.
#
dmesg | tail -30
exit # 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.
-
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?
-
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.
-
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 /etc
And 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.
-
Hat off Mark!
I have it working...
-
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 bash
modprobe tnt4882
# wait a few seconds here
/usr/local/sbin/gpib_config --minor 0
exit
One 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:
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/sh
exec > /tmp/rc.local.log 2>&1
echo "Loading gpib driver (configuring in 5 seconds)..."
modprobe tnt4882
(
sleep 5
echo "Configuring gpib driver..."
/usr/local/sbin/gpib_config --minor 0
chmod a+rw /dev/gpib*
) &
EOF
chmod +x /etc/rc.local
exit
The 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.)
-
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?
-
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/#msg2140066 (https://www.eevblog.com/forum/testgear/hp-8594e-spectrum-analyzer-at-last-i-own-a-decent-spec-an/msg2140066/#msg2140066)
As 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).
ibterm -d 19
Attempting to open /dev/gpib0
pad = 19, sad = 0, timeout = 10, send_eoi = 1, eos_mode = 0x0000
ibterm>cat *
INTERNAL: 6994 238070
ibterm>cat on*
ON EVENTS:
ONEOS UNDEFINED
ONSWP UNDEFINED
TRMATH UNDEFINED
ONCYCLE UNDEFINED
ONDELAY UNDEFINED
ONMKR UNDEFINED
ONSRQ UNDEFINED
ONTIME UNDEFINED
ONPWRUP UNDEFINED
ibterm>cat reg*
ST/TR REG:
ST1 UNUSED
ST2 UNUSED
ST3 UNUSED
ST4 UNUSED
ST5 UNUSED
ST6 UNUSED
ST7 UNUSED
ST8 UNUSED
TR0 UNUSED
TR1 UNUSED
TR2 UNUSED
TR3 UNUSED
TR4 UNUSED
TR5 UNUSED
TR6 UNUSED
TR7 UNUSED
TR8 UNUSED
TR9 UNUSED
TR10 UNUSED
TR11 UNUSED
TR12 UNUSED
TR13 UNUSED
TR14 UNUSED
TR15 UNUSED
TR16 UNUSED
TR17 UNUSED
TR18 UNUSED
TR19 UNUSED
TR20 UNUSED
TR21 UNUSED
TR22 UNUSED
TR23 UNUSED
TR24 UNUSED
TR25 UNUSED
TR26 UNUSED
TR27 UNUSED
TR28 UNUSED
TR29 UNUSED
TR30 UNUSED
TR31 UNUSED
TR32 UNUSED
TR33 UNUSED
TR34 UNUSED
TR35 UNUSED
TR36 UNUSED
TR37 UNUSED
TR38 UNUSED
TR39 UNUSED
TR40 UNUSED
TR41 UNUSED
TR42 UNUSED
TR43 UNUSED
TR44 UNUSED
TR45 UNUSED
TR46 UNUSED
TR47 UNUSED
TR48 UNUSED
TR49 UNUSED
TR50 UNUSED
TR51 UNUSED
TR52 UNUSED
ibterm>
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.
-
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.
# It seems that the perl bindings are not installed by default.
# Go back and do them.
#
cd linux-gpib-user-4.2.0/language/perl
make
sudo 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
. ~/.bashrc
mkdir ~/bin
# Go get the rest of the scripts.
#
cd ~/Downloads
wget http://www.employees.org/~markl/gpib-perl-v0.3b.tgz
wget http://www.employees.org/~markl/gpib-dlp-poc.tgz
# Extract them both...
#
tar xf gpib-perl-v0.3b.tgz
tar 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/bin
mv 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 = 0
pad = 18
eos = 0x0a
timeout = 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.
-
Something didn't go well
miti@miti-System-Product-Name:~$ ibterm -d 18
Attempting to open /dev/gpib0
pad = 18, sad = 0, timeout = 10, send_eoi = 1, eos_mode = 0x0000
libgpib: ibBoardOpen failed to open device file
libgpib: No such file or directory
libgpib: error in is_cic()!
ibterm error: open failed
- EDVR 0: OS error
ibdev error
ibterm: Aborted
miti@miti-System-Product-Name:~$ spq "*id"
libgpib: ibBoardOpen failed to open device file
libgpib: No such file or directory
libgpib: error in is_cic()!
libgpib: ibfind failed to get descriptor
exit value cannot find gpib device "sp" at /home/miti/bin/gpib-lab-lib.pl line 405.
miti@miti-System-Product-Name:~$
-
Ok, I fixed it. Apparently cat command overwrites the conf file. I copied it again and ibterm works.
miti@miti-System-Product-Name:~$ ibterm -d 18
Attempting to open /dev/gpib0
pad = 18, sad = 0, timeout = 10, send_eoi = 1, eos_mode = 0x0000
ibterm>*id
HP8594E
ibterm>ibterm>cat *
ibterm>cat*
INTERNAL: 4830 238062
C_ONLV 34
ibterm>cat on*
ON EVENTS:
ONEOS UNDEFINED
ONSWP UNDEFINED
TRMATH UNDEFINED
ONCYCLE UNDEFINED
ONDELAY UNDEFINED
ONMKR UNDEFINED
ONSRQ UNDEFINED
ONTIME UNDEFINED
ONPWRUP UNDEFINED
ibterm>cat reg*
ST/TR REG:
ST1 CF: 1.65 GHz SP: 10.00 kHz
ST2 CF: 1.65 GHz SP: 20.00 kHz
ST3 CF: 1.45 GHz SP: 2.900 GHz
ST4 CF: 1.45 GHz SP: 2.900 GHz
ST5 CF: 1.45 GHz SP: 2.900 GHz
ST6 CF: 1.45 GHz SP: 2.900 GHz
ST7 CF: 1.63 GHz SP: 10.00 kHz
ST8 CF: 1.45 GHz SP: 2.900 GHz
TR0 TL: 07:55:52 FEB 23, 1999
TR1 TL: 17:34:55 SEP 14, 2001 17:36:57 SEP 14, 2
TR2 TL: 17:34:55 SEP 14, 2001 17:36:57 SEP 14, 2
TR3 TL: 07:55:53 FEB 23, 1999
TR4 TL: 07:55:53 FEB 23, 1999
TR5 TL: 07:55:53 FEB 23, 1999
TR6 TL: 07:55:53 FEB 23, 1999
TR7 TL: 07:55:53 FEB 23, 1999
TR8 TL: 07:55:53 FEB 23, 1999
TR9 TL: 07:55:53 FEB 23, 1999
TR10 TL: 07:55:53 FEB 23, 1999
TR11 TL: 07:55:53 FEB 23, 1999
TR12 TL: 07:55:54 FEB 23, 1999
TR13 TL: 07:55:54 FEB 23, 1999
TR14 TL: 07:55:54 FEB 23, 1999
TR15 TL: 07:55:54 FEB 23, 1999
TR16 TL: 07:55:54 FEB 23, 1999
TR17 TL: 07:55:54 FEB 23, 1999
TR18 TL: 07:55:54 FEB 23, 1999
TR19 TL: 07:55:55 FEB 23, 1999
TR20 TL: 07:55:55 FEB 23, 1999
TR21 TL: 07:55:55 FEB 23, 1999
TR22 TL: 07:55:55 FEB 23, 1999
TR23 TL: 07:55:55 FEB 23, 1999
TR24 TL: 07:55:55 FEB 23, 1999
TR25 TL: 07:55:55 FEB 23, 1999
TR26 TL: 07:55:55 FEB 23, 1999
TR27 TL: 07:55:56 FEB 23, 1999
TR28 TL: 07:55:56 FEB 23, 1999
TR29 TL: 07:55:56 FEB 23, 1999
TR30 TL: 07:55:56 FEB 23, 1999
TR31 TL: 07:55:56 FEB 23, 1999
TR32 TL: 07:55:56 FEB 23, 1999
TR33 TL: 07:55:56 FEB 23, 1999
TR34 TL: 07:55:56 FEB 23, 1999
TR35 TL: 07:55:56 FEB 23, 1999
TR36 TL: 07:55:57 FEB 23, 1999
TR37 TL: 07:55:57 FEB 23, 1999
TR38 TL: 07:55:57 FEB 23, 1999
TR39 TL: 07:55:57 FEB 23, 1999
TR40 TL: 07:55:57 FEB 23, 1999
TR41 TL: 07:55:57 FEB 23, 1999
TR42 TL: 07:55:57 FEB 23, 1999
TR43 TL: 07:55:57 FEB 23, 1999
TR44 TL: 07:55:57 FEB 23, 1999
TR45 TL: 07:55:58 FEB 23, 1999
TR46 TL: 07:55:58 FEB 23, 1999
TR47 TL: 07:55:58 FEB 23, 1999
TR48 TL: 07:55:58 FEB 23, 1999
TR49 TL: 07:55:58 FEB 23, 1999
TR50 TL: 07:55:58 FEB 23, 1999
TR51 TL: 07:55:58 FEB 23, 1999
TR52 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.
-
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 = 0
pad = 18
eos = 0x0a
timeout = T30s /* needed for slow print response */
}
EOF
I 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.
-
I edited the conf file manually and I have communication. It doesn't work, however. Please see attached.
-
Ok, add your current directory to the search path:
echo 'export PATH='.:'$PATH' >> ~/.bashrc
. ~/.bashrc
That'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
-
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
It is:
00000000: 0d 0a ..
-
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' ]; then
to this:
if [ ! \( "$res" == $'\x0d' -o "$res" == $'\x0d'$'\x0a' \) ]; then
-
I changed the line and still fails. Perl_new is after changing the line.
-
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:
if [ ! \( "$res" == $'\x0d' -o "$res" == $'\x0d'$'\x0a' \) ]; then
the "code" tag seems to preserve the backslashes.
-
And in parse_a get rid of these two lines near the top:
# default options always given
args[i++]="-l"
I apologize for all the old junk in these scripts.
-
I get
miti@miti-System-Product-Name:~$ cd ~/Downloads/gpib-dlp-poc
miti@miti-System-Product-Name:~/Downloads/gpib-dlp-poc$ ./do_cmds
--- trdef Q_TRA (xfer) ---
reading from stdin
read 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 stdin
read 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 stdin
read 809 bytes
./do_cmds: 9: [: closing paren expected
--- trdef Q_TRC (define,mov) ---
./do_cmds: 9: [: closing paren expected
--- trdef _ONE (xfer) ---
reading from stdin
read 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
-
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.
-
Here they are:
#!/bin/sh
SP=sp
SPQ=spq
check_err()
{
res=$($SPQ "CMDERRQ")
if [ ! \( "$res" == $'\x0d' -o "$res" == $'\x0d'$'\x0a' \) ]; then
echo "********** CMDERRQ: $res **********"
fi
}
### trdef
trdefs=$(cd var_a && grep -l '^#A' *)
# echo trdefs $trdefs
for i in $trdefs; do
echo "--- trdef $i (xfer) ---"
# use trace C to transfer
echo -n "TRC" > tmp
cat var_a/$i >> tmp
$SP - < tmp
check_err
echo "--- trdef $i (define,mov) ---"
$SP "TRDEF $i,401; MOV $i,TRC;"
check_err
done
-
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.
-
:-+ :-+ :-+ :-+ :-+ :clap: :clap: :clap:
It worked!!
Thanks a lot Mark. Sorry to keep you awake so late...
-
Great! Have fun with the EMC and QPD! And goodnight!
-
Great! Have fun with the EMC and QPD!
Thanks, I will...
And goodnight!
Are you kidding me? Time to play... :-DD
-
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.
-
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.
Absolutely 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.htm (http://www.ke5fx.com/gpib/readme.htm)
It 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.
-
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.
-
https://vma-satellite.blogspot.com/2019/02/vma-simple-spectrum-analyser-version.html
https://vma-satellite.blogspot.com/2019/03/vma-spectrum-analyser-for-hp-8590.html
Regards,
Vitor
-
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.
It 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.
-
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
-
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.
I could easily am going to write 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
-
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!
...
Take a look at this post:
https://www.eevblog.com/forum/testgear/hacking-old-hp-spectrum-analyzers/msg1021445/#msg1021445 (https://www.eevblog.com/forum/testgear/hacking-old-hp-spectrum-analyzers/msg1021445/#msg1021445)
That 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/#msg1030583 (https://www.eevblog.com/forum/testgear/hacking-old-hp-spectrum-analyzers/msg1030583/#msg1030583)
If 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.
-
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-block
data 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
-
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.
-
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:
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
-
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
-
I've "cat" :palm: 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!
-
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
The 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.
-
I've "cat" :palm: 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!
Thanks 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!
-
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
The 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.
Oh 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
-
Here is the "S_CAP" program, which I restored manually.
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 memory
2) 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 them
Regards,
Vitor
-
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.
I think this is what you are doing with Python under Linux.
More 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 (https://www.eevblog.com/forum/testgear/hacking-old-hp-spectrum-analyzers/msg421596/#msg421596)
-
@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