google
yahoo
bing
Sep 25
Wireless Version of PXI?
icon1 Eric Starkloff | icon2 Automated Test, Technology | icon4 September 25th, 2007| icon3No Comments »

I came across an interesting blog post by Richard A. Quinnell, Technical Editor — Test & Measurement World.  In his blog, he made the following statement, “With just about everything going wireless, I’ve started wondering when PXI will join the parade.”  I felt a response by our PXI Marketing Group Manager, Richard McDonell would be appropriate.  

Guest Blogger: Richard McDonell – PXI Group Manager

Every day I learn about another common device that has gone wireless…from cell phones to game controllers to PCs and laptops.  In each of these cases, the wireless interface is replacing a previously wired solution providing increased range, improved flexibility, and added user-convenience.  These are great benefits, so why hasn’t PXI gone wireless?  Well, in many ways it already has.  PXI is already being used to design and test thousands of wireless devices and you can use a wireless (802.11) LAN interface to transfer data to other systems or back to a network location.  Wireless LAN interfaces can also be used for controlling your PXI systems remotely.   

So why not decouple each PXI module from a wired PXI bus and connect them using a wireless protocol?  Technically, there is no reason why you couldn’t do this.  The real question is do you really want to?  Unfortunately, the convenience of a wireless interface doesn’t come without tradeoffs in performance, setup ease-of-use, and cost.  The core benefits of PXI come from the shared card cage architecture, the high bandwidth and low latency PCI and PCI Express bus, and integrated timing and synchronization (I suppose this could also count as “wireless” since PXI eliminates the need for most external trigger and synchronization cables).  Separating each PXI module into its own separate sub-system via WiFi would dilute the benefits of PXI and significantly decrease the performance (due to increased bus latency), cost (due to dedicated fans, power supplies, and boxes per device), and synchronized measurement accuracy (due to a lack of triggering) that PXI offers in its current state compared to traditional standalone instrumentation.  You would however retain the user-defined software aspects of PXI in such a configuration which is a key component of PXI’s measurement flexibility and reuse.   

Thus, I do not feel wireless PXI in the form of discrete PXI devices connected via wireless interface is worth the effort.  However, I would agree PXI is the ideal platform for designing and testing wireless devices and that it enables higher performance, lower cost, and improved flexibility in most test and control applications today.

Sep 17

I just read the latest 2007 Test and Measurement Salary Survey. One of the questions that really peaked my interest was on the topic of what technologies are engineers being required to learn. The number one test platform listed was PXI (20% of readers listed it), with PXI Express, an extension to PXI, a close second. This is just another example of the increasing industry adoption of PXI. Most of the other technologies engineers are being asked to learn are communication protocols - Firewire, WLAN, and WiMAX were all high in the ranking.

Aug 20
New PXI Modules from Agilent
icon1 Eric Starkloff | icon2 Automated Test, News | icon4 August 20th, 2007| icon3No Comments »

One the biggest signs of success factors of PXI has been the increased adoption by major test and measurement vendors. Even though at times they have been hesitant to wholeheartedly support the PXI standard, Agilent, has several product lines in PXI:

Last week, Agilent released new PXI modules in their optical test product line. Their press release notes that the modules offer their customers “a smaller, faster, more cost-effective solution” - precisely the primary benefits of the PXI platform.

Aug 15
“NI Euphoria”
icon1 Eric Starkloff | icon2 Automated Test | icon4 August 15th, 2007| icon3No Comments »

I came across this blog today, from a Lockheed Martin engineer that attended NI Week last week. As usual, I can’t say it any better that our users! Enjoy.

Aug 13
Decompressing from NI Week
icon1 Eric Starkloff | icon2 Automated Test, News | icon4 August 13th, 2007| icon3No Comments »

Last week was National Instrument’s annual user conference, NI Week. It has become more of a whirlwind every year, and this year set a new bar: over 2500 customers, plus members of the trade press, investors, university professors, partners, and NI employees. I’m still digesting all the feedback and takeaways, but here was my overriding impression: over the past few years, the sophistication of applications that our users have accomplished with NI tools has grown remarkably. I recall judging our application paper contest just a few years ago in the communication category and all the applications submitted were fairly straightforward GPIB-controlled test applications. Today, NI hardware and software are being used in research labs to prototype the latest communication standards, in RF chip validation testers, and in high volume production test of wireless devices. During the NI Week keynotes, we showed leading edge applications of virtual instrumentation, including a ‘mind controlled wheelchair’, a Boeing 787 audio flyover test system, multichannel video streaming, and a cryogenic medical device - all applications of LabVIEW. It really is amazing what our users our accomplishing with our tools.

