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?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:
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.
(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)
Frequency_# is just a marker for frequency number. simply switch it to decimal.
(Attachment)
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)
how did you get so many lines of Frequency# ?
err = fft.createAnalogData(fftDS, "FFTdB", -50, +150);
for (i = 0; i < range / 2; i++) {
fft.replaceNext(20 * log10(fftA1[i]));
}
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.
Are you saying you get 2 waveforms/sec over X11 (not VNC)?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.This depot has lsof for HP-UX 10.20:
I need to find out which process is accepting connections on port 6500 of the RPI interface.
telnet <whatever IP>
user: root
password: uh,uhuh
mkdir -p /tmp/.scope
touch /tmp/.scope/DebugScope
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.
telnet <whatever IP>
user: root
password: uh,uhuh
mkdir -p /tmp/.scope
touch /tmp/.scope/DebugScope
where did you find this info
[attach=1]
Are you saying you get 2 waveforms/sec over X11 (not VNC)?
Many thanks! :) il get lsof, works fine!
This depot has lsof for HP-UX 10.20:
http://mirrors.develooper.com/hpux/downloads.html (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!
...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'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?
please explain this.. :)
I figured out the debug procedure by running strings on lib16534.sl.
"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.I figured out the debug procedure by running strings on lib16534.sl.please explain this.. :)
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?of 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...
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.
...Right, 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.
of 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..
...
...
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.