Keithley TSP reference material

[imageel]

Hi new member to the EEV forum, but long time lingerer!
I have a DMM6500 bought new back in 2019 for developing some ultra-low power consumption Arduino type devices for a low volume remote telemetry project which was AA battery powered with battery life >1y, so needed something to measure low uA.

Years later am trying to profile some other kit and wanted to script the process and allow later PC analysis of the captured data.
I originally had the Keithley TSB app and recollect whilst it worked ok it was a little cryptic to use, and now I see that s/w is deprecated  in favour of using Visual Studio Code + a tsp plugin.
I have used VS before - I used the PLATFORM IO plugin to develop IoT code, however the Keithley plugin does not appear to support the DMM6500, so whilst I can connect via a LAN/USB my DMM it offers no assistance wrt commands that are supported.

I have browsed GitHub and picked up a few hints to perform basic setup and reading of data using PYVISA via Python and I wondered if there was ever published an API or similar reference document that would allow me to write some more sophisticated scripts, such as those published by Cuneyt Ozdas

[tooki]

:following:

[HKJ]

If you want to log from the meter you can use TestController, it is free.
Discussion: https://www.eevblog.com/forum/testgear/program-that-can-log-from-many-multimeters/
Download: https://lygte-info.dk/project/TestControllerIntro%20UK.html (Bottom of page)

TestController can do a lot more than logging, including scripting.

[imageel]

Hi thanks - I saw the thread wrt TestController, however it is using scpi and not tsp - so would likely not be fast enough for my intended use-case.
Out of interest what is the maximum sample frequency you can achieve using it?

I have the bare-bones of a script to do what I want written using pyvisa and tsp and I just wondered if some of the functions such as those listed by typically Keithley engineers on GitHub were in fact documented somewhere...

[HKJ]

Hi thanks - I saw the thread wrt TestController, however it is using scpi and not tsp - so would likely not be fast enough for my intended use-case.
Out of interest what is the maximum sample frequency you can achieve using it?

TC can sample up to about 100 samples/sec, but not with a DMM6500, there the rate is slower. Each command must return one sample and that limits the rate.
You could probably make a TSP interface for the meter in TC, but the rules are the same, i.e. one sample for each command and up to 100 commands/sec.

[KungFuJosh]

You should look at LUA in addition to TSP. That will give you a better idea of what the meter is capable of.

That said, I use TestController for anything related to logging, especially over longer periods of time.

How frequently are you trying to sample? You can certainly get multiple samples per second.

I attached a ~2 minute test sampling at .01 second connected to my DAQ6510.

Thanks,
Josh

[imageel]

Ah.. I was looking at 1000+ samples/s, so will maybe look at lua - have used that in the distant past...
I know I'll likely need to switch to a USB2 connection to transfer the data as opposed to the rather pathetic 100baseT ethernet connection, however that isn't an issue for my use-case.

Stepping back a bit - Is it the case that Keithley have not published any reference docs or API for this DMM?
I'll admit over the years I had assumed a lot of the published scripts, albeit fairly basic were in fact 'reverse engineered' from such scripts that Keithley Engineers have published - I deduce that this may well be the case...

[HKJ]

Ah.. I was looking at 1000+ samples/s

For that you probably need a local script that uses two buffers: Collect to one, transmit the other. That may get you well above 1000 samples/sec, maybe even above 10000+ samples/sec (The meter has a high speed sampling circuit with reduced resolution).

[KungFuJosh]

Just curious, what do you need to see 1000/s for?

For Lua learning, go to the site: https://lua.org/start.html

[imageel]

In my retirement I joined an open source project who are using SBC's -typically Raspberry Pi's attached to cheap security IP cameras that utilise OpenCV to characterise meteor paths - https://globalmeteornetwork.org/ - I know little about astronomy however I was intrigued by their novel use of OpenCV to perform this task.
I subsequently ported their ARM based s/w suite to vanilla x86 linux and enhanced it by enabling multiple cameras to be supported on a single host be it a 10y old laptop or more modern kit.

Tangential to this involvement  I noticed how a large number of the largely non-tech global participants - they for sure are astro-nerds but know diddly-squat about IT, were reporting weird problems a lot of which were as a result of using cheap sometimes no-brand wall-wart psu's, and one day I idly set up a RPi 4 I had to hand and using a 0.1 ohm shunt I measured the active current consumed and was surprised at how spiky it was - with my DMM6500 it was easy to see the dramatic spikes in power draw - even something as innocuous as from a remote ssh session, issuing  an ls on an otherwise idle system.
So I would like to be able to record over a typically ~8hr period the power draw during an overnight capture and the subsequent post-capture process that is known to cause heavy resource utilisation on an RPi - users who have these units running in airtight enclosures frequently report data quality issues due to the RPi getting so hot it triggers the on-chip thermal protection throttling.

