Author Topic: Ethernet Connectivity with Agilent/HP 89400 Series Vector Signal Analyzers  (Read 2962 times)

0 Members and 1 Guest are viewing this topic.

Offline garrettmTopic starter

  • Frequent Contributor
  • **
  • Posts: 274
  • Country: us


So I bought an Agilent 89410A last year and have been wanting to use all the cool Ethernet connectivity options shown in the product literature.



This desire to use a remote interface really hit home once I started using a floppy disk to save plots, as I don't have an HP-IB adapter to control the unit with. To be honest, I don't know how anyone survived the floppy disk era--the noises and speed of copying even the smallest of files is almost cancer inducing.



Interestingly enough, the 89400 series VSAs don't have an RJ45 port as one would come to expect from its ubiquity in today's world. Instead, the UTH/UFG option module is equipped with a BNC (10base2) thinnet port and an AUI port. The AUI, or attachment unit interface, lets you connect different MAUs, or medium attachment units. These MAUs allow for using 10baseT and various types of fiber optic media or even thicknet (10base5) if you are feeling nostalgic.



On a whim, I picked up one of the CentreCOM MX20T MAUs off of eBay for 12 USD. The MX20T provides full-duplex 10baseT Ethernet connectivity with auto polarity and is the smallest MAU I could find. While looking on eBay I noticed that the MX20T comes in two different housings: a rounded clamshell and this more square variety that I bought shown below. From what I can tell the square type seems to be a slightly newer revision. If you'd rather go HP, the 28685B EtherTwist will do the job but is slightly larger than the CentreCOM unit.

Datasheet for CentreCOM MAUs: https://www.newark.com/pdfs/datasheets/Allied_Telesyn/AT-210TS_TRANSCEIVER.pdf



After configuring the VSA to use the AUI port and a non-occupied IP address (as the VNA doesn't support DHCP), I could thankfully ping the meter. I'm not sure if it's the option module that is slow or if 10baseT hardware is just naturally slow, but ping times of 7 to 8ms were normal for a 15ft run of cat5e cable. Pinging my router over a 100+ feet of cable gives 1ms with gigabit link speed.

After the sanity check, I opened up putty and connected to the VSA via Telnet (port 23) and sent *idn? and *opt? commands. I noticed that the VSA is a little slow to respond to commands over the network while performing measurements (occasionally timeouts with large 23ms and higher ping times). Pausing the measurement returns the pings time back to around 7 to 8ms. Interestingly, turning on averaging and setting the display update rate to say 10 drops the ping times back down to the baseline with a few 10 to 40ms pings here and there. So the display update rate affects the latency of the instrument.

Next was testing the FTP connectivity. I initially tried using WinSCP but kept getting errors, so I opened up command prompt and ran Windows' built-in ftp client: ftp.exe. This worked great--I was able to change directories and copy the saved config file from nvram to my desktop. If you want the fastest data transfer speeds you will want to set up a large volatile ram drive on the VSA. Saving a plot of the display to the RAM drive and copying it over to the PC via FTP was significantly faster than using a floppy drive.

Finally, I wanted to see what all this X Window stuff was about, so I downloaded the free portable version of MobaXterm and fired up an x11 server instance on my desktop. Then I went over to the VSA and activated the remote X Window through the networking menu.

https://mobaxterm.mobatek.net/download-home-edition.html



Lo and behold, a miniature VSA front panel popped up on my PC! (It looks tiny because of my 4k display resolution.) Despite the high ping times and low transfer rates, the X Window seemed to work great and really felt like I was using the instrument directly. The only problem I found was with the green text around the plotting area, where some of the text is cut off by a few pixels. My guess is that this is due to the differences in x11 used back in 95 / 2000 and today. I'm not sure of how to get a hold of an older piece of X Window software, but my guess is it would work better.



My next goal is to figure out how to do a time capture and then bring that data into MATLAB. The 89400 VSAs do not use the full 10 seconds of time data when performing the FFT plot. Instead, it breaks it up into chunks and runs it for each one separately. If averaging is enabled, then it will average those FFT plots together.

Overall, I'm pretty happy with my 12 USD purchase: it has given me much more control over the instrument and was significantly cheaper and easier to work with than using HP-IP. IEEE488 has its place, but I find it cumbersome and am infinitely more comfortable with TCP/IP connectivity.

If anyone is interested, I am planning on writing a program that combines all the advanced functionality (FTP, X Window, and Telnet) into one package. I would like to do it all in MATLAB so I can run longer FFTs using the extended time capture capability of the AY9 option module and quickly configure the instrument to perform different measurements and possibly do swept sine network analysis with the built-in ARB signal generator (as opposed to using a chirp signal).

Before I forget, the UFG option module can be easily upgraded to UTH by installing a 16MiB, 72-pin, 5V, 60ns, FPM (fast page mode) memory module. (The 4 megs of ram on the UTH/UFG module are Micron MT4C4001JDJ-6.) EDO memory may work too, but I didn't test.








« Last Edit: January 30, 2021, 06:42:18 am by garrettm »
 
The following users thanked this post: mightyohm, tv84, boblevy4321@sbcglobal.net, matthuszagh

Offline KE5FX

  • Super Contributor
  • ***
  • Posts: 2013
  • Country: us
    • KE5FX.COM
Very cool.  I'm surprised the SCPI interface is slow over the Ethernet connection.  Usually it's much faster than GPIB, but then I've never had any experience with these older 10Base2 interfaces.  Doesn't sound like a hardware issue given that the X terminal performs well.  I wonder if they're leaving Nagling turned on, or something obvious like that...
 

Offline garrettmTopic starter

  • Frequent Contributor
  • **
  • Posts: 274
  • Country: us
I thought I would give a little update.



When lowering the X Window update rate to 4 Hz, the remote display looks reasonably smooth. The fastest update rate that didn't look too jumpy (pause/move too fast) on the remote display was about 10 Hz. I also noticed that the X Window will still update fine when a ping request times out, so I don't think pings tell the whole story here.

Below is a resized image of the instrument panel so people can better see the cutoff pixels on text around the plotting grid and on some of the buttons. Still not sure why this is happening to be honest.



Note that the display's update rate is linked to the X Window update rate, if enabled. And using too fast of an update rate will cause the X Window to look a little jumpy/laggy on the remote PC--though this might simply be an issue with my setup.

On a whim, I grabbed a 25ft Cat5e cable and connected the VSA directly to my PC and configured the NIC manually to 10Mbps full-duplex. Pinging the instrument this time gave basically the same results (6 to 9ms ping while paused and 5 to about 35ms while running). This implies that my original setup (VSA<10FD>switch<100FD>router<1000FD>PC) wasn't causing the high ping times. So it’s probably that the instrument is just really slow. And I would expect similar slowness/lag to occur on the HP-IB interface as well. Regardless of the lag, the ability to transfer data to and from the PC is awesome and the remote instrument panel is a really neat feature.



And for fun, here's some comparison tests I did against an HP 35665A DSA. I believe I configured everything fairly, both are set to 800 points (801 for the 89410A), 1Mohm input with auto range on and same 0 to 102.4kHz span. The resolution bandwidth might be the only setting that is different: with the 89410A having more memory it can do finer bandwidth resolutions in vector mode than the 35665A and gives it a lower noise floor as a result.





If you have option AY7 (second 10Mhz input) the 89410A VSA can be used as a DC-10MHz DSA / VNA (using chirp). The main advantage of the 35665A is slightly lower noise in the DC to 10kHz band, but the finer RBW of the 89410A can offset this somewhat.

And talking of options, here's the AY9 "deep capture" option module:





And here's a pic of the A10 analog input module (1/2 of the AY7 option):

« Last Edit: October 06, 2020, 01:28:30 am by garrettm »
 
The following users thanked this post: bozidarms

Offline bozidarms

  • Regular Contributor
  • *
  • Posts: 176
  • Country: at
Hi garrettm,

thanks to your explanation I was able to make X11 contact with my 89441A :).
I am using one CentreCOM 210TS adapter.

