I just purchased a PicoScope 4262. One of the first things I did was test its noise floor. I put a 50 ohm terminator on the A input and then ran a spectrum analysis. The result is shown in the first attachment.

As is evident, there is a significant spur at 51 KHz. There are also spurs at ~0 Hz, ~100 KHz, ~138 KHz, and ~150 KHz. For the record, the dBm values are based on 600 ohm termination. I am running PicoScope 6 on Centos 7 and there is no way to select 50 ohm termination for the dBm calculation.

Attachment 2 shows the oscilloscope output for this configuration. There is clearly a 51 KHz ghost signal appearing. Ripples on this base signal suggest interposition of the higher frequency components.

This spectrum used 1048576 bins, a Hanning window, AC coupling, and a span of 0-200 KHz. The power of the 51 KHz spur is significant - 2.6 mV.

Can someone suggest what is going on?

Regards,

Dan Nessett

Hi Dan,

First of all, rest assured what you are seeing is not a result of the performance of the PicoScope 4262. Below is a screenshot for the capture of a 1kHz squarewave from the Signal Generator. As you can see the worst case signal distortion is well below 105 dBu, and the last visible signal component that you can confidently consider to be a harmonic is just below 105 dBu.

What you are seeing in your capture can only be either induced EMI from a close enough proximaty source, mains born interference bleeding through the ground plane, or a fault with the PicoScope (although this kind of ramification from a PicoScope problem would be highly unlikely). So let's consider the first 2:

