The next generation of data loggers: an ecosystem

The data logger has been around for hundreds of years, evolving from an assistant with paper and pencil to the technology-packed, automated products that they can be today. Much like hammers are tools to carpenters, data loggers are tools to scientists, engineers and anyone else working in a measurement environment.

Also like hammers, there are several options from which to choose yet the cost-conscious consumer wants to own as few of them as possible.

Unfortunately, data loggers and their associated software applications have been very purpose specific.

These purposes range from portable devices used in the field, to simple benchtop testers, to advanced ruggedised in-vehicle data loggers for road testing.

The infinite range of use cases coupled with the fixed functionality of most data loggers means there are multiple devices and expenditures for each project.

Data loggers have many features, including measurement type, number of measurements, storage mechanism, storage space, environmental operating conditions, signal processing components, display device, reporting procedure, controlling or analysing software and many more.

These characteristics dictate hardware needed for a project and in many cases changing just one of the requirements will result in the need for a new instrument.

Sometimes new instrumentation is a different model range from the same vendor but often it is from a different, more specialised vendor meaning multiple support contacts, hardware standards and purchase orders to keep track of.

Instrumentation and data logger venders have been working towards a solution to this problem over a series of hardware evolutions.

Open file formats such as ASCII or .CSV files are used by data loggers that store to a disk to be more ‘software flexible’. Modular systems were introduced to the data logging market allowing users to expand the channel count or even measurement type of the data logger.

Communication buses such as serial, ethernet or USB have been added to data loggers to enable computer connectivity when desired and memory card slots have been integrated for expandable storage options.

The line between a PC-based data logger and a standalone data logger continues to blur as more devices use PC technology, such as processors and FPGA chips, for flexible performance.

Modular hardware is great but the desktop data logger that plugs into the wall usually takes different modules than the compact, DC-powered data logger that can be installed in-vehicle, or the small portable data logger that can be used with a notebook computer.

Modules can reduce the cost of hardware if implemented correctly or they can compound the problem of overloaded equipment libraries if designed or purchased without thought.

What is needed is a flexible data logger that can be re-tasked and re-used as projects grow and change. In this case, flexibility is more than just the capability to add modules or adjust the file type. To encompass a wider range of applications, the next evolution of data loggers needs to be a larger family of products that has the ability to swap not only modules but deployment systems and software as well.

With a focus on both flexibility and performance, instrumentation vendors can create a ‘data logging ecosystem’ that can meet a larger spectrum of data logging use cases, allowing companies to reduce their equipment spending, support and training costs.

One such example of a data logging ecosystem is the C series family of data logging hardware from National Instruments. The series is based on over 40 modules that contain all the signal conditioning, data conversion and connectivity needed in a small, metal, rugged housing a little larger than a deck of cards.

By isolating the measurement to the module, end users can expand their systems by buying new modules and the vendor can expand the data logging ecosystem by developing more modules.

The series is not the only product or company that is using a modular-based system and one of the ways the hardware from the company differs, is in the deployment of these modules.

For deployment, the family consists of several chassis and carriers for different tasks.

For low-cost, low-channel count or portable applications, the C series single module carrier will log data directly to a PC via USB. The next step for growth or for multiple measurement types is to deploy the larger USB CompactDAQ chassis that will support and synchronise data from up to eight modules.

Both the single module carrier and CompactDAQ are used for PC deployment but many data logging applications are in more harsh environments or smaller spaces that exclude use of a full PC.

For these scenarios, the family has CompactRIO which has built-in processing and expandable storage. No PC is needed for the deployment of CompactRIO and its rugged 50 g shock and -40 to 70°C environmental operating range means this system can go where several other data loggers would fail.

One set of modules and multiple deployment options mean a portable system, benchtop system and installed system can perhaps use the same exact module.

Hardware is only part of the data logging ecosystem as even with the most flexible of all hardware the functionality is still restricted and defined by the software that is controlling the logger.

The proper software interface for a good data logging ecosystem is one that can change functionality or be re-used on different hardware when needed.

Keeping with a scalable solution, the software portion of the evolved logger needs to be flexible and range from a low-cost simple solution all the way to a more advanced solution that can add analysis and log data to custom file formats. Many data loggers have the simple end covered with included turnkey software and the advanced end is covered by programming languages such as ANSI C, Visual Studio and LabVIEW but few can bridge the gap and allow scalability from the low to the high end.

The C series, programmed with LabVIEW, can. On the low-channel count end, the USB hardware comes with logging software that will log data to disk with minimum set-up.

As the project grows, features such as triggers, alarms and outputs can be added. Ultimately the project can be converted into LabVIEW code for complete processing and logic capability as well as customisation of data storage format.

Moving from the benchtop to the field with the hardware is as easy as moving modules from one chassis to another but what about the software?

LabVIEW code can be written that, with little to no modification, can run with the single, portable USB carrier, the 8-slot USB CompactDAQ carrier or the embedded CompactRIO data logger with onboard storage.

The modules selected and software configured or programmed will usually represent the majority of time and cost when implementing a system.

The ability to transport this sunk cost from one phase of a project to the next adds value far beyond the cost of the actual instrumentation.

It is important to realise that a good data logging ecosystem will have components that allow the user to scale a project from the low-cost, low-channel count design research, to the full-featured embedded logging system used in prototypes.

To use the family as an example we can look at temperature logging for motor vehicle brake rotor design. For early, small-scale design testing the single module carrier can be used for low-channel thermal tests on different metal thicknesses or maybe different hole patterns for vented discs.

For this example we will have the test engineer develop the simple software application in LabVIEW for use with the single module carrier. Later testing of the brake rotor may involve a test set-up on a dynamometer where more of the same modules could be purchased and installed into a larger USB chassis, NI CompactDAQ.

With minor tweaks on the software, the same analysis and code from earlier testing could be re-used completely on the dynamometer.

Maybe at this stage accelerometers would be used for vibration analysis on the suspension system. An accelerometer module could be added to the system and code could be added to the existing program to perform analysis or, with no modification, the program could simply log vibration data in the same file as the existing temperature data.

The final testing stage of the brake rotors would be real-world test track logging.

This is a different deployment paradigm from the previous two as now the power available is different, the environmental conditions are harsher and a notebook computer may not be a feasible option. For this test, the same modules and code can be transported to CompactRIO for the road tests. This has a built-in controller and storage.

The same data file can be collected via SD memory card, serial interface, TCP/IP interface or even over wireless if an 802.11 network can be set up around the test track.

Each phase in this testing process used the same vendor, the same software and the same modules.

This example represents re-tasking and re-using a system for a single project. Once the brake rotor is designed, the next project that comes in may be to test the exhaust, design a new spoiler or monitor manifold pressure from a new engine block.
Fortunately for end users, he/she did not purchase a brake rotor data logger or even a standard temperature data logger, they purchased into a data logging ecosystem that means with a new program they can re-task their hardware for any project yet to come.

Whether your test department is one building or one person, the result is greater productivity.

*Brett Burger is a product marketing manager for Data Acquisition Systems at National Instruments. He started his career at NI in 2003 as a member of the engineering leadership program where he was a team leader and provided technical support for top accounts. He graduated with a BS in Aerospace Engineering from Texas A&M University.