Siglent SDS800X HD 12 bit DSO's

[tautech]

That's considerably more than 25ppm.  About 6 times.  It's also far worse than any watch or clock I have.

Maybe an enquiry to Siglent to find out where the OS timebase is coming from?

Why does clock accuracy matter to you? Do you plan to keep the scope running 24/7? It is a bit of a power hog...

See Reply #1226
It's a valid accuracy need for long term logging.
However when interweb and NTP syncing is not possible for the mobile service tech it is useful to have some idea of long term clock accuracy......

[BillyO]

Why does clock accuracy matter to you? Do you plan to keep the scope running 24/7? It is a bit of a power hog...

Either you are missing the point or you just want to be contrary.  Not sure which.

The point is, if the OS is getting it's clock from the scope reference, then 150ppm is way out of spec.

Personally I'm not too concerned about what time is displayed as I do sync via NTP and give or take a few seconds is no problem for file timestamps.

Plus what Rob just said for affected use cases..

[ebastler]

]Either you are missing the point or you just want to be contrary.  Not sure which.

The point is, if the OS is getting it's clock from the scope reference, then 150ppm is way out of spec.

Personally I'm not too concerned about what time is displayed as I do sync via NTP and give or take a few seconds is no problem for file timestamps.

Plus what Rob just said for affected use cases..

Sorry , I did not mean to sound contrarian. Had missed reply #1226, and I see that this would indeed be a use case which benefits from stable long-term timekeeping. But it also seem like a niche case. Normally I would expect long-term operation to occur in an automated setup, where there is a network connection and the possibility to re-sync the time.

I don't think you should make conclusions about the scope's reference clock accuracy based on its long-term time-keeping. The time may be affected by factors like missed low-priority interrupts, or may be derived from another source entirely. Others have measured external 10 MHz reference clocks using the scope's counter, which seems like a much more direct and reliable method, and have found in-spec accuracy.
 

[tautech]

]Either you are missing the point or you just want to be contrary.  Not sure which.

The point is, if the OS is getting it's clock from the scope reference, then 150ppm is way out of spec.

Personally I'm not too concerned about what time is displayed as I do sync via NTP and give or take a few seconds is no problem for file timestamps.

Plus what Rob just said for affected use cases..

Sorry , I did not mean to sound contrarian. Had missed reply #1226, and I see that this would indeed be a use case which benefits from stable long-term timekeeping. But it also seem like a niche case. Normally I would expect long-term operation to occur in an automated setup, where there is a network connection and the possibility to re-sync the time.

It is.
However buddy Muttley asked me to do this test to obtain a datapoint, good, bad or otherwise.
He is a mobile tech operating in industrial and commercial environments where his only interwed connection might be to hotspot his phone for accurate timestamps. This I have tested for NTP with SDS1104X-E and their convenient USB WiFi dongle.
SDS800X HD sadly does not offer such convenience......yet.

[2N3055]

Why does clock accuracy matter to you? Do you plan to keep the scope running 24/7? It is a bit of a power hog...

Either you are missing the point or you just want to be contrary.  Not sure which.

The point is, if the OS is getting it's clock from the scope reference, then 150ppm is way out of spec.

Personally I'm not too concerned about what time is displayed as I do sync via NTP and give or take a few seconds is no problem for file timestamps.

Plus what Rob just said for affected use cases..

It is not like there are hardware divider circuits that divide main clock directly into clock cycles in hardware. It is likely implemented as software interrupt, and low priority at that. It likely has some jitter too.
It is same as software clock on PC OS that drifts a lot, and why NTP is used a lot to keep them disciplined to some reasonable accuracy.

[BillyO]

It is not like there are hardware divider circuits that divide main clock directly into clock cycles in hardware. It is likely implemented as software interrupt, and low priority at that. It likely has some jitter too.

Hmm..

It seems folks are reading stuff between the lines I didn't put there.

First, go back and read my other posts on this topic.  I'm not saying the system clock IS driven by the timebase.  I'm okay with it not being, but I'd like to know if it is or not.  Just inquisitive.

Now, that that is out of the way..

The timing for the the instrument side of things is, hopefully, handled properly and not just some semi-random software interrupt.  It ultimately also needs to be dealt with in the code.  That timing could, no .. it should also be used to update system time.  It would be a simple thing

