Effect PC SysTimer to work oscilloscope and set HPET in BIOS

Hello, Velleman.
In the manual for PCS500 on page 24 stated that:

[size=85]“Errors in Recorder time scale
When recording at short time base (< 2s/div) the sampling interval is 10ms.
This is possible only on fast computers. Anyhow, do not execute other
applications during the recording process; it may influence the measuring
time scale.
The time base of the measurements is generated by the internal timer of the
computer. This timer can be put on hold by other processes on the computer.
This can cause a deviation in the time measurement.
To ensure the precision of the time measurement at short time base:
· Use a fast computer: 486 or Pentium.
· Do not run other applications when recording
· Prevent your computer from going into power saving mode”[/size]

And from my own experience of programming is obvious that time interval of less than 20 milliseconds is not constant, and moreover, and Microsoft specifies that the time interval of less than 50 milliseconds is not standardized.

My conclusion from the above: Timer PC affects the operation of oscilloscope.

My Questions:
Enabling HPET in the BIOS PC will improve the stability and accuracy of measurement oscilloscope?

PC Timer: It effect on the precision work of the oscilloscope OR only on the accuracy of charting in software?

Can I be sure that the values ​​of measurements made by the oscilloscope and after recorded in the log file will be true EVEN IF the PC timer works is unstable?

Where numerical values ​​are generated measurements recorded in the log file: in the oscilloscope or PC software?


Your guide stated possible problems in the short intervals.
How is it displayed when working in spectrum analyzer?

and more …
I did not find where the minimum requirements for the PC configuration for work your oscilloscope.
Question:
To work PCS500 spectrum analyzer mode - will there be enough of the old PC x486DX66 with RAM 4mb memory?

Thank you for your work.

[quote]Can I be sure that the values ​​of measurements made by the oscilloscope and after recorded in the log file will be true EVEN IF the PC timer works is unstable?[/quote]Only in the transient recorder mode can occur inaccuracy if the PC is very “busy” during the measurement run.

[quote]Your guide stated possible problems in the short intervals.
How is it displayed when working in spectrum analyzer?[/quote]The spectrum analyzer is using crystal oscillator as the time base. The results are accurate.

[quote]and more …
I did not find where the minimum requirements for the PC configuration for work your oscilloscope.
Question:
To work PCS500 spectrum analyzer mode - will there be enough of the old PC x486DX66 with RAM 4mb memory?[/quote]This should be OK.

Thank you for your help
Yet something remains unclear to me and I shall be grateful for your further clarification.

My statements below - it is true or false?

Time intervals between single samples of measurements are:
(a) In mode Oscilloscope and Spectrum Analyzer - is set via crystal oscillator located on the inside of PSB Velleman Device: - it is true or false?

(b) In mode Transient Recorder - is set from a PC (using the PC generator System Timer), and then this control signals are transmitted to the device Velleman: - it is true or false?

quote In mode Oscilloscope and Spectrum Analyzer - is set via crystal oscillator located on the inside of PSB Velleman Device: - it is true or false?[/quote]This is true.

quote In mode Transient Recorder - is set from a PC (using the PC generator System Timer), and then this control signals are transmitted to the device Velleman: - it is true or false?[/quote]True… We are using third party timer software FASTTime32.dll. It allows 1ms timing resolution.

Now, i understand the impact of "PC is very “busy” on work your “timer-driver-optimizer” FASTTime32.dll.

But, i could not find more information from other sources about FASTTime32.dll (which is understandable) for self-study - therefore i have additional questions.

question:
Which values deviations of time is PC-lab2000SE + FASTTime32.dll on a period of 10ms and 1ms?
Which means your definition - "PC is very “busy”?

P.S. :
I thought, but was not able to simplify my questions to more specific - I hope that you have a greater understanding of this topic.


and more …
In my lab PC is enabled HPET_mode in BIOS (High Precision Event Timer in Chipset of Main Board PC). That I need for a different, not your equipment.

This changes processing of “tik-signal” from the “Hard System Timer” in Windows, that allows more precisely work standard code of ordinary programs with periods less 50ms - without the use special additional “timer-driver-optimizer” program code.

question:
Your FASTTime32.dll - compatible with the regime HPET?

[quote]Which means your definition - "PC is very “busy”?[/quote]If a slow PC is doing very heavy operations e.g. word processing.

[quote]Your FASTTime32.dll - compatible with the regime HPET?[/quote]No.

Here’s a snippet from the FASTTime documentation:
[size=85]Description
The TFastTimer component causes an OnTimer event to occur whenever a specified period of time passes. Within that OnTimer event handler, your code specifies what you want to happen each time the OnTimer event occurs. The TFastTimer has a higher potential resolution than the built-in TTimer, which is limited to 55ms (18.2 times/second).[/size]

Thank you for your help.

Too bad that there is no clear information (expressed in numbers) about the accuracy of FASTTime32.dll for periods less than 55ms. So I can not calculate and indicate the reliability of the parameters in the results of my experiments, which use sensors to connection to “Transient Recorder”. This is very bad. You general recommendations - I understand, but do not allow to apply the principle = “reliability and repeatability,” in experiments using “Transient Recorder” below 55ms. Without knowledge of the numerical values ​​of possible deviations from the nominal value when work FASTTime32.dll - I would be difficult to evaluate “the accuracy and repeatability” during my experimentation.

If there is more numerically measured on the work FASTTime32.dll - I will be glad to see it.

Thank you for attention to my questions.

[quote]Too bad that there is no clear information (expressed in numbers) about the accuracy of FASTTime32.dll for periods less than 55ms. [/quote]I’m sorry, no such information available.
I made one hour test run at the highest sample rate (100Hz) to check the recorder timing accuracy.
The cumulative timing error during the one hour run was 50ms.
This was checked from the data file generated during the test run.
So the timing accuracy in this case was 100*50ms/3600s = 0.0014% = 14 ppm

The function generator used for the accuracy test has 8 ppm frequency error to the same direction as the result.
So the final error due to the FASTTime32.dll is about 6 ppm.

Very Well!
Thank you for your experiment. your results (“error the FASTTime32.dll is about 6 ppm”) give me a basis for own thoughts. Especially I appreciate that you voiced the method of measurement using a “Function Generator” - it is perfect! - I did not thought about this variant.
Thank you for your help.