Using a PicoScope 4262 as a low frequency recording spectrum analyzer

[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]

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.

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]

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.

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

[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.

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

The requirement to go to 100kHz rules out using a USB audio interface. I've been looking at the RME UC which would go to around 80kHz (192kbs sampling) and down to 1Hz even though it is AC coupled. Otherwise it has the advantage of multiple channels and better resolution and noise specs for a lower price. It also allows an external word clock which I did think was important but now am not so sure. People measuring ADEV have got good results with even fairly simple sound cards but there they are only interested in doing cross correlation at a fixed frequency of say 100 Hz not getting a spectrum from 1 to 100kHz.
The other idea I'd had was something like the Linear Technology DC2222A board with the DC890B but these are expensive for just boards and are limited in the number of samples but again the resolution is much higher than 16 bits and there is the option to use a good reference voltage and low jitter clock.

[dnessett]

The requirement to go to 100kHz rules out using a USB audio interface. I've been looking at the RME UC which would go to around 80kHz (192kbs sampling) and down to 1Hz even though it is AC coupled. Otherwise it has the advantage of multiple channels and better resolution and noise specs for a lower price. It also allows an external word clock which I did think was important but now am not so sure. People measuring ADEV have got good results with even fairly simple sound cards but there they are only interested in doing cross correlation at a fixed frequency of say 100 Hz not getting a spectrum from 1 to 100kHz.
The other idea I'd had was something like the Linear Technology DC2222A board with the DC890B but these are expensive for just boards and are limited in the number of samples but again the resolution is much higher than 16 bits and there is the option to use a good reference voltage and low jitter clock.

If you are principally interested in ADEV, then working in the time domain is the approach to take. I am working in the frequency domain, so I don't have a lot of experience to share with time domain measurements or suitable equipment to use. Generally, time domain measurements involve counting zero crossings of the DUT oscillator signal and comparing them with the zero crossings of a reference oscillator during the same interval. From these comparisons, it is possible to determine whether the DUT oscillator is running fast or slow (for stochastic variations, this will change over time). So, the critical characteristic is a very low phase-noise reference oscillator. This doesn't involve the use of a spectrum analyzer. Instead, you need a frequency counter (either one you build yourself, or a commercial one that can analyze two signals simultaneously).

It is possible to convert the measures made in the frequency domain to ADEV (and vice versa), but I have not focused on this yet, since I am interested to first characterize short-term phase noise. ADEV really is best suited to characterize long term variations in phase or frequency fluctuations.

[jpb]

I am thinking of the short term ADEV (0.1 secs to say 10 secs) where it starts to look more like phase measurements.
I have a good counter but for good oscillators using direct measurements I'm really restricted (by the noise floor - 50 psec 1 shot resolution) to 10 seconds and above.

For shorter measurements there is the mixing down approach but counting crossings gets very difficult in the presence of noise because the slopes are so shallow. Practically I found that I had gains when mixing down to say 1MHz but going below that what a gained in heterodyne factor was lost in increased effects of noise.

Sorry - a bit of a preamble on something that you're not directly interested in. But it was leading up to the approach used in this

http://cdn.intechopen.com/pdfs/24305/InTech-High_precision_frequency_measurement_using_digital_signal_processing.pdf

(and other) papers. The approach here, I think, is similar to making phase measurements or at least requires similar equipment except for the fact that a much narrower bandwidth can be used.

Anyway, I don't expect you to get diverted into looking at any of this but remain interested in seeing the outcome of your phase measurements - I'm interested in phase as well as longer term stability especially given that using GPSDOs basically guarantees good long term stability so the shorter term/phase noise becomes more important.

[dnessett]

I am thinking of the short term ADEV (0.1 secs to say 10 secs) where it starts to look more like phase measurements.
I have a good counter but for good oscillators using direct measurements I'm really restricted (by the noise floor - 50 psec 1 shot resolution) to 10 seconds and above.

For shorter measurements there is the mixing down approach but counting crossings gets very difficult in the presence of noise because the slopes are so shallow. Practically I found that I had gains when mixing down to say 1MHz but going below that what a gained in heterodyne factor was lost in increased effects of noise.

Sorry - a bit of a preamble on something that you're not directly interested in. But it was leading up to the approach used in this

http://cdn.intechopen.com/pdfs/24305/InTech-High_precision_frequency_measurement_using_digital_signal_processing.pdf

(and other) papers. The approach here, I think, is similar to making phase measurements or at least requires similar equipment except for the fact that a much narrower bandwidth can be used.

Anyway, I don't expect you to get diverted into looking at any of this but remain interested in seeing the outcome of your phase measurements - I'm interested in phase as well as longer term stability especially given that using GPSDOs basically guarantees good long term stability so the shorter term/phase noise becomes more important.

Allan deviation and its square Allan variance were created in order to solve a particular problem, viz., as time proceeds a clock driven by an oscillator with phase noise displays non-convergent variance. It is important to distinguish between an oscillator and a clock. RoGeorge has provided a nice explanation of the difference here. David Allan attacked the problem by recording the first difference of fractional frequency fluctuations (see this wikipedia article for more information). It turns out that the variance of this random variable possess a convergent variance and therefore is amenable as a measure of clock stability over long periods of time.

However, when studying oscillators without reference to their use in long term time-keeping applications, the usefulness of Allan variance and deviation is minimal. Its not that these measures aren't defined over short-time periods. Rather, their properties, specifically convergent variance, are less useful, since over short-intervals the standard variance of a clock driven by an oscillator is convergent.

So, studying ADEV over short time intervals (as you suggest: .1 sec - 10 sec), is more trouble than it is worth. You can do it, but using standard statistical techniques are just as useful.

[dnessett]

It occurred to me, given that PicoScope 6 produces both positive and negative frequencies when saving a spectrum in csv format, it might be possible it simply saved the full FFT transformation data. That is, normally the spectrum would consist of only one of these segments (in most cases the positive frequency segment), in which case the values in each bin would be doubled. If PicoScope 6 saved the double-sided spectrum, then not only would it be necessary to discard one of the segments, the values of the remaining segment would have to be multiplied by 2.

In order to test which of these situations obtained, I generated a 100 KHz signal at 1 mV. I first used this signal as input to my Siglent SSA 3032X to ensure its integrity. The result is shown in Figure 1.

Figure 1 -

The marker information shows a signal at 99.76 KHz and 1 mV.

I then used this signal as input to the PicoScope 4262. I used a BNC Tee with one side fed by the signal generator, the other side terminated by 50 ohms and the middle connector attached to Input A of the 4262. The display (Figure 2) shows a signal at 100 KHz with magnitude -60.29 dBV. This is an average value over 10 captures. -60.29 dBV corresponds to .9672 mV.

Figure 2 -

I also saved the spectrum from the PicoScope 4262 as a csv file. Looking at the Properties window at the right side of Figure 2 reveals I selected 2,097,148 samples, generating 1,048,576 bins. At the bottom of the spectrum (the x-axis label) shows the span was 0-200 KHz. This yields a bin width of 190.7 mHz (as shown in the Properties window). Finally, the Properties window indicates the window I chose for the FFT spectrum was Blackman-Harris.

The 100 KHz bin is located in the middle of the first and second segments. Here is listed the vicinity of both:

First segment

    99.9992370600000  -141.8629000000000
    99.9994278000000  -101.1544000000000
    99.9996185300000   -76.8896200000000
    99.9998092700000   -64.7258800000000
   100.0000000000000   -60.2860000000000
   100.0001907300000   -62.5510900000000
   100.0003814700000   -72.0155000000000
   100.0005722000000   -91.4557800000000
   100.0007629400000  -137.6536000000000
   100.0009536700000  -140.5280000000000
   
Second Segment

    99.9992370600000  -141.8629000000000
    99.9994278000000  -101.1544000000000
    99.9996185300000   -76.8896200000000
    99.9998092700000   -64.7258800000000
   100.0000000000000   -60.2860000000000
   100.0001907300000   -62.5510900000000
   100.0003814700000   -72.0155000000000
   100.0005722000000   -91.4557800000000
   100.0007629400000  -137.6536000000000
   100.0009536700000  -140.5280000000000

The two are identical.

So, it is only necessary to see if the value in one segment corresponding to 100 KHz represents a 1 mV signal.

The bin width is 190.7 mHz, so five bins correspond to .9535 Hz. In order to combine these bin values, it is necessary to first convert them to power values, add the power values together, divide by the noise power bandwidth associated with the Blackman-Harris window and then reconvert to a voltage value.

This National Instruments paper gives the noise power bandwidth of Blackman-Harris (see table 3 in section 3), which is 1.7. It also provides the algorithm for combining bins (last paragraph of the "Estimating Power and Frequency Section" in section 4), i.e., sum the power values and divide by the noise power bandwidth.

Here is a table of the spectrum values in the 5 bins associated with a 1 Hz width around 100 KHz, where the first column is the dBV value, the second column is the equivalent V_rms value, and the third column is the equivalent mW value, assuming a 50 ohm resistance figure.

dBV	Vrms	mW
-76.89	1.431E-4	4.093E-7
-64.73	5.801E-4	6.73E-6
-60.29	9.672E-4	1.871E-5
-62.55	7.456E-4	1.112E-5
-72.02	2.506E-4	1.256E-6

Adding the power values gives: 0.0000382 mW. Dividing by 1.7 gives: 0.00002249 mW. Converting to V_rms at 50 ohms gives .00106 V. So, it appears the csv file contains single-sided spectrum values repeated in two segments.

This exercise yields two important results. First, it confirms that throwing away one of the segments and using the other is the correct workaround. Second, it confirms the bin combining algorithm given in the National Instruments paper.

[dnessett]

Gerry, the tech specialist I referred to in a previous post, got back to me about the duplicated segments when saving files in csv format. It turns out that this only occurs when the maximum number of bins is chosen (1,048,576). If one of the lesser number of bins is selected, there is only one segment. (I checked this out and it is correct). He has submitted a bug report.

[jpb]

Hi dnessett,

How are the phase measurements going?

I'm thinking of getting a PicoScope 4262 to do both ADEV (via the beat method) and phase measurements but it is a lot of money if it is not going to do the job. It is also a pity that it is only 2 channels and is only 50ppm on the time base with no option of external clock. The alternative I've been thinking of is the RME UX audio interface - this will accept an external word clock of up to 200kHz so could cover the frequency range 1Hz to 100kHz in 24 bit and very low noise but it would probably require some sort of low noise pre-amp arrangement and is much less convenient than the PicoScope. On the other hand it is cheaper, has 8 channels and better specs for the frequency range up to around 80kHz.

Are you happy with your PicoScope 4262?

[dnessett]

At present I am trying to obtain a low phase noise 10 MHz tunable oscillator in order to characterize the noise floor of the HP11729C in a frequency discriminator configuration. The tunable requirement is necessary to use it in a phase detector configuration.

I have located a device that has the spec's I want, but the company that manufactures it does not deal through distributors. This means I have to deal directly with their sales department, which is not used to selling 1 piece orders nor with dealing with individuals instead of companies. It has been slow going and now that we are in the Christmas/New Years holidays, I don't imagine things will speed up until the first of the year. Even then I may not be able to convince them to sell me what I need. They have two pieces in inventory and if both of those are sold to someone else, there is a 14 week wait time from the factory to get additional devices. We'll see what happens.

I am satisfied with the Picoscope 4262 as it is the only low frequency recording spectrum analyzer that is available at a reasonable price. It should do the job. I don't know anything about the RME UX audio interface, but I would be careful to ensure it will actually record down to 1 Hz without signal loss. Audio hardware generally stops at about 20 Hz and trying to capture signals below this boundary may observe losses that would make it difficult to use.(I experienced this with the Spyconverter upconverter, although in that case the cutoff was about 1 KHz).

[jpb]

I am satisfied with the Picoscope 4262 as it is the only low frequency recording spectrum analyzer that is available at a reasonable price. It should do the job. I don't know anything about the RME UX audio interface, but I would be careful to ensure it will actually record down to 1 Hz without signal loss. Audio hardware generally stops at about 20 Hz and trying to capture signals below this boundary may observe losses that would make it difficult to use.(I experienced this with the Spyconverter upconverter, although in that case the cutoff was about 1 KHz).

I'm basing the 1Hz lower end on the RME specs where the gain flatness is quoted down to 1Hz and up to 80kHz (for 192kHz sampling). Also others on this forum have stated that some RME devices go down to dc though I don't know which ones as the ones I've looked at are AC coupled.
Using an audio interface though is a pain, the signal has to be conditioned to be somewhere near line level if most of the channels are to be used (there are 2 mic preamps though) and I think the signals also need to be balanced which is more external circuitry.
It is a pity that they don't do a 4 channel version of the Picoscope 4262 - the specs of the 4 channel versions are rather worse. 4 channels would allow a three cornered hat measurement to be made on 3 devices plus the  reference input.
Good luck with getting your low phase noise device. There are a lot of "low noise" Wenzel OCXOs on ebay but they are all expensive and there is no information as to what their phase noise measurements are.

[dnessett]

Good luck with getting your low phase noise device. There are a lot of "low noise" Wenzel OCXOs on ebay but they are all expensive and there is no information as to what their phase noise measurements are.

I have finally obtained a low phase noise 10 MHz oscillator (actually 3 of them). Since this is not really germane to the topic of this thread, I give details in a more suitable one - found here