Method and process for rapid transplantation of sensor system
Creating a new multi-sensor system can be a tough job because you have to make sure your design meets the specific requirements of your sensor and achieve long-term accuracy and reliability. When more wireless connectivity is required depending on the application, it is difficult for designers to provide a solution that maximizes radio sensitivity, expands coverage, and maintains a noise-free signal chain. A single-board computer (SBC) designed for sensor applications provides an excellent solution to meet the complex requirements of wireless sensors without compromising the compact project schedule.
Typically, sensor system design combines a microcontroller (MCU) with more analog circuitry and digital control logic to accurately and reliably acquire and transmit sensor data (Figure 1). SBC accelerates the design of these systems by providing a test platform that combines hardware and software with sensor application development tools. Developers can focus on optimizing the features and functions they need to meet the specific requirements of their unique applications without having to spend time recreating the basic systems common to many sensor designs.
Figure 1. Most sensor systems have a common design that includes a microcontroller (MCU) and analog front end (AFE) for sensor signal acquisition, and a communication subsystem for sending sensor data to other devices or host systems. .
Texas Instruments and NXP's professional board-level systems are designed for sensor applications, combining wireless sensor hardware and professional software libraries with a complete development environment that helps speed design and test these applications.
Tightly integrated SBC
Texas Instruments SensorTag offers a tightly integrated solution that provides a comprehensive sensor processing system in a 5 x 6.7 x 1.4 cm package. The SensorTag is built on the capabilities of the TI CC2650 Wireless MCU and adds the necessary components to connect the CC2650 to multiple sensors and user interface devices built on the SensorTag board (Figure 2).
Figure 2. Texas Instruments SensorTag utilizes the integrated capabilities of the TI CC2650 Wireless MCU for wireless communication and sensor processing to provide multiple sensors and interfaces for rapid development of sensor applications.
For more complex custom applications, SensorTag hardware provides an advanced development platform built on open hardware solutions. Among them, the open hardware solution is designed to show how to use a variety of low-power sensors. Developers can further extend the SensorTag using a daughter card called DevPack, which makes it easy to design and test other types of sensors and actuators. In particular, the combination of SensorTag and the available Debug DevPack provides an affordable, comprehensive platform for developing custom hardware and software for sensor applications (Figure 3).
Figure 3. Texas Instruments' SensorTag Debugger DevPack is used to add test and debug capabilities to the SensorTag, including JTAG debug features and Grove connection pads that simplify hardware addition (such as when adding the Seed Technology's Grove fingerprint sensor).
For wireless deployments, the SensorTag kit includes a low-power Bluetooth (BLE) stack that runs in the TI Real-Time Operating System (TI-RTOS) software environment. TI-RTOS is a real-time, preemptive, multi-threaded operating system that can execute applications and BLE stacks simultaneously, both of which run as separate tasks within the RTOS. Here, the BLE stack runs in the highest priority order to help ensure reliable communication.
In SensorTag, the wireless transaction itself leverages the CC2650's integrated RF core, which includes the ARM® Cortex®-M0 processor integrated with analog RF and baseband circuitry. Although engineers cannot program the RF core's M0 processor, TI offers a high-level, command-based application programming interface (API) that enables code-issuing commands from the host processor to the RF core. The RF core goes to its dedicated 4 KB SRAM (for data) and ROM (for code) to handle the time-critical part of the wireless protocol autonomously—alleviating the load on the main CPU and preserving the resource supply itself. .
Simplified software development
With the integrated controller of the CC2650, the Sensor Controller Engine (SCE), the processing of sensor signals can be equally efficient. Just as the RF core can perform wireless transactions independently, the SCE can control the sensors and associated peripherals independently of the host processor. As a result, the SCE can run an analog-to-digital converter (ADC) or poll the digital sensor through an integrated serial peripheral interface (SPI) without waking up the main processor, eliminating the extra power and wakeup required to acquire sensor data. time.
Unlike the RF core, engineers can program the SCE. By using the C-like language, developers can write custom code to perform sensor polling or to handle special conditions and processing requirements. As a result, developers can create more dynamic sensor processing without having to rely on this static configuration that is commonly used when setting up peripherals for sensor data acquisition. TI provides Sensor Controller Studio (SCS) for sensor code deployment, a special software tool for writing, testing, and debugging code for SCE (Figure 4).
Figure 4. The developer uses the TI Sensor Controller Studio software development tool and class C language to program the CC2650's integrated sensor controller engine. This generates C source code for inclusion in the main application that runs exclusively on the CC2650 wireless MCU.
SCS generates a sensor controller interface driver, a set of C source files. Developers will instead compile these C source files using TI Code Composer Studio (CCS), any of which is specifically designed to run on the CC2650's ARM Cortex-M3 host processor as part of the main application.
CCS is an Eclipse-based integrated development environment (IDE) that provides a full suite of tools for application development and debugging of the TI MCU family. Among its development capabilities, Code Composer Studio includes an ever-optimized C/C++ compiler, source code editor, project build environment, debugger, and parser -- all accessed through the IDE's single-user interface, which is designed to facilitate The developer completes each phase of application development.
Flexible sensor solution
NXP takes a different approach to its OM13078 Sensor Processing Motion Solution (SPM-S). The SPM-S is based on the NXP LPC54102 MCU and combines the NXP's OM13077 LPCXpresso board with a sensor expansion board connected via the LPCXpresso expansion interface (Figure 5). As shown, the sensor expansion board includes a BLE module for wireless communication (AMS0002) and multiple sensors for temperature, pressure, ambient light and distance, as well as accelerometers and gyroscopes for more sophisticated motion detection applications. Instrument and magnetometer sensor.
Figure 5. NXP provides a sensor solution. The solution combines the LPC54102 LPCXpresso board with an expansion board that loads multiple sensors and a complete development environment that includes a complete sensor software library.
For the accompanying runtime software environment, NXP provides its LPC sensor framework, which includes system software and sensor processing software (Figure 6). During normal operation, the LPC54102 MCU samples the sensor and processes the sensor data using the BoschSensortec BSX Lite library. The results can be further sent to other devices or host processors via wireless BLE communication or any of the multiple host interfaces supported by the LPCXpresso board.
Figure 6. The developer builds a sensor application on NXP's LPC sensor framework that provides a comprehensive runtime environment, including system services and sensor signal processing, as well as built-in support for sensor fusion applications via the Bosch Sensortec BSX Lite library.
Sensor fusion architecture
In addition to the basic functionality of collecting data from multiple sensors, the SPM-S solution stands out from the crowd with the ability to combine multiple sensor outputs with sensor fusion algorithms designed for advanced context-aware applications. Sensor fusion combines the results of multiple sensors to provide information that cannot be obtained from any single sensor. For example, applications that specifically identify orientation require a combination of accelerometers, magnetometers, and gyro sensors. NXP specifically designed the SPM-S system to aggregate data from multiple physical sensors using sensor fusion software included in the system.
Deep support for sensor fusion is embedded in the SPM-S architecture. As with typical sensor systems, the SPM-S architecture identifies sensor devices as unique physical devices connected to SPM-S hardware. The software accesses each device using the unique ID provided in the sensors.h sensor header file (Figure 7).
Figure 7. Each physical sensor can be identified by a unique sensor ID defined in the PhysSensorId counter in the sensor header file sensors.h.
To support sensor fusion at the application level, the SPM-S architecture leverages its support for virtual sensors at the underlying software layer to extend this fundamental concept. A single virtual sensor contains multiple physical entity sensors whose results are combined according to a sensor fusion algorithm to generate new information.
For example, sensor fusion results resulting from the combination of the accelerometer, magnetometer, and gyro sensor data required to calculate direction information are returned by the virtual direction sensor. In the SPM-S development environment, developers can specify virtual sensors in the system's SensorMap array (Figure 8). In this array, each virtual sensor is listed as a single entry, and the entry specifies which physical sensors the virtual sensor uses.
Figure 8. The SensorMap array describes the physical sensors that provide data to virtual sensors. For example, virtual sensors in the direction use solid sensors such as accelerometers, magnetometers, and gyroscopes.
Another deep embedding feature in the SPM-S architecture helps maintain synchronization when combining the results of multiple sensors in a single virtual sensor.
Accurate sensor fusion results require accurate timing to ensure that only the same "time point" samples are combined by sensor fusion algorithm. During interrupt-driven sampling in SPM-S, the sensor samples autonomously at a predefined rate and generates an interrupt when the result is ready. Each interrupt-driven sensor has an associated interrupt handler. The interrupt handler simply stores the timestamp when the interrupt occurs; the actual sensor result read is performed in the subsequent service program. This approach helps maintain the accurate timing data needed to generate accurate virtual sensor results from data from multiple individual physical sensors.
The design of a basic wireless sensor system can create significant impacts on project timelines and on the application itself. Professional single-board computers provide a proven hardware and software foundation for sensor processing, allowing companies to focus resources more clearly on differentiated sensor applications. By using SBC and its associated development environment, engineers can quickly develop sensor applications and even extend basic hardware and software to create customized solutions that meet more complex requirements.