Seeking opinions on HP 16533/16534A oscilloscope card - Page 1
Forum section: electronics / testgear

author: DIPLover
author_rank: Regular Contributor
timestamp: April 18, 2018, 11:19:58 am
content: 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.

author: gslick
author_rank: Frequent Contributor
timestamp: April 18, 2018, 05:07:38 pm
content: 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.

author: texaspyro
author_rank: Super Contributor
timestamp: April 19, 2018, 01:00:45 am
content: You can convert a '533 intp a '534 by swapping two resistors... there is thread on the forum that tells you how.

author: PaulAm
author_rank: Frequent Contributor
timestamp: April 19, 2018, 12:23:16 pm
content: 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.

author: MarkL
author_rank: Unknown
timestamp: April 19, 2018, 10:24:04 pm
content: 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.

author: DIPLover
author_rank: Regular Contributor
timestamp: April 20, 2018, 02:21:00 pm
content: 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.

author: MarkL
author_rank: Unknown
timestamp: April 20, 2018, 03:24:54 pm
content: 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.

author: gslick
author_rank: Frequent Contributor
timestamp: April 20, 2018, 04:25:54 pm
content: 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.pdfI have never looked at one of those myself.

author: PrecisionAnalytic
author_rank: Regular Contributor
timestamp: May 06, 2019, 03:18:58 am
content: Quote from: MarkL on April 19, 2018, 10:24:04 pmAny ideas on improving the performance of these to increase the capture buffer and update rate? Is the limiting factor on the 16533A/16534A itself?

author: MarkL
author_rank: Unknown
timestamp: May 07, 2019, 02:09:09 pm
content: Quote from: PrecisionAnalytic on May 06, 2019, 03:18:58 amThe 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/#msg1171633For 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: rootpassword: uh,uhuhmkdir -p /tmp/.scopetouch /tmp/.scope/DebugScopeDo 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.

author: rtr989
author_rank: Contributor
timestamp: March 03, 2021, 03:02:01 pm
content: 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 - FFThttps://github.com/rtr989/Agilent-16700-FFTAlthough 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!

author: MarkL
author_rank: Unknown
timestamp: March 08, 2021, 03:56:01 pm
content: 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.

author: rtr989
author_rank: Contributor
timestamp: March 09, 2021, 08:47:33 pm
content: Quote from: MarkL on March 08, 2021, 03:56:01 pmHi! I added decibel display, please update.Quote from: MarkL on March 08, 2021, 03:56:01 pmFrequency_# is just a marker for frequency number. simply switch it to decimal.Quote from: MarkL on March 08, 2021, 03:56:01 pmwhat 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.

author: rtr989
author_rank: Contributor
timestamp: March 09, 2021, 08:53:54 pm
content: how did you get so many lines of Frequency# ?

author: MarkL
author_rank: Unknown
timestamp: March 16, 2021, 08:39:33 pm
content: Quote from: rtr989 on March 09, 2021, 08:47:33 pmThanks! But what I meant was that FFT amplitude is usually shown in dB, like a spectrum analyzer.QuoteOk, I get it now. The peak number is embedded as the bit value of the "Frequency_#" label.QuoteThis 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.QuoteIf 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.

author: MarkL
author_rank: Unknown
timestamp: March 16, 2021, 10:28:09 pm
content: For the FFT display, I mean something like this:Code:err = fft.createAnalogData(fftDS, "FFTdB", -50, +150);for (i = 0; i < range / 2; i++) {fft.replaceNext(20 * log10(fftA1));}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 HzMinimum Frequency: 762.939 Hz, Max Frequency: 12500.000 kHz--------------------------------------------#1: 800.02 kHz -15.88 dB#2: 1.2001 MHz -13.90 dBThe frequency is certainly right.If you want to keep improving this, you might also want to consider applying some windowing (Blackman-Harris, Hanning, etc.).

author: rtr989
author_rank: Contributor
timestamp: March 17, 2021, 10:03:59 am
content: Quote from: MarkL on March 16, 2021, 08:39:33 pmI 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.

author: MarkL
author_rank: Unknown
timestamp: March 17, 2021, 02:39:58 pm
content: Quote from: rtr989 on March 17, 2021, 10:03:59 amAre you saying you get 2 waveforms/sec over X11 (not VNC)?QuoteThis depot has lsof for HP-UX 10.20:http://mirrors.develooper.com/hpux/downloads.htmlI 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!

author: rtr989
author_rank: Contributor
timestamp: March 17, 2021, 02:42:23 pm
content: Quote from: MarkL on May 07, 2019, 02:09:09 pmwhere did you find this info

