1588 Reasons for Synchronised Measurements
01 October 2010
Taking measurements is the bread and butter of an engineer or scientist’s work, yet with the increased functionality built into modern devices, measurement complexity and the required test time has grown.
In order to meet these growing needs it is often not instrument resolution or channel count that is the gating factor, it’s all about time. Applications frequently require advanced timing and synchronisation to accelerate test time or enable complex measurements.
The most accurate and straightforward implementation is for all of your instruments to share the same timing source. For example, systems based on the PXI platform share a built-in common 10 MHz clock. Combined with the Star Trigger bus, this allows synchronisation and triggering of multiple instruments, with skew of less than 1 nanosecond between slots.
The limitation of a shared timing source comes when implementing distributed systems, since cabling introduces issues of impedance matching, noise and propagation delay. The solution is for distributed instruments to have independent clocks that are precisely synchronised.
The introduction of the IEEE 1588 standard in 2002 made this a reality, enabling distributed architectures via Ethernet, LXI or even satellite communication. IEEE 1588 defines a standard set of clock characteristics with value ranges for each.
By running a distributed algorithm throughout the network, the highest quality or “grand master” clock can be indentified and used to broadcast timestamp packets to update all the other “slave” clocks. This creates a fault tolerant setup that requires minimal network bandwidth, overhead, processing power or administrative set-up.
Implementing IEEE 1588 brings new challenges to your application; the standard simply specifies the packet exchange protocol allowing devices from different manufacturers to interoperate, and does not include any standard implementation for adjusting each instrument’s clock. This means the software design must be written to understand the timing constraints and clock synchronisation. It can be difficult to write a program with timing constraints if the environment you are using does not explicitly have a concept of time.
There is currently considerable corporate research and development being committed to solve exactly this problem. For example, the latest release of NI LabVIEW has many mechanisms to uniquely deal with time. The Timed Loop structure, for instance, is a well-defined API for specifying timing constraints in your application. In addition, you can use the Timed Loop to configure priority, processor affinity and timing sources. You can synchronise multiple Timed Loops to each other within a single system or as part of a distributed real-time system. LabVIEW 2010 introduces IEEE 1588 synchronisation as an additional timing source for Timed Loops. This further extends the capabilities of LabVIEW programs to synchronise across wide areas, on different LabVIEW Real-Time targets, over standard Ethernet with millisecond resolution.
For over 20 years, LabVIEW has been used by engineers and scientists across the world to program test and measurement applications, as it abstracts much of the complexity traditionally associated with software design. As a high level graphical programming language, LabVIEW allows developers to maximise both the efficiency of the development process and the power and functionality required to meet the specification needs. The addition of IEEE 1588 into LabVIEW as a fully integrated timing source enables engineers from any background to truly become masters of time.
Graham Green is Technical Marketing Engineer at National Instruments UK & Ireland
Contact Details and Archive...
Related Articles...
Most Viewed Articles...