Seeking opinions on HP 16533/16534A oscilloscope card

[DIPLover]

Hi,

I have recently acquired an HP 16700A and am busy filling out the empty slots in the mainframe. What an awesome piece of gear!

If you have ever used the 16533A/16534A oscilloscope card in a 16700 series LA, I would like your subjective opinion. Does it work OK, good or great? What did you like and not like etc.

If you used the scope cards with 16500 series LA, I am also interested in your opinion.

The scope cards are still relatively expensive, are they worth it?

I already own 2 good scopes, tektronix 2465 and TDS784A. I have 4 active probes for the 784A.

[gslick]

If you do not already have any digital oscilloscopes a 16533A/16534A oscilloscope card is certainly better than nothing. The rated 500MHz bandwidth and 2G sample/second are higher than, for example, an entry level Rigol DS1054Z, but the 32K sample depth is tiny compared to any modern entry level digital oscilloscope.

As a general purpose tool there are certainly better options than a 16533A/16534A oscilloscope card in most situations.

Where they are useful is for time correlation between analog signals and digital signals, for example in a system with an older style parallel bus microprocessor controlling some analog signals where you can set markers on points of interest in the analog signal traces and switch to the digital listing view and see what the microprocessor was doing around the time of those markers, or the other way around. I did that not too long ago trying to reverse engineer some aspects of an old 8085 controlled device programmer with 4 firmware controlled analog programming voltage channels and it was helpful.

One possible concern, 16533A/16534A oscilloscope cards might not hold up so well over the years compared to the logic analyzer cards, based on my limited experience. I have maybe 4-5 16534A oscilloscope cards now. One is dead enough that it fails its power up tests and the mainframe will not even try to use it. Another passes power up and PV tests, but will fail self calibration when that is attempted. Without checking I'm not sure if I have any fully functional 16534A oscilloscope cards left now.

[texaspyro]

You can convert a '533 intp a '534 by swapping two resistors...   there is thread on the forum that tells you how.

[PaulAm]

There is a battery NVRAM that goes bad on the card.  I resurrected one by changing that out.

The ability to tie the triggering to the LA makes it handy.   So in some cases it would be very useful.  As a general DSO, it's not so hot.

OTOH, if the LA is already taking up half your bench you won't need to find a space to perch your scope if you want to look at something.

[MarkL]

I have 8 16534A cards and about half of them are currently working.  The majority suffer from the same green corrosion caused by the runner adhesive that kills so many of digital analyzer cards in this series, although in the scope cards it doesn't seem as severe.

If you decide to get any of these cards, I'd strongly recommend getting them as "Used" and not "As-is/Parts".  I received 6 cards in a row from various sellers that were listed as "Used" that either didn't pass self-test or didn't pass self-calibration.  (Do both before accepting a card!)  Some sellers didn't want the cards back after a refund, and I was able to fix several of them, but it was difficult because there are no schematics and very little documentation for the diagnostic output.  I'm not sure it was worth the time.

I've encountered a number of dead ADCs and flaky attenuators.  Fortunately, both are easily replaceable and they're not difficult to obtain since they're also used in other Agilent scopes.  The attenuator contacts can be cleaned instead of replacing the whole assembly if you prefer, but it's time consuming since it requires unsoldering the relay coils from the ceramic substrate.

As others have noted, the 16533A/16534A is not a very good substitute for a standalone digital scope.  Besides the small 32k capture buffer, they have a very slow screen update rate of about 1 per second, and it gets slower as you add more cards to the group (max of 4 cards/8 channels).  But this may not matter since you would most often use them in single shot mode.  Just don't expect them to replace your DSO.

The cards can be very handy in analyzing analog to digital interfacing and to verify digital signal integrity, all correlated to the logic analysis.  You can of course also trigger your stand-alone scopes from the analyzer if you need more analog capture length, and visa-versa if the scope has a needed triggering mode (like serial).  Some Agilent Infiniium scopes can be more tightly coupled (time correlated) to the analyzer's GUI, but I haven't done it.

On the price, put in an ebay search and be patient.  Often you can find the cards cheaper bundled with a chassis.  You can either buy the whole thing and sell off what you don't need, or I've found more than once that some sellers are willing to extract a card and sell it separately.  You just have to ask and offer a fair price.  The worst they can say is "no".

