EEVblog Electronics Community Forum
Products => Test Equipment => Topic started by: User2938 on November 13, 2018, 06:33:34 pm
-
I recently acquired a Keithley 2015-P for performing measurements on audio devices, and in the interest of taking full advantage of the capabilities of the meter, I’ve been doing some experimenting to try to figure out how useful it actually is. The best info I could find on the remote functionality was from forum posts started by G0HZU and 2bluesc, but some of the information there seems to be incomplete, so I’ll supplement their posts with the results of my experimentation.
**Caveat Emptor: The information below may contain errors or even be entirely wrong, so please feel free to correct me if you have a better understanding of the software or hardware than I do. **
Hardware: Based on info from Dave’s teardown and the service manual, it seems that the distortion measurement section of the meter uses an AD7722AS 16-bit (up to 90.625kHz) ADC for Vrms measurement (this is a separate ADC from the rest of the front end). The clock frequency for sampling is generated by an AD9850 clock generator, and the frequency is set by the DSP. The sampling rate for the signal voltage can be adjusted with high resolution, as the AD7722AS sampling frequency is linearly proportional to the input clock frequency generated by the AD9850. The signal generator part of the meter also uses a separate AD9850 as a DDS generator, this is a 10-bit DAC for generating the audio sine waves. Two things I like about this meter for audio testing is that the generator outputs are isolated from earth ground, and there are two outputs, which facilitate testing of balanced audio inputs. The meter inputs are obviously also isolated from ground, but also isolated from the generator outputs.
Remote Spectrum Analysis: In order to determine how the meter performs its spectrum analysis, I used Matlab scripts for control, access and plotting of the data. For best accuracy, the meter takes the FFT of the incoming waveform (depending on settings) using 1023 bins (actually 1024 but the last one is always out of range for some reason) after measuring the input frequency and voltage of the incoming signal. The resulting spectrum is then used to calculated THD, THD+N, and SINAD. However, the way the data is sampled is not at all transparent, and the FFT results require some speculation to interpret.
The 2015-P meter supposedly differs from the 2015 meter by the addition of “Peak” commands for getting magnitudes and frequencies of individual FFT bins … the thing which negates their usefulness, however, is that to use them, you’re forced to set the FFT bin frequency to 20Hz (which turns off the automatic frequency measurement), giving a max FFT frequency of 20460Hz. If you want to use the FFT data to do your own calculations, for example, then you’re forced to use test frequencies that are multiples of the 20Hz frequency, since as far as I can tell, the meter doesn’t implement any kind of windowing (I’m no expert here, but I’m guessing that’s a good thing).
To illustrate, attached is the FFT result I got from the meter using the :DIST:FFT:BINS? 1, 1023 command (in blue) on an incoming 1210Hz sine wave, with the bin width set to 20Hz. In red is the result of performing an FFT in Matlab on a sinewave sampled at 40960Hz for 0.05sec, or 2048 samples. THD+N numbers on this measurement would be off, since the peak fans out due to there not being an even number of periods. This is definitely something to be aware of, so it would have been nice if there were more control over the bin widths.
The much more annoying aspect of the spectral analysis is that if you use the :DIST:FFT:BINS? command on a signal with automatic frequency measurement active, while you get an accurate response, there is no command to get the bin frequencies. The :PEAK:LOC? command doesn’t work under these circumstances, so you can get the FFT with accurate harmonic/noise values, but you only have bin numbers and no idea as to how Keithley actually does the frequency calculations.
To experiment with this, I used a signal with an expected harmonic response (square wave) from a Siglent 1032X, and used the predicted harmonics (1st, 3rd, 5th, etc) to determine bin widths, number of samples and sample rates. First of all, while the claim of a 20Hz-50kHz measurement bandwidth is true, this is not the case for all acquired input frequencies, and Keithley doesn’t do a great job of explaining this. A different sample rate and number of samples is used for each auto-acquired input frequency to ensure an even number of periods. For example, a 50Hz signal uses 1000 bins, for a max FFT frequency of 50kHz, whereas a 70Hz signal uses 1023 bins for a max FFT frequency of only 35805Hz.
As a test, I created a spreadsheet of values from different square wave tests and calculated sample rates, number of samples, etc. to see if I could find some kind of correlation/equation for how Keithley calculates these. To verify that my hypothesis is correct, I plotted a matlab calculated FFT on a theoretical square wave (with same characteristics) using the values I calculated, and they seem to line up quite well. My second attachment is a random square wave test.
In this case, I’ve converted the Keithley’s dBc to volts and superimposed the frequencies I’ve calculated from the bin widths using what they should actually be in theory, and the Keithley and matlab models agree. I ASS-U-ME that since the meter measures the input signal frequency quite accurately, that the bin centers would be on some multiple of this, but without having access to the firmware, it’s impossible to know 100%. According to my calculations though, the Hz/bin is always related to the input frequency by the integer number of sampled periods.
Here is where I’m hoping someone can look at my data (attached) and chime in... anyone have any more insight into how to accurately determine the FFT bin frequencies for any input signal? Or how they think Keithley likely calculates the sample rate/periods/samples for calculating the FFT? Access to Keithley firmware would be cool too ;)
-
Decided to revisit this -
When taking the FFT of any repeated wave, it seems the Keithley calculates the number of bins used in the FFT as follows:
#bins = (50000 x (#Sample Periods)) / Input Frequency. This value is rounded down to the nearest integer, or to 1023 if higher than 1023.
Then, #Samples = 2 x #bins
Sample Rate = 2 x Input Frequency x #bins.
This works for all of the square waves I tested.
Still can't figure out how it decides on the number of sample periods of the waveform though, I'm guessing it has something to do with the measured frequency, the max sample rate, and/or the max number of samples, or total sample duration.
-
You have made some good progress on getting results from your meter. I have one, not the P model, and have not been able to get a spectrum from it yet. I would really like a set of the P roms as i'm sure others here would as well.
I made some modest progress on an automated test sequence for it but ran out of steam on that project before it was complete. https://github.com/1audio/Keithley-Windows-10
-
Any chance someone can post the ROM of the P revision of Keithley 2015? I assume that the difference between the 2015 and 2015P is only in the ROMs.
-
I recently acquired a Keithley 2015-P for performing measurements on audio devices, and in the interest of taking full advantage of the capabilities of the meter, I’ve been doing some experimenting to try to figure out how useful it actually is. The best info I could find on the remote functionality was from forum posts started by G0HZU and 2bluesc, but some of the information there seems to be incomplete, so I’ll supplement their posts with the results of my experimentation.
**Caveat Emptor: The information below may contain errors or even be entirely wrong, so please feel free to correct me if you have a better understanding of the software or hardware than I do. **
Hardware: Based on info from Dave’s teardown and the service manual, it seems that the distortion measurement section of the meter uses an AD7722AS 16-bit (up to 90.625kHz) ADC for Vrms measurement (this is a separate ADC from the rest of the front end). The clock frequency for sampling is generated by an AD9850 clock generator, and the frequency is set by the DSP. The sampling rate for the signal voltage can be adjusted with high resolution, as the AD7722AS sampling frequency is linearly proportional to the input clock frequency generated by the AD9850. The signal generator part of the meter also uses a separate AD9850 as a DDS generator, this is a 10-bit DAC for generating the audio sine waves. Two things I like about this meter for audio testing is that the generator outputs are isolated from earth ground, and there are two outputs, which facilitate testing of balanced audio inputs. The meter inputs are obviously also isolated from ground, but also isolated from the generator outputs.
Remote Spectrum Analysis: In order to determine how the meter performs its spectrum analysis, I used Matlab scripts for control, access and plotting of the data. For best accuracy, the meter takes the FFT of the incoming waveform (depending on settings) using 1023 bins (actually 1024 but the last one is always out of range for some reason) after measuring the input frequency and voltage of the incoming signal. The resulting spectrum is then used to calculated THD, THD+N, and SINAD. However, the way the data is sampled is not at all transparent, and the FFT results require some speculation to interpret.
The 2015-P meter supposedly differs from the 2015 meter by the addition of “Peak” commands for getting magnitudes and frequencies of individual FFT bins … the thing which negates their usefulness, however, is that to use them, you’re forced to set the FFT bin frequency to 20Hz (which turns off the automatic frequency measurement), giving a max FFT frequency of 20460Hz. If you want to use the FFT data to do your own calculations, for example, then you’re forced to use test frequencies that are multiples of the 20Hz frequency, since as far as I can tell, the meter doesn’t implement any kind of windowing (I’m no expert here, but I’m guessing that’s a good thing).
To illustrate, attached is the FFT result I got from the meter using the :DIST:FFT:BINS? 1, 1023 command (in blue) on an incoming 1210Hz sine wave, with the bin width set to 20Hz. In red is the result of performing an FFT in Matlab on a sinewave sampled at 40960Hz for 0.05sec, or 2048 samples. THD+N numbers on this measurement would be off, since the peak fans out due to there not being an even number of periods. This is definitely something to be aware of, so it would have been nice if there were more control over the bin widths.
The much more annoying aspect of the spectral analysis is that if you use the :DIST:FFT:BINS? command on a signal with automatic frequency measurement active, while you get an accurate response, there is no command to get the bin frequencies. The :PEAK:LOC? command doesn’t work under these circumstances, so you can get the FFT with accurate harmonic/noise values, but you only have bin numbers and no idea as to how Keithley actually does the frequency calculations.
To experiment with this, I used a signal with an expected harmonic response (square wave) from a Siglent 1032X, and used the predicted harmonics (1st, 3rd, 5th, etc) to determine bin widths, number of samples and sample rates. First of all, while the claim of a 20Hz-50kHz measurement bandwidth is true, this is not the case for all acquired input frequencies, and Keithley doesn’t do a great job of explaining this. A different sample rate and number of samples is used for each auto-acquired input frequency to ensure an even number of periods. For example, a 50Hz signal uses 1000 bins, for a max FFT frequency of 50kHz, whereas a 70Hz signal uses 1023 bins for a max FFT frequency of only 35805Hz.
As a test, I created a spreadsheet of values from different square wave tests and calculated sample rates, number of samples, etc. to see if I could find some kind of correlation/equation for how Keithley calculates these. To verify that my hypothesis is correct, I plotted a matlab calculated FFT on a theoretical square wave (with same characteristics) using the values I calculated, and they seem to line up quite well. My second attachment is a random square wave test.
In this case, I’ve converted the Keithley’s dBc to volts and superimposed the frequencies I’ve calculated from the bin widths using what they should actually be in theory, and the Keithley and matlab models agree. I ASS-U-ME that since the meter measures the input signal frequency quite accurately, that the bin centers would be on some multiple of this, but without having access to the firmware, it’s impossible to know 100%. According to my calculations though, the Hz/bin is always related to the input frequency by the integer number of sampled periods.
Here is where I’m hoping someone can look at my data (attached) and chime in... anyone have any more insight into how to accurately determine the FFT bin frequencies for any input signal? Or how they think Keithley likely calculates the sample rate/periods/samples for calculating the FFT? Access to Keithley firmware would be cool too ;)
Hello Sir. Im trying to add an FFT plot to my keithley 2015 programs here:
https://github.com/andmarti1424/free_keithley
Does the bin width in the Keithley have to be always set to 20Hz for this to work?
Thank you.
-
@User2938 ?
Can you confirm about the bin width?
Thank you!
-
It would be good to change the window algorithm.
Signal looks a bit noisy, as opposed to Analog Discovery 2..
see pictures attached.