Hi,

I am saving a large spectrum plot (2 MHz span with 1,048,576 bins) and have discovered that the picoscope software is creating 7 files of about 46 MB each. I am not suggesting this is incorrect behavior. I am just wondering what each file contains.

It appears that the first column of each file is identical and the second is different. For the record, I am using linear scaling for both the x and y axis. I suspect each file represents one or more "passes" of the spectrum software processing the signal input. What I don't know is whether a value in the second column of a particular file is generated by the FFT algorithm using a single sample of the signal over the sampling interval or if it is generated from an average of values gathered over multiple samples.

This leads to another question. Would it be appropriate to average the values at a specific hertz bin in all of the files to generate an average of those values? This might depend on whether the values are from single or multiple samples.

Regards,

Dan

Hi Dan,

By default, PicoScope 6 is set up to capture 32 waveforms when you use a trigger Mode other than Single trigger in Scope Mode. It's also set up to capture 32 waveforms by default in Spectrum Mode (you can change how many are captured by going to the 'Tools->Preferences'menu option and altering the value for 'Maximum Waveforms' in the 'Waveform buffer' section). So the 7 files should represent the 7 captures that were completed and transformed by FFT.

The 1st column should be the frequency of a specific spectrum bin, while the second will be the height of that bin in volts. The first row actually represents the second bin (as the first one, including DC is ignored).