And if you come to depend on the 16533A/16534A, you should probably get more then one since they can die without warning.

[DIPLover]

Thank you all for the replies, I think I will get by with external triggers for now.

I have had a look at what Agilent did with the 16900 and infiniium scopes and I may try to use the 16700 tools development kit to implement something similar (automatic deskew and waveform import using external triggers and LAN ports). That in itself would be an interesting project.

[MarkL]

The analyzer talks to the Infiniium scopes with RPC.  Maybe the calls are documented somewhere and you could use that.

Or reverse engineer it by watching the exchange, but that would require an Infiniium scope.

[gslick]

There was also the E5850A Time Correlation Fixture which supported a 16700 logic analyzer and an Agilent 548XX series Infiniium oscilloscope.

http://literature.cdn.keysight.com/litweb/pdf/E5850-97002.pdf

I have never looked at one of those myself.

[PrecisionAnalytic]

As others have noted, the 16533A/16534A is not a very good substitute for a standalone digital scope.  Besides the small 32k capture buffer, they have a very slow screen update rate of about 1 per second, and it gets slower as you add more cards to the group (max of 4 cards/8 channels).  But this may not matter since you would most often use them in single shot mode.  Just don't expect them to replace your DSO.

Any ideas on improving the performance of these to increase the capture buffer and update rate?  Is the limiting factor on the 16533A/16534A itself?

[MarkL]

Any ideas on improving the performance of these to increase the capture buffer and update rate?  Is the limiting factor on the 16533A/16534A itself?

The 32k capture buffer is inside the acquisition hybrid, so there's no hope for increasing that.  Here's a photo of the inside if you're curious:

  https://www.eevblog.com/forum/blog/eevblog-982-hp54616b-500mhz-oscilloscope-repair/msg1171633/#msg1171633

For the slow waveforms/sec, the same hybrid is used in other Agilent DSOs that have decent performance, so it's probably not anything to do with the hybrid or transfer of data from it.

My guess is that it's software related.  And I should point out it's EXACTLY one second from one acquisition to the next when in free-run mode, which makes me suspicious it's intentionally delaying the start of the next of the next acquisition.

I haven't found any settings to control this delay, but maybe the developers created it to let the user look at the waveform between captures.  Or, if I were to put my conspiracy hat on, maybe they crippled it on purpose so these cards didn't compete with DSO sales.

If you want to try playing with it, the card has a debug mode which can be entered by doing:

  telnet <whatever IP>
  user: root
  password: uh,uhuh
  mkdir -p /tmp/.scope
  touch /tmp/.scope/DebugScope

Do this after starting the main menu and before starting the scope application.  A "Debug" tab will appear in the scope setup menu where you can turn various things on and off, but nothing I've found seems to improve the update rate.

The scope application creates some setup files in the above directory.  I haven't played with them to see if there's anything useful.

The calibration routine will also create a ton of files there, but the information in them is fairly cryptic and obviously meant for the developers' internal use.

[rtr989]

I bought a board 16534A for my Agilent 16702 about 2 months ago, the first tests showed that the displayed frequency is not limited to 500 MHz, the device successfully shows frequencies up to 1 GHz.





A big plus was the ability to use the buffer in third-party applications, it turned out to implement Fast Fourier transform - FFT https://github.com/rtr989/Agilent-16700-FFT






Although the device is outdated, it still offers many possibilities.
My device updates the screen 2 times a second, I would like to overclock it a little, of course ...
The money is well spent!

[MarkL]

Thanks for sharing your FFT implementation, along with the installer and the source!

One suggestion I have is to make the vertical axis in dB, or have it be selectable.

And I'm not sure what the expanded "Frequency_#" waveform is supposed to be showing.  I'm guessing you meant to mark each peak with a pulse, but that doesn't seem to be what's happening.  Maybe I have the wrong idea of what it's supposed to be.  Example below of a 1MHz square wave.

I still only get about one update per second, and with the FFT on about an update every two seconds.  The 16700 series is just slow.

[rtr989]

Thanks for sharing your FFT implementation, along with the installer and the source!

One suggestion I have is to make the vertical axis in dB, or have it be selectable.

Hi! I added decibel display, please update.