So this characterisation of the power profile is what I would like to achieve and due to the unexpectedly spiky nature of the power-draw I want to use sampling in the order of 1k/s so as not to miss likely transient events.
As far as I can tell no such analysis has been undertaken or published, so there is all manner of almost 'folk-lore' surrounding the most suitable minimum psu specs required for stable running.

I appreciate that this perhaps is seen as largely academic exercise in that one could solve the problem just by over-speccing the psu you choose, however that is ignoring the fact that some of these recording stations operate in very remote off-grid locations such as desserts etc and so use solar/battery based power sources, principally because such places offer very low levels of light pollution.

[HKJ]

The internal buffer in DMM6500 is fairly large and I believe you can easily store 1 hour at 1000 samples/sec in it. The question is how to get it to a PC. I do not believe TC has a function to get the buffer (If someone want to add that it would be nice).

There is also PC based specialized tools to measure DC power consumption/fluctuations, they can generally log very fast and handle a huge current range.

[imageel]

Many thanks for all the helpful replies.

I have read enough sample scripts to cobble together a high sample rate collector and transfer that data to a PC host for later analysis - I perhaps naively thought that there was somewhere published a more comprehensive reference guide as to the likely machine-specific limitations and the supported functions !

I'll perhaps post back when I am done with the results - I'll admit I was not expecting such transient peaks in the current draw - I guess this is a feature of the regulator designs typically used on such kit that have relatively low value capacitors in their paths and thus my old-school and largely audio based PSU experience is not applicable !!

[KungFuJosh]

From your description of the issues, I wonder if an oscilloscope might be more helpful? Rather than being forced to go through 28.8 million samples yourself (1000/s x 8 hours), you can setup the appropriate trigger on a scope to sample the errors, and/or run a pass/fall test count.

[imageel]

I do have a Picoscope 5254 MSO - so could go down that route, however given that 'out-the-box' the DMM6500 can capture and graph at the resolution I need, I just wanted to script it and utilise PC based tools to simplify the subsequent processing/analysis.

TBH as a long time Linux user I know it is super simple and quick to use even basic shell commands to manipulate this type of data - when I last worked it was commonplace to have to sift through Gig's of data from log files from distributed datastore nodes - 100's of Hadoop servers, and the like to look for and summarise specific events, so that aspect is of little concern to me !!

However thanks to all who have offered suggestions and advice - they are all super useful !

/Ed

[Richard W.]

Hi Ed,

my experience with TSP is "limited" to using it with a 2601A Source Meter, but the concept is the same.

Insted of trying to program some kind of live data-transfer to a PC i would simply log all the Data into the reading buffer and then save the buffer as CSV to an USB-Drive.

This could be done with a TSP-Script (which you can write in any editor and save on the USB-Drive), or you can do it manually.
Should be easier on the Graphic Screen than on the 2 Line Display of my 2601A.

On the SMU its a matter of activating the buffer, defining its size/number of samples, trigger it and its logging until the defined count of samples is reached or the buffer is full.
Scan-Rate is defined by NPLC of the measurement and the Delay between measurements.
Afterwards save to USB as CSV.

This CSV can then be importet into any spreadsheet.

Super easy and super fast on the 2601A; i would be surprised if it would not work with a DMM6500.

I had a quick look at the DMM6500, it should be that easy: https://www.tek.com/de/manual/model-dmm6500-6-1-2-digit-multimeter-user-manual


Regards
Richard

[Brad O]

Stepping back a bit - Is it the case that Keithley have not published any reference docs or API for this DMM?

The API is in the DMM6500 Reference Manual, chapters 13 & 14: https://download.tek.com/manual/DMM6500-901-01B_Sept_2019_Ref.pdf
There are some other supported, but not documented, features inherited from Lua 5.0. Like most of the 'math' library or the 'table' functions: https://www.lua.org/manual/5.0/
The officially-unofficial commands to control the display on the touchscreen instruments like the DMM6500 are only documented on GitHub: https://github.com/tektronix/keithley/tree/main/TTI_Apps/TTI_Display_API

[imageel]

Many thanks to all who have responded - I think I now have enough information to achieve what I want - and I do appreciate perhaps a more sophisticated oscilloscope would be a more appropriate tool for the task, however my days of investing in new test kit are long gone !!

Equally, and quite whether this is a correct interpretation - when I purchased the instrument to assist in developing ultra-low current metrology devices it seemed to me that the DMM6500 kinda spanned the meter-'scope domain and as-such it was the ideal tool to enable me to develop power efficient code.

Many thanks once again to all who replied - the last two posts by Richard W. and Brad O have assisted me greatly in both structuring my approach and better understanding the instrument API

/Ed