GPS - Do you know where your test system is?

OK, I agree...that title is a little misleading. While GPS is popularly known to provide accurate position data anywhere on the globe, it's use in test systems is far different. A lesser known feature (lesser known outside of the scientific and engineering world) of GPS is the precise time reference that can be used to, among other things, synchronize clocks or discipline frequency sources to provide long-term clock stability. It is this feature that is of interest in the world of test and measurement.

The M213 M-Module is a GPS Timing Receiver capable of producing a highly accurate 1 Pulse Per Second (PPS) or 100 Pulse Per Second signal.

The M213 utilizes the M12+ Timing Receiver formerly manufactured by Motorola now manufactured by iLotus, LTD. and distributed by Synergy Systems. The M12+ is specifically designed for timing applications. The M12+ can track up to 12 satellites simultaneously and includes an algorithm known as Time-Receiver Autonomous Integrity Monitoring (TRAIM) that ensures the integrity of the PPS signal. The M213 actively monitors the PPS signal providing status of the signal via a front panel LED and a software register. In addition, the M213 can generate an interrupt on any change of status of the PPS signal. The M213 can be programmed to output a 1 PPS or a 100 PPS signal and the PPS can be configured to be active all the time, never, only when tracking at least one satellite or only when the TRAIM conditions are met.

A software driver is available that allows easy integration into any test system and like all of C&H's drivers, it includes a soft front panel application that provides out-of-the-box interactive control of the module. Finally, being an M-Module, the M213 can be used in any platform for which there exists an M-module carrier, including, VXI, VME, PXI, cPCI, LXI, and more.

While you certainly could monitor the location of you test system using the M213, it is not likely to be of interest. On the other hand, the ability to discipline a frequency source to provide extreme long term stability can be invaluable for many applications.

Event Detectors Receive the Official LXI Stamp of Approval

A quick follow-up to the post titled Reflections of the LXI Plugfest and General Meeting:

At the LXI Board of Director's Meeting on March 10th, our application for class C conformance for both of our Event Detector Products (EM405-8x106 and EM405-8x107) was approved. The products have been added to the LXI Consortium's official list of conformant devices.

LabView Support for M-Module Instrument Drivers

I few weeks ago, I recieived a call from a customer wanting to use our MA204 VXIpnp Driver in LabView. While we have experience using LabView to call VXIpnp drivers, we had not, as of this phone call, attempted to use LabView with a driver written in our new APIS base architecture. The Ma204 driver was migrated to this architecture late last summer and I must admit, when I received this phone call I had to cross my fingers.

The bottom line result from this call was that it worked as adveritsed. The customer was able to use LabView to control the Ma204 Pulse Generator and went forward with their LabView application development. The process is actually very simple.

LabView has had, for a long time, a utility to convert LabWindows/CVI device drivers into LabView libraries complete with VI's for each function in the driver. In LabView versions prior to 8.0, this utility was available from any VI using the menu item Tools>>Instrumentation>>Import CVI Instrument Driver. In LabView 8.0, the menu name was changed to Tools>>Instrumentation>>Create VI Interface to CVI Instrument Driver. Beyond LabView 8.0, this utility was removed from the normal LabView installation and instead, is available as an independent download referred to as LabView Interface Generator for LabWindows/CVI Instrument Drivers. This tool is available as a free download from ww.ni.com.

Running this tool is a matter of iterating through a simple wizard. The tool uses the CVI driver's function panel (.fp) file to create LabView VI's for each function in the library. The VI's are implemented using LabView's Call Library Function Node which is LabView speak for a utility that allows LabView to call a standard Windows Dynamic Link Library (DLL). In this case, the DLL being used is the CVI driver's DLL.

All of our M-module drivers include a Windows DLL and a CVI function panel (.fp) file. Therefore, all of our M-module drivers can be used in LabView. As the case from a few weeks ago proves, the process is simple and dependable. If you would like to use one of our driver's in LabView and would like further details or assistance with this process, please contact us and we will be happy to support your efforts.

Reflections of the LXI PlugFest and General Meeting

I attended the LXI Consortium's PlugFest and General Meeting in Newport Beach, CA on February 11-13. The LXI Consortium holds these meetings once a quarter at sites throughout the world. This was by far the heaviest attended meeting to date. C&H has attended at least half a dozen of these meetings since 2006 and we've noticed the continual growth in participation. This bodes well for LXI and all those involved. I am continually amazed at how well a group of competitors can collaborate for the betterment of the industry and I'm not strictly speaking about the collaboration on writing the specifications. Short of providing proprietary source code or design details, you find at these meetings, engineers providing guidance, advice and even debug assistance that help better a competitors instrument(s). The type of help that is unheard of in other industries.

There were several components of the 3-day meeting some of which happened in parallel. On the first day, C&H participated in the Class C Multivendor System Demo (MVSD). This involved connecting several different vendors' instruments, including our EM405-8, to a network, and performing same basic connectivity tests. We tested LXI discovery and Identification on all the major software vendor's tools (Agilent, Mathworks and National Instrument). We pulled up web pages and XML files. We performed tests such as removing the DHCP server and verifying that all the instruments switch to an AutoIP configuration. The good news about this testing, was that there was no news. It may be uninteresting, but it is great that there were no major problems with any of instruments nor any of the software vendor's products. According to Rob Purser of Mathworks who has been in charge of the MVSD work for the last couple years, this is the first time things have gone so smoothly. This tells me that the products are starting to mature to a point where the Class C features have a solid foundation.

In parallel with the Class C demo, a group of engineers performed some Class B (IEEE-1588) testing. As expected, there were more difficulties than the Class C testing but they were able to create a system of class B devices and get the clocks synchronized with a precision on the order of nanoseconds. I was not involved with this testing so I don't know details but the reports were very promising.

A large part of the meeting was dedicated to "lowering the barrier" to 1588. This included the demo/testing discussed above, open discussions amongst the attendees, and presentations by 1588 tool vendors. The common themes of all this discussion and presentations were that 1588 works, 1588 is useful and desirable, 1588 will become an increasingly import feature of LXI instruments and 1588 is becoming easier to implement by instrument vendors.

The second day was full of presentations discussing all of the current happenings with the LXI consortium. The LXI Standard Version 2.0 is currently in works and there are many technologies being worked on and several more being explored. Some of these include, improved web support for triggering, resource management, scripting, and IEEE 1588-2008. The consortium is very active and is building upon a solid foundation by adding features that improve the user's experience with LXI instruments. C&H is closely following these improvements and we will continue to adapt our LXI offering as the specification improves.

The final day was open to the public and consisted of presentations by LXI members and users. In addition, the final day was reserved for compliance testing and we brought our LXI Event Detector along to be tested. Compliance testing involves sitting down with Lynn Wheelwright, the consortium's compliance guru, and running through a sequence of tests that verify that your device meets the LXI specification. Every rule of the specification is verified and your instrument is poked and prodded to make sure it is compliant. The entire test is guided by a piece of software written by Lynn called the LXI Compliance Test Suite. Several of the tests are automated; however, most of them require some sort of user intervention or simple manual verification.

The test process did expose a few LXI rules in which our device was non-compliant; however, every one of them was fixed on the spot and we were able to leave the meeting requiring only paper work and the release and registration of the IVI driver in order for us to achieve certification. What was most interesting about our testing was that it exposed a couple items that existed in the EM405-8 which received compliance in 2006. That is a testament to how far the testing has come. The problems were nothing that affected the functionality of the carrier but they were problems non-the-less and we were grateful that the test exposed them. More robust testing like this no doubt improves the quality of our products.

The meeting was a success. We left with everything needed to achieve compliance and we learned a lot about the future additions to the LXI specification. Our compliance paper work has since been submitted and the IVI driver has been registered on the IVI Foundation website. We are a compliance committee review and a board of directors meeting away from formal approval of our second LXI device. We are excited about LXI and its growing demand in the marketplace. It seems that so is the rest of the Test and Measurement Industry.

Event Detectors

My efforts over the last couple of weeks have been focused on preparing our 64/128 Channel Event Detector products for LXI compliance testing. While the compliance testing effort is interesting enough, it is actually the features of the Event Detector itself that I would like to focus on. We can discuss LXI compliance testing in a couple of weeks after I return from the LXI plugfest in Irvine, California.

The Event Detector is by no means a new product. We have been shipping the MA203 Event Detector M-module in both VXI and PXI systems since 1999. In fact, to date the MA203 install-base resides at over 430 units. This new offering of Ethernet Event Detectors consists of the same MA203 M-Modules integrated into an EM405-8 carrier in either a 64 or 128 channel configuration.

The Event Detector works by sampling all channels in parallel and selectively storing the samples along with a 31-bit timestamp into a FIFO. At every period of the programmable sample clock, the event detector samples all channels in parallel. It then compares the sample with the previous stored value and determines if any of the watched inputs have toggled. If an input has changed, the entire sample is stored along with the timestamp. The process repeats at a rate of up to 5MHz. The Event Detector features a highly programmable sample clock and the capability to use an external clock of up to 5MHz. It also includes per-channel programmable input thresholds of up to 25 volts, programmable debounce logic, and extensive triggering utilities for synchronization.

The key feature of the Event Detector is the ability to store samples only when one or more of the watched inputs have change. This provides real-time data compression and takes the burden off software to recognize and determine the interesting part of an acquisition. We call this “Data Abstraction.”

At Autotestcon in September, we demonstrated the 128 Channel Event Detector with a game that required users to press a sequence of buttons to cause events. When a user started the game, the Event Detector began continuously sampling all 128 channels at 5MHz. Events occured when a user pressed one of the toggle buttons during the game. Each play of the game typically lasted about 3 seconds. We kept statistics during the show and after three days, we had sampled a total of 14 minutes and 59.91 seconds. In that time, we received a total of 791 events and transferred across the network a total of 10.04 kilobytes (including timestamps). In stark contrast, if we would have used a standard Data Acquisition module that stores every sample at 5MHz, we would have transferred 25.14 gigabytes. In addition, a large amount of processing power would have been required to monitor the data to find the events. This example is a clear illustration of the advantages of the Event Detector and its ability to perform data abstraction. The contrast of the amount of data as compared to a continuously sampling data acquisition module is remarkable.

In just over a week we will obtain LXI compliance on the 64 and 128 Event Detectors. Beyond that, we plan to continue advancing this technology and adding products that compliment this functionality as well as our entire product line.

Introduction - Who is C&H?

For my first post, I considered skipping the typical introduction and going straight to the meat and potatoes of this blog – news and commentary on all things C&H including the industry in which we live, the products we create and the employment of those products in various applications – but, I’ve reconsidered. A little self reflection is always valuable and there are those of you, unfamiliar with C&H, who upon finding this blog will head straight to this first post to find out what this is all about.

Who are we? What do we do? In short, C&H designs and manufactures instrumentation and other electronics for the test and measurement industry. In fact, we have nearly 100 different products spanning a wide spectrum of functionality including sources, measurement, data acquisition, switching, digital and analog I/O, and serial communications.

So what is different about us? Our approach is unique and is best described not in words, but in a picture and a single tag line "Platform Independent Instruments."


We focus on instruments in the ANSI standard M-module format and we provide the tools to use those instruments in any platform. In addition to the M-modules themselves, we provide M-module carriers for all of the major platforms used in the test and measurement world. This opens up a world of functionality to the test and measurement industry making available a large number of devices, not only from C&H but also from almost a dozen other M-module manufacturers. A comprehensive list of available M-modules can be found here.

In addition to M-modules and M-module Carriers, we manufacture several other unique products for the test and measurement industry. Products such as: the VX407C Intelligent PXI Carrier for VXI, the VX411C Intelligent PMC/PCMCIA Carrier for VXI, the VX402C-64 VME, VXI (As or B size) or VME64.carrier for VXI, Industry Pack modules and carriers for both VXI and PXI, and a collection of Standard VXI instruments.

More details on all of these products and on C&H in general can be found on our website. For direct inquiries you can contact us at support@chtech.com or sales@chtech.com. In addition, your local sales rep will be happy to answer any of your inquiries.