It is same as software clock on PC OS that drifts a lot, and why NTP is used a lot to keep them disciplined to some reasonable accuracy.

PCs are generally not considered precision instruments.  BTW, I have had PCs that kept great time without NTP.  My 1998 Toshiba Tecra comes to mind.

[2N3055]

It is not like there are hardware divider circuits that divide main clock directly into clock cycles in hardware. It is likely implemented as software interrupt, and low priority at that. It likely has some jitter too.

Hmm..

It seems folks are reading stuff between the lines I didn't put there.

First, go back and read my other posts on this topic.  I'm not saying the system clock IS driven by the timebase.  I'm okay with it not being, but I'd like to know if it is or not.  Just inquisitive.

Now, that that is out of the way..

The timing for the the instrument side of things is, hopefully, handled properly and not just some semi-random software interrupt.  It ultimately also needs to be dealt with in the code.  That timing could, no .. it should also be used to update system time.  It would be a simple thing

It is same as software clock on PC OS that drifts a lot, and why NTP is used a lot to keep them disciplined to some reasonable accuracy.

PCs are generally not considered precision instruments.  BTW, I have had PCs that kept great time without NTP.  My 1998 Toshiba Tecra comes to mind.

I tried and failed.

Scope is driven by complex hardware state machine. No need for hope.

Time kept in Linux is software clock. It has no correlation to scope hardware timing.
That thing is run exactly like on PC. It will have no idea it is actually a scope. It thinks it is just some Linux computer. It will have accuracy of software running on general purpose ARM processor running code for clock.
As such is what it is. I think nobody designed it to be cronometer.

Maybe direction to look into is to do what PC servers do: actually discipline itself to NTP more actively if user wants more accurate timing.

It has no RTC anyways.

[BillyO]

It has no RTC anyways.

Presumably, seeing how bad it is.  That could be fixed for pennies.

However, it does have precision timing hardware available to it.  An RTC could (hypothetically) be implemented as an application and time maintained precisely once it is set at startup.

Even today many PCs have RTCs built into them (maybe all?).  My Lenovo T480 does and it keeps great time.  Not as good as my old Teccra, but pretty good.

I'm not Linux expert, so are you saying if I install Linux on the T480, it will ignore the built in RTC?  IIRC, MS-DOS 5 and later MS OSs will find a query the RTC on startup.

Anyway this is going off topic.

[Muttley Snickers]

(snip...)
PCs are generally not considered precision instruments.  BTW, I have had PCs that kept great time without NTP.  My 1998 Toshiba Tecra comes to mind.

My current scope is well past its best before date, however it does hava an RTC and maintains excellent time so I trust it inherently. I don't do much in the field anymore but if I am called in to assist with a problem then we need approximate timestamps to correlate with other events or happenings, and minute either way over a 24 hour period would be fine as long as we know to expect that discrepancy.

[Electro Fan]

Despite everything, my wish is that we could use a better reference. An oscilloscope is specifically a time axis measuring device. The time axis should be as accurate as reasonably possible. Today we have better than initial +/- 25ppm references available for the price of a shirt button. Why leave time axis in the measuring device to the poor accuracy just to save a penny or some jiao?

+1
and fwiw, DHO1000 is able to include a 10 MHz ref in and out

[Electro Fan]

In this image we can detect that data sheet 25ppm is like elephant in porcellain store and nothing to do with jitter (what is much more important).

rf-loop, your metaphors are excellent!   
Thank you for all your deluxe technical analysis and commentary. 

[whodiini]

I really like knowing how the DSO/MSO makes its automatic measurements, but using the Cursors to measure the Slew Rate, or the Rise Time, I did it once, I learned how to use the tool, but on a daily basis, I prefer use the Instrument's automatic measurement, as generally the number scales are not whole numbers, and this is bad for locating where the 10% and 90% of the pulse are, it can cause a lot of inaccuracy in the reading and calculations.

Yes, automated measurements are generally always better than "manual" cursor based measurements.  Even though all of our oscilloscopes can automatically measure this, I included the cursor-based method because some scopes (and particularly, analog scopes) cannot.

The cursor method also allows me to use my old-school RPN calculator and turn it into an Instagram post

I did not know there was a HP15C collector's edition.  I am still using on a daily basis, my original 15C, now going on 42 years.....

[KungFuJosh]