And I'm not sure what the expanded "Frequency_#" waveform is supposed to be showing.  I'm guessing you meant to mark each peak with a pulse, but that doesn't seem to be what's happening.  Maybe I have the wrong idea of what it's supposed to be.  Example below of a 1MHz square wave.

Frequency_# is just a marker for frequency number. simply switch it to decimal.

I still only get about one update per second, and with the FFT on about an update every two seconds.  The 16700 series is just slow.

what version of the system do you have? i check it again and i have 50 updates per 25 seconds in 2GSa/s, and about one update per second with FFT.

[rtr989]

how did you get so many lines of Frequency# ?

[MarkL]

(Attachment Link) (Attachment Link) (Attachment Link)

Thanks for sharing your FFT implementation, along with the installer and the source!

One suggestion I have is to make the vertical axis in dB, or have it be selectable.

Hi! I added decibel display, please update.
(Attachment Link)

Thanks!  But what I meant was that FFT amplitude is usually shown in dB, like a spectrum analyzer.

Frequency_# is just a marker for frequency number. simply switch it to decimal.
(Attachment Link)

Ok, I get it now.  The peak number is embedded as the bit value of the "Frequency_#" label.

what version of the system do you have? i check it again and i have 50 updates per 25 seconds in 2GSa/s, and about one update per second with FFT.
(Attachment Link)

This was my mistake.  I am running it over X11 to a different workstation.  I thought I had looked at the impact of doing this a long time ago and it was not an issue.  I do get your numbers when running natively on the LCD screen.  But I still call 2 waveforms/sec very slow.

how did you get so many lines of Frequency# ?

If you click on the "Frequency_#" label and select "Expand" from the pop-up, it will display the eight bits you're using to encode the peak number.  But now that I understand what you're doing with this label, it makes no sense to look at it expanded.

[MarkL]

For the FFT display, I mean something like this:

Code: [Select]

  err = fft.createAnalogData(fftDS, "FFTdB", -50, +150);
  for (i = 0; i < range / 2; i++) {
    fft.replaceNext(20 * log10(fftA1[i]));
  }
Inserted right after your bit that does the linear FFT on line 210.  It creates a second analog waveform in dB.

This fragment probably needs min/max checking, and maybe the range is wrong.  But hopefully you get the idea.  I just copied your code and put in the dB computation that you had for the peaks.  I don't know if it's numerically correct or not.

Below is an example of a dual-tone signal (1MHz +/-200kHz) coming out of a signal generator.  Those spurs are actually in the signal, but you can't see them on the linear FFT.  Your peak detect message says:

  Measurement accuracy: 76.294 Hz
  Minimum Frequency: 762.939 Hz, Max Frequency: 12500.000 kHz
  --------------------------------------------
  #1: 800.02 kHz  -15.88 dB
  #2: 1.2001 MHz  -13.90 dB

The frequency is certainly right.

If you want to keep improving this, you might also want to consider applying some windowing (Blackman-Harris, Hanning, etc.).

[rtr989]

This was my mistake.  I am running it over X11 to a different workstation.  I thought I had looked at the impact of doing this a long time ago and it was not an issue.  I do get your numbers when running natively on the LCD screen.  But I still call 2 waveforms/sec very slow.

I use my 16702b only over X11.
Of course 2 updates/sec is very slow. I have already tried the RPI interface, the speed is the same. I still can't figure out who is slowing down, a lib16534.sl library or a shell. Do You know how to look at which process which port is listening? lsof is a useful utility, but I cannot find it for HPUX 10.20.
I need to find out which process is accepting connections on port 6500 of the RPI interface.

[MarkL]

This was my mistake.  I am running it over X11 to a different workstation.  I thought I had looked at the impact of doing this a long time ago and it was not an issue.  I do get your numbers when running natively on the LCD screen.  But I still call 2 waveforms/sec very slow.

I use my 16702b only over X11. Of course 2 updates/sec is very slow.

Are you saying you get 2 waveforms/sec over X11 (not VNC)?

I have already tried the RPI interface, the speed is the same. I still can't figure out who is slowing down, a lib16534.sl library or a shell. Do You know how to look at which process which port is listening? lsof is a useful utility, but I cannot find it for HPUX 10.20.
I need to find out which process is accepting connections on port 6500 of the RPI interface.

