[SOLVED] Siglent SDS1202X-E frequency measurement issue

[mm7]

Hi,
While I was trying to measure the frequency of some crystal oscillators (4 pin ones!) with my new SDS1202X-E scope I noticed that the auto-measurement outputs a frequency incorrect for some crystals. The trigger counter (top-right corner) instead reports the correct frequency (within tolerances of the crystal and the of the scope itself). The problem seems to vanish as soon as I reduce the time base to 10-20ns/div, but at the same time the stability of the measurement drops (std-dev goes higher than 1khz).

Here are some measurements. (time base >20ns):

Crystal nominal frequency (MHz)	Trigger counter (MHz) / error from nominal (ppm)	Auto-measurement (MHz) / error from nominal (ppm)
3.6864	3.68656/43.40	3.69/976.56 (ok, because of the 3 digit resolution)
9.600	9.600/0	9.62/2083.33 (out by 0.02; something is wrong here)
14.7456	14.7459/20.34	14.93/12505  (out by 0.1844; something is wrong here)
16.000	15.9999/6.25	16.13/8125 (out by 0.13; something is wrong here)
16.000	16.0002/12.5	16.13/8125 (out by 0.13; something is wrong here)
20.000	19.9999/5	20/0
25.000	24.9993/28	25/0
40.000	39.9991/22.5	40/0

The trigger counter is definitely working as expected (I'm testing it against some cheap crystals, not against a serious frequency generator, thus even 43.4ppm is good because (probably) it is due to a crystal's drift). Vice-versa the auto-measurement seems to be massively out (in the 9-16MHz range).

Are these sort of results ok for the auto-measurement? If not, what could be causing this issue?

If you own a SDS1202X-E, please, can you try to do some similar measurements are report back your results; test on the 9-16MHz range are especially welcome!; If you don't have a crystals in that range but you have an atmega328-based board (Arduino), you could probe the XTAL signal on the atmega328 (since it is the output of the crystal built-in in the board)? Thank you.

[tautech]

Welcome to the forum.

Your scope might be brand new but check it has the latest firmware that was only released last week: v5.1.3.17R1
http://siglenteu.com/gjjrj-xq.aspx?id=4072&tid=15

There have been some fixes that aren't mentioned in the changelog so don't be put off by the list. 

[JPortici]

How are the measurements done? whole buffer or screen data? i don't remember.

either way, if cursors can track the measurement they should place themselves at the cycle used by the measurement.
then with zoom mode use manual cursors to confirm.

[mm7]

Welcome to the forum.

Your scope might be brand new but check it has the latest firmware that was only released last week: v5.1.3.17R1
http://siglenteu.com/gjjrj-xq.aspx?id=4072&tid=15

There have been some fixes that aren't mentioned in the changelog so don't be put off by the list. 

I'm running the software version: 5.1.3.13
The firmware you posted seems to apply to the SDS1002X-E model, does it work even on the SDS1202X-E?

How are the measurements done? whole buffer or screen data? i don't remember.

Honestly I don't know. I can't find any option to switch between whole buffer and screen data; but I suppose that it is done only on the screen data because if I decrease the time bases to 20-10ns/div the measurement reports the correct frequency, if I go up to 50-100ns/div (or more) the measurement starts to display a wrong frequency. I suppose that if the measurement were always done on the entire buffer then I would've seen always the same frequency value, regardless of the time bases setting.

either way, if cursors can track the measurement they should place themselves at the cycle used by the measurement.
then with zoom mode use manual cursors to confirm.

Unfortunately the cursor can't stably track the input signal (cursor mode: track): it continuously jumps between 2-3 values (on the vertical axis); so it is not possible to take accurate measurements. And the delta between one step and the next one in the t axis is simply too large to measure the signal frequency up to decimals.