Many thanks :-+
 
The following users thanked this post: garrettm

Offline boblevy4321@sbcglobal.net

  • Newbie
  • Posts: 8
  • Country: us
Hello
Thank you Sooo Much.
I just finished repairing the 89441a that I bought off Ebay.                 
The memory that you described , is this parity or non parity.

THANKS AGAIN
Bob
 
The following users thanked this post: garrettm

Offline garrettmTopic starter

  • Frequent Contributor
  • **
  • Posts: 274
  • Country: us
Hi garrettm,

thanks to your explanation I was able to make X11 contact with my 89441A :).
I am using one CentreCOM 210TS adapter.

Many thanks :-+

I'm happy to have helped bozidarms! By the way, what ping times do you see with the CentreCOM 210TS? I've been wondering if my MX20T is causing my high ping times.


Hello
Thank you Sooo Much.
I just finished repairing the 89441a that I bought off Ebay.                 
The memory that you described , is this parity or non parity.

THANKS AGAIN
Bob

The 16MiB SIMM I installed had 8, 60ns Hitachi chips--so I'm fairly certain it was non-parity.

As far as I can tell, the 894xx do not use parity or any form of error correction since the 4MiB of built-in memory on the UFG option module has only 8 Micron MT4C4001JDJ-6 chips (60ns, FPM, 5V). If it were configured for parity, there would have had been at least 9 chips.

I think any 5V, 72-pin, non-parity, 16MiB, 60ns, FPM module should work. EDO (extended data out) may work, but I didn't test.

I bought my module off of eBay for 6 USD (shipping and everything), so it should be a low cost upgrade. Since this is a hardware option, it's detected automatically at boot.

To enable all the software options, check out this thread by bovist:

https://www.eevblog.com/forum/testgear/enable-all-options-on-hp-89441a-and-89410a/
« Last Edit: January 30, 2021, 10:32:27 pm by garrettm »
 

Offline boblevy4321@sbcglobal.net

  • Newbie
  • Posts: 8
  • Country: us
Re: Ethernet Connectivity with Agilent/HP 89400 Series Vector Signal Analyzers
« Reply #6 on: February 08, 2021, 07:41:36 pm »
Thanks again for all your help.
Yes 16mb 5v 60ns 8 chip works great.
I have the network link working. The major option with this is I would like is to be able to print the screen shot over the network.
Mobaxterm is not working for this. I tried the screen capture and can't get it to see the Xterm screen, only the main screen.

You mentioned you are working on an App for the network. I don't have Matlab , but I am interested 
THANK YOU AGAIN
Bob
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf