C&H Technologies

Feel the Power

noreply@blogger.com (David Clark) — Fri, 02 May 2008 20:54:00 +0000

I'm feeling very powerful these days. It has to be the PowerPC, the ARM processor, Embedded Linux, M-Modules, ANSI-C drivers, APIS, PXI Modules, PMC Modules, the VX406C, the VX407C, the VX411C, and the EM405-8 or, in other words, C&H's Intelligent Carriers. The marriage of an embedded processor with the power of open source Linux and the countless number of instruments in the M-module, PMC and PXI formats creates a very powerful product line with limitless possibilities.

I recently wrote a simple demo application for a customer utilizing the VX406C running Embedded Linux and the M395 16-Channel DAC M-Module. This embedded application creates 4 custom VXI Word Serial Commands: “volt” – sets the DAC output, “volt?” – queries the DAC output, “sweep” – sweeps the voltage from 0 to 5 volts, and “clearirq” – clears a pending interrupt. The commands “volt” and “volt?” are self explanatory. The command “sweep” starts a sweep of the DAC output from 0 to 5 volts in 1-bit increments dwelling for 1ms at each point. When the sweep completes, the application generates a VXI interrupt. The command “clearirq” clears the generated VXI interrupt. The host software consists of a small GUI allowing the user to interactively send the commands. When the “sweep” command is sent, the host software starts a counter and continuously updates the counter illustrating that the sweep, indeed, runs asynchronously on the PowerPC residing on the VX406C. When VX406C completes the sweep and generates the VXI interrupt, the host software receives the interrupt and handles it appropriately stopping the counter and going back to normal.

Yes this is a very simple example, but it illustrates the power of the intelligent carriers and opens the mind to the possibilities available with this architecture. Even more important is that the application, utilizing the M395 ANSI-C driver, the VX406C Linux APIS Platform Support Module, and the standard Linux toolset, took less than half an hour to write (the source code can be viewed here). It goes to show that it is extremely simple to create a basic application that can be expanded upon to add features and functionality.

A more complex example is an antenna tuner utilizing the VX407C, a PXI Arbitrary Waveform Generator (ARB) and a PXI digitizer. In this application, the ARB output and the digitizer inputs were connected to a separate device that performed attenuation, amplification and coupling to/from the antenna. The digitizer received a reference signal from the ARB and a reflected signal from the antenna. As in the above example, a sweep command was created. When the sweep command was received, the embedded application would step the ARB through a range of frequencies. At each frequency, the embedded application would digitize both the reference and reflected waveforms, would perform an FFT on each digitized waveform and would use the FFT results to calculate a Voltage Standing Wave Ratio (VSWR). The host software would only retrieve an array of VSWR measurements. Imagine the VXI or PXI traffic and the processing power required to perform this in a standard setup. By dedicating an embedded processor to this task the host is free to manage its other responsibilities.

The above examples are just a taste of what can be created with C&H's intelligent carrier architecture. With well over 100 different M-modules and countless PMC and PXI modules, you can just envision the possibilities. With the addition of Linux and the vast array of open source tools that come along with it, this platform becomes very, very powerful.

m395_demo.c

GPS - Do you know where your test system is?

noreply@blogger.com (David Clark) — Thu, 03 Apr 2008 02:59:00 +0000

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

noreply@blogger.com (David Clark) — Thu, 13 Mar 2008 04:19:00 +0000

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

noreply@blogger.com (David Clark) — Mon, 03 Mar 2008 05:32:00 +0000

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

noreply@blogger.com (David Clark) — Mon, 25 Feb 2008 16:44:00 +0000

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

noreply@blogger.com (David Clark) — Fri, 08 Feb 2008 04:29:00 +0000

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?

noreply@blogger.com (David Clark) — Fri, 18 Jan 2008 22:32:00 +0000

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.