need a fast sample-rate DMM with scpi or other open protocol

[linux-works]

I'm looking for something that will give me volt, current (etc) samples, ideally over rs232 or ttl serial, at 10samples/sec or better.  accuracy needs to be 4.5digits or so, not super critical.

maybe my python DIY code is not so great; or maybe its my meters being kind of old, or maybe I need better scpi-fu.  meters I have access to are fluke 45, hp 34401, keithley 2015.  all have db9 serial ports on them, I am able to poll them for values and get nice values back, but I'm getting only about a sample per second.  I want at least 10/sec.

I can buy new equip (I'm using my own, for now, but at work we have some budget for new gear).  I don't need 5.5 or 6.5digit resolution, although if 10hz samples can be had, that would be great.

any ideas?  should I be able to get what I want from my older gear?  or do I need to find new stuff, maybe using ethernet for i/o?

[tautech]

The baby of the SDM3000X series can do what you need.
https://www.siglentamerica.com/digital-multimeters/sdm3045x-digital-multimeter/

[voltsandjolts]

I don't have a 34401 but it should be able to do at least 10 sample per second if you reduce NPLC appropriately. Maybe it is set to 100 (slow) at the moment?

[voltsandjolts]

Manual says GPIB is faster but RS232 is still 50 reading per second.

[plesa]

If you needs really fast readout use GPIB or Ethernet.
But for usecase 34401A is enought. Post commands used and meter setting.
I made comparison between 34411A/34410A meters while ago and even with 34401A you should be able to be close to paper spec (55 samples/s).
In RaspberryPi logging thread is link to Github with some python examples.

[linux-works]

I will fetch my code and post it when I get a chance (at work, not at home).  its simple synchronous code, though; some sleeps of about 0.1sec between doing python-serial ser.write() and ser.read(20).  20, just to pick some buffer size.  I'm sending '\r\n' and I'm not getting beeps when I poll the 34401a.  when I was writing the code, I'd put the meter into 'syst:rem' mode and then do 'meas:volt:dc?' and get back a string that was in EE format.  I simply add a unix epoch integer timestamp to the line, print() them and go back to asking the meter for the next value.  very simple, dumb, synch code. I know it could be a lot better, but I don't get more than about 1 sample per sec.  the meter is at 6.5digit mode, and when I try to lower it (via the front panel) I get beeps when I use the same python polling code.  seems strange, but I did not spend a lot of time on that, yet.  maybe the python code is resetting any front-panel 'resolution' setting I made and always going with 'slow' update mode?  on my fluke 45, I can choose S, M or F update mode and the display surely updates as fast as I want, but my poller over 9600serial still seems to be about 1sample/sec.

are people really getting 10 and even 50/sec over 9600 rs232?  if so, then I won't give up on these meters quite yet.

I prefer the simplicity of ethernet/ip (to me, its simpler than worring about which db9 cable to use with which gear!).  I'd also really want it to be battery powered (isolated, portable).  we can use inverters, but the use-case is to do some testing in a car (while on the road) and if we can run from our own battery power in a handheld, that helps logistics a lot.

I have some agilent 5.5digit dmm's that I got for work and they have an opto interface, but the dmmutil that I've tried also seems to be about 1s/sec.  and for some reason, agilent EOL'd that opto serial/usb cable and its hard to find, now.  the meter is great, other than it needs a custom opto cable, it does not lie flat (sticks out the rear of the meter at 90deg), and its not really reliable enough to trust the connection in a bouncy car ride.  having cables that latch or screw together and form a fast polling or streaming interface would be the most ideal.

I don't know if bluetooth is fast enough or reliable enough, but a wireless connection would also be acceptable, as long as I can have several sessions of that type going at the same time and have them not see each other or be affected by each other.  we want to have 2 or even 4 measurements going on at the same time (for now), so having each pair of things (end points) be wireless seems a bit much.  cat5 ethernet into a switch and using IP and maybe REST commands, that would be the best thing I could imagine, but I'm not sure any handhelds do -that-, do they?

[plesa]

There should be no beep during remote control, it indicate there is error.
It is while ago when I made some experiments with fast readout,It was made in LV but we can transfer it to Python easily.