author: MarkL
author_rank: Unknown
timestamp: March 17, 2021, 02:56:36 pm
content: Quote from: rtr989 on March 17, 2021, 02:42:23 pmThe 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.

author: rtr989
author_rank: Contributor
timestamp: March 17, 2021, 03:52:07 pm
content: Quote from: MarkL on March 17, 2021, 02:39:58 pmyes

author: rtr989
author_rank: Contributor
timestamp: March 17, 2021, 04:07:39 pm
content: Quote from: MarkL on March 17, 2021, 02:39:58 pmMany 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?

author: MarkL
author_rank: Unknown
timestamp: March 17, 2021, 04:49:47 pm
content: Quote from: rtr989 on March 17, 2021, 04:07:39 pmI 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.

author: rtr989
author_rank: Contributor
timestamp: March 17, 2021, 05:24:45 pm
content: Quote from: MarkL on March 17, 2021, 02:56:36 pmplease explain this..

author: MarkL
author_rank: Unknown
timestamp: March 17, 2021, 07:00:46 pm
content: Quote from: rtr989 on March 17, 2021, 05:24:45 pm"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 debugstrings /usr/sprockets/tools/instrument/16700/16534/lib16534.sl | morein more: /DebugScopeThere 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.

author: rtr989
author_rank: Contributor
timestamp: March 21, 2021, 08:22:49 pm
content: Ida pro disassemble vp and lib16534.sl without errors, but I have no clue where to start looking for a place of slowing down...when i start scope, vp loads lib16534.sl library, but i can`t find place in code where it`s happens.The Start and repetititve start buttons is in libWorkspace.sl library...so, I stuck...

author: MarkL
author_rank: Unknown
timestamp: March 23, 2021, 11:00:01 pm
content: What kind of assembly did IDA make for you? Did it read and integrate the symbol file from lib16534.sl? Can you assemble what IDA produced and will it run?If you had the C source, you could do profiling. I don't know if an equivalent exists for assembler, but you might be able to call out to the C library and have monitor() to set it up.Another thing to do is to probe the ADC to confirm it's being read out at a high speed. I doubt the card or backplane is constraining the data readout, but it wouldn't hurt to confirm this before digging into the software side. You'd have to figure out which ADC pins were the data bus and bus clock.Without the original source code, I think it's going be be difficult to figure out what's slowing it down. I don't think it's worth the effort, but if you want to pursue it, I'll add where I can.

author: rtr989
author_rank: Contributor
timestamp: March 24, 2021, 02:50:44 pm
content: Quote from: MarkL on March 23, 2021, 11:00:01 pmof course IDA can`t generate C source code for HPUX binary, and it can disassemble only one executable file, to complete the picture need to consider at least lib16534.sl and libWorkspace.sl...I'm studying the question of how to add libraries to the project..And you right, the game is not worth the candle, but I'm just curious and I do it in my spare time..

author: MarkL
author_rank: Unknown
timestamp: March 24, 2021, 04:52:09 pm
content: Quote from: rtr989 on March 24, 2021, 02:50:44 pmRight, I wasn't suggesting it can re-create the C code, but I was thinking you could start to insert some profiling or other tracking methods into the assembly and load that.There's an interestingly named symbol called "read_data__6HWFISOFUii" and maybe IDA identified that as a subroutine. "FISO" is a term used for the ADC's on-chip buffer (Fast In Slow Out), so this might be a routine which reads the data from the ADC. Possibly it's a place to start. It might also be possible to set a breakpoint there (or in other places) with the debugger and dump the stack to start to get an idea of the callers' identities.

author: MarkL
author_rank: Unknown
timestamp: March 24, 2021, 10:38:51 pm
content: I said:Quote from: MarkL on March 24, 2021, 04:52:09 pmSeems that adb doesn't support shared libraries, but dde does and it's much more pleasant to use. There's a menu option under "Execution" and you can turn on debugging for specific loaded libarires (in this case lib16534.sl).It will also disassemble the code for you around the execution point, but it's still rather raw. I've never used IDA but I understand that it tries to comment the disassembled code. Maybe looking at the IDA output at the same time while working with dde will be more useful.In a very cursory play with dde, it seems that much more often than not, when the scope is running and I randomly interrupt vp, it's in \\HWFISO::read_data(). It could be an indication that it's spending a lot of time collecting data from the scope card. On the other hand there are some suspiciously named callers on the stack like "timedRunEvent" which might have a role in pacing the acquisitions.All food for thought.