Do you have a laptop that you could power from batteries only, to see if you then get the same problem? (50-70 kHz interfernce can be found from other devices on the power line (see "Some Typical RFI sources" on page 33 here: http://www.arrl.org/files/file/RFI/Thompson%20Noise.pdf).

If that doesn't solve the problem, are you able to take the laptop to another room (or better yet outside, far enough away from any potential radiating sources)?

Regards,

Gerry

Hi Gerry,

Thanks. I will load PicoScope 6 on my Mac laptop, run it off the battery and see if the spurs disappear.

I have found another problem, this time with the PicoScope 6 software. In order to get an accurate measurement of the spur amplitudes, I downloaded the spectrum in csv format and looked at it using Octave (a Matlab open-source clone). I used Averaging display view, 1Hz-200KHz span, 1048576 bins (2097148 samples), giving a bin width of ~190mHz (this is visible in the spectrum plot I downloaded for a previous message. However, I noticed that the csv file had 2097148 enters, rather than the 1048576 I expected.

I then printed the values around the 1048576th entry and noticed the csv file repeated the whole sequence again. Here is the printout from Octave:

i =

Columns 1 through 12:

1048564 1048565 1048566 1048567 1048568 1048569 1048570 1048571 1048572 1048573 1048574 1048575

Columns 13 through 21:

1048576 1048577 1048578 1048579 1048580 1048581 1048582 1048583 1048584

>> s(i,:)

ans =

199.997901920000004 -152.262900000000002
199.998092649999990 -151.198200000000014
199.998283390000012 -148.782900000000012
199.998474119999997 -146.594699999999989
199.998664859999991 -147.314699999999988
199.998855590000005 -149.708699999999993
199.999046329999999 -145.180000000000007
199.999237060000013 -134.984299999999990
199.999427800000007 -135.350500000000011
0.000000000000000 -78.427530000000004
0.000190730000000 -87.431160000000006
0.000381470000000 -123.355500000000006
0.000572200000000 -123.590000000000003
0.000762940000000 -126.192300000000003
0.000953670000000 -126.045800000000000
0.001144410000000 -124.921999999999997
0.001335140000000 -125.535700000000006
0.001525880000000 -126.539100000000005
0.001716610000000 -127.017399999999995
0.001907350000000 -128.087099999999992
0.002098080000000 -126.796999999999997

The first two entries after the final one for ~200KHz (i.e., those with first column values of 0.000000000000000 and 0.000190730000000), do not appear at the beginning of the file, but starting with the third row after ~200KHz, the rows repeat

>> i
i =

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21

>> s(i,:)

ans =

3.81470000000000e-04 -1.23355500000000e+02
5.72200000000000e-04 -1.23590000000000e+02
7.62940000000000e-04 -1.26192300000000e+02
9.53670000000000e-04 -1.26045800000000e+02
1.14441000000000e-03 -1.24922000000000e+02
1.33514000000000e-03 -1.25535700000000e+02
1.52588000000000e-03 -1.26539100000000e+02
1.71661000000000e-03 -1.27017400000000e+02
1.90735000000000e-03 -1.28087100000000e+02
2.09808000000000e-03 -1.26797000000000e+02
2.28882000000000e-03 -1.25268100000000e+02
2.47955000000000e-03 -1.28183200000000e+02
2.67029000000000e-03 -1.26110000000000e+02
2.86102000000000e-03 -1.24814600000000e+02
3.05176000000000e-03 -1.24261700000000e+02
3.24249000000000e-03 -1.26752900000000e+02
3.43323000000000e-03 -1.27805000000000e+02
3.62396000000000e-03 -1.26224300000000e+02
3.81470000000000e-03 -1.26886500000000e+02
4.00543000000000e-03 -1.26117900000000e+02
4.19617000000000e-03 -1.27262200000000e+02

It appears the PicoScope software confuses the number of samples with the number of FFT bins.

Regards,

Dan

Hi Gerry,

You were absolutely right. There is EMI seeping into the 4262. However, I was able to isolate the problem. I ran my laptop with the USB cable supplied with the product hanging near the computer I normally used as the host. With that computer off, I did not observe any EMI interference. With that computer on, the 51 KHz etc. showed up. I suspected that the usb cable was the problem. So, I used a multi-shielded cable with a ferrite choke at one end to connect to my laptop. The EMI disappeared. I then connected the 4262 directly to the computer with that cable and there is now no EMI causing problems. Attachment 1 shows the spectrum with the shielded cable.

Of course its your product manager's decision, but shipping the 4262 with a low cost usb cable doesn't make sense to me. This is a $1235 product. The few dollars you save on a cheap usb cable, versus a proper multi-shielded and choked cable, isn't worth the confusion that may cause the product to gain a bad reputation.

When I look at the spectrum, there seems to be a spike around 0 or 1 Hz (showing up as about -73 dBm). I think this is an artifact of the repetition of the spectrum that shows up in the csv file. When I use Octave to look at the raw data, the maximum dBm value for the first 10,000 entries is -131,7804.

Finally, and this is a nit-pick, when I used PicoScope 6 on my Mac laptop, I wanted to copy a file name and paste it into the dialog box of the Save As function. I used the normal command-C keyboard short-cut to copy the file name, but using command-V after selecting the text in the Save As file name dialog box didn't do anything. I then tried control-V and it worked. I think the PicoScope 6 programmers have used the Linux convention for keyboard shortcuts, rather than the Mac convention for the Mac version of the software. It's a small thing and I probably won't be using my Mac laptop with the 4262 so it doesn't really matter to me. However, users who are used to Macintosh conventions may find it irritating.

Regards,

Dan

Hi Gerry,

I apologize for not putting this in my previous message, but I just noticed it. The csv file produced from the 1-200KHz spectrum isn't properly scaled. Here are the first few entries:
>> s([1:100],:)
ans =

3.8147e-04 -1.3178e+02
5.7220e-04 -1.3512e+02
7.6294e-04 -1.3455e+02
9.5367e-04 -1.3726e+02
1.1444e-03 -1.3475e+02
1.3351e-03 -1.3835e+02
1.5259e-03 -1.3447e+02
1.7166e-03 -1.3408e+02

Notice the step size, it is .00038147. This does not represent 200 KHz divided into 1048576 bins. It actually represents 200 Hz divided into 524288 bins (524288 is one half of 1048576) or 400 Hz divided into 1048576 bins. If you look at the spectrum I posted, it is showing 0Hz-200KHz as the range (which is the span I selected for the spectrum), which results in a bin width of 190.7 mHz.

I tried to figure out why this might occur. If the program did not take into account the KHz factor and divided by 1048576, then that would result in an easy explanation. However, I don't understand why the numerator is half that value.

This problem became apparent when I looked at the border between the two repeated segments. The values are:

>> s([1048571:1048576],:)
ans =

199.999237060000013 -160.269299999999987
199.999427800000007 -160.820099999999996
0.000000000000000 -76.223290000000006
0.000190730000000 -85.258340000000004
0.000381470000000 -131.780399999999986
0.000572200000000 -135.119200000000006

Notice that the first segment ends at 200 Hz, not 200 KHz.

Cheers,

Dan

Hi Gerry,

For the record, I loaded PicoScope 6 onto Windows 8 (I multi-boot the machine I use for hosting the 4262). I got the same results for the csv file:

>> s([1048571:1048576],:)
ans =

199.999237060000013 -163.648099999999999
199.999427800000007 -162.306900000000013
0.000000000000000 -73.994619999999998
0.000190730000000 -83.024209999999997
0.000381470000000 -131.754199999999997
0.000572200000000 -135.937800000000010

Again, the repeated segment includes 2 entries not at the beginning of the file:

>> s([1:5],:)
ans =

3.81470000000000e-04 -1.31754200000000e+02
5.72200000000000e-04 -1.35937800000000e+02
7.62940000000000e-04 -1.38556500000000e+02
9.53670000000000e-04 -1.37715500000000e+02
1.14441000000000e-03 -1.37524200000000e+02

Either I am very confused about what comprises the csv file when spectrum view is selected or it appears the Windows version has the same problem as the Unix/Mac OS version of PicoScope 6.

Regards,

Dan

Hi Dan,

Regarding the repeating values, when calculating the Values for the Spectrum plot, the FFT produces 2 identical spectrums mirror'd around the zero frequency axis. This is what you get from the Fast Fourier Transform, i.e. a negative frequency spectrum as well as the positive frequency spectrum, and as the negative frequency range has no real value for plotting the magnitude it is discarded before creating the graphic display). However, when exporting the data as CSV only the plotted values are exported, to one file (and if you had plotted 2 waveforms, for instance, they would be exported as 2 separate files).

So, I'm not immediately sure why you would be seeing repetition. Could you post your psdata file, so that we can examine what is going on and see what I may have missed here.

Thanks for the heads up on the Command/Control key confusion (I suspect it's due to not changing the default for Windows, and no, it's not nit-picking if it's a functional error). I'll create a request for a fix from our developers.

Regarding the effect of using a USB lead that is screened, using a ferrite core or using both, our USB leads are multi-shielded, but ferrite cores are not necessarily a general fix for EMI problems.

The solution is not as simple as just snapping on any core, because how effective the core will be depends upon what you’re trying to reject and what core you’re using to reject it. It is possible (but in most cases unlikely) that you could encounter some significant interference, but this could originate from a large variety of potential sources, at widely different frequencies and bandwidths. Also, there are different cores that can be used, for different frequencies and ranges (you may have to use the right type of core, and try and match the resistance region of the cores impedance curve to the bandwidth and location of the unwanted signal, which, even if you have the manufacturers specification, can sometimes be difficult, as shown here: https://www.allaboutcircuits.com/techni ... ite-beads/). If you add to this the fact that not every application and environment that a user will want to capture data in will necessarily be the same, you can see that this can easily become more hit and miss, than effective countermeasure. An easier way of doing this would obviously be to use cores that can reject unwanted signals over a wider frequency range to catch more potential sources if you’re using the core only as preventative measure. The broader band width approach may not be as effective as matching the interference bandwidth to the rejection bandwidth of the core, and your experience with a USB cable that has a ferrite core happens to be an example of where one of these approaches proved successful, but is not applicable to all circumstances.

So, unfortunately, we can't propose a USB lead with a ferrite core as a guaranteed solution to EMI interference.

Regards,

Gerry

Hi Gerry,

Both the psdata and csv files are too large to post to the forum (psdata is 19.8 MB and csv data is 55.5 MB). So, I have uploaded them to parking storage (google drive). The link for the csv file is https://drive.google.com/open?id=1byOrS ... HTi12aN5G2 - the link for the psdata file is: https://drive.google.com/open?id=17FgR8 ... MfGVpgbz6U - when you have downloaded them, please let me know and I will delete them.

If you need to explore things further, the setup is pretty simple : put a 50 ohm terminator on the input being displayed in spectrum view. As a reminder, I am using a 4262.

I need to correct myself about the first column. The header on the csv file is:

Frequency,Channel A
(kHz),(dBV)

(I have to comment out these lines so Octave will read the file). This clearly shows that units for the first column is kHz. So, the bins go from 0 Hz to 199.99943 KHz (however, see below for differences between the first half and second half of the file). Also, the bin size is correct, 190.7 mHz. I was confused since the first entry shows twice that, i.e., 381.47 mHz.

On the other hand, if the csv file records the double sided spectrum, I would have expected the first half of the file to have negative frequencies and to start from -199.99943 KHz increasing to -190.7 mHz. Also, I thought the spectrum elided the DC component. However, it is clearly there:

0.000000000000000 -77.830510000000004

I wouldn't have expected the DC component to be non-zero, since I used AC coupling, which should have resulted in a DC bin of zero.

There is an anomaly between what bins are in the first half of the spectrum and those in the second half. The first half ends with a bin associated with the frequency 199.999427800000, whereas the second half ends with a bin associated with the frequency 199.999809270000, which means the first half has 2 bins less than the second half.

Just for the record, I was using logrithmic averaging of volts (dBV). I also used a Hann window. The sample interval was 2.5 us, sample rate of 400 KS/s, and a time gate was 5.243 sec. Input A was set to +/- 10 mV and (as I already indicated) AC coupling.

In regards to the ferrite core, it is integrated into the USB cable (I didn't snap on a free standing core), so I would imagine it is engineered with the proper choking parameters. Although this is not the cable I used, here is a similar one (https://www.amazon.com/Tripp-Lite-Hi-Sp ... ite+Chokes). That said, I have since experienced the same problem with leakage of 51 KHz into the spectrum even with the choked cable in place. I had to make sure it wasn't near any other cables to ensure leakage doesn't occur. I have bought a PCI based USB3 interface and plan to experiment using it to see of I can reduce the problem.

Cheers,

Dan

Hi Dan,

First of all, I exported the data from your psdata file to 3 CSV files and the first entry in the CSV file is the second bin (the first bin is not included to minimize the DC contribution). The last value (which is the DC component you refer to) is clearly a minor error in pulling information from the array containing the data where the pointer has wrapped around to the first array entry (you wouldn't have 0 Hz immediately following 200 kHz in the real world).

Regarding the double sided spectrum that you refer to, I'm not seeing it.
Both the file that you exported, and the files that I generated have entries that go up to cell 1048576 (which is actually Spectrum entry 1048573, as the first three rows are for the titles) and, as mentioned previously the values start to wrap at entry 1048573 (but in excel you only get 1 extra value, not a whole additional spectrum). The actual number of samples used for the plot is 2,097,148, which when you halve for the number of bins is 1,048,574. Again looking at the actual data plotted we have cell 4 to cell 1048576 that contain unique values, which by my calculation amounts to 1048573 and is missing the first non zero value at 190.7 mHz as you mentioned (and as I explained), which would be the 1048574th value as required.

Regarding the AC coupling, it won't necessarily be zero because there is a Zero error that will typically give you a non-negligible voltage with no signal present (which you can see on the smaller input ranges, in Scope Mode) which is a result of either the gain error, or offset error or both, for the Digital Converter.
There is an option to 'Zero Channel Offsets' within the Channel Options window, which will reduce the error (but not necessarily remove it completely because of the inherent Digital Converter problem previously mentioned). However, unfortunately for the PicoSocpe 4000 series there is a bug in the software which leaves PicoScope 6 hanging if you try to use it (a request for a bug fix has already been passed to our development team for this).

Regarding the ferrite core not solving your EMI problem, that was exactly my point. You can't pre-'Engineer' a solution to an unknown problem, so a choke is still a hit or miss approach, unless you hand pick a specific choke for EMI affecting a specific measurement application once you have been able to identify the EMI.

Regards,

Gerry

Hi Gerry,

I tried to open the csv file with Excel. It returned an error message, "file not loaded completely". When I looked at the results, there were only 1048576 rows. However, when I opened the file with a text editor, there were 2097151 rows, twice the number shown by Excel minus 1. For some reason, Excel isn't loading the whole file. The duplicated data is in the second part of the file. (Try opening the file with a text editor capable of working on large files.)

This explains why what you observed is different than what I observed. For the record, the csv save generated 3 files, but since I was using averaging, these files are identical.

Anyway, I can work around the csv save bug. I will simply truncate the file when it wraps around.

Cheers,

Dan

Hi Gerry,

I just posted a summary of the problems I have found with the PicoScope 4262 spectrum analyzer, and which we have discussed, to the EEVBlog forum. Here is the link. I thought I would let you know in case you wished to respond there.

Regards,

Dan

Hi Gerry,

I thought I had resolved all of the issues I ran across when viewing the noise floor of the PicoScope 4262 in spectrum mode. However, I now realize one issue remains. The csv file contains two segments that repeat the spectrum from 0 Hz to (N/2)-1 Hz (the first segment drops the first 2 bins). If I understand your explanation of this, the values dumped to the csv file are the spectrum for both the positive and negative frequencies produced by the FFT algorithm. If that is the case, then in order to correctly obtain the one-sided spectrum, I need to double the values in one of these segments and discard the values in the other segment. Is this correct?

On the other hand, if the software producing the csv file is just copying the values of the one-sided spectrum twice into the file (through some bug that uses the wrong indexing value), then the doubling is already handled by the software and I shouldn't double the values.

I need to know this in order to apply the workaround I mentioned in the EEVBlog post.

Thanks.

Regards,

Dan

Hi Dan,

I apologise for the delay in responding, statistics has played it's part with the law of averages, and it was my turn to have a week off with the flu bug that has been circulating!

The issue with the doubling of data in the written file is associated with the specific case where the file is over the million row/line limit previously imposed by Microsoft on their office products. If you export any number of bins of data other than the absolute maximum of 10485676 bins then you will get the single set of data. However, because there is now a warning given when record lengths exceed the Microsoft maximum the likelihood is that the correct truncation of the amount of data stored in the buffer has been adversely affected when the warning was introduced.
There is no doubling of data done to the positive frequency spectrum to compensate for the discarding of the negative frequencies, because what is discarded relates to conjugate symmetry. So, unless you are either also looking at phase, or considering performing an Inverse FFT, the negative frequency spectrum is not needed (in fact we can perform an unbalanced inverse FFT with just a one sided spectrum).

So, I will submit a bug fix request with our development team to perform the truncation, in the meantime, just truncate the second set if using the maximum number of bins

Regards,

Gerry

Thanks Gerry,

Regards,

Dan

Hi Gerry,

I have a quick question. The procedure for adjusting measurements made by a low frequency spectrum analyzer when used by the HP111729c include adding in the insertion loss due to any log-amps at the front-end of the analyzer. For the HP spectrum analyzer specified in the HP11729c operations guide, this amounts to 2.5 dB for the given log-amp. In other words, the correction stipulates adding 2.5 dB to the measurement values in order to compensate for this loss.

The question I have is: does the PicoScope 4262 have the same hardware front-end architecture as the HP analyzer? In other words, is there a log-amp or other input conditioning circuit at the front-end of the PicoScope 4262? If so, do you happen to know what is its insertion loss? Since the PicoScope is a digital spectrum analyzer, it would be possible for its software to compensate internally for this insertion loss, meaning no correction is necessary. If so, would you indicate that this is true?

Thanks,

Dan