My current scope is well past its best before date, however it does hava an RTC and maintains excellent time so I trust it inherently. I don't do much in the field anymore but if I am called in to assist with a problem then we need approximate timestamps to correlate with other events or happenings, and minute either way over a 24 hour period would be fine as long as we know to expect that discrepancy.

If RTC is something you'd benefit from, take a step up to the SDS1000X HD.

[rf-loop]

Why does clock accuracy matter to you? Do you plan to keep the scope running 24/7? It is a bit of a power hog...

Either you are missing the point or you just want to be contrary.  Not sure which.

The point is, if the OS is getting it's clock from the scope reference, then 150ppm is way out of spec.

Personally I'm not too concerned about what time is displayed as I do sync via NTP and give or take a few seconds is no problem for file timestamps.

Plus what Rob just said for affected use cases..

SDS800X HD  acquisition system have own (25MHz) reference clock, some things about its "accuracy" (or better said inaccuracy) told in data sheet. It is not as common time base for other things inside SDS800X HD. Example "linux pc" run there using its separate clock oscillator.  SDS800X HD have only just software running time o'clock, because there is not separate RTC circuit with its own separate reference oscillators and battery for run it when other systems are off. SDS1000X HD  is different. It have separate independently running RTC (when machine is off, RTC run with its own battery) and its linux read real time o'clock from it.   (naturally also RTC can automatically sync (set new time) using NTP, how it is arranged depends software (and most of RTC circuits do not have fine disciplining its reference oscillator).  As example all normal (windows or linux or what ever OS) PC's usually do with its internal RTC circuit.

[rf-loop]

Overall about time o'clock in modern oscilloscope. All understand that old Tektronix 565 or 545 did not need clock. (yes some still have oscilloscope wagon some example Revue stop watch... ) And also later 2465 and so on... no need RTC or other way arranged time o'clock.

But today, modern oscilloscopes are different. Some times we  need(!) really anough accurate real time.  Just when we take document images is only one case.
It is good to remember that we have there also History.  Normal runtime history and also same history used for Sequence acquistion mode.
Every wfm (segment) in history have time stamp. It can use just as delta time between segments but it can usse also real time stamps.
Think you set oscilloscpope watching some system what some times hick up due to unknown reasons but there happen many things time after time what may interfere...
Then oscilloscope run two days and collect data... with time stamps... what value these time stamps have... ther is hours, minutes, seconds and milliseconds and even more...
If its clock drift tens of seconds... in some cases  collected data value is just  as garbage... you see events but time is more like from lottery machine than real trusted time stamper.  So, we build machine where is fine time stamping system for events but then we do not have time... oh well we have "some" time... perhaps even minute is wrong... (* look ETA)

But then, this is inexpensive machine and ...  what average users do with it... just playing some fun... not as tool for analyze important things but oscilloscope for oscilloscope hobby... aka playing just with oscilloscope instead of playing nintendo. Or just playing fun images on screen... entertainment things, not as tool for some real important work..  world have changed.

Still I do not like that time axis measurement instrument time accuracy is just like "not so important" because old times real oscilloscopes did not need it. Clock was on room wall or on user wrist. (Remember that the exact right time only exists when there is one clock and only that one.... (yes I am Ex Time Nutter))

ETA: Think also if there is poor accuracy time o'clock running and based to it doing trigger time stamps. Then somewhere inside long data collection time, there is automatic  clock adjust due to NTP... just in random time position inside long time data collection... example just long Sequence. How user know where this time is adjusted by automatic NTP if it exist.  For these cases we need enough accurate RTC (or software clock) and example during one Sequence automatic NTC time sync need be blocked (if it exist). As can see, also with this tiny thing,  there is many things what need think when implement features to system.

 

[rf-loop]

I really like knowing how the DSO/MSO makes its automatic measurements, but using the Cursors to measure the Slew Rate, or the Rise Time, I did it once, I learned how to use the tool, but on a daily basis, I prefer use the Instrument's automatic measurement, as generally the number scales are not whole numbers, and this is bad for locating where the 10% and 90% of the pulse are, it can cause a lot of inaccuracy in the reading and calculations.

Yes, automated measurements are generally always better than "manual" cursor based measurements.  Even though all of our oscilloscopes can automatically measure this, I included the cursor-based method because some scopes (and particularly, analog scopes) cannot.

The cursor method also allows me to use my old-school RPN calculator and turn it into an Instagram post

I did not know there was a HP15C collector's edition.  I am still using on a daily basis, my original 15C, now going on 42 years.....

Here also original genuine 15C, not this later made different looks a like "Coll Edit" )
It have also been over 40 year near daily use. Now it is stored for save it...  and daily use is 11C (and some times 16C) when not use slide rule.

