Here's my working setup. The signal is a 10V reference with chopper spikes.
By zooming in, you can clearly see the 20µs / 50kHz sample spacing.
Currently I connected the instrument via USB, to avoid any network and firewall problems over the internal LAN network. (The 1 GBit LAN does work also, anyhow).
The highest rate of 50kHz can not be set consistently, sometimes I also get this limitation of 25kHz, or a forced trigger delay of 20µs, which I can not get rid of via BV.
Root cause, is that the 34465A is not set properly to DIGITIZING, but will stay in CONTINUOUS mode instead, which implements this 20µs delay.
I think, the initialization to fastest setting is not working correctly.
In this case, I set the instrument to local, and set it manually to DIGITIZING, zero delay, and so on.
If I select DIGITZING over BV afterwards, it will usually work, and you can now also set zero delay in the BV menu, as displayed.
If I use long samples as 1MSa or so, the digitizing and data transfer takes much too long.. obviously, the data were not transferred fast enough over the bus.
One problem is the wrong data format, ASCII, instead of binary (8 byte real number).
See command log, by using IOMonitor and command logging.
As a summary, BV is still not optimized for digitizing at fastest rates.
I recommend to get the 2M memory option (you'll get it for free, currently), and then sample at 50Khz directly into the instrument, creating a file afterwards, which you may import to PC over USB or LAN.
Frank
Update:
I have the 2nd DMM Pro license installed on a much faster machine, also USB, same problems. So the speed of the PC is not the crucial parameter.
It's working with 50kSa/sec, if I go to local <shift key> => <Acquire> => <Digitize>
If I chose 1MSa/Trigger , 1 Trigger, it takes 40sec instead of 20sec to digitize and upload.
It takes 3 minutes, if I set 1Sa/Trigger and 1M Triggers.
Root cause is also the simple READ command to transfer data: "R?"
This FiFo transfer, using the output buffer, slows everything down.
This has to be programmed differently, w/o buffering, directly reading, or DMA transfer, and again, using 8 byte REAL format, instead of 16bytes ASCII format.
Keysight should also change 34465A firmware to have the elder 4 byte REAL format available, like in the 34411A. (also for compatibility reasons)
Keysight anyhow uses the VISA / IVI interface and drivers for MatLab, where data transfer is probably not optimized for fast acquisition.
Or maybe they need to use a different command set / macro for DMA, I'm not familiar with that package.
Update II:
LAN, including several switches and central router seems to slow down transfer to 25kSa/sec.
Over USB, it works up to 2 MSa.
data transfer is about 100kB/s on the first 40s, where the 34465A is busy digitizing.
After that, data rate increases to about 700kB/sec, where 34465A can respond to data requests with full speed.
A 2byte integer format would be better, (like the 3458A), then the 34465A state machine would be able to transfer data in real time.
Digitizing sample depth with BV is limited to the depth of the 34465A internal memory (50kSa or 2MSa), plus a certain percentage of data transfer during the digitizing phase.
Additional samples will be skipped.
Home
Help
Search
Login
Register