Jul 6
“Open Analysis”
icon1 Eric Starkloff | icon2 Automated Test, News | icon4 July 6th, 2007| icon3No Comments »

I am hearing increasingly from customers and other vendors in test and measurement about the need for “Open Analysis”. The need is driven by the increasingly diverse set of applications and thus measurement requirements driven by, among other things, macro trends outlined in the book The Long Tail. As communication standards continue to proliferate, and the pace of change increases, users need tools that can adapt just as rapidly to their changing measurement needs. Instrumentation vendors such as Tektronix, for example, are increasingly offering options for users to plug in third party analysis tools, or export their data to analysis environments for custom processing. Tek’s OpenChoice is “a collection of software libraries, utilities, samples, industry-standard protocols and interfaces”. An example of OpenChoice software is SignalExpress Tektronix Edition, which is used to automate Tektronix instruments and bring data into and open, PC-based environment for further analysis. Tektronix AEs, third parties, or customers themselves can add in their own custom analysis to meet their specific application needs.

Jun 10

I’d like to clarify the difference between these two terms as I have found that there is very often confusion between them. The distinction is entirely in the software model and the programmability of software-based analysis by the instrument user. A Virtual Instrument’s primary programming model is to present raw data to the user for customized measurements. A Traditional Instrument’s primary programming model is to present vendor-defined measurements to the user.

What about Standalone Instruments versus Modular Instruments? This is a question of form-factor, not software, and is therefore entirely orthogonal to whether the instrument is virtual or traditional. A standalone instrument can indeed be used as a virtual instrument. An example is a standalone oscilloscope that is automated to create custom measurements in software. Similarly, it is possible for a modular instrument to present only a traditional use model to the user; VXI instruments, for example, were most often vendor-defined instrument repackaged in a modular form factor.

While the definition of virtual instruments and modular instruments is orthogonal, it is true that many modular instrument standards lend themselves to building virtual instrumentation systems. In order to effectively perform user-defined analysis on a signal, the user must have access to the raw data from the instrument’s acquisition. For high-speed measurements, this requires transferring many megabytes of data from the instrument to a processor to be analyzed in software. High-speed interface buses such as PCI Express, which can transfer data at up to 4 Gigabytes/s, are well-suited to this application. Instrumentation standards such as PXI combine high-speed buses and upgradeable PC-based processors, making it an ideal platform for virtual instrumentation systems.

May 11
PXI Turns 10!
icon1 Eric Starkloff | icon2 Automated Test, Industry Trends, News | icon4 May 11th, 2007| icon31 Comment »

PXI is celebrating its 10 year anniversary in 2007. Richard Quinnell at Test and Measurement World recently wrote about PXI’s anniversary, highlighting the compatibility it has achieved during this time. For me, its been remarkable to see the growth and changes in this marketplace over the past 10 years, especially all the times that PXI vendors achieved “the impossible”. Here are a few of my favorites:

  • 1999 - 50 members and over 200 products. The first few years of the standard saw a rapid adoption by vendors and the release of a lot of products. Grow exceeded expectations in every dimension.
  • 2002-PXI’s entry ito RF. Prior to the release of products by National Instruments and Aeroflex, certain vendors had been outspoken that “you could never do RF in PXI”. Last year, Phase Matrix announced that they are taking PXI all the way up to 26.5 GHz!
  • 2003 - PXI systems shipments exceed VXI. By 2006, PXI vendors shipped over 10,000 systems per year - 3 times larger than VXI at its peak. Naysayers claimed modular systems would never be mainstream.
  • 2004- A 512 Cross-Point Switch. With the release of the PXI-2532, National Instuments put to rest those that claimed the Achilles heal of PXI was switch density.
  • 2005-PXI Express. The PXI Systems Alliance did a remarkable job incorporating new technology to achieve a 45-fold increase in bandwidth while preserving backward compatibility. Those that claimed PCI Express would break compatibility become suddenly quiet.
  • 2007 - Agilent joins the PXISA. Agilent Technolgies joined other big name vendors such as Advantest, Aeroflex, Keithley, National Instruments, Rohde & Schwarz, and Teradyne. So much for not having any big name companies in PXI!
May 7
VBAs
icon1 Eric Starkloff | icon2 Automated Test, Technology | icon4 May 7th, 2007| icon3No Comments »