Within the Spectrum options, you have 'Display Mode' selection where you can choose 'Magnitude' which will display the instantaneous height of each bin, 'Average' which displays a rolling average of the height of each bin for the last waveforms captured (so, for instance, by default that would be waveforms 19 to 50 if you've captured 50 waveforms), and 'Peak hold' which displays a rolling maximum of the bin heights across the collected waveforms.

Regards,

Gerry

Hi Gerry,

Thanks for the info on how the Picoscope 6 software creates the files produced by the save function. I have more experience with swept frequency spectrum analyzers (SAs) than FFT SAs. In fact the picoscope is the first FFT SA I have used. So far, I am quite impressed with its features and professional quality and look forward to using it in the future.

Since I am inexperienced with FFT SAs, I decided to do some background reading to come up to speed with how they operate. I found this paper to be very helpful in understanding what is going on. Nevertheless, I am bound to make mistakes and show my ignorance until I get a better handle on their operation. I hope you will bear with me.

Section 10 of the paper cited above covers averaging and overlap and provides a foundation for some questions. First, with your permission, I would like to express my understanding of the terminology you used in your last post so we are both on the same page. In particular, when you use the term "waveform", I understand it to mean the time series resulting from sampling the input signal over an interval of time resulting in N samples. In section 10 of the paper referenced above, they call this a segment, but I am happy to use the term waveform.

Now to the questions:

+ You indicate that the default behavior of the SA component of the picoscope is to capture 32 waveforms. Yet, when I saved the result of the SA computation, it only produced 7 files. So, either the SA software decided to capture only 7 waveforms or the file data contains processing that reduced 32 waveforms to 7 results. Do you happen to know which of these is likely?

+ In section 10 of the referenced paper (2nd paragraph), it states that reducing the standard deviation requires averaging the bin results of multiple processed waveforms. It also notes that the averaging must be carried out on the power spectrum, not the linear spectrum (in the context of the picoscope, the square of the linear value). It stipulates that if a linear result is desired, the square root should be taken after the power averaging is carried out. Does the picoscope SA do this, or does it compute the linear result in a different manner?

+ Section 10 also notes that taking non-overlapping waveforms throws away useful data and suggests using an overlapping strategy with the amount of overlap dependent on the window selected. Does the picoscope SA do this?

Thanks,

Dan

Hi Dan,

The reasoning behind the implementation of Discrete Transformation, and the resulting benefits and drawbacks of transforms and methods can involve a large volume of background material, so it's sometimes difficult to avoid inadvertently developing areas of misunderstanding/misinterpretation in getting up to speed. I don't claim to be an expert in the field, but I do have a grasp of the rudimentary theory, a useful working knowledge and access to our development team, so hopefully my answers to your questions will be lucid enough to point you in the right direction.

Regarding your first question, the sample buffer in the Hardware PicoScope defines the limit of how much data can be captured. So, the buffer is split according to how many of the requested waveforms (requested by the limit specified in the preferences) can fit into the available hardware space. The waveform sizes are defined by the number of samples used per waveform, multiplied by the number of active channels. Finally, the number of samples used per waveform are defined by the Timebase selected, and the 'Number of Samples' requested by the value entered in the 'Number of Samples' text box, next to the Timebase text box. You can see the actual number of samples used per waveform by enabling the 'View Properties' pane on the right hand side of the graphic display, by selecting the Menu option 'Views->View Properties'.
If all of the waveforms requested can fit into the hardware buffer, then you would, by default, get 32 waveforms captured, unless you stop the multiple captures early. Otherwise, the PicoScope will capture as many waveforms as it can before running out of buffer space (which in your case would have been 7).

Regarding the paper you mention, it's complete focus is on power spectra while, as you know, our spectral analysis normalizes for amplitudes, but then gives you the option to select an absolute referenced linear voltage scale or a relatively referenced (depending upon the chosen decibel units) logarithmic scale (which can be power, e.g. dBm or voltage, e.g. dBV). So, while it's theory is applicable there are aspects that are not necessarily put into practice in our Spectrum mode analysis tool. On the linear scale, as our Spectrum plot is of an amplitude spectrum we can directly manipulate the amplitude of a signal displayed in a spectrum plot and derive meaningful computational results that relate to the amplitudes. If we first square the amplitudes, then we can also go on and calculate power measurements from the results (e.g. Total Harmonic Distortion, which requires the rms values of both the harmonics and fundamental frequency). On the logarithmic scale, where decibel units relating to power ratios are used we can directly calculate power measurements.
In the link that you mention, the statement "Note that the averaging must be done with the power spectrum (PS) or the power spectral density (PSD), not with their square roots LS or LSD. If the square roots are desired as result, they must be computed at the end after the averaging is finished." refers to waveform trace (or segment) averaging over a power spectrum of a signal to reduce random variation due to noise. It infers that if you start with an amplitude spectrum, average it across waveform traces, and then square the individual values you obtain a different result to correctly averaging across waveform traces of already squared values (i.e. power spectra), and it will not be valid for any power analysis (and that is what we avoid doing).
On a Linear voltage scale, the waveform trace averaging that we do in Spectrum mode (by selecting a 'Display Mode' of 'Average' in our Spectrum Options) is simply averaging the amplitude of each frequency value across the captured buffers of data, which includes both signal and noise. On a decibel scale waveform trace averaging is averaging the relative power (relative to the reference used for the decibel scale). When the signal content is based on a fixed point the signal level barely changes, but because the noise waveform is random the level for each frequency position settles at the average level for that frequency. So, this method doesn't improve the signal to noise ratio, but it does clean up the signal so that the peaks of the noise waveform no longer mask any signal content, and is a valid computation when referenced to signal amplitudes (not signal power values) on a linear scale, and when referenced to power values on a decibel scale.

However, in Spectrum Mode, in PicoScope 6, using the decibel scale, we have a better method of actually reducing the noise floor relative to the signal level (instead of just smoothing the noise out through waveform averaging). When you perform an FFT conversion of a time domain signal you are dissecting the full spectrum bandwidth into frequency bins which will then contain values representing the time domain signal and any noise over that specific bandwidth (this is, in a way, analogous to what happens in a Spectrum Analyzer, when you sweep a filter with a finite RBW across a signal bandwidth to generate a frequency plot, although in the case of the FFT engine it would effectively have an aperture that would be moving in steps the width of a bin). If you consider the Mth division (or bin) of the Discrete Fourier Transform (DFT), it's output Signal to noise ratio increases as M gets larger, because a DFT bin's output noise standard deviation (rms) value is proportional to √M, and the DFT's output magnitude for the bin containing the signal tone is proportional to M. What this means is that increasing the number of ADC samples used in an FFT decreases bin bandwidth (reduces the width of a bin in a PicoScope Spectrum plot) and increases bin amplitude. A larger number of samples also improves frequency resolution and decreases the amount of noise in the bin's pass-band. The net result is an increase in signal to noise ratio of 3dB for every halving of bin width. for a worked example see this post here: topic25101.html?&p=86081&hilit=process+gain#p86081.

Regarding window functions, we implement a range of window functions so that the user can optimize the effect of windowing in an FFT calculation for their measurement goals. The choice of windowing function affects (a) the amount of spectral leakage, and the smoothness of the transition between bins, and (b) the appropriate emphasis between the level and shape of the main amplitude lobe relative to the level of the side lobes of the spectral content, for the FFT required analysis (among other aspects). So the overlap values used are what is appropriate for the type of window function for the best compromise between (a), while the window function type is selected by the user to achieve the appropriate implementation of (b).

Regards,

Gerry

Hi Gerry,

Thank you for your detailed response to my questions. I very much appreciate the time you took to formulate your comments into a clear exposition of the issues.

However, I am still somewhat confused about certain details, which I will pursue in this email. To clarify the discussion, I think it beneficial to use a concrete example. The attached figure (Properties.png) shows on the right hand side the properties window for a sepcific signal processed by the PicoScope SA. Not that it is important for the following discussion, but for clarity the input is an FM modulated 1 MHz/100 mVRMS carrier with sidebands generated by a Frequency deviation of 200 Hz and FM frequency of 10 KHz.

The parameters chosen are 1,048,576 bins which requires 2,097,148 samples. The sample rate is 4 MS/s and the span is 2 MHz. This induces a bin width of 1.907 Hz and a sample time of 524.3 ms. The window chosen is Blackman and coupling is AC.

I ran two experiments with these paramters, one using Magnitude Display Mode and the other Average Display Mode. Both resulted in 7 46.1 MB files.

From what you wrote in your last message, I interpreted the production of 7 files to indicate that the physical buffer on the PicoScope hardware can hold 7 * 2,097,148 samples, but not 8 * 2,097,148 samples. Also, my interpretation of your discussion led me to understand that in the Magnitude case each of these files contain non-averaged bin values. That is, they are the magnitudes of the Discrete Fourier Transform coefficients generated by the FFT algorithm.

However, I was confused when 7 files were generated when using the Average Display View. I expected one file in which each bin value represents the average of the coefficient magnitudes generated by appling the FFT algorithm to the 7 waveforms stored in the PicoScope hardware buffer. So, I expect I have misunderstood something. Perhaps you can help me find my error.

I thought I would mention that the application I am interested in is measuring phase noise of various amplifiers. I said this in a post in a different thread (topic39384.html#p140297), but have not mentioned it in this thread. The reason I bring this up is measuring noise has some different characteristics and objectives than measuring non-stochastic signals in the presence of noise. Once I understand the content of the files PicoScope generates for its SA processing, I have some other questions about noise measurement using the PicoScope SA that I would like to ask you. It would make this post too long to include them here, so I thought I would give you a heads-up that more questions are coming .

Thanks once again for your help.

Regards,

Dan

Hi Dan,

To answer your questions, Magnitude Display Mode in Spectrum Mode of our PicoScope 6 software will indeed give you 7 dissimilar wave traces. However, when selecting an Average Display Mode the waveform buffers will have been averaged, at each point in the waveform trace, to generate 1 sample value for all corresponding values in the 7 sample buffers. Ordinarily you would have just one buffer representing the average trace, but because the software is set up to collect and display 7 traces it just repeats the Average trace for all 7 captures. Technically this is a bug, but a small one (as it adds confusion) so I will raise this with our development team if it hasn't already been done.

In your other post you mention phase noise of RF oscillators. Just out of curiosity, what sort of frequency would these be oscillating at?

Thanks for the heads up, we'll look out for your questions.

Regards,

Gerry

Hi Gerry,

Thanks for clarifying what the 7 files produced under Average Display Mode represent.

The oscillators I am studying in regards to phase noise resonate at 10 MHz. I think it would be helpful to very, very briefly describe the problem. I can point you to a more detailed description if you are interested, but it is not an easy topic.

Oscillator phase noise is displayed as frequency fluctuations in oscillator output. That is, a 10 MHz oscillator will not perfectly produce a 10 MHz signal over time. At some time t, it might produce a signal that instanteneously represents, say, 10,000,001 Hz. The cause creating this deviation is fairly complex and is modeled as stochastic noise processes summing together to form a complicated signal that modulates the 10 MHz "carrier" signal.

There are several approaches to measuring oscillator phase noise. The one I am using employes a phase detector to instantaneously map oscillator frequency fluctuations into a voltage signal. Again, the details of how the phase detector works are not important to this discussion, but I can point you to more information if you are interested.

Phase noise for a 10 MHz oscillator generally arises from frequency fluctations in the range 1 Hz - 100 KHz (it could go higher, say to 200 KHz, but most 10 MHz oscillator phase noise specs I have read stop at 100 KHz or lower). The output of the phase detector is correspondingly a voltage signal with a spectrum in which the majority of power resides in the 1 Hz - 100 KHz range. This spectrum is detected by applying the phase detector voltage signal to a spectrum analyzer.

Oscillator phase noise is normally given in units of dBc/Hz, that is decibels below the oscillator, or "carrier", signal level for which the power in each frequency bin is normalized to 1 Hz. The voltage signal produced by the phase detector is not relative to the level of the "carrier" signal, so it is necessary to post-process the spectrum analyzer output to transform it into the desired form. Other adjustments are also necessary, but, once again, I will elide their description in order to keep this post to a reasonable length.

Not only must the power levels in the spectrum analyzer output be adjusted to accomodate differences between the phase detector voltage output spectrum and the desired phase noise spectrum, they also must be adjusted to normalize the phase noise spectrum to 1 Hz bins. This is perhaps easiest to explain by an example.

Before purchasing my PicoScope, I used a Siglent SSA3032X spectrum analyzer to process the phase detector output. The minimum RBW that the Siglent supports is 10 Hz, which I used when producing the spectrum from the output signal. In order to normalize the spectrum to 1 Hz, it is necessary to view the 10 Hz bins produced by the Siglent as the sum of 10 1 Hz bins. This means the power level in each 10 Hz bin must be reduced by a factor of 10 (10 dB) to achieve the desired normalization.

This background information sets up some questions I have about how to apply my PicoScope to the problem of measuring oscillator phase noise. First, the power levels of the phase detector output in the 1 Hz - 100 KHz range generally go no lower than -100 dBm. So, as long as the noise floor of the spectrum analyzer is less than this, its measurment of the phase detector output should provide valid results.

The classic way to measure an SA's noise floor is to put a terminator on its input and display the resulting spectrum. I did this for my Siglent SA by putting a 50 ohm terminator on its input and selecting a RBW of 10 Hz. I also did this with the PicoScope and, for a span of 1 - 100 KHz with 2,097,148 samples, observed a noise floor of about -130 dBm. But, the input impedance of the Siglent is 50 ohms, whereas the input impedance of the PicoScope is 1M ohm. So, putting a 50 terminator on its input doesn't really make sense. Consequently, I left the input unterminated, which generated about the same -130 dBm noise floor (actually, it was marginally less). Is there a better way to measure the PicoScope's noise floor for these span and sample parameter values?

The frequency bin width for the span and sample number given above is 95.37 mHz. This means normalizing to 1 Hz requires not decreasing the the power levels, but increasing them. That is, it is necessary to add bins together, in this case about 11 of them, to normalize to 1 Hz. Of course, I could reduce the number of samples, but since 100K is not a power of 2, I will have to combine frequency bins in any case.

I have done some research on adding together adjacent FFT frequency bins and it appears this may not generate the correct result. In particular, it may be necessary to take into account the windowing process used when generating those bins. In the section "Estimating Power and Frequency" in section 4 of the paper found here, it is suggested that the sum must be divided by the noise power bandwidth of the window. This is stated without justification, so I am wondering if this advice has some concrete reasoning behind it.

I realize this is a pretty specialized question, so you may not have any thoughts to contribute, but if you do I would very much appreciate hearing it.

Cheers,

Dan

Hi Dan,

Thanks for expanding on what your measurement goals are. It might surprise you to know that I am actually working on a project where factors such as jitter, temporal quantisation noise and phase noise need to be quantified in order to validate the outcome. So, I have been fortunate to find some really informative reference material, but as you can never have too much, I would be interested in what you have used.

Before I answer your latest post I would just like to say that I made a glaring omission in my post discussing how we plot in Spectrum Mode (I meant to, but forgot to discuss how plotting on our logarithmic scale is affected). So, I have gone back and updated it, while also taking the opportunity to replace the explanation of Process Gain with a more rigorous description (which I thought I had done in the link for the example). You will find that this adds missing clarity to the explanation.

In Scope Mode, the noise level that we would quote for the PicoScope 4224 (but which isn't in our spec) would be < 80uVrms (which would include the uncertainty due to factors such as component tolerances/batch variation, variation of temperature, power supply, etc) but if you are working in an environment with minimal induced noise, for your specific Scope you should be able to achieve <50uVrms. Adding a 50Ω terminator on the input of the model I used reduces the noise level by about 20%, so in that respect it's good practice to use a 50Ω terminator (which simulates the addition of a 50Ω RG58 cable when attaching a scope probe to an input channel in order to eliminate spurious pickup from an unterminated input).
In Spectrum Mode, because the noise level will already be reduced by 57dB when using 2,097,148 samples, when terminating the input, the change in dB at such a low level would be negligible. So, there is no need for 50 ohm termination for your Spectrum analysis.
Regarding process gain, because it affects the stochastic signals in your measurement it would affect both the unwanted noise and the phase noise waveform equally (i.e. reducing both by the same amount). So, unfortunately, in your application there is no advantage in using process gain in an attempt to minimize unwanted noise. You would be better off just adjusting the bin size to suit your 1Hz requirement, so that you don't have to do any post processing. You will then need to add the process gain from the number of bins used, to your phase noise measurement (as in your case it will actually be process loss) and then subtract the noise voltage measured (with no signal applied, using the same number of bins) to get accurate values for your measurements. Because the unwanted noise will be fairly close to Gaussian white noise (with a flat power spectrum) the subtraction will be just a broadband level subtraction. (Unfortunately, you won't be able to just use an arbitrary dB scale, so that the adjustment can be made by calculating what the equivalent reference voltage would be for the process gain and unwanted noise, because of the platform you're using, as we established in the other post!).
In terms of the minimum values that you want to be able to measure (at the -100dBm level of the voltage output) the -130dBm noise floor you measured equates to -73dBm without process gain, which is about what would be expected for a 12-bit Scope (to achieve a noise floor approaching 96dBm you would have needed a 16-bit Scope with a low noise input, such as the PicoScope 4262).

Finally, the reason for summing the individual power values of each bin and then dividing by the noise power bandwidth of a window, to find the total noise power across the frequency of interest is as follows:
In establishing the spectral content in the first place, the values for each bin were found by applying a window with a finite bandwidth, in discrete steps across the spectrum, to calculate the power values for it. So, if you want to sum the total power of the bins you have to take into account the mechanism that originally calculated the power for a bin.
As the power level is proportional to the bandwidth across which you are measuring it, a narrower bandwidth window gives a reduced total noise power (because you have a smaller bandwidth of noise, and therefore less values to total, and a smaller bin height), but an increased signal power (because there is less averaging, i.e. division, going on for the same signal height, giving a greater bin height), which is what happens when you increase the number of bins.

Regards,

Gerry

Hi Gerry,

Thanks for your last post. I have a couple of more questions and will provide some references to information about oscillator phase noise and the experimental approaches to measuring it at the end of this message.

First, I need to clear up one thing. In my last post I stated: "... the power levels of the phase detector output in the 1 Hz - 100 KHz range generally go no lower than -100 dBm." While this is true, it is misleading. First, these power measurements were made on my Siglent SA, which is a 50 ohm instrument. The noise floor measurements I made using the Spectrum View of the PicoScope are based on 600 ohm loads (on my Linux machine, there is no way, at least yet, to select 50 ohms as the basis of power calculations). So, it is necessary to transform the 50 ohm based power values to 600 ohm based values.

Before doing that, I need to clarify a second point. This is a link to a plot of the raw data from the Siglent. This plot runs from 10 KHz (corrected 11/2/18) to 200 KHz. The power levels observed in the 10 KHz (corrected 11/2/18) to 100 KHz part of the spectrum are higher than the -100 dBm I mentioned. Eye-balling things, the minimum power level is about -92 dBm.

With these two points in mind, what is the 600 ohm based power level (in dBm) that corresponds to a 50 ohm power level of -92 dBm. First, -92 dBm @ 50 ohms corresponds to 5.617*10^-6 Vrms. Converting this to a 600 ohm value means squaring that value and dividing by 600 = 31.55*10^-12/600 = 5.26*10^-14. Converting to dBm: 10*log10(5.26*10^-14) = -132.7 dBm.

So, the noise floor required is roughly -135 dBm on the PicoScope. This is right at the limit of the noise floor I measured and generally, you want at least 10 dB separation between the noise floor of a measuring instrument and the signal being measured.

However, there is a mitigating factor that I have not yet mentioned, that might save the bacon (sorry for the Americanism). I am using an HP11729C as the active part of the phase detector. The particular output port I am using has an output impedance of 600 ohms (how's that for serendipity? ). When I connected this output to the Siglent, I used a 600ohm-50ohm matching pad, which has an insertion loss of 16.6 dB. So the raw data is degraded by that figure due to impedance matching. If I connect the HP11729C output directly to the PicoScope and terminate the coax with a 600 ohm terminator instead of a 50 ohm terminator, the minimum power level should rise to -132+16.6 = -115.4 dBm @ 600 ohms, which is easily 10 dB above the -130 noise floor I measured.

On the other hand, your previous post seems to suggest that the processing gain achieved by the sample size should not be considered when computing the PicoScope's noise floor. I must admit, even after reading your revised post on processing gain, I did not understand this point. Could you elaborate on this? (I now understand your point. There is no reason to address this question.)

One thing you suggest is adjusting the number of samples "to suit [my] 1Hz requirement". I think the 95.37 mHz bin width is pretty convenient in that regard. 11*95.37 mHz = 1.05 Hz. Is there another bin width that would be better for the 1Hz-100Khz span? By the way, thanks for the explanation of dividing the summed bin values by the noise power bandwidth of the window. Do you happen to have handy a reference to the mathematics behind the explanation?

In regards to references, I should at first state that oscillator phase noise measurement differs from two-port additive (corrected 11-2-18) or residual phase noise measurement of, say, an amplifier. Just a warning that material describing oscillator phase noise and its measurement may, or may not, be applicable to other phase noise measurements.

That said, here are some references you can look at. For an introduction to oscillator phase noise, I would recommend a Master's Degree Thesis located here. One nice thing about Master's Theses is they generally have good tutorial sections at the beginning. If that is too elementary, then you can hop into the middle of the tornado and read this. Since this is a product of NIST, which has responsibility for maintaining the US time standard, it is heavily biased toward time-keeping. Unless you are a masochist I recommend starting with chapter 8. That is the only chapter I read.

In terms of material covering the practical issues of measuring oscillator phase noise, the discussion I posted on the EEVblog (starting here) might be helpful. I would start at that post and read until you think the reward generated is less than the effort costs. A more formal and certainly more comprehensive account of the problem is addressed here.

For a discussion of the stochasitic processes that contribute to oscillator phase noise, I would recommend this report. It is a bit old, but sometimes old reports have better tutorial information because they explain things more modern reports take for granted. The material on noise processes starts on page 13.

Cheers,

Dan

Hi Gerry,

Your statement that 12-bit scopes can only support ~50 uV finally sunk in. Since I need something that can resolve ~5 uV, the 4224 isn't going to hack it.

I have two options. One is to use my Siglent for that part of the spectrum that is less than -73 dBm and the 4224 for the part greater than or equal to -73 dBm. This is a pain, but probably would work.

The other option is to get a 16-bit PicoScope. Two questions about this option: 1) does your company allow returns if they occur within some time period? I then could return the 4224 and get more capable hardware. Second, (this is no longer relevant, see my comments in parentheses that follow) (I checked with sales at pico tech and have sent an RMA request to return the 4224. I will then order a 16-bit scope based on your input) There seems to be 2 scopes that would work. The first is the 4262, which you suggest. The other is the 5242D, which supports flexible resolution up to 16-bits. The latter, surprisingly, costs less than the 4262. But, I want to make sure it can do the job.

Update (11-3-18): I had to make a decision, since TEquipment had a 4262 on sale for a very good price (but only one left). I looked at the data sheet for the 5242D and noticed a footnote that stipulated when operating at +/- 10 mV, 2 bits of precision are lost. Therefore, at this scale, the 5242D only provides 14 bits of precision. The 4262 provides the full 16 bits at +/- 10 mV. So, I decided to buy the 4262 from TEquipment.

Thanks,

Dan

Hi Gerry,

I expect to get my 4262 next Monday. Would you indicate the unpublished sensitivity of this device. If a 12-bit 4224 can measure signals roughly <50 uVrms, I would expect a 16-bit to measure signals 50/16 ~ 3.125 uVrms. Of course there may be mitigating factors, which is why I am asking.

Also, I think 2 other publications are good reference sources for oscillator phase noise. These are ancillary publications supporting the HP11729C: 1) Phase Noise Characterization of Microwave Oscillators / Phase Detector Method and 2) Phase Noise Characterization of Microwave Oscillators / Frequency Discriminator Method. While these publications are intended to describe the use of the HP11729C, the exposition describing the theory of phase noise measurement is quite general and perhaps some of the clearest written I have read.

Regards,

Dan

Hi Dan,

I apologise for the long delay in responding. I have been on vacation and have only now managed to catch up with forum posts.

Regarding my comment about Process Gain I made the assumption that the Phase detector voltage output would be a stochastic signal, much like noise, which would also be reduced through Process Gain. If this assumption was wrong, then you need to disregard that comment.

Regarding the references to phase noise, oscillator phase noise is one of the phenomena that influencing my project, as the sample clock that we use is an oscillator, so I have a fair amount of material covering the basics, but I appreciate the NIST, 'Infrared Millimeter Waves', and 'Frequency Domain Stability Measurements' references which have material that sheds some light on areas that it is difficult to find from alternative sources.

Regarding your choice of 16-bit resolution PicoScope for your specific application, you made the right choice between the two. The issue is that the relative noise and distortion levels between the 2 Scopes will reduce their effective dynamic range (typically stated as Effective Number Of Bits, or ENOB, for more on this see here: https://www.analog.com/media/en/trainin ... MT-003.pdf).

The 5000 series PicoScopes have more of a problem with noise and distortion levels, when no adjustments are made. This is because they give you flexible resolution (the ability to trade bandwidth for resolution) but in order to do that there are design compromises that had to be made. These include an input stage that is not optimised for resolution or bandwidth but is reasonably good for both, and converters that must be stacked for higher resolution. The consequences of this are that the noise level, and distortion level is high on the lower input ranges and comparatively less but still high on the higher input ranges. However, as the 5000D series have significantly increased buffer size over the previous 5000B series models, some bandwidth can be sacrificed to reduce the noise level, significantly in most cases (for further discussion on these topics see here: topic14879.html?&p=49601&hilit=gerry+enob#p49601).

In comparison, the PicoScope 4262 natively has a lower noise and distortion level. This means that you will be able to reveal more signal information than that of a 5000 series PicoScope when using Spectrum Mode, because the initial noise floor will be much lower. However, you need to be aware that, although the distortion for the PicoScope 4262 is lower (-95dB as opposed to -70dB for the 5000 series) it is not stochastic in nature, so you won't be able to suppress it using Process Gain. This also means that this will be the limit to the minimum level that you can measure in Spectrum Mode before typically hitting distortion.

I believe you may have made a mistake in calculating the minimum level of signal that you will be able to transfer to the PicoScope from your phase detector.

My understanding is that 0dBm, is 1mW, and typically w.r.t a 600Ω load. So, when it is w.r.t. a 50Ω, the voltage will be √(50 * 0.001) = √0.05V. So, to change the reference, you would do the following:

The voltage ratio (Vmeasured/Vreference) represented by -92dB is 0.00002512. As this was measured by your Siglent, the measured voltage is 0.00002512 * √0.05V = 5.617 * 10^-6.
The reference of 0dBm w.r.t. a 600 load will have an associated voltage of √(600 * 0.001) = √0.6V, so to change your measurement for an equivalent reference 0dBm level w.r.t to 600Ω, the new voltage ratio will be 5.617 * 10^-6/√0.6V = 7.251 * 10^-6, which is -102dB.

So, your minimum measurement level now becomes -102+16.6 = 95.4dB. Which, conveniently is about where your minimum detectable level sits in Spectrum Mode for the PicoScope 4262.

Regarding the bin width, what you can do is use a Primary view of Scope Mode, with a Secondary view of Spectrum Mode which gives you more scope (if you'll forgive the pun) over setting the Bandwidth relative to the Bin width. So, for instance in the screenshot below I have got a bin width of 1.06Hz for a bandwidth of 555.5kHz, and zoomed into the 100kHz range (no calculation necessary ). Ordinarily, this way of viewing the spectrum restricts your ability to vary the bin width while holding the bandwidth constant, but if you won't gain any advantage from using Process Gain there would be no need to change the Bin Width.

To answer your last question regarding the 'precision' of the PS4262, I've alluded to the effective resolution above, and in Spectrum Mode, if your Phase Detector output voltage is stochastic the limiting factor will be the noise of the PS4262. Unfortunately, the untreated noise level of the PS4262 is still significant, and any noise reduction methods would also affect your signal (as it will not be very distinguishable from a noise type signal). This can be 100uV p-p which would reduce the dynamic range to -47.6dB.
If the waveform is more deterministic the limiting factor of your dynamic range will be the distortion of the PS4262.

Regards,

Gerry