I have been seeking a low frequency recording spectrum analyzer in order to measure the phase noise of some typical hobbiest 10 MHz oscillators (see
this thread for more information). Since such an instrument has other uses than phase noise characterization, I decided to start a new thread to document my experience.
The approach I eventually settled on uses a PicoScope 4262, which includes a FFT-based spectrum analyzer measuring spectra from 0 Hz - 5 MHz. It supports 10 MS/s with 16-bit precision, which makes it capable of measuring signal voltages down to ~40 nVrms. This level of sensitivity is necessary for my application.
This post is not a detailed review of the PicoScope 4262 spectrum analysis capabilities. Others on the EEVBlog have provided an excellent review of the PicoScope FFT capabilities (see
this thread). The objective of this post is to document some problems with the spectrum analysis functionality of the 4262. Fortunately, these problems all have workarounds, which means that the 4262 is a suitable instrument for my purpose.
This post summarizes three threads on the PicoScope forum, specifically,
this one,
this one and
this one. I would like to acknowledge the help of Gerry, a Picotech technical specialist, in working through the issues I raised. His responses to my questions were not only thoughtful, but also well-written and very professional.
Finally, it is possible these problems will be fixed at some future date, so I will document the version information for both the hardware and software used for testing as well as the test setup parameters:
PicoScope 4262 Hardware:
Hardware Version: 1
Calibration Date: April 9, 2018
Firmware Version: 1.0.5.0/1.1.4.0
Driver version: PS4000 Linux Driver 2.1.0.570
PicoScope Software: PicoScope 6.13.7.707
Test setup:
Number of bins: 1,048,576
Number of samples: 2,097,148
Span: 0Hz - 200 KHz
Hanning window
Y-axis units: dBV
Bin width: 190.7 mHz
Input voltage range (selected using the scope settings): +/- 10 mV
AC coupling
Time gate: 5.243s
The first issue is hardware related. The PicoScope 4262 is a USB oscilloscope with spectrum analysis capabilities. Obviously, this means the PicoScope hardware is connected to a host computer using a USB cable. Unfortunately, it is strongly susceptible to EMI inteference. This is clearly illustrated in Figure 1.
Figure 1
This spectrum is of the 4262 with 50 ohm terminator on Input A. In other words, it is measuring the noise floor of the instrument. In the EEVBlog review mentioned above, some mention was made of EMI interference on the coax cables used to feed the signal to the oscilloscope. Since no coax cables were involved in this test, I wonder if these reviewers were observing EMI interference on the usb cable? Perhaps not, but it is an interesting question.
EMI at 51KHz and its harmonics is clearly apparent in Figure 1. As it turned out I had the usb cable hanging near the computer's power cable, which induced the spurs shown. The first thing I did was replace the usb cable supplied by Picotech with a multi-shielded usb cable employing a ferrite choke at one end. This did not solve the problem. Gerry, the tech specialist mentioned above, indicated that the usb cable they supply is multi-shielded. So, the only way to solve this problem is to route the usb cable well away from any power sources. This solved the problem (see Figure 2).
Figure 2
The usb cable supplies power to the 4262. I am no expert on EMI management, but I wonder if better power-supply bypassing on the 4262 hardware might fix this problem. Another workaround is to connect the 4262 to a laptop running off battery.
The remainder of the problems were software bugs or missing features. This is encouraging, since fixing software problems doesn't require buying new hardware (currently, software updates are free).
The software application supplied by Picotech is the PicoScope 6. It runs on Windows, Mac OS and Linux (for the latter two, the software is in beta). However, the Windows version is more advanced than the Mac OS and Linux versions. In particular, on the Windows version, when selecting logrithmic power (dBm) for the Y-axis, it is possible to specify the power-calculating resistance, i.e., 50 ohms, 75 ohms, or 600 ohms. This feature is not yet available on the Mac OS or Linux versions. The dBm calculation assumes a terminating resistance of 600 ohms. The workaround is to select the Y-axis units to be dBV. It is then possible to square this value (since it is in logarithmic units, multiply it by 2) and divide by the appropriate resistance value to obtain a valid dBW or dBm measure (the latter, of course, requires scaling the voltage value to milli-volts).
The tech people on the Picotech forum stated that there is a project to bring the Mac OS and Linux versions into line with the Windows versions. So, in the future the Windows, Mac OS, and Linux versions should be the same (how far in the future is anyone's guess).
The second problem is when producing csv formated captures of the spectrum, the PicoScope 6 software generates redundant files when averaging is used. That is, when selecting averaging from the spectrum view menu, more than one file is produced. These files are identical. The workaround is easy, just ignore the redundant files. The only downside is the necessity of cleaning up the redundant files (which may be fairly large - the files generated using the parameters specified above are 55.5 MB).
Another problem is when saving the spectrum in csv format, the software saves both the positive and negative frequency data of the FFT algorithm. Since these values are identical, this makes it appear that the software is saving the (positive frequency) spectrum twice. Furthermore, the two copies are not identical. For example, using the parameters specified above, the spectrum has 1,048,576 bins.
However, loading the file into Octave and examining it, yields the following. The first 3 rows are:
3.81470000000000e-04 -1.32426300000000e+02
5.72200000000000e-04 -1.35356700000000e+02
7.62940000000000e-04 -1.35783900000000e+02
Row 1048571 to 1048576 are:
199.999237060000013 -162.893100000000004
199.999427800000007 -162.989699999999999
0.000000000000000 -73.301040000000000
0.000190730000000 -82.329089999999994
0.000381470000000 -132.426299999999998
0.000572200000000 -135.356699999999989
Note that the second copy of the spectrum includes the DC component and the second bin, which doesn't appear in the first copy.
The last 3 rows of the files are:
199.999427800000 -162.989700000000
199.999618530000 -163.570100000000
199.999809270000 -164.225900000000
Note there are two bins at the end of the second copy of the spectrum that don't appear in the first copy.
The workaround for this is straight forward. Use the second copy of the spectrum (throw away the DC bin and the last bin, since the information they contain are not equivalent to that in the other bins).
The last problem is more of a puzzle than a legitimate problem. If you use Excel to load the csv file, it will truncate the file at the 1048573rd row, give you a warning that the whole file has not been loaded and present the first copy of the spectrum with the DC bin at the end. This caused confusion when working with Gerry to figure out what was going wrong. However, it is easy to see that the file contains two copies of the spectrum. Open it with a text editor that shows line numbers (e.g., textedit on Windows, bbedit on Mac OS, or gedit on Linux). there are clearly 2097151 lines in the file (3 of these are header information).
One final issue needs to be addressed. It is not a problem with the 4262 software or hardware. Rather it concerns how to combine frequency bins produced by an FFT spectrum analyzer.
In the above example used to illustrate some of the problems with the 4262, the width of each FFT bin is 190.7 mHz. In some cases, when presenting a spectrum for discussion, one first "normalizes" the bin width to 1 Hz. Frequently, with analog spectrum analyzers, the minimum resolution bandwidth is greater than 1 Hz, so this requires dividing the observed value by a constant to normalize this value to 1 Hz. For example, the Siglent SSA 3032X has a minimum RBW of 10 Hz. To convert the observed power in a bin to a 1 Hz normalized value, the power is divided by 10; or equivalently if power is expressed in dBm, subtracting 10 dB from the value.
When bins are narrower than 1 Hz, the power in each bin must be added together to obtain a 1 Hz normalized value. However, the windowing function associated with an FFT spectrum causes leakage between bins, so their values are inflated. To obtain an accurate 1 Hz value requires adding bins and then dividing by the noise power bandwidth associated with the window (see section 4 of
this paper for a more detailed treatment of FFT spectrum computations).
Each window has a different associated noise power bandwidth. Table 3 in the above referenced paper provides the value associated with some common window functions.