| Electronics > Projects, Designs, and Technical Stuff |
| Using a PicoScope 4262 as a low frequency recording spectrum analyzer |
| (1/3) > >> |
| dnessett:
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. |
| jpb:
I am interested in following the outcome of your experiments. I had a brief look at the earlier thread you referenced. Have you looked on Bill Riley's site: http://www.wriley.com/ Several interesting publications which are available either as free pdfs or you can buy the printed version pretty cheaply (this is what I've done). He also has now made his software available for free. Though he is more concerned with longer term oscillator stability while I think you are more interested in modeling phase. He does, in his book, cover different types of oscillator noise and how it shows up on various measures such as ADEV. I would have thought that the biggest problem you have is having a stable reference. Does the PicoScope allow an external reference? My thoughts along similar lines (I am very slowly designing a GPSDO and want to do measurements on 10MHz OCXOs) was to mix down to audio frequencies and use an Audio USB interface which has a Word Clock input which could be locked to the reference. |
| dnessett:
--- Quote from: jpb on November 27, 2018, 06:43:45 pm ---I am interested in following the outcome of your experiments. I had a brief look at the earlier thread you referenced. Have you looked on Bill Riley's site: http://www.wriley.com/ Several interesting publications which are available either as free pdfs or you can buy the printed version pretty cheaply (this is what I've done). He also has now made his software available for free. Though he is more concerned with longer term oscillator stability while I think you are more interested in modeling phase. He does, in his book, cover different types of oscillator noise and how it shows up on various measures such as ADEV. I would have thought that the biggest problem you have is having a stable reference. Does the PicoScope allow an external reference? My thoughts along similar lines (I am very slowly designing a GPSDO and want to do measurements on 10MHz OCXOs) was to mix down to audio frequencies and use an Audio USB interface which has a Word Clock input which could be locked to the reference. --- End quote --- I have read one of Bill Riley's NIST publications, Handbook of Frequency Stability Analysis, but have not used his software (it runs on Windoze, which is not my OS of choice). He seems to concentrate on long-term time-keeping, which is not surprising since he worked at NIST. I am currently focusing on short-term phase-noise, but will eventually turn my attention to long-term time-keeping. I am using an HP11729C, which supports two configurations to measure phase-noise: 1) the frequency discriminator, and 2) the phase detector. The first one does not require a second oscillator, using instead a delay line to supply the second signal that puts the HP11729C into quadrature. From my perspective, it has the major advantage that it doesn't require a reference oscillator. The phase detector configuration requires a tunable low phase-noise reference. Tunability is necessary to keep the two signals feeding the HP11729C in quadrature. The frequency discriminator has many advantages, but one major disadvantage is its noise floor rises as the offset frequency approaches 0. Whether this is a problem for the set of oscillators I intend to characterize is still an open question. I am working now on characterizing this noise floor to see if the frequency discriminator configuration will solve the problem I am currently examining. Eventually, I intend on using the HP11729C in phase detector mode, but I have to find a reasonably priced tunable low phase-noise oscillator to use as a reference. I have provided an explanation of the two configurations here and in the next few messages have provided the practical and theoretical basis for their use. |
| jpb:
Thanks for the further information. Coincidentally, I've been looking for (general) spectrum analysers and came across the LF one : https://www.ebay.co.uk/itm/Hewlett-Packard-HP3580A-5Hz-50kHz-SPECTRUM-ANALYSER-100-Excellent-MINT/253994503241?hash=item3b23408c49:g:s7UAAOSw6dhb9t7N:rk:3:pf:0 The existing owner has used it for a similar purpose (phase noise measurement), which having read your posts, makes more sense than when I first saw the listing. |
| dnessett:
--- Quote from: jpb on November 28, 2018, 07:58:50 pm ---Thanks for the further information. Coincidentally, I've been looking for (general) spectrum analysers and came across the LF one : https://www.ebay.co.uk/itm/Hewlett-Packard-HP3580A-5Hz-50kHz-SPECTRUM-ANALYSER-100-Excellent-MINT/253994503241?hash=item3b23408c49:g:s7UAAOSw6dhb9t7N:rk:3:pf:0 The existing owner has used it for a similar purpose (phase noise measurement), which having read your posts, makes more sense than when I first saw the listing. --- End quote --- The HP3580A is a good SA, but there are issues with using it for phase noise measurements. First, it has a frequency range of 5Hz - 50 KHz. Generally, you want a low-frequency analyzer that goes down to 1 Hz. For the 10 MHz oscillators I am interested in, you also want a range up to at least 100 KHz (at least one of the oscillators I intend to characterize specifies phase noise at 100 KHz). Since I an interested in how these oscillators have aged over 15-20 years, comparing the spec with my measurements is a requirement. Finally, the HP3580A is not a recording spectrum analyzer. The output of the HP11729C is read by the spectrum analyzer and then the spectrum data processed to turn this output into phase noise data. So, it is necessary to capture the spectrum as digital data. Dan |
| Navigation |
| Message Index |
| Next page |