USD

Fast-Track Your Next Wireless Sensor Design

Colaboración de Editores de Digi-Key de América del Norte

Creating a new multi-sensor system can be painstaking as you have to ensure that the design accommodates sensor-specific requirements and delivers long-term accuracy and reliability. When application requirements further dictate a need for wireless connectivity, designers are hard-pressed to deliver a solution able to maintain noise-free signal-chain operation while maximizing radio sensitivity and range. Single-board computers (SBCs) designed specifically for sensor applications offer a compelling solution for meeting complex requirements for wireless sensors without compromising tight project schedules.

Typically, sensor system designs combine a microcontroller (MCU) with the additional analog circuitry and digital control logic required to acquire and transmit sensor data reliably and accurately (Figure 1). SBCs can accelerate the design of these systems by providing a tested platform combining hardware and software with tools for sensor application development. Rather than spending time recreating the basic system that is common to many sensor designs, developers can focus on optimizing those features and capabilities needed to meet the specific requirements of their unique application.

Image of Texas Instruments microcontroller (MCU), analog front end (AFE) for sensor signal acquisition

Figure 1: Most sensor systems share a common design comprising a microcontroller (MCU), analog front end (AFE) for sensor signal acquisition, and communications subsystem for transmitting sensor data to another device or host system. (Source: Texas Instruments)

Intended specifically for sensor applications, specialized board-level systems from Texas Instruments and NXP combine wireless sensor hardware with specialized software libraries and complete development environments able to help speed design and test of those applications.

Tightly integrated SBC

The Texas Instruments SensorTag offers a tightly integrated solution that delivers an extensive sensor processing system in a footprint measuring only 5 x 6.7 x 1.4 cm. SensorTag builds on the capabilities of the TI CC2650 wireless MCU, adding the components required to interface the CC2650 with multiple sensors and user-interface devices built on the SensorTag board (Figure 2).

Image of Texas Instruments CC2650 wireless MCUs

Figure 2: The Texas Instruments SensorTag leverages the TI CC2650 wireless MCUs integrated features for wireless communications and sensor processing, providing multiple sensors and interfaces for rapid development of sensor applications. (Source: Texas Instruments)

Intended for rapid development of connected sensor applications, the TI SensorTag is a complete development kit that supports a number of different development styles.  In fact, its default mode makes it easy for developers to begin working quickly with sensor data. On start-up in its default mode, the SensorTag advertises itself to a Bluetooth low energy-compliant central device such as a smartphone. Developers can simply access sensor data from the SensorTag through the cloud or using JavaScript and jQuery to access data directly. In this mode, developers can use Android or iOS mobile applications as starting points or write HTML5 platform-independent code based on the source code from sample web application projects available with the kit.

For more involved custom applications, SensorTag hardware offers a sophisticated development platform built around an open hardware solution designed to demonstrate how to use diverse low-power sensors. Developers can further extend the SensorTag with daughter cards, called DevPacks, which make it easy to design and test additional types of sensors and actuators. In particular, the combination of the SensorTag and the available Debug DevPack provides an affordable comprehensive platform for developing custom hardware and software for sensor applications (Figure 3).

Image of Texas Instruments SensorTag Debugger DevPack

Figure 3: The Texas Instruments SensorTag Debugger DevPack extends the SensorTag with additional features for test and debug including a JTAG debug capability and Grove connector pads that simplify addition of hardware such as Seeed Technology’s Grove fingerprint sensor. (Source: Texas Instruments)

For wireless development, the SensorTag kit includes a Bluetooth low energy (BLE) stack, which in turn runs on the TI real-time operating system (TI-RTOS) software environment. TI-RTOS is a real-time, pre-emptive, multithreaded operating system that synchronizes execution of the application and BLE protocol stack, both of which run as separate tasks within the RTOS. Here, the BLE stack runs at the highest priority to help ensure reliable communications.

In the SensorTag, the wireless transactions themselves take advantage of the CC2650's integrated RF core, which contains an ARM® Cortex®-M0 processor integrated with analog RF and baseband circuits.  Although the RF core's M0 processor is not programmable by the engineer, TI provides a high level, command-based applications programming interface (API) for issuing commands to the RF core from code running on the main processor. In turn, the RF core uses its dedicated 4 KB SRAM for data and ROM for code to autonomously handle time-critical aspects of the radio protocols – offloading the main CPU and preserving resources for use by the application itself.

Simplified software development

Sensor signal processing is equally efficient thanks to the Sensor Controller Engine (SCE), an autonomous processor integrated in the CC2650. Just as the RF core can independently perform wireless transactions, the SCE can control sensors and associated peripherals independently of the main processor. Thus, for example, the SCE can run the analog-to-digital converter (ADC) or poll a digital sensor over the integrated serial peripheral interface (SPI) without waking the main processor, thereby eliminating the extra power consumption and wake-up time that would otherwise be required for acquiring sensor data.

Unlike the RF core, engineers can program the SCE. Using a C-like language, developers can write custom code to perform sensor polling or handle specialized conditions and processing requirements. As a result, rather than rely on the kind of static configurations typically used in setting up peripherals for sensor data acquisition, developers can create more dynamic sensor-processing capabilities. For sensor code development, TI provides its Sensor Controller Studio (SCS), a special software tool for writing, testing, and debugging code for the SCE (Figure 4).

Image of Texas Instruments Sensor Controller Studio software