[martinot]

Just put an order for a SDS804X HD scope.  Seems out of stock in Europe, but hope I will get delivery in a month or so.

I did not know there was a HP15C collector's edition.  I am still using on a daily basis, my original 15C, now going on 42 years.....

The new one is great!

I have two (one to use, and one as spare). You can find more info about the reissue here:

https://hpcalcs.com/product/hp-15c-collectors-edition/

[temperance]

Off topic: HP15 collectors edition. They should lower the price and force children to use RPN calculators in order to avoid those stupid PEMDAS discussions.

On topic:

On topic:

Then oscilloscope run two days and collect data... with time stamps... what value these time stamps have... ther is hours, minutes, seconds and milliseconds and even more...
If its clock drift tens of seconds... in some cases  collected data value is just  as garbage... you see events but time is more like from lottery machine than real trusted time stamper.  So, we build machine where is fine time stamping system for events but then we do not have time... oh well we have "some" time... perhaps even minute is wrong... (* look ETA)

Can you give an example of a case where something like that was required?

For a glitch which happens every now and then, I narrow down where it might occur and revert to brute force methods instead of waiting.

[markone]

I played a little bit with FFT math function, i would say nice but i'm getting this following strange behavior : sweep time changes time to time from very fast to choppy slow, is it a known bug ?

[Martin72]

It would help if you could describe your setup.
Which input signal, which FFT settings, time base, memory, etc....

[Martin72]

What does the XY mode have to do with the FFT?

[tautech]

What does the XY mode have to do with the FFT?

Brain fart, post removed.

[markone]

It would help if you could describe your setup.
Which input signal, which FFT settings, time base, memory, etc....

I tried different setup, that i will describe in detail later, but i can say in advance the issue is not related to FFT number of points, since i changed them many times together with sample rate, or other scope settings.

I also disabled history and every kind of measurements, without solving the problem.

The tested signals were the output of my HF magnetic loop antenna and my SDG2042X generator with FM modulated carriers around 100MHz.

Easiest way to show the problem would be to make a video of the screen (and probably i will do), anyway try to imagine to see a very fast update rate FFT "disrupted" here and there by a remarkably slower update period that last up to some seconds.

The phenomenon does not seem to be related to FFT (or other) settings, to me it looks like some software task "disturbs" FFT analysis process.

Of course FW is the latest available on the site (at least last monday, when I received the instrument).

[tautech]

It would help if you could describe your setup.
Which input signal, which FFT settings, time base, memory, etc....

I tried different setup, that i will describe in detail later, but i can say in advance the issue is not related to FFT number of points, since i changed them many times together with sample rate, or other scope settings.

I also disabled history and every kind of measurements, without solving the problem.

The tested signals were the output of my HF magnetic loop antenna and my SDG2042X generator with FM modulated carriers around 100MHz.

Easiest way to show the problem would be to make a video of the screen (and probably i will do), anyway try to imagine to see a very fast update rate FFT "disrupted" here and there by a remarkably slower update period that last up to some seconds.

The phenomenon does not seem to be related to FFT (or other) settings, to me it looks like some software task "disturbs" FFT analysis process.

Of course FW is the latest available on the site (at least last monday, when I received the instrument).

Drill down here for detailed explanation of FFT:
https://www.eevblog.com/forum/testgear/sds800x-hd-review-demonstration-thread/

[markone]

Not sure this is the best way to put in share a video here ( keeping the source anonymous ), anyway following this link https://file.io/096xZZwUNYJF you guys will be able to download a short video where it's clear that the FFT time is heavily affected by mouse movement, no matter of the cursor position on the screen, no matter of DSO settings.

Problem is that I randomly experimented this "effect" also without a mouse attached, same setup, with LAN attached, where Instrument Control via web interface does not have the same effect unless you select a menu, but this is easily understandable.

Sorry for the low video quality, feel free to re-post it by a different mean.