Anyway I still tried to take some measurements with cursors: first, I tried to measure two identical points of the signal, then I incremented a cursor by one step to check how much resolution I can get. (I'm measuring a 16MHz crystal in this case):

Time base (ns/div)	Frequency (MHz) /picture number	Frequency 1-step increment  (MHz) /picture number	Delta (resolution) (MHz)
5	16.00/17	15.97/18	0.03MHz
10	15.97/15	16.03/16	0.06MHz
20	16.03/19	15.92/21	0.11MHz
50	16.13/23	15.87/20	0.26MHz

All these measurements were done without zooming.

Then I did a second test: Starting from 100ns/div time base I stopped the scope, at this point the auto-measurement was reporting 16.13MHz - 36 counts. Then I decreased the time base by one step (to 50ns/div), somehow the auto-measurement took another measurement (Is this normal? Shouldn't It stay off when the scope is stopped?) and it was still 16.13MHz - 37 counts. Again I decreased the time base (to 20ns/div), the auto-measurement took another measurement, this time 16.03MHz - 38 counts. I did it another time (to 10ns/div), again another measurement: 16.03MHz - 39 counts. Now I tried to measure the frequency with cursors and I got 16.03MHz. Then I decreased the time base another time (to 5ns/div) and the auto-measurement failed to measure (it shows "****" on the "current" column) the freq; with cursors the frequency was spot-on 16.00MHz.

Based on this second test, It seems that the auto-measurement drops its resolution as soon as the time base is increased. Is this correct? If, yes I stll can't understand why It could measure 40MHz crystals without problems even on high time bases 

[tautech]

I'm running the software version: 5.1.3.13
The firmware you posted seems to apply to the SDS1002X-E model, does it work even on the SDS1202X-E?

SDS1002X-E series includes SDS1202X-E.
There are other models sold in China we do not see.
Update the firmware please.

[rf-loop]

Automatic measurements use full sampling resolution and full memory length.
Trigger coiunter is very very different. There is some enough long gate time and procedure what I do not exactly know how it works, but in many cases accuracy/resolution is much more than can measure from one cycle length.
Think you have 50ns cycle. You have 1ns samling interval. Without more deep thinking... yu have 1/50 period resolution. That is all  what it have for tell frequency!

Try slower time base and still you get this resolution... somewhere in forum is long thread about scope measurements and resolution and partially also accuracy. Try example with 16MHz and set 1Ch on and t/div for 1ms/div (memory 14M)
Automatic measurement show exactly same 16.00MHz with this and example with 50ns/div.
But it is not so simple machine still that it only look 1ns interval samples. Of course there "oversampling" or fine interpolation between sample points. Fine interpolation is also needes for signal fine positioning horizontally to trigger position on the screen for minimize trigger jitter. This is normal in modern digital oscilloscopes.  How measuremensts do fine interpolation between samples and with what t/div settings I do not know what kind of "gear box" they have programmed for this.

But so or so, here is 16MHz quite stabile 16MHz signal without freq or level or shape jitter.

Scope is SDS1202X-E
(Btw, for FW upates:
SDS1002X-E means all 2-channel models of SDS1000X-E series
SDS1004X-E means all 4-channel models of SDS1000X-E series.)

Look images and automeasure results using exactly same signal with three different time base setting.
(if you try this same example with Rigol DS1000Z models, with this signal and 500µs/div. ( yes it can not at all due to very extremely low measurement horizontal resolution)

[Performa01]

SDS1000X-E_5.1.3.17R1 is the correct latest firmware for SDS1202X-E. SDS1002X-E just stands for the entire 2-channel X-E family, where only the 200MHz model SDS1202X-E happens to be sold outside China.

The SDS1000X-E (which again means the whole family of 2- and 4-channel X-E scopes, i.e. SDS1202X-E, SDS1104X-E and SDS1204X-E) scopes use the entire acquisition memory up to 14Mpts for automatic measurements, hence the accuracy of time measurements is rather good even at slow timebases, as long as the memory depth has not been limited, hence the sample rate is kept high.

The reason why you still see noticeable inaccuracies is because automatic measurement only takes one single signal period for frequency calculation and the sample rate is limited.

In your example, you have 1GSa/s, that means 1ns sampling interval. Now do the math for a 16MHz signal:

Period is 1/16MHz = 62.5ns;
With 1ns sampling interval we also get 1ns worst case uncertainty, hence 62.5 +/-1 ns, equivalent to +/-1.6% error.
With this error period could be anything from 63.5ns to 61.5ns but with 1ns sample interval we can only get either 62ns or 63ns, depending on the trigger level, which determines the relative phase of the input signal with regard to the sample clock. As a consequence, we get a frequency display of either 15.873MHz or 16.129MHz (=16.13MHz rounded).

The reason why you see less error at faster timebases is the interpolation required for determining the exact signal phase at the trigger point that effectively increases the time resolution quite significantly. I do not know for sure, but strongly suspect the interpolated time resolution is kept to 1/50 of a horizontal division. This would be 20ps for 1ns/div, 200ps for 10ns/div and 1ns (hence no interpolation at all) at 50ns/div and above.

Cursor measurements are restricted to the screen data of course, anything else wouldn't make much sense as you can position them only with a granularity of one pixel on the screen.

The trigger frequency counter on the other hand works as any modern frequency counter does, by measuring the number of periods together with the average period over a longer time and calculates the frequency from that (reciprocal counter). Even though clock accuracy is only guaranteed to be within +/-25ppm, the error usually is much less than that.

EDIT: Timing accuracy has been improved in the latest SDS1004X-E firmware, so this might have trickled down to the SDS1002X-E as well.

[mm7]

Thank you very much for your answers.
I updated the firmware and the issue is gone (the scopes reports the correct frequency), the auto-measurement is also faster!

Are auto-measurements always taken on one-cycle? Isn't there a setting to measure the frequency by counting how many cycles occur within the full data buffer?

EDIT: You said that the full memory buffer is used to take measurements, it means that the scope measures the period of each cycle and then displays the mean of all these periods?

[JPortici]

How are the measurements done? whole buffer or screen data? i don't remember.

i was expecting either tautech or rf-loop to answer. i recalled it used the full memory data but i wasn't sure.

Honestly I don't know. I can't find any option to switch between whole buffer and screen data; but I suppose that it is done only on the screen data because if I decrease the time bases to 20-10ns/div the measurement reports the correct frequency, if I go up to 50-100ns/div (or more) the measurement starts to display a wrong frequency. I suppose that if the measurement were always done on the entire buffer then I would've seen always the same frequency value, regardless of the time bases setting.

for longer timebases the samplerate is going to drop (of course, current sample rate is a function of acquisition lenght in time and number of samples) and the uncertainty is going to be of at least one sample.

Unfortunately the cursor can't stably track the input signal (cursor mode: track): it continuously jumps between 2-3 values (on the vertical axis);

i wouldn't expect it to, the measurement will show one of the three: max, min, average. for some measurements which is which is easy (think max, min) but for others i don't know which will be chosen by the scope.. risetime, the fastest? the slowest? an average? same for frequency.
since it jumps between acquisition, just take a single acquisition and check.

if you enable measurement statistics it should average to the value shown by the hardware counter (which, by the way, should be always running at full samplerate regardless of the timebase settings so you don't have alaising issues).. i suppose it choose a random cycle for the measurement

[mm7]

Honestly I don't know. I can't find any option to switch between whole buffer and screen data; but I suppose that it is done only on the screen data because if I decrease the time bases to 20-10ns/div the measurement reports the correct frequency, if I go up to 50-100ns/div (or more) the measurement starts to display a wrong frequency. I suppose that if the measurement were always done on the entire buffer then I would've seen always the same frequency value, regardless of the time bases setting.

for longer timebases the samplerate is going to drop (of course, current sample rate is a function of acquisition lenght in time and number of samples) and the uncertainty is going to be of at least one sample.

Yeah. But let's consider the maximum we can get at 1giga sample: 14Mpoints = 14ms.  So the buffer should contain 224000 cycles (14ms*16000cycles/ms). The resolution we can get is much higher than 1 period, but for simplicity let's assume that the error can be as high as +-1period. Thus the result would be 224000+-1 cycles; this converts to a frequency of 15999928MHz - 16000071MHz, aka a deviation from 16MHz of 4.5ppm. Please correct me if I'm wrong

[rf-loop]

EDIT: You said that the full memory buffer is used to take measurements, it means that the scope measures the period of each cycle and then displays the mean of all these periods?

No.

Take example. There is 20ns cycle time (50MHz)
1ms/div, 14M acquisition length. 1GSa/s sampling.
Automatic measurement can show 50.00MHz and 20.00ns cycle time. It is mesured over one cycle. It do not count every 700000 cycle what is in buffer and then average these. Scope need keep speed as fast as can. in perfect system there need regognize and measure every pulse, every zero crossing and it may need interpolation if we some day want measure pulse width also because every single pulse there can be different.
This is only rare case that we are looking low jitter continuously repeating uniform signal. What it show if there is bursts or other freq changes. But what we here know, even if we can not see signal (my first image) There is trigger and depending settings and signal I have trigged to some place.   If signal is not repetitive mostly still im most interest to point where I have trigged.  It mesure this cycle there afaik.
For avoid big confusiuon in many different situations I do not recommend averaging over memory length. (exept if there is special new function and settings for this kind of frequency measurement special function). But soon we ask then if we can get also input for external frequency reference.


But it also full memory and resolution  mean that even when 1 div on the display is 1ms it have 1M sample points (but only 50 display points)
 (1000000ns) so it have still 1ns resolution available for measurements. Many scopes measure only from display memory or some second buffer where is decimated sample points, example in Siglent 1000X models it looks like this second buffer is 70k perhaps) and if look Rigol DS1000Z it may have something like 300- <1k) points resolution.

But then, we have 14Mpoints buffer now and 1ms/div in use. With this 50MHz it use only 20ns slice--- for detect this freq and width (near trigger)  Thisd is big advantage over many these scopes what use second buffer or even only display memory resolution. 
But there is also cases where also this full length is important. Lets keep 1ms/div.
Set pulse length 13.99ms. And it show +width is 13.99ms. (trigger just near left border) It show rise and fall times right 6ns


And here come now RANTING. I want now these nanoseconds also for pulse length because they are there and you advertise full resolution! Why Siglent reduce this result far below true resolution what is now there. Ok I know there is more decimals and room in display is small. This display area can really use much more clever way) It  show this 13.99ms pulse (+width) and that it have 6ns rise and fall time. Why it do not show 13.990005 ms or 13990005ns because it was this and also there is this resolution available in memory. (this is not only place where they trunkate numbers without real reason, but please do not this 0.000000ps stubidity, it is reserved only for Rigol)

[CustomEngineerer]

this is not only place where they trunkate numbers without real reason, but please do not this 0.000000ps stubidity, it is reserved only for Rigol)

Sounds like someone's jealous of Rigol's superior attosecond resolution.

[rf-loop]

this is not only place where they trunkate numbers without real reason, but please do not this 0.000000ps stubidity, it is reserved only for Rigol)

Sounds like someone's jealous of Rigol's superior attosecond resolution.

Yes, and lot of.

 

[chris_ee]

I see a similar difference on my Siglent SDS2304X running 1.2.2.2 R19 FW.
trigger = 95.998 MHz
measured = 96.15 MHz

Drove me crazy for a couple of days until I noticed the trigger frequency.