Figure 4: Developers program the CC2650's integrated Sensor Controller Engine in a C-like language using the TI Sensor Controller Studio software development tool. This generates C source code for inclusion in the main application designed to run on the CC2650 wireless MCU. (Source: Texas Instruments)

The SCS generates a sensor controller interface driver, which is a set of C source files. In turn, developers use the TI Code Composer Studio (CCS) to compile these C source files with any other custom code intended to run as part of the main application on the CC2650's ARM Cortex-M3 host processor.

CCS is an Eclipse-based integrated development environment (IDE) that provides a comprehensive set of tools for developing and debugging applications for TI's MCU families. Among its development features, the Code Composer Studio includes an optimizing C/C++ compiler, source code editor, project build environment, debugger, and profiler -- all accessed through the IDE's single user interface that is designed to ease developers through each phase of application development.

Flexible sensor solution

NXP takes a different approach with its OM13078 Sensor Processing-Motion Solution (SPM-S). Based on the NXP LPC54102 MCU, the SPM-S combines NXP's OM13077 LPCXpresso board with a sensor shield board connected through the LPCXpresso's expansion connector (Figure 5). As illustrated in the figure, the sensor shield includes a BLE module (AMS0002) for wireless communications along with multiple sensors for temperature, pressure, ambient light, and proximity as well as accelerometer, gyroscope, and magnetometer sensors for more complex motion-detection applications.

Image of NXP LPC54102 LPCXpresso board

Figure 5: NXP offers a sensor solution that combines its LPC54102 LPCXpresso board with a shield loaded with multiple sensors as well as a comprehensive development environment that includes a complete sensor software library.  (Source: NXP)

For the accompanying run-time software environment, NXP provides its LPC Sensor Framework, which includes both system software and sensor processing software (Figure 6). During normal operation, the LPC54102 MCU samples the sensors and uses the Bosch Sensortec BSX Lite library to process sensor data. The results can be further transmitted to another device or host processor through wireless BLE communications or through one of the various host interfaces supported by the LPCXpresso board.

Image of Bosch Sensortec BSX Lite library

Figure 6: Developers build sensor applications on NXP's LPC Sensor Framework, which provides a comprehensive run-time environment including system services and sensor-signal processing with built-in support for sensor-fusion applications through the Bosch Sensortec BSX Lite library. (Source: NXP)

Sensor-fusion architecture

Besides its basic capabilities for gathering data from diverse sensors, the SPM-S solution distinguishes itself by its ability to merge outputs from multiple sensors using sensor-fusion algorithms designed for sophisticated context-aware applications. Sensor fusion combines results from multiple sensors to provide information that is simply unavailable from any single sensor. For example, an application designed to recognize orientation requires the combined results from accelerometer, magnetometer, and gyroscope sensors. NXP designed the SPM-S system specifically to aggregate data from multiple physical sensors using the sensor-fusion software included in the system.

Support for sensor fusion is deeply embedded in the SPM-S architecture. As with a typical sensor system, the SPM-S architecture recognizes sensor devices as distinct physical devices connected to the SPM-S hardware. Software accesses each device using its unique ID supplied in the sensors.h sensor header file (Figure 7).

Image of PhysSensorId enumerator in the sensor header file

Figure 7: Each physical sensor can be identified by its unique sensor ID defined in the PhysSensorId enumerator in the sensor header file, sensors.h. (Source: NXP)

To support sensor fusion at the application level, the SPM-S architecture extends this basic concept with its support for virtual sensors at the underlying software layers. An individual virtual sensor comprises multiple physical sensors, the results from which are combined in sensor-fusion algorithms to produce new information.

For example, a virtual orientation sensor would return the sensor-fusion result developed by combining the accelerometer, magnetometer, and gyroscope sensor data required to compute orientation information. The SPM-S development environment allows developers to specify virtual sensors in the system's SensorMap array (Figure 8). In this array, each virtual sensor is listed as a single entry that specifies which physical sensors are used by that virtual sensor.

Image of NXP SensorMap array

Figure 8: The SensorMap array describes the physical sensors that contribute data to a virtual sensor. For example, the virtual sensor for orientation uses the accelerometer, magnetometer, and gyroscope physical sensors. (Source: NXP)

Another deeply embedded feature in the SPM-S architecture helps maintain synchronization when results from several sensors are combined in a virtual sensor.

Accurate sensor-fusion results require accurate timekeeping to ensure that only samples from the same time "epoch" are merged in sensor-fusion algorithms. During interrupt-driven sampling in the SPM-S, sensors sample autonomously at a pre-defined rate and generate an interrupt when results are ready. Each interrupt-driven sensor has an associated interrupt handler, which simply stores a timestamp when the interrupt occurs; the actual sensor reading is performed in a subsequent service routine. This approach helps maintain the accurate timing data needed to produce accurate virtual-sensor results from data from multiple separate physical sensors.

Conclusion

The design of a basic wireless sensor system can present significant challenges that can erode project schedules and compromise the application itself. Specialized single-board computers provide a proven base of hardware and software for sensor processing, enabling companies to focus resources more squarely on differentiated sensor applications. Using SBCs and their associated development environments, engineers can rapidly develop sensor applications, even extending the base hardware and software to create custom solutions needed to meet more complex requirements. 

Descargo de responsabilidad: Las opiniones, creencias y puntos de vista expresados por los autores o participantes del foro de este sitio web no reflejan necesariamente las opiniones, las creencias y los puntos de vista de Digi-Key Electronics o de las políticas oficiales de Digi-Key Electronics.

Acerca de este editor

Editores de Digi-Key de América del Norte