[SOLVED] Siglent SDS1202X-E frequency measurement issue - Page 1
Forum section: electronics / testgear

author: mm7
author_rank: Newbie
timestamp: February 13, 2018, 06:59:50 pm
content: 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.68643.68656/43.403.69/976.56 (ok, because of the 3 digit resolution)9.6009.600/09.62/2083.33 (out by 0.02; something is wrong here)14.745614.7459/20.3414.93/12505 (out by 0.1844; something is wrong here)16.00015.9999/6.2516.13/8125 (out by 0.13; something is wrong here)16.00016.0002/12.516.13/8125 (out by 0.13; something is wrong here)20.00019.9999/520/025.00024.9993/2825/040.00039.9991/22.540/0The 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.

author: tautech
author_rank: Super Contributor
timestamp: February 13, 2018, 09:00:35 pm
content: 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.17R1http://siglenteu.com/gjjrj-xq.aspx?id=4072&tid=15There have been some fixes that aren't mentioned in the changelog so don't be put off by the list.

author: JPortici
author_rank: Super Contributor
timestamp: February 14, 2018, 07:34:16 am
content: 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.

author: mm7
author_rank: Newbie
timestamp: February 14, 2018, 09:04:08 am
content: Quote from: tautech on February 13, 2018, 09:00:35 pmI'm running the software version: 5.1.3.13The firmware you posted seems to apply to the SDS1002X-E model, does it work even on the SDS1202X-E?Quote from: JPortici on February 14, 2018, 07:34:16 amHonestly 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.QuoteUnfortunately 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 numberFrequency 1-step increment (MHz) /picture numberDelta (resolution) (MHz)516.00/1715.97/180.03MHz1015.97/1516.03/160.06MHz2016.03/1915.92/210.11MHz5016.13/2315.87/200.26MHzAll 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

author: tautech
author_rank: Super Contributor
timestamp: February 14, 2018, 10:05:49 am
content: Quote from: mm7 on February 14, 2018, 09:04:08 amSDS1002X-E series includes SDS1202X-E.There are other models sold in China we do not see.Update the firmware please.

author: rf-loop
author_rank: Super Contributor
timestamp: February 14, 2018, 10:15:08 am
content: 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 seriesSDS1004X-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)

author: Performa01
author_rank: Super Contributor
timestamp: February 14, 2018, 10:24:54 am
content: 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.

author: mm7
author_rank: Newbie
timestamp: February 14, 2018, 10:43:53 am
content: 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?

author: JPortici
author_rank: Super Contributor
timestamp: February 14, 2018, 10:52:24 am
content: Quote from: JPortici on February 14, 2018, 07:34:16 ami was expecting either tautech or rf-loop to answer. i recalled it used the full memory data but i wasn't sure.Quote from: mm7 on February 14, 2018, 09:04:08 amfor 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.Quotei 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

author: mm7
author_rank: Newbie
timestamp: February 14, 2018, 11:09:21 am
content: Quote from: JPortici on February 14, 2018, 10:52:24 amYeah. 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

author: rf-loop
author_rank: Super Contributor
timestamp: February 14, 2018, 11:32:29 am
content: Quote from: mm7 on February 14, 2018, 10:43:53 amNo.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 6nsAnd 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)

author: CustomEngineerer
author_rank: Frequent Contributor
timestamp: February 15, 2018, 05:38:21 am
content: Quote from: rf-loop on February 14, 2018, 11:32:29 amSounds like someone's jealous of Rigol's superior attosecond resolution.

author: rf-loop
author_rank: Super Contributor
timestamp: February 15, 2018, 11:56:57 am
content: Quote from: CustomEngineerer on February 15, 2018, 05:38:21 amYes, and lot of.

author: chris_ee
author_rank: Newbie
timestamp: March 25, 2022, 12:47:16 am
content: I see a similar difference on my Siglent SDS2304X running 1.2.2.2 R19 FW.trigger = 95.998 MHzmeasured = 96.15 MHzDrove me crazy for a couple of days until I noticed the trigger frequency.