Latest News
June 1, 2012
By Peter Anderson
Desktop personal computers gave engineers the power to create custom test-and-measurement applications. Laptop computers gave engineers the ability to create smaller and more portable data acquisition (DAQ) systems. Are tablet computers the natural evolution of this trend?
MCC’s DAQFlex message-based protocol can facilitate communications for
DAQ on a tablet device.
While the penetration of tablets still lags that of traditional PCs, their growth rate has been phenomenal. According to Pew Research, 57% of adults own a desktop computer and 56% of adults own a laptop computer. However, tablet ownership climbed from 8% in May 2011 to 19% in January 2012.
The growth in tablets, however, has not yet substantially penetrated the engineering lab. Because both desktop and laptop platforms shared much of the same infrastructure the move from desktop computer to laptop was relatively seamless. Tablets, on the other hand, support different programming languages, run under different operating systems and have less processing power and connectivity options than their PC counterparts.
There are two other drawbacks to consider:
- The top two programming languages for custom DAQ applications, C# and LabVIEW, are not supported in either Android or iOS.
- USB, a common DAQ bus, is found on only a small subset of tablets on the market today.
Because of these technical discontinuities, moving to a tablet requires special attention to how systems and applications are put together. With limited battery capacity and lack of processing power, the tablet offers a less-forgiving environment for DAQ application developers, and requires a deeper understanding of how the program and the OS interact.
Tablet Apps
There are a few test-and-measurement apps on the market, though, including Oscium’s iMSO-104, a 5MHz bandwidth, mixed-signal oscilloscope. The iMSO-104 oscilloscope supports one analog and four digital signals, and offers 12Msps sampling. Its circuitry connects to the dock connector port, and uses the iPad, iPod Touch or iPhone as the display and user interface.
Another app is National Instruments’ Data Dashboard Mobile. The Data Dashboard, which runs on both iOS and Android, allows users to create custom and portable views of National Instruments’ LabVIEW applications by displaying the values of network-published shared variables and/or web services on charts, gauges, text indicators and LEDs. While not taking data directly, the Data Dashboard does provide access to real-time test data on a tablet.
The Oscium and National Instruments apps provide a useful start to bringing tablets into the lab, but neither of them let users build custom DAQ apps like they have for years on desktops and laptops.
The ability to create custom applications that fit a particular industry need catapulted the PC into the test-and-measurement arena. If the tablet is going to significantly break into this market, users will need to be able to create custom applications for this platform as well.
Figure 1: DAQFlexsupported devices’ internal engine consists of the “Message Engine”
and “DAQ Engine.”
There are three main differences in creating a DAQ application on a tablet vs. creating one on a PC:
1. Hardware connectivity. PCs were designed to easily add peripherals, either with internal or external buses. The controlled environment of a tablet has far fewer options for connecting peripherals. Wi-Fi and Bluetooth are two communication methods that most tablets support, and the Apple iPad includes a proprietary dock connector port. However, connectivity to existing DAQ devices is a challenge for tablet applications.
A survey of the DAQ market shows few options that offer Wi-Fi, Bluetooth or the Apple dock connector port. The communication method that offers the most options—both in tablets and DAQ devices—is USB. A limited number of Android tablets support USB host mode and offer a respectable DAQ platform.
As the application space for tablets in test and measurement grows, though, more devices supporting Bluetooth, Wi-Fi and Wi-Fi Direct will become available.
2. Program language/structure support. Most PC-based DAQ programs are written in LabVIEW or C#; however, tablets support neither of these programming languages. Programming in Android is done in Java, while programming in iOS is done in Objective C. Both are object-oriented languages that are similar to C++ and C#.
Getting Started If you are interested in creating your own DAQ application on a tablet, you will need to download the required tools and the software development kits (SDKs). Android development can be done on a Mac, Windows or Linux machine, while iOS development requires a Mac. Download the Measurement Computing example program for Android. |
Unlike PCs, where languages like LabVIEW or DASYLab allow novice users to create custom applications, tablets require expertise in object-oriented programming. This means that tablet app development is really the domain of those with a strong background in programming.
Beside the language difference, programming a DAQ application on a tablet is significantly different than programming a DAQ application on a PC. Tablets have limited memory and processor speeds, so they cannot handle having many programs running at once. Instead of letting programmers manage when an application closes (as a desktop OS would do), the tablet OS—either Android or iOS—decides when to close them. This is why you do not typically see a “close” button on a tablet application.
3. Device driver availability. Device drivers offer a high-level way to easily and reliably execute DAQ board functionality. Device drivers are components of DAQ systems that many take for granted, because these drivers are usually supplied free with the DAQ hardware. While most DAQ companies provide drivers for Windows, no major company at this time offers DAQ drivers for tablet OSs. Without the device driver or intricate knowledge of the device, interfacing with a DAQ device from a tablet is futile.
Measurement Computing has a solution for this, though, with its DAQFlex-supported collection of USB DAQ devices. Unlike most DAQ devices, which interface to the computer via lowlevel commands, DAQFlex devices interface with simple text messages.
For instance, to read a channel from a DAQFlex device, a programmer would send (“?AI{“ channel”}:VALUE”) over a USB Control Transfer and read the response from the device with another control transfer.
DAQFlexsupported devices contain an internal device engine (see Figure 1), which consists of the “Message Engine” and “DAQ Engine.” Once received, these messages are parsed and converted to instructions and sent to the DAQ Engine. The DAQ Engine then configures the device, performs the operations, and returns the data to the Message Engine, which in turn sends the data to the host when requested.
A growing number of measurement computing devices support DAQFlex:
Users can create their own simple drivers for any OS using the DAQFlex message-based protocol. Open-source drivers are available for Linux, Mac and Windows.
Sample Program Available
One way to learn how to program for tablets is to look at an example. Dave Fraska, an application engineer at Measurement Computing, has put together an example program for Android tablets that reads temperature data from the Measurement Computing USB-2001-TC thermocouple measurement device, which supports DAQFlex, displays the data on a chart, and saves it to local memory. It has three main parts:
1. A simple device driver for communicating with the USB-2001-TC. This driver has two main, low-level methods that send and receive messages through USB control transfers. Because multiple devices share this DAQFlex protocol, the programming will be similar for all DAQFlex devices.
2. An acquisition service for collecting and saving data. The background service interfaces to the driver, controlling when the data is captured and saving the data to memory. This service is not tied to the activity lifecycle, and runs until the application/activity stops it or the tablet powers down.
3. A charting activity for requesting data from the acquisition service and charting it to the user interface. The application requests data from the acquisition service and plots it on a strip chart. It uses an open source chart.
This application program shows that data acquisition on a tablet device with a standard off-the-shelf DAQ device is possible—with the right driver support, an understanding of the platform limitations, and a good knowledge of object-oriented programming.
Application Lifecycle: Android OS The application lifecycle is an important concept to understand when programming tablet devices. To understand application lifecycle, let’s look at the Android OS. Android defines four program components, and we will focus on two: “activities” and “services.” An activity represents a single screen with a user interface, which may be closed at any time. A service is a component that, when set to foreground mode, can run without interruption to perform long-running operations. Activities are managed in a stack. When a new activity is started, it is placed on the top of the stack and becomes the running activity—while the previous activity always remains below it in the stack. This activity will not come to the foreground again until the new activity exits. An activity has essentially three states: 1. If an activity in the foreground of the screen (at thetop of the stack), it is active or running. 2. If an activity has lost focus, but is still visible (that is, a new non-full-sized or transparent activity has focus on top of your activity), it is paused. A paused activity is completely alive (it maintains all state and member information, and remains attached to the window manager), but can be killed by the system in extreme low-memory situations. 3. If an activity is completely obscured by another activity, it is stopped. It still retains all state and memberinformation; however, it is no longer visible to the user, so its window is hidden. It will often be killed by the system when memory is needed elsewhere. If an activity is paused or stopped, the system can drop the activity from memory by either asking it to finish, or simply killing its process. In essence, if an application is not in the foreground, it has the potential of being killed by the OS. Imagine this happening during a critical data collection operation! One way around this uncertainty is to use services—an application component that can perform long-running operations in the background. An activity has no control over when it is considered in the foreground or in the background. By contrast, a service can be manually set to run in the foreground, minimizing the chance that it will be closed. An activity can start a service and have it continue running, even if the user switches to another application. For example, a service might handle network transactions, play music, perform file I/O or collect data from a DAQ device, all running without interruption of another activity coming into the foreground. While services can also be killed by the OS, it is far less likely, and only in states of low memory or low power. Sources: The author and Developer.Android.com |
Peter Anderson is general manager of Measurement Computing.
MORE INFO
Subscribe to our FREE magazine, FREE email newsletters or both!
Latest News
About the Author
DE’s editors contribute news and new product announcements to Digital Engineering.
Press releases may be sent to them via [email protected].
