{"id":2908,"date":"2026-10-31T21:36:31","date_gmt":"2026-10-31T21:36:31","guid":{"rendered":"https:\/\/raynovtechnology.com\/acquisition-timing-jitter-windows\/"},"modified":"2026-11-01T10:29:49","modified_gmt":"2026-11-01T10:29:49","slug":"acquisition-timing-jitter-windows","status":"publish","type":"post","link":"https:\/\/raynovtechnology.com\/fr\/acquisition-timing-jitter-windows\/","title":{"rendered":"Temps d'acquisition et gigue : pourquoi Windows ne garantit pas la milliseconde"},"content":{"rendered":"<p>A test engineer measures how long a relay stays closed on a validation bench, gets 49 ms, then 53 ms, then 61 ms on the same part, and starts doubting the relay. Most of the time the relay is fine. The spread comes from where the stopwatch lives: inside a loop running on a desktop operating system.<\/p>\n<p>This guide explains where that timing error comes from, how to size it, and how to design an acquisition chain where the hardware keeps the time and the PC only programs and displays.<\/p>\n<h2>1. The problem: software timing on a desktop OS<\/h2>\n<h3>1.1 What the scheduler does to your loop<\/h3>\n<p>Windows, and desktop Linux without a real-time kernel, are general-purpose operating systems. The scheduler shares the CPU between your test application, drivers, antivirus, updates, the user interface and dozens of background services. When your code calls <code>sleep(1)<\/code> or reads a timestamp in a loop, nothing guarantees it will be woken exactly 1 ms later.<\/p>\n<p>The result is <strong>jitter<\/strong>: the variation between the time you asked for and the time you got. By default the Windows system timer ticks every 15.6 ms (64 Hz); applications can request a finer resolution, down to about 1 ms. As a result, software delays and wake-ups commonly vary by 1 to 16 ms depending on timer resolution, load, power settings and drivers. This is a typical range, not a hard bound: occasional larger delays can occur. Measure it on the actual platform.<\/p>\n<h3>1.2 Typical symptoms on a bench<\/h3>\n<ul>\n<li>Pulse durations that vary from run to run while the device under test is stable.<\/li>\n<li>Two channels read &#8220;at the same time&#8221; that are in fact sampled several milliseconds apart.<\/li>\n<li>Timestamps in the log that cluster on regular steps instead of spreading continuously.<\/li>\n<li>Results that change when someone opens a browser on the bench PC.<\/li>\n<\/ul>\n<h3>1.3 Worked example: what jitter does to a pass\/fail limit<\/h3>\n<p><em>Example, illustrative values only.<\/em> A test requires a pulse of 50 ms \u00b1 2 ms. The software measures it by polling a digital input and reading the PC clock.<\/p>\n<ul>\n<li>Polling-loop jitter, assumed worst case: \u00b18 ms at the start edge and \u00b18 ms at the end edge.<\/li>\n<li>Worst-case measurement error: up to 16 ms, eight times the \u00b12 ms tolerance (four times the full 4 ms window).<\/li>\n<\/ul>\n<p>The test cannot discriminate a good part from a bad one. This is a measurement-system problem, not a device problem. A gauge study on such a bench would show it immediately.<\/p>\n<h2>2. Principle: the hardware keeps the time<\/h2>\n<p>The rule we apply on our benches is simple: <strong>the PC software programs and displays; the hardware times.<\/strong><\/p>\n<h3>2.1 Described principle diagram<\/h3>\n<p>Picture three blocks from left to right:<\/p>\n<ol>\n<li><strong>Timebase<\/strong> \u2014 a crystal oscillator on the acquisition hardware (DAQ module, microcontroller, FPGA or real-time target).<\/li>\n<li><strong>Sample clock and trigger logic<\/strong> \u2014 derived from the timebase; it decides exactly when each sample is taken and when acquisition starts.<\/li>\n<li><strong>Buffer and PC link<\/strong> \u2014 samples are stored with their index in a hardware buffer and transferred to the PC in blocks (USB, Ethernet, PCIe).<\/li>\n<\/ol>\n<p>The PC sits at the far right. Its job is to configure blocks 1 and 2, start the task, and read the buffer. Transfer latency can vary by milliseconds without consequence, because each sample&#8217;s time is defined by its index, not by when it reached the PC.<\/p>\n<h3>2.2 Finite acquisition clocked by hardware<\/h3>\n<p>For short events, the cleanest method is a finite, hardware-timed acquisition:<\/p>\n<p><strong>duration = number of samples \/ sample rate<\/strong><\/p>\n<p><em>Example:<\/em> at 10 kS\/s, 5,000 samples cover exactly 500 ms, and each sample is 100 \u00b5s apart, to the accuracy of the module&#8217;s clock. A 50 ms pulse is then measured by counting samples between edges: resolution 100 \u00b5s, independent of Windows.<\/p>\n<h3>2.3 Options for the timebase<\/h3>\n<table>\n<thead>\n<tr>\n<th>Option<\/th>\n<th>Typical use<\/th>\n<th>Strength<\/th>\n<th>Watch out for<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>DAQ module with hardware sample clock<\/td>\n<td>Analog and digital measurement<\/td>\n<td>Simple, driver-supported<\/td>\n<td>Check that the task is really hardware-timed, not software-timed<\/td>\n<\/tr>\n<tr>\n<td>Microcontroller timer<\/td>\n<td>Pulse timing, simple sequencing<\/td>\n<td>Low cost, deterministic<\/td>\n<td>Firmware to maintain, data link to PC<\/td>\n<\/tr>\n<tr>\n<td>FPGA<\/td>\n<td>Fast edges, many channels in parallel<\/td>\n<td>Clock-cycle determinism (tens of ns at typical FPGA clocks)<\/td>\n<td>Development effort<\/td>\n<\/tr>\n<tr>\n<td>Real-time target (e.g. cRIO-type controller)<\/td>\n<td>Closed loops, HIL<\/td>\n<td>Deterministic loop plus FPGA<\/td>\n<td>Cost, toolchain<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<p>Our team has analysed acquisition timing on NI cRIO and cDAQ platforms, comparing hardware timing with Windows-side jitter. The method in this guide comes from that type of work.<\/p>\n<h2>3. Triggers: hardware versus software<\/h2>\n<h3>3.1 Software trigger<\/h3>\n<p>The software watches a value and starts recording when a condition is met. The start time inherits all the OS jitter. Acceptable for slow trends; not acceptable for timing measurements.<\/p>\n<h3>3.2 Hardware trigger<\/h3>\n<p>A digital edge or an analog level, detected by the acquisition hardware itself, starts the sample clock. The latency is fixed and short, and known from the hardware documentation. Use it whenever the start of the measurement matters. Pre-trigger buffering lets you keep samples taken before the event, which is useful to see what led to a fault.<\/p>\n<h3>3.3 Synchronising several modules<\/h3>\n<p>When channels are spread over several modules or chassis, share a single clock and trigger between them (shared backplane, a dedicated trigger line or a clock-distribution signal). Two modules running on their own crystals will drift apart, as section 4 shows.<\/p>\n<h2>4. Clock drift: the slow error<\/h2>\n<p>Even a hardware timebase is not perfect. A crystal is specified in <strong>ppm<\/strong> (parts per million).<\/p>\n<h3>4.1 Worked calculation<\/h3>\n<p>One hour = 3,600 s.<\/p>\n<ul>\n<li>\u00b120 ppm: 3,600 s \u00d7 20 \u00d7 10\u207b\u2076 = 0.072 s, about <strong>72 ms per hour<\/strong>.<\/li>\n<li>\u00b12 ppm: 3,600 s \u00d7 2 \u00d7 10\u207b\u2076 = 0.0072 s, about <strong>7 ms per hour<\/strong>.<\/li>\n<\/ul>\n<p><em>Example:<\/em> a cycling test runs for 8 hours on a module with a \u00b120 ppm clock. The accumulated time error can reach about 0.58 s. Fine for a temperature log; not fine if you correlate events with another recorder to the millisecond.<\/p>\n<h3>4.2 What to do about it<\/h3>\n<ul>\n<li>For long tests, synchronise all instruments to one clock, or periodically to a reference time source.<\/li>\n<li>Record which clock produced each timestamp.<\/li>\n<li>Do not mix PC timestamps and hardware timestamps in the same calculation without converting one into the other.<\/li>\n<\/ul>\n<h2>5. Selection criteria for a timing-critical acquisition chain<\/h2>\n<ol>\n<li><strong>Required resolution:<\/strong> as a rule of thumb, about ten times finer than the tolerance to verify (the classic 10:1 ratio between measurement capability and tolerance). A 4:1 test uncertainty ratio (TUR) is often accepted when 10:1 is not practical. The ratio you apply should be written in the test specification.<\/li>\n<li><strong>Sample rate:<\/strong> high enough to resolve the fastest edge of interest, with margin for filtering.<\/li>\n<li><strong>Timing source:<\/strong> hardware-timed sample clock confirmed in the driver configuration.<\/li>\n<li><strong>Trigger:<\/strong> hardware trigger available on the right signal type (digital edge, analog level).<\/li>\n<li><strong>Clock accuracy (ppm):<\/strong> consistent with the test duration and the correlation needs.<\/li>\n<li><strong>Synchronisation:<\/strong> shared clock and trigger if several modules are involved.<\/li>\n<li><strong>Buffer size:<\/strong> enough on-board memory to absorb transfer delays without loss.<\/li>\n<\/ol>\n<h2>6. Common mistakes<\/h2>\n<ul>\n<li><strong>&#8220;It&#8217;s a DAQ, so it&#8217;s hardware-timed.&#8221;<\/strong> Many drivers allow on-demand, software-timed reads. Check the task&#8217;s timing mode.<\/li>\n<li><strong>Timestamping samples on arrival at the PC.<\/strong> You measure USB latency, not the signal.<\/li>\n<li><strong>Using <code>sleep()<\/code> to pace a test sequence<\/strong> where the delay matters to the device.<\/li>\n<li><strong>Measuring with two unsynchronised modules<\/strong> and subtracting their timestamps.<\/li>\n<li><strong>Ignoring drift on multi-hour tests.<\/strong><\/li>\n<li><strong>Leaving power-saving modes active<\/strong> on the bench PC, which can change timer behaviour.<\/li>\n<\/ul>\n<h2>7. Checklist before you trust a timing measurement<\/h2>\n<ul>\n<li>[ ] The required resolution and tolerance are written in the test specification.<\/li>\n<li>[ ] The acquisition task is hardware-timed (checked in the configuration, not assumed).<\/li>\n<li>[ ] The start is on a hardware trigger where timing matters.<\/li>\n<li>[ ] All channels that are compared share one clock.<\/li>\n<li>[ ] Clock accuracy has been converted to an error over the test duration.<\/li>\n<li>[ ] The method was verified with a known reference signal (e.g. a pulse from a calibrated generator).<\/li>\n<li>[ ] The report states the timing source and resolution.<\/li>\n<\/ul>\n<h2>8. Going further<\/h2>\n<p>Timing is one part of proving that a bench measures correctly. Our guide on <a href=\"https:\/\/raynovtechnology.com\/test-bench-qualification-fat-sat\/\">qualifying a test bench before production (FAT\/SAT)<\/a> covers the full verification. Real-time constraints are also central in <a href=\"https:\/\/raynovtechnology.com\/hil-test-bench-architecture\/\">HIL bench architecture<\/a>, and our <a href=\"https:\/\/raynovtechnology.com\/test-automation-script-to-sequencer\/\">test automation guide<\/a> shows how to keep timing in hardware while the sequencer runs on a PC. For how timing verification fits into acceptance testing, see <a href=\"https:\/\/raynovtechnology.com\/atp-vs-qtp\/\">ATP vs QTP<\/a> and our <a href=\"https:\/\/raynovtechnology.com\/atp-methodology\/\">ATP methodology<\/a>.<\/p>\n<p>RAYNOV designs <a href=\"https:\/\/raynovtechnology.com\/custom-validation-system-delivery\/\">custom validation systems<\/a>, from specification to commissioning, and also supports teams through <a href=\"https:\/\/raynovtechnology.com\/validation-as-a-service\/\">Validation as a Service<\/a>.<\/p>\n<p><strong>Timing results you can&#8217;t fully trust? <a href=\"https:\/\/raynovtechnology.com\/contact\/\">Talk to our engineers<\/a>.<\/strong><\/p>\n<p><strong>External references:<\/strong> Microsoft documentation on the Windows timer resolution, <a href=\"https:\/\/learn.microsoft.com\/en-us\/windows\/win32\/api\/timeapi\/nf-timeapi-timebeginperiod\">timeBeginPeriod<\/a>; Python&#8217;s <a href=\"https:\/\/docs.python.org\/3\/library\/time.html\">time module<\/a> (clock resolution and <code>perf_counter<\/code>).<\/p>\n","protected":false},"excerpt":{"rendered":"<p>A test engineer measures how long a relay stays closed on a validation bench, gets 49 ms, then 53 ms, [&hellip;]<\/p>\n","protected":false},"author":2,"featured_media":2941,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_uag_custom_page_level_css":"","site-sidebar-layout":"default","site-content-layout":"","ast-site-content-layout":"normal-width-container","site-content-style":"unboxed","site-sidebar-style":"default","ast-global-header-display":"","ast-banner-title-visibility":"","ast-main-header-display":"","ast-hfb-above-header-display":"","ast-hfb-below-header-display":"","ast-hfb-mobile-header-display":"","site-post-title":"","ast-breadcrumbs-content":"","ast-featured-img":"","footer-sml-layout":"","ast-disable-related-posts":"","theme-transparent-header-meta":"","adv-header-id-meta":"","stick-header-meta":"","header-above-stick-meta":"","header-main-stick-meta":"","header-below-stick-meta":"","astra-migrate-meta-layouts":"default","ast-page-background-enabled":"default","ast-page-background-meta":{"desktop":{"background-color":"var(--ast-global-color-4)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"tablet":{"background-color":"","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"mobile":{"background-color":"","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""}},"ast-content-background-meta":{"desktop":{"background-color":"var(--ast-global-color-5)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"tablet":{"background-color":"var(--ast-global-color-5)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"mobile":{"background-color":"var(--ast-global-color-5)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""}},"footnotes":""},"categories":[22],"tags":[],"class_list":["post-2908","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-testing-guides"],"uagb_featured_image_src":{"full":["https:\/\/raynovtechnology.com\/wp-content\/uploads\/2026\/10\/G6-featured-v2.png",1200,675,false],"thumbnail":["https:\/\/raynovtechnology.com\/wp-content\/uploads\/2026\/10\/G6-featured-v2-150x150.png",150,150,true],"medium":["https:\/\/raynovtechnology.com\/wp-content\/uploads\/2026\/10\/G6-featured-v2-300x169.png",300,169,true],"medium_large":["https:\/\/raynovtechnology.com\/wp-content\/uploads\/2026\/10\/G6-featured-v2-768x432.png",768,432,true],"large":["https:\/\/raynovtechnology.com\/wp-content\/uploads\/2026\/10\/G6-featured-v2-1024x576.png",1024,576,true],"1536x1536":["https:\/\/raynovtechnology.com\/wp-content\/uploads\/2026\/10\/G6-featured-v2.png",1200,675,false],"2048x2048":["https:\/\/raynovtechnology.com\/wp-content\/uploads\/2026\/10\/G6-featured-v2.png",1200,675,false],"trp-custom-language-flag":["https:\/\/raynovtechnology.com\/wp-content\/uploads\/2026\/10\/G6-featured-v2-18x10.png",18,10,true]},"uagb_author_info":{"display_name":"Sphie-bot","author_link":"https:\/\/raynovtechnology.com\/fr\/author\/sphie-bot\/"},"uagb_comment_info":0,"uagb_excerpt":"A test engineer measures how long a relay stays closed on a validation bench, gets 49 ms, then 53 ms, [&hellip;]","_links":{"self":[{"href":"https:\/\/raynovtechnology.com\/fr\/wp-json\/wp\/v2\/posts\/2908","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/raynovtechnology.com\/fr\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/raynovtechnology.com\/fr\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/raynovtechnology.com\/fr\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/raynovtechnology.com\/fr\/wp-json\/wp\/v2\/comments?post=2908"}],"version-history":[{"count":1,"href":"https:\/\/raynovtechnology.com\/fr\/wp-json\/wp\/v2\/posts\/2908\/revisions"}],"predecessor-version":[{"id":2926,"href":"https:\/\/raynovtechnology.com\/fr\/wp-json\/wp\/v2\/posts\/2908\/revisions\/2926"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/raynovtechnology.com\/fr\/wp-json\/wp\/v2\/media\/2941"}],"wp:attachment":[{"href":"https:\/\/raynovtechnology.com\/fr\/wp-json\/wp\/v2\/media?parent=2908"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/raynovtechnology.com\/fr\/wp-json\/wp\/v2\/categories?post=2908"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/raynovtechnology.com\/fr\/wp-json\/wp\/v2\/tags?post=2908"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}