The Keithley 2015 and 2016 audio analysing multi-meters. guide to behaviour, limitations and issues

*jamesmking* · May 9, 2022

This is a very niche topic so if you are not planning to buy or write programs for the Keithley 2015 or 2016 thd or p multi-meters then this post will probably not be interesting to you - especially given their skyrocketing prices on ebay and their age.

If you are planning to buy one because it has audio analysis built in then there are a number of limitations and issues you should be aware of before deciding to buy. Some of these limitations effect the accuracy and validity of its calculations and are not documented in the manual, some of the limitations effect usability and some effect it programmatically if you access it through gpib or rs232. If you look on the internet there is very little software written for these meters and you may be wondering why. Well now I have written some software for them I think I have a better idea...

Here is an example of the "quality" of the manual

"The Model 2015/2015-P/2016 can use up to the 64th harmonic of a signal (64 times the fundamental frequency) in the THD measurement, but only recognizes frequencies below 50kHz. Harmonics with frequencies above 50kHz are ignored, therefore acting as an adjustable lowpass filter."

What do you mean by use? are the ignored harmonics included in the background noise measurement? or are they simply ignored completely? Well it turns out thd+n included the harmonics as does SINAD. ( I'm still trying to determine for background noise since my calculations do not match the Keithleys). Similarly the statement about the upper frequency is ambiguous for multiple reasons. Bellow 50khz is included and above 50khz is ignored... what about exactly 50khz? more importantly what about a harmonic bin that starts before 50khz but ends after 50khz? or has its centre frequency at 50khz? The 50Khz limit is NOT adjustable and is absolute. There is a separate low pass filter which is configurable and can be switched on and off. Once you dig into the detail the descriptions in the manual leave more questions unanswered than answered.

Limitations

the in built signal generator goes from 10hz to 20khz only and is flat to within only 0.02db it also has a noise spike at 10khz average noise is about 50uV noise spike is more than 350uV....
thd measurement is limited to a maximum of 64 harmonics. This means if you are measuring the thd a 20hz input, the bandwidth of the thd measurement tops out at 20hz*64 harmonics i.e. way bellow 5khz.. However, Sinad and thd+n not limited to 64 harmonics.... this is obviously inconsistent behaviour and if the harmonics higher than the 64th are large in magnitude then the thd will be underestimated but the sinad and thd+n will be good...
it is possible to limit the number of harmonics calculated in the thd to less than 64 using the front panel or programmatically but this does not effect sinad or thd+n calculations. But if you do limit the harmonics and then programmatically ask for all the harmonics any above the limit are not returned - they are lost forever.
thd cannot be measured for inputs bellow 20hz or above 20khz
all audio analysis is bandwidth limited to 50khz or lower (in some cases the bandwidth limit is 20khz due to the limited number of fft bins) and it is not possible to get the actual bandwidth limit via the front panel or programmatically. If you want to know the upper limit you have to reverse engineer its behaviour - the behaviour is not documented.
The fft and harmonics are bandwidth limited to 50khz so if you measure a 20khz fundamental thd is calculated on two harmonics only and one of them is the fundamental!
the fft bin width automatically varies depending upon the input signal fundamental frequency for example at 20hz the bin width is 20hz at 1Khz the bin width is 66.6 recurring hz this is not documented and must be reverse engineered to workout the relationship between fundamental frequency and bin width. This is made more difficult when:
- it is NOT possible to get the bin width displayed on the screen of the keithley or get the bin width programmatically.
- it is not possible to get the starting or ending frequency of a bin
it is not possible to get the number of fft bins used in the thd, thd+n, sinad or noise calculations
it is totally unclear from the manual if the rms value for the signal returned in audio analysis mode is the rms value of the entire signal, the signal plus harmonics or just the first harmonic. The manual simply says the result will be different from measuring the ac volts value of the input... Extensive experiments seem to indicate it is the rms of the 1st harmonic.
The slowest part of a program communicating with the Keithley is transferring the fft bins especially using rs232. But the keithley does not provide a way for you to obtain the number of fft bins which contain valid data so you have to get all the bins. This increases an fft transfer time by up to 25% (in the case where bandwidth limits the number of valid bins) compared to only fetching the bins with valid data and the situation is far worse if weightings or low and high cut filters are used.
you can improve performance across the gpib bus by setting the keithley to transfer floating point numbers rather than number in their text representation however not all measurement returns actually support this so you have special cases all over your program to determine if it should be reading a float or the ascii representation of a float. The manual is also not accurate ascii rather than a float is returned in float mode.
If you apply a weighting filter such as C-message which only has a bandwidth from 60hz to 5khz the keithley does not reduce the fft bin width to provide higher FFT resolution. As a result, a 1khz input FFT with C-message results in only 300 valid bins out of 1023 and uses a bin width of 66.66hz when the keithley could have chosen a bin width of 33.33z and doubled the resolution.... or picked a bin width of 20hz and triple the resolution.
The weighting filters have brick wall filters attached which is not documented in the programming and user manual. However a promotional document for the keithley does have graphs for the weightings but the actually implemented brick walls are not consistent with the promotional material graphs for CCIR and CCIR/ARM. Experiments show the brick walls are at:
- CCIT low cut 50hz high cut 5khz
- CCIR low cut 31.5hz high cut 20khz - this is not consistent with the keithley promotional documentation which shows the weighting graphs and shows CCIR extending to 30khz
- CCIR/ARM low cut 31.5hz high cut 20khz - this is not consistent with the keithley promotional documentation which shows the weighting graphs and shows CCIR extending to 30khz
- A weighting low cut 20hz high cut 20khz
- C message low cut 60hz high cut 5khz
It is not possible to get the rms value of a harmonic or fft bin - the only option is to get the result in dbc relative to the first harmonic/fundamental frequency rms value.
there is a limit of 1023 fft bins as well as a bandwidth limit of 50khz which means some measurements are only performed on around 735 bins because the bin width is large for example 68hz and more than around 735 bins exceeds the 50khz bandwidth limit - the keithley does not try to minimise the bin width to maximise the resolution and the algorithms used are not documented. As a result at input frequencies bellow 50hz you run out of bins before you reach 50khz and above 50hz you run out of bandwidth and lose bins. The bin width behaviour is very dependant upon the fundamental frequency and so two frequencies close to each other can result in radically different bin widths.
you can manually set the bin width BUT if the largest input frequency is not a multiple of the bin width the FFT analysis produces poor results.
for input frequencies bellow 61hz the bin width equals the input frequency i.e. all fft bins are harmonics so measuring the noise is impossible since there are no noise bins... However, at least with my firmware, the keithley reports a bogus noise value for frequencies of 60.8 to 61hz even though all bins are fundamantals.
there are multiple features which you can only access programmatically:
- noise measurement (only for input frequencies above 61hz)
- fft bin values
- low and high cut filters
The keithley has a programmable capture window for acv measurements. A too long window results in slow readings, a too short window results in errors in calculating the frequency of the signal. This capture time is NOT programmable in audio analysis mode and is set to a too short value for low frequencies and results in frequency measurement errors at 20hz to about 30hz resulting in incorrect ffts and high distortion values
The signal generator is not particularly low noise or low distortion - about 50uV noise at 1V output and about 0.02% distortion (1khz 64 harmonics). My pc sound card analogue output managed almost an order or magnitude lower distortion when measured by the keithley.
The programming manual is misleading and varies in quality and detail from section to section. For example equations are provided for thd, thd+n and sinad but not for its noise calculation or its weightings e.g. A, C-message, CCITT etc. Nowhere does the manual mention fft bin width or number of bins varies with fundamental frequency or provide the equations to work out the number of fft bins or fft bin width for a given fundamental frequency - and reverse engineering this was complicated the algorithm changes 3 times over the frequency range 20 to 20khz...
For thd, thd+n and sinad I implemented the equations in the user/programming manual and came up with identical answers to the keithley to around 8 significant digits - the rest being rounding errors. For noise I assume all valid non harmonic bins are noise but my calculations do not match the Keithley... I get around a 1% underestimate so the keithley is finding extra noise from somewhere! But my thd and thd+n calculations match the keithley. If I calculate THD+n - thd should just be the noise and this matches the value I get from calculating on all valid bins minus the harmonic bins and still does not match the keithley. If the keithley was finding noise from somewhere then my thd+n calculation should not match the keithley. I.e. the keithleys (thd+n - thd) and noise calculations are not consistent with each other. Sinad also takes into account noise and again my sinad calculations match the keithleys.
The keithley has built in averaging but can only apply this to the thd measurement and NOT noise, sinad, thd+n, fft or harmonic measurements.
The keithley uses the SAME command to inform it of the fundamental frequency as it does to set the fft bin width (if you choose to hardwire the binwidth)! This has the effect that if you hardwire the bin width the keithley thinks that value is also the value of the fundamental frequency! it is also not possible on screen or programmatically after the fact to separately get and disambiguate the set hard wired bin width from the fundamental frequency - again the same command is used to get both!
if a low or high cut filter cut off frequency is part way into an fft bin the fft ban is not excluded. This is not documented.
However possibly my biggest issues with the keithley is that it appears that it does not store raw measurement values and then apply filters, weightings sinad, thd thd+n calculations. Instead it stores the final processed values so there is no way to undo a setting or examine how a setting effects the result. For example if you set a low or high cut filter this effects all calculations. Harmonic bins and fft bins excluded by the filters are lost forever and can not be recovered...
changing absolutely any setting invalidates the current reading and requires a new measurement to be taken!
- i.e. you cant change the weighting filter,
- cant change the low or high cut filters,
- can't change the measurement type from thd+n to sinad or vice versa,
- can't change the number of harmonics included in the thd calculation
- can't even change the returned thd and thd+n values from db to percent or visa versa.
- Absolutely any setting change results in you needing to make a new reading.

To summarise

The signal generator is poor, audio analysis is difficult to control, difficult to understand how it works under the hood, has multiple low frequency measurement limitations, only saves processed values is missing multiple commands for getting useful information about fft bins and has poor documentation on the detailed workings and interactions between settings - especially when multiple settings effect a calculation.

Conclusion

The keithley hardware is not an audio percision on the cheap.

I don't know if any of this will ever be useful to anyone, but I have said it now - perhaps this is more or a rant because of the amount of time and effort I have had to go through to reverse engineer its behaviour and algorithms. If you are insane enough to want to write program(s) for the Keithley I can provide you code for calculating the bin width vs fundamental frequency, number of expected valid bins returned vs fundamental frequency, etc.

P.S.

AC current limitations

the 2015 and 2016 also only have two ac amps ranges 1A and 3A so they are not great choices for low current ac measurement. In contrast the older and more humble keithley 197a has a AC current ranges from 200uA to 10A!

here is the frequency response of the keithley signal generator100 frequencies log sweep 10 measurements per frequency. notice at 20hz the standard deviation is almost 1mv on a 1v output and varies by 0.015db over the 10 readings . This is not the signal generators fault - it is a issue with the way the keithley measures frequencies bellow 30hz in audio analysis mode. If you measure in ac volts mode almost all of this variation is gone

here is the total thd vs frequency for the inbuilt signal generator. Again notice the disproportionally high thd at 20hz (10 times that of 1khz) and large variations in the 10 measurements min reading at 20hz 0.07% max at 20hz 0.14% at that frequency: The+n looks simular and other signal generators feed in to the keithley also show high 20hz thd and thd+n results.