I just saw another example of what we call a VBA, a “van-based acquisition”. It turns out that in RF applications, virtual instrumentation is particularly common when customers need portability and real-time data streaming. There aren’t a lot of commercial products to solve this application, but a PXI-based system can handle most of these requirements at a very low cost. Here is the latest example I just received of a VBA:

“The customer was looking for a completely mobile RF spectral monitoring application. They want to have a DC-based system mounted in their vehicles and they want to drive through areas and monitor a band of secure radio channels and signal strengths for those channels. The main requirements of the system are portability, quick spectral acquisition and storage (stream-to-disk) and time/location stamping for each spectral sweep.

This is a unique application that requires a small form-factor, stream-to-disk capabilities and GPS stamping. It can solved today with commercial off the shelf PXI products”

Other PXI-based VBAs are deployed in military applications (either looking for “signals of interest” or jamming them), ground-based transceiver testers, commercial spectral monitoring systems, and cell-phone coverage mapping applications.

Apr 16
Instrumentation 2.0
icon1 Eric Starkloff | icon2 Automated Test, Industry Trends, News | icon4 April 16th, 2007| icon3No Comments »

I’ve recently been using the term Instrumentation 2.0 to refer to the changes happening in the architecture and use of test instrumentation. Rick Nelson, Editor of Test and Measurement World, wrote about this trend in his recent editorial and blog, I’d like to clarify what this concept means in terms of architecture and usage, for the two are related, but can be independent.

The internal architecture of test instruments is changing. Rapidly improving capability of PC processors, bus technology, and FPGAs have changed the architecture of both standalone instruments as well as modular devices such as PXI. Standalone oscilloscopes, for example, used to use proprietary technology from the front-end conditioning, through digitization, memory, storage, and display. Instrumentation companies were once the pioneers of early display technology, like the DVBST CRT in the Tektronix 4014. Signal processing on these devices has often been done using custom Digital Signal Processors, or DSPs. The investment in commercial PC and consumer electronics technology has created a compelling alternative to these proprietary architectures, however. Increasingly, standalone instruments use commercial operating systems, displays, memory, and storage. Indeed, most high-performance modern instruments contain a standard PC motherboard, transfer data over a commercial bus such as PCI, and run the Windows operating system. Increasingly, I believe the digitization and signal processing capability inside standalone instruments will also migrate to commercial technologies. Commercial A/Ds, driven by applications such as direct conversion for cellular base stations, are now available up to several GS/s. And studies have show that for many applications general-purpose processors and FPGAs can outperform dedicated DSPs. Modern instruments, will, in fact, start to look a lot more like a PC, at least architecturally speaking. A typical standalone instrument will have a acquisition block connected over a commercial high speed bus, such as PCI Express, to a general purpose processor. This processor will both run Windows and drive the display, as well as perform the signal processing necessary for real time measurements. In the highest performance instruments, FPGAs will be used to augment the analysis capability of the processor.

The change is architecture, combined with evolving needs of design and test engineers, has led to a change in usage. Increasingly, users require flexibility in their measurement systems and desire the ability to define capability specific to their application. This trend towards ever increasing customization and the ability through technology to capture this demand, is well articulated by Chris Anderson in his blog and book, both titled The Long Tail. He focuses on the trend in media markets such as music and film, but examples of long tail demand abound in test and measurement as well. Wireless technologies, for example, continue to evolve at a fast pace, and devices often include more than one wireless link. The model of a “one-box” tester specific to a single wireless protocol, therefore, has become a dinosaur. Users need a common platform where they can deploy measurements for new standards as they are deployed, without replacing their hardware. The relationship between these two trends is that the ability of users to define their own measurement capability is enabled by the architectural changes noted above. Instruments built on a PC architecture that use commercial technolgy components can enable users to write their own algorithms in software for processing the acquired data. Even better if they can switch out the acquisition front-end when the requirements necessitate it.

Of course, modular, or PC-based, instrumentation has been at the forefront of this trend. By their nature, these devices build on PC busses and processors and separate the acquisition from the measurement analysis. And the rapid evolution of converters, buses, and PC processors, has increased the capability of this approach over recent years, so that in many cases it is equal to or greater than the alternative standalone instrument. Software tools such as LabVIEW have been used for many years to create customized analysis for measurement applications. Newer developments, such as LabVIEW FPGA actually target LabVIEW programs to FPGA components in a test system to create very powerful embedded processing that is still defined by the user to their needs.

« Previous Entries Next Entries »