This depot has lsof for HP-UX 10.20:

  http://mirrors.develooper.com/hpux/downloads.html

I couldn't get the .sd (software depot) version to install, but the lsof-4.67-pa1.1 raw binary works fine.

The process is "vp".  Good luck on your quest - please share if you discover anything!

[rtr989]

  telnet <whatever IP>
  user: root
  password: uh,uhuh
  mkdir -p /tmp/.scope
  touch /tmp/.scope/DebugScope

where did you find this info

[MarkL]

  telnet <whatever IP>
  user: root
  password: uh,uhuh
  mkdir -p /tmp/.scope
  touch /tmp/.scope/DebugScope

where did you find this info

The root password has been widely known for a while.   I found it in a post on this forum or maybe on the HP-Agilent-Keysight groups.io, I don't exactly recall.

I figured out the debug procedure by running strings on lib16534.sl.

[rtr989]

Are you saying you get 2 waveforms/sec over X11 (not VNC)?

yes

[rtr989]

This depot has lsof for HP-UX 10.20:

  http://mirrors.develooper.com/hpux/downloads.html

I couldn't get the .sd (software depot) version to install, but the lsof-4.67-pa1.1 raw binary works fine.

The process is "vp".  Good luck on your quest - please share if you discover anything!

Many thanks! il get lsof, works fine!
I'm sure it's not the library that slows down, but the vp shell sends requests for updates very rarely.
You said that the same ADC module is used in other Agilent DSOs, what performance did you observe on them?

Do you know any Agilent DSO of that time that work on HPUX?

[MarkL]

...
I'm sure it's not the library that slows down, but the vp shell sends requests for updates very rarely.
You said that the same ADC module is used in other Agilent DSOs, what performance did you observe on them?

Do you know any Agilent DSO of that time that work on HPUX?

I haven't seen any running HP-UX.  The only ones I know of with the same ADC (1NB7-8353) all run some form of windows (546xx, and 548xx), or proprietary OS (545xx).

I've never actually used one of these scopes.  However, the 545xx series has a spec of 47 waveforms/sec for a full 32k record, and it's the oldest in the bunch.  So it has to be at least that.

The 548xx is quoted at 2100 waveforms/sec but only 512 points, so that doesn't really count.  I don't see any waveform specs for the 546xx series.  More digging may find the specs.  Some of the sub-models in these series may also use different ADCs.  If the spec is 1Gsa/s or 2Gsa/s and 32k, it's almost certain to be the 1NB7-8353, but to confirm you also have to check with the service manual.  While there are no schematics (unfortunately), it will still list the ADC as a replaceable part.

I'm not sure what's slowing down my X11.  I'll have to look at that.

[rtr989]

I figured out the debug procedure by running strings on lib16534.sl.

please explain this..

[MarkL]

I figured out the debug procedure by running strings on lib16534.sl.

please explain this..

"strings" is a Unix utility that prints any ASCII strings that it finds in any file.  You can use it on binaries or other unreadable format files.  "man strings" for detailed info.

In this case, I was looking to see if there was any additional debug info for the 16534A cards.  The "pv" utility was not not providing the same level of information that it was for the digital analyzer cards, so I figured there had to be something special for the scope cards.  (And I was somewhat motivated to do something with a pile of 6 dead 16534A cards.)

Running strings on lib16534.sl and searching for the word "debug" quickly found the "DebugScope" string, and then running strings again and looking for other strings around "DebugScope" showed the string "/tmp/.scope", something like this:

  strings /usr/sprockets/tools/instrument/16700/16534/lib16534.sl | grep -i debug
  strings /usr/sprockets/tools/instrument/16700/16534/lib16534.sl | more
    in more: /DebugScope

There was a lot of trial and error and sifting through other possibilities until I stumbled across the right incantation, but hopefully you get the idea.  Although this will work on the 16702B, it's faster to grab a copy of the entire /usr/sprockets directory and search for things using a more modern machine.

My next step was to go after it with the debugger (adb/dde), but I didn't have to go that far.

In the end, the additional info available via scope debug mode was unfortunately not super-helpful in fixing the cards.  Maybe the answers were in there, but the output was meant for HP developers and I found it to be rather cryptic in describing what it was up to.  Oh well.