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.