FAQ

Why National Instruments/LabVIEW?

The quick answer is ease of use and speed of system development.

The longer answer is that NI/LabVIEW has a long history in the testing community and a lot of trust and confidence has been established over the years. This is important in testing, since the integrity of the test results must withstand scrutiny and be trustworthy. National Instruments takes the necessary effort to qualify its hardware and produce specifications that are reliable. They design to standards' compliance and note the applicable standards in the product documentation. Since most of the NI hardware used in MODAQ have been in production for many years, any issues have been long resolved. It's just one less thing to worry about.

NI hardware can be used with many common programming languages, such as C and python, however LabVIEW excels at integration with NI hardware and rapid software development. LabVIEW differs from most other common programming languages in that instead of lines of text, it uses a graphical approach that emphasizes dataflow. The graphical simplicity betrays its inherent power. LabVIEW greatly simplifies tasks such as multitasking, I/O operations, GUIs or HMIs, and binary file saves, to name a few. Programming in LabVIEW can actually be fun.

All that said, becoming skilled at LabVIEW can take years of dedicated study and practice. Many advanced concepts, like many of those used in MODAQ, require (or at very least, benefit from) competence in several disciplines including data acquisition, mathematics, control theory, sensors and instrumentation, electrical and computer engineering, and electrical circuits/components.

Why not just use generic DAQ controllers?

There are a lot of options out there, but it does not take long to realize that:

  1. You're just trading one ecosystem for another.
  2. Specification to price ratio might be (much) worse.
  3. Documentation and libraries may be lacking.
  4. Device compatibility may become a bit of an issue.
  5. Your preferred programming language or operating system might not be supported.
  6. Software still needs to be developed (or in some cases configured) to achieve expected results.
  7. It could end up being a lot of work!

Of course it depends on individual needs and expectations, but whether going with National Instruments or an alternative, there's no getting away from the tasks of programming the system and assuring it will perform to expectations and deliver quality results.

Some vendors sell controllers and I/O modules and offer software packages that require some configuration to achieve basic and limited data acquisition that can be considered on the easy end of the spectrum. However, doing anything beyond simple acquisitions often requires accessing a vendor supplied API and writing code in a traditional language like C/C++ or python - or worse - writing code in a vendor developed scripting language.

There's a class of controllers that include an array of built-in I/O that are nice, well thought out, easy to configure, and performant, however under closer inspection, they lack some key features that make them unsuitable in an embedded application deployed in the field. For example, these options generally have limited data logging capability, supporting only small (usually 64 GB or less) and slow microSD cards. There's also limitations when it comes to more technical matters, such as sampling speed, multiplexing (or scanning) vs simultaneous sampling, data synchronization, bit depth, multitasking, determinism, and noise. They also lack flexibility of local filtering or signal processing of data, local QC, and communications/remote supervision. Of course, use case and measurement objectives matter, so these can be perfectly fine for some applications.

Why is my sensor/instrument not supported?

There are a lot of sensors and instruments available at various price-points with different interfacing requirements. With the exception of devices with simple, voltage or current varying outputs, devices tend to have a protocol, API, or unique data stream that requires custom code (drivers) to acquire the measurement data. Even different models of a similar device from the same manufacturer could have significant differences in the way the device 'talks'. Writing a new driver can range from trivial to complex, dependent on how the data are acquired from the device and/or the data formatting employed by the manufacturer.

NREL will share drivers for hardware previously written for MODAQ. For NREL to develop custom MODAQ drivers, please see the FAQ question below about working with NREL.

Why not use something like a RaspberryPi or Arduino?

While RaspberryPis, Arduinos, and other similar devices are best known in the hobbyist realm, they have become quite prevalent in research and commercial applications. In fact, these devices are finding their way into PLCs and other industrial equipment and have demonstrated reliability. However, there's always considerations and trade-offs to be made. For instance:

  1. Mass produced, general purpose boards designed to meet hobbyist price-points might not be built to exacting standards and there could be considerable differences in component quality and design tolerances. This could include boards that use generic, knock-off, counterfeit, binned, or grey-market variants of key components. They might use cheap alternatives that compromise performance in demanding applications- such as poor-quality oscillators or low-efficiency regulators. Circuit boards may have cold solder joints or sloppy solder bridges.
  2. They may be unable to cope with or survive over-voltage, polarity reversals, and/or electrostatic discharge like purpose-built hardware.
  3. Insufficient attention may be paid to proper grounding and/or isolation to crosstalk and external interference.
  4. The board may not be survivable in punishing applications where it might be subject to temperature extremes, humidity, vibrations, and/or high shock.
  5. There is probably very little or questionable validation of published specifications.
  6. They might not be designed for 24/7 uptime and applications that push them to their limits and could suffer from overheating and/or intermittency.
  7. Many devices, particularly the microcontrollers, have limited storage options, with most only supporting microSD cards with small capacity and slow read/write speeds.

And, code still needs to be written so that the hardware can acquire data and perform related tasks. The developer assumes the risk of assuring the code is performant, stable, and can provide some level of determinism. It should not be unexpected for the software development costs to vastly eclipse the cost of the hardware. Therefore, it might be economically more advantageous to go with a trusted, packaged solution rather than DIY it.

That said, NREL has developed DAQ solutions based on the Espressif ESP32 platform for less demanding use-cases that require a small, light weight form-factor and/or operable on battery power. Details of this system are expected to be published to the NREL Github in 2023.

Can NREL help configure or customize MODAQ?

MODAQ is funded by the Department of Energy's Water Power Technology Office for the purpose of advancing the development and testing of Marine Renewable Energy devices. There are mechanisms in place for large and small organizations to engage NREL.