Author: Tuyền Nguyễn

HomeAuthor Tuyền Nguyễn
Kalman Filter: Breakthrough in IoT & Navigation
February 10, 2026by Tuyền NguyễnTechnology

Kalman Filter: Breakthrough in IoT & Navigation

1. What is Kalman Filter? The “Silent Hero” of Modern Navigation
2. Why use Kalman filter? Solving sensor noise and uncertainty IoT 
3.  Core Principles: How the Kalman Filter Algorithm Works Step-by-Step 
4. Pros and Cons: Key Advantages and Limitations of Kalman Filters
5. Sensor Fusion in Action: Kalman Filter Applications in IoT and Autonomous Vehicles
6. Real-world Case Study
7. Conclusion: The Future of Precision Positioning in the IoT Era

1. What is a Kalman Filter? The “Silent Hero” of Modern Navigation

Have you ever wondered how your phone can still accurately pinpoint your location on a map even when the GPS signal is intermittent while navigating through tall buildings or tunnels? Or how a self-driving car can smoothly navigate its lane despite constant sensor vibrations? The answer behind these intelligent technologies is the Kalman Filter.

So what is a Kalman Filter? Simply put, it’s not a physical filter (like a water or air filter), but rather an intelligent mathematical algorithm that uses a series of measured values, affected by noise or error, to estimate a variable, thereby increasing accuracy compared to using only a single measured value. Its purpose is to help us “guess” (estimate) the true state of a system, even when the information we receive from sensors is noisy or not entirely accurate. It filters out “noise” from chaotic data to find the “true” signal.

Do you know what this historic moment on the Moon, the smartphone in your pocket, and a modern self-driving car have in common?

They are all secretly using the same tool to answer the seemingly simple yet incredibly complex question: “Where am I in this chaotic world?”. It’s one of the greatest mathematical achievements of the 20th century, a “silent hero” behind most modern navigation technologies, yet its name is little known. Let’s uncover the secrets of the algorithm that took humans to the Moon and is guiding our future.

2. Why is a Kalman filter needed? To solve the problem of noise and uncertainty.

In an ideal technological world, if you want to know the position of an object, you simply use a measuring tape. But in the real world, nothing is perfect. The Kalman filter was created to address the core problem: uncertainty.

The practical problem: Sensor error and environmental noise

In an ideal technological world, determining the position of an object is simply a matter of using a measuring tape. However, the real world is never perfect, and we are always faced with the core problem of uncertainty. Any measuring device has an error margin; for example, the GPS on a phone can be off by tens of meters depending on the weather, or a temperature sensor can still fluctuate slightly even in a stable environment. No measurement is absolutely precise. Furthermore, constantly changing environmental factors such as wind, road friction, or engine lag make predicting movement difficult. If you rely solely on a single, often distorted, source of information, the result will be a erratic and inaccurate journey.

Anti-interference controller

  • Sensors are always subject to interference: Your phone’s GPS can be off by a few meters to tens of meters depending on weather conditions. Temperature sensors can fluctuate slightly even if the room temperature remains constant. No measurement is 100% accurate.
  • The environment is constantly changing: Wind, road friction, engine lag… are external factors that make predicting the movement of an object difficult.

If you rely solely on a single source of information (for example, only on a GPS that’s experiencing interference), the result will be a choppy and inaccurate route.

The need for Sensor Fusion to optimize accuracy

To address this problem and optimize accuracy, engineers use the “Sensor Fusion” process to combine multiple different sources of information, and the Kalman filter is the most powerful tool for this. Imagine driving in thick fog: you have a predictive model based on maps and speedometers to calculate your position, but this calculation can be wrong due to slippery roads or wind. At the same time, you also have “measuring sensors”—faint road markers—but the fog makes you unsure if you’re seeing them correctly. At this point, the Kalman Filter acts as an intermediary “brain,” constantly evaluating whether to trust its own calculations more or those vague benchmarks. Based on the reliability of each source, it combines them to provide the best possible location estimate.

3. Core Principles: How the Kalman Filter Algorithm Works Step-by-Step

The Kalman filter never fully trusts anything. It operates based on a combination of mathematical modeling (prediction) and sensing (measurement).

Step 1: Prediction

The algorithm uses the physical state equation to shift the system from time t-1 to t.

  • Logic: Based on the old velocity and position, it calculates the theoretical new position.
  • Uncertainty: Due to external factors (system noise – Process Noise), the confidence probability range widens. This means that after each prediction step, we become less certain about the object’s exact position.

Step 2: Measurement

This is where raw data is collected from the sensors (GPS, Radar, Lidar).

  • Logic: The sensor provides a direct observational value of the current state.
  • Sensor error: Every measurement involves noise (Measurement Noise). This data is also represented by a probability distribution with its own standard deviation depending on the accuracy of the device.

Step 3: Correction/Update

This is the core logic of the algorithm, where the Kalman Gain (K) acts as the arbiter.

  • Calculating K: This coefficient is determined by the ratio between the uncertainty of the forecasting model and the uncertainty of the sensor. If the sensor has low noise, K approaches 1 (the algorithm favors the measurement result). If the sensor has high noise, K approaches 0 (the algorithm favors the forecast result from the model).
  • Optimal Estimate: This combination produces a new probability distribution with sharper peaks (smaller standard deviation) than both original data sources. This means the final result is more accurate than any single data source.

Kalman Filter Algorithm: The 3-Step Recursive Process

4. Pros and Cons: Key Advantages and Limitations of Kalman Filters

The Kalman algorithm has become an indispensable tool in modern engineering due to two outstanding advantages: mathematical optimization and computational efficiency. Theoretically, it has been shown to provide the best possible state estimation (with the smallest mean square error), provided the input assumptions are met. Besides accuracy, Kalman’s practical strength lies in its recursive nature. The algorithm doesn’t need to store entire cumbersome historical data sets; it only needs the immediately preceding state to compute the current step. This “lightweight” characteristic makes it extremely ideal for embedded computing systems with limited memory and power resources, such as in autonomous robots or handheld mobile devices.

However, the standard (basic) Kalman filter is not a panacea due to significant limitations when applied to chaotic real-world scenarios. The biggest limitation is that it only works well with LINEAR systems, that is, systems that can be described by simple linear equations. Meanwhile, most real-world movements—for example, a robot performing a turn—are complex non-linear. Furthermore, this algorithm relies on the rigid assumption that system noise must follow a normal Gaussian distribution (bell-shaped). If the actual environmental noise has a different, unusual shape, the filter’s estimation efficiency will be severely degraded.

Gaussian Noise

To overcome the linearity barrier and bring the algorithm closer to practical applications, scientists have developed powerful upgraded versions. The most well-known and widely used solution is the Extended Kalman Filter, abbreviated as EKF. EKF handles nonlinear systems by applying local “linearization” techniques at each computation step, straightening complex curves to apply the basic Kalman mechanism. Thanks to this adaptability, EKF has now become an industry standard and is widely used in most advanced GPS and navigation systems today.

The Kalman Filter is considered one of the greatest algorithms of the 20th century, playing a core role in the Apollo moon landings and present in most modern rovers. To understand why this algorithm is so important yet so challenging, we need to consider two aspects: its superior computational capabilities and its stringent physical limitations.

Below is a detailed summary of the advantages, limitations, and potential extensions of the Kalman Filter:

Kalman Filter: Overview of Strengths and Limitations

5. Sensor Fusion in Action: Kalman Filter Applications in IoT and Autonomous Vehicles

The Kalman filter is one of the most widely used algorithms in engineering history.

  • Applications in GPS Positioning and Navigation: On phones/cars, positioning systems often combine GPS (providing accurate location but slow updates and prone to signal loss) with inertial sensors (inertial meters, gyroscopes – very fast responses but prone to drift errors over time). The Kalman filter combines the advantages of both, providing smooth positioning even when the vehicle enters short tunnels.
  • Key Role in Robotics and Autonomous Vehicles: Localization: Helps robots know their exact location on a surface map (SLAM); Object Tracking: Autonomous vehicles use Kalman to predict the movement of pedestrians or other vehicles on the road, thereby calculating a path to avoid collisions.
  • Applications in Aerospace, Signal Processing, and Finance: Aerospace: Extremely important for determining the position and attitude of aircraft, rockets, and spacecraft. The Apollo program used Kalman filters in its navigation computers. Signal processing & finance: Used to smooth volatile stock market data or remove noise in audio and video signals.

Returning to the spacecraft mentioned above, this is where Kalman filters made their name.

Neil Armstrong took the first steps on the Moon.

When the Eagle module was only a few dozen meters from the lunar surface, the navigation computer (AGC) became overloaded and repeatedly reported the “1202 Alarm” error. In this context, the Kalman algorithm acted as the “silent brain” to process conflicting data streams to predict (a physical model). The computer calculated the trajectory of the fall based on the Moon’s gravitational pull and the thrust of the jet engines; then, using sensors and the landing radar, it continuously fired signals down to the surface to measure the actual distance and velocity. Finally, the radar data was heavily disrupted by the uneven terrain and blown-away lunar dust. If the radar had relied entirely on the data, the spacecraft would have made erratic engine adjustments and run out of fuel.

This is how Kalman handled it in those 12 seconds:

  1. Real-time noise filtering: The Kalman algorithm constantly compares: “The radar says it’s 5 meters away, but the physical model says it should be 7 meters.”
  2. Calculating Kalman Gain (K): Because the radar was experiencing interference at that time, the coefficient K automatically decreased. The algorithm “suspected” the radar and placed more trust in the stable orbital model.
  3. Optimal blending: Instead of jerky jumps between numbers, Kalman provided a smooth estimate, allowing Neil Armstrong to maintain stable control and steer the spacecraft away from large rocks, landing safely with only 25 seconds of fuel remaining.

6. Real-World Case Study

The story of Apollo 11 is not just a historical milestone; it also laid the foundation for modern navigation technology. Today, Kalman filters are no longer found in NASA’s massive computers, but are present in every smartphone, drone, and autonomous vehicle through the GNSS/INS integration model.

To understand why we need this combination, let’s look at the illustration of a GNSS satellite system (like GPS, GLONASS…). GNSS provides us with absolute positioning but has the disadvantage of slow update speeds and is prone to signal loss (when entering tunnels or tree canopies). In this case, the Kalman filter acts as the “conductor,” combining satellite data with an inertial navigation system (INS) – consisting of accelerometer and gyroscope sensors – to create a continuous and centimeter-accurate stream of positioning data.

To understand the power of the Kalman Filter, let’s consider a real-world car navigation system where it has to solve the problem of combining data from two sensor sources with contrasting characteristics:

  1. Accelerometer (INS): Extremely fast response to any change in motion, but if used for long-distance calculations, errors accumulate very quickly (drift).
  2. GPS (GNSS): Provides accurate absolute position and velocity over the long term, but the update rate is very slow (usually only once per second) and often experiences delays.

We will solve this problem in two stages (two consecutive Kalman loops):

Case 1: Velocity Estimation (A combination of “Quickness” and “Accuracy”)

In the integrated navigation system, the goal of Case 1 is to optimize instantaneous velocity estimation by combining two data sources with different noise characteristics, aiming for both responsiveness and system accuracy.

  • Prediction Phase – Leveraging Dynamics: Using data from inertial sensors as input. Through the integration of the kinematic diagram, the filter provides a prediction of the velocity at time $k$. The advantage of this method is its high sampling frequency and instantaneous response to dynamic changes (acceleration, braking). However, due to the influence of white noise and bias, the integration process will cause cumulative error (drift), leading to a gradual deviation of the prediction value over time.
  • Update Phase – Absolute Reference Correction: At this stage, the velocity from the GNSS receiver is used as a reference measurement (Observation). Although GNSS data is highly reliable in terms of absolute values, it is limited by the low update frequency and large signal delays due to satellite processing.

The Kalman Filter’s optimization mechanism:

The algorithm balances the two data sources using the Kalman Gain. When the vehicle undergoes a sudden change in state, the difference between the accelerometer prediction and the actual GNSS measurement increases. The Kalman filter analyzes the covariance of the error to determine the weighting:

  1. In dynamic state: When there is a large change in acceleration that the GNSS hasn’t updated in time due to delay, the filter will temporarily increase the weighting of the accelerometer prediction model, helping the system track the actual velocity trajectory without data lag.
  2. In steady state: The filter will prioritize data from GNSS to “anchor” the velocity value, while estimating and eliminating the accelerometer polarization error, preventing data drift.

Result: The output of Case 1 is an optimal velocity estimate with smooth, high bandwidth characteristics and no cumulative error. This is the pure input variable for the position estimation model in the next stage.

Case 2: Estimating Location/Distance (Utilizing the results of Case 1)

After obtaining the optimal velocity vector from Case 1, the goal of this phase is to determine the precise spatial coordinates of the vehicle using a second-stage Kalman filter (Cascaded Kalman Filter).

  • Prediction Phase – Smooth Trajectory Interpolation: The system uses the “clean” velocity estimate from the output of Case 1 as the input variable to perform position integration. Based on a dynamic state-space model, the filter predicts the vehicle’s next position at a high frequency (e.g., 100Hz). Thanks to the use of the denoised and biased velocity from the previous step, the predicted trajectory becomes extremely smooth, eliminating the “jump” in position often seen in devices using only GNSS.
  • Update Phase – Coordinate Anchoring Correction: Absolute coordinates (Longitude, Latitude) from the GNSS system are used as a correction measurement. This is a source of “ground truth” data to control errors. Although the velocity integration in the prediction step was very good, mathematically, even the smallest errors will accumulate over time (Integration Drift). The coordinate points from the GNSS act as absolute “anchors” to reset these errors.

The role of the Kalman Filter in trajectory optimization: The algorithm performs Sensor Fusion at a more complex level:

  1. Maintaining Continuity: In scenarios of temporary satellite signal loss (e.g., a vehicle entering a tunnel or under dense foliage), the Kalman filter relies entirely on the predicted model from the velocity in Case 1 to “continue” the trajectory. This capability helps the system maintain continuous navigation without interruption.
  2. Smoothing Data: When a new GNSS signal (which often has noise of a few meters) is detected, the filter does not immediately jump to the new location. Instead, it calculates the difference between the predicted and measured location (Innovation), then subtly adjusts the estimated location through the weights of the covariance matrix.

Overall result: Through a two-stage Kalman filter structure, the system achieves optimal convergence: providing position and velocity with high temporal resolution (from INS) and consistently high absolute accuracy (from GNSS). This is the core principle that enables autonomous vehicles and guided missiles to operate stably in the most dynamically complex environments.

7. Conclusion: The Future of Precision Positioning in the IoT Era

The Kalman filter is proof of the power of mathematics in conquering chaotic realities. From the historic Apollo missions to today’s era of autonomous vehicles, this algorithm remains the “soul” that helps positioning systems achieve absolute accuracy through its ingenious Sensor Fusion mechanism.

In short, mastering the Kalman filter is key to creating groundbreaking IoT products—where smoothness and accuracy are paramount. This is not just technology, but the foundation for a safer and smarter automated future.

Read More
TLV320AIC3254 Linux Audio Codec Driver Integration Guide
February 6, 2026by Tuyền NguyễnTechnology

TLV320AIC3254 Linux Audio Codec Driver Integration Guide

1. Introduction to TLV320AIC3254 Linux Audio Driver
      1.1. Purpose of the TLV320AIC3254 Codec Driver
      1.2. Scope and Out-of-scope Features
2. System Overview for TLV320AIC3254 Audio Codec
      2.1. Hardware Architecture Overview
      2.2. Functional Role of Each System Component
3.  Linux Audio Software Architecture (ALSA SoC)
      3.1. Audio Data Path in ALSA ASoC Framework
      3.2. Audio Control Path (Mixer, Codec, Registers)
4. Linux Kernel Configuration for TLV320AIC3254
      4.1. Enable Subsystem in Defconfig
      4.2. Disable Audio flag check (AUDIO_ENABLE_FILE)
      4.3. Add support Sound Card into Build System
5. Device Tree Integration for TLV320AIC3254
      5.1. Declare I2C Controller and Codec Node
      5.2. Declare Regulator (Source)
      5.3. Declare Sound Card (MDM9607 Audio Common)
6. Verify Driver TLV320AIC3254 Driver Operation
      6.1. Checking Sound Card Registration
      6.2. Testing Audio Playback Using WAV Files

1. Introduction to TLV320AIC3254 Linux Audio Driver

1.1. Purpose of the TLV320AIC3254 Codec Driver

This document is compiled to provide in-depth technical guidance on the integration (porting) and activation (bring-up) process of the TI TLV320AIC3254 audio codec chip on the Cavli C10QM module platform (based on the Qualcomm MDM9607 chipset) running the Linux operating system.

The C10QM module is designed with a digital audio interface (DAC/ADC) and does not include an integrated analog-to-digital converter (DAC/ADC) for analog-to-digital audio applications; the integration of a codec is required to support voice and music playback features.

Within the scope of this guide, the CC3200 Audio Boost board is used as the reference hardware (Reference Hardware). However, it should be noted that the CC3200 microcontroller on this board will be disabled or ignored (ignored). The C10QM module will act as the host/master device, fully responsible for:

  1. Data flow management (Data path): Transmitting/receiving PCM audio data via the I2S/MI2S interface.
  2. Control management (Control path): Configuring the codec’s registers, clock, and power via the I2C interface.

This document will focus on addressing the following core technical issues:

  • Software Architecture: Understanding the ALSA audio subsystem (Advanced Linux Audio Architecture) and the ASoC framework (ALSA System on Chip) on the Qualcomm platform.
  • Kernel Configuration: Guidance on selecting and compiling necessary drivers (Machine Drivers, Platform Drivers, Codec Drivers).
  • Device Tree Integration (DTS): Declaring hardware, configuring GPIO pin muxing, regulators, and clocks for the system to control device recognition actions.
  • Testing and Verification: Using non-user-space tools such as tinyalsa and amixer to test audio paths and signal quality.
1.2. Scope & Out-of-scope Features

To ensure the focus and efficiency of the integration process, this document clearly defines the following work items: within the scope of implementation and outside the scope of implementation.

In Scope:

  • Hardware Communication Setup: Instructions for connecting and configuring the physical interface between the C10QM and the TLV320AIC3254, including the MI2S data bus (MCLK, BCLK, WCLK, DIN, DOUT) and the I2C control bus.
  • Driver Development and Integration: Activating the driver for the TLV320AIC32x4 codec in the Linux Kernel. Declaring a virtual Sound Card in the Device Tree to link the DAI (Digital Audio Interface) CPU and the DAI Codec.
  • Audio Routing Configuration: Using kcontrols (Mixer controls) to set the signal path within the Codec (e.g., routing from DAC to Headphone Output).
  • Playback Feature: Focuses on enabling PCM audio output to the headphone jack (3.5mm) in Stereo mode.

Out of Scope:

  • Advanced Digital Signal Processing (DSP): Does not mention acoustic echo cancellation (AEC), noise suppression (NS), or audio effects (EQ, 3D) on Qualcomm’s Hexagon DSP.
  • Application Layer Encoding/Decoding: Does not include integration of decoding libraries for compressed formats (MP3, AAC, Opus, OGG…). The document only covers playback of .wav files (raw PCM).
  • Firmware Development for CC3200: Does not include any source code or configuration for the CC3200 MCU chip.
  • Analog Circuit Design: Does not delve into the design of filters, capacitors, or analog amplifier circuits. It is assumed that the CC3200 Audio Boost hardware is electrically sound.
  • VoLTE/CSFB Call: This document focuses on the System Audio path and does not include detailed configuration for voice stream during mobile network calls.

2. System Overview for TLV320AIC3254 Audio Codec

2.1. Hardware Architecture Overview

The system is built on a Host-Codec model, where the C10QM acts as the master device controlling all operations, and the CC3200 Audio Boost acts as an expansion board providing an analog audio interface. The connection between the two components is based on two industry-standard physical interfaces:

Data Link – Interface MI2S

  • Protocol: Uses the MI2S (Multi-channel Inter-IC Sound) standard, also known as Primary I2S.
  • Function: Responsible for transmitting raw PCM audio data in real time.
  • Data direction: The audio system is designed to operate in full-duplex mode, allowing simultaneous playback and capture on the same I2S/PCM physical interface. Although sharing a common clock bus, the data of these two streams travels on separate signal lines, ensuring no signal interference and supporting independent debugging for each communication direction:

Playback (DL):

For downlink, audio data travels from the host device to the peripheral device. Specifically, digital PCM data is output by the C10QM module’s CPU via the PCM_DOUT pin (Pin 48). This signal enters the DIN pin of the TLV320AIC3254 codec. Here, the codec processes the signal through an interpolation filter and a digital-to-analog converter (DAC) to convert it into analog signal. The final signal is then passed through the amplifier (Headphone Driver) and output to the 3.5mm jack. Software-wise, the DAPM (Dynamic Audio Power Management) path is routed from the “Left/Right DAC” through the corresponding mixers to the HPL/HPR output.

Capture (UL):

In contrast to the transmission stream, the uplink stream is responsible for bringing the signal from the environment into the processing system. The analog signal from the microphone enters the analog input of the codec, is amplified by the PGA (Programmable Gain Amplifier), and converted to digital via the ADC. The digital data is then output from the DOUT pin of the codec and goes to the PCM_DIN pin (Pin 47) of the C10QM module. At the C10QM side, the CPU receives this data stream to perform recording or processing for voice calls.

  • Clocking:

The C10QM operates in Master mode, responsible for providing critical clock signals (MCLK, BCLK, WCLK) to synchronize the data sampling of the Codec. The stable operation of both data streams depends entirely on the clocking mechanism, with the C10QM acting as the master device. The C10QM module is responsible for generating and maintaining two crucial signals: the Bit Clock signal (PCM_CLK) on pin 49 to synchronize each data bit, and the Frame Sync signal (PCM_SYNC) on pin 46 to mark the start of the audio frame. Loss of either of these clock signals will cause both transmission and reception to stop immediately.

Control Link – Interface I2C

The I2C interface acts as the “command center” of the audio system, operating in parallel but completely separate from the audio data stream. While the MI2S interface is responsible for transporting digital signals (PCM), the I2C (Inter-Integrated Circuit) protocol is used specifically to configure and monitor the operating status of the Codec chip. Here, the C10QM module acts as the master device, sending read/write commands to the registers of the TLV320AIC3254 to perform complex control tasks:

  • Power Management: Controls the power supply or power off for specific functional blocks within the Codec (such as turning off the ADC block when only listening to music, or turning on the Mic-Bias block when recording) to optimize power consumption for the device.
  • Clocking System Configuration: Set parameters for the phase-locked loop (PLL) and internal dividers, ensuring the codec can generate standard sampling frequencies (such as 44.1kHz, 48kHz) from the original MCLK clock provided by the C10QM.
  • Audio Routing: Control the internal switch matrix of the codec to determine the signal path, for example, connecting the signal from the DAC to headphones or transferring the signal from the microphone to the ADC converter.
  • Signal Conditioning: Set digital volume levels, configure the analog gain for the microphone to avoid distortion, and configure audio filters if available.
2.2. Functional Role of Each System Component

Module Cavli C10QM (Follow Qualcomm MDM9607 SoC)

Acting as the Audio Master and considered the central controller of the system, this component operates on an embedded Linux operating system using the ALSA (Advanced Linux Sound Architecture) audio architecture. It integrates machine-level and platform-level drivers to manage all communication with the hardware. Core tasks include initiating the I2C protocol to activate (‘wake up’) and load configuration for the Codec at boot time, managing the audio buffer and controlling DMA to transmit PCM data over the MI2S interface, and providing the essential base clock (MCLK) source to ensure the Codec operates synchronously.

Chip Codec TI TLV320AIC3254

  • Features: A low-power stereo audio codec with an integrated miniDSP.
  • Main functions: DAC (Digital-to-Analog Converter): Receives digital signals from the C10QM, converts them into analog signals for headphone output; ADC (Analog-to-Digital Converter): Receives electrical signals from the microphone, converts them into digital signals to send back to the C10QM; Mixer & Amp: Mixes signals and amplifies power to drive headphones or external speakers.

CC3200 Audio Boost (Hardware Carrier)

  • Function: Provides the electrical infrastructure for the Codec to operate (power supply, filter capacitors, 3.5mm jack, connector header).
  • Special Note (Hardware Bypass): By default, this board is designed to work with the CC3200 MCU. In this integration guide, the CC3200 MCU on the board will be completely disabled, and the I2S and I2C signal lines of the Codec (which are connected to the CC3200 MCU) will be disconnected and directly connected (Jump wiring) to the corresponding GPIO pins on the C10QM module. This turns the CC3200 Audio Boost into a pure “Breakout board” for the TLV320AIC3254 chip.

3. Linux Audio Software Architecture (ALSA ASoC)

The audio system on the C10QM (MDM9607) is built on the ALSA System on Chip (ASoC) architecture. This is a standard framework in the Linux kernel designed specifically for embedded systems, separating the SoC control code, codec, and motherboard (machine) for easier reuse.

3.1. Audio Data Path in ALSA ASoC Framework

This is the journey of audio data from a music file to the user’s headphones. The data stream processing (Playback Flow) process occurs as follows:

  1. User Space (Application Layer): Tools like tinyplay, aplay, or Android Audio HAL read data from the music file (wav, pcm).
  2. ALSA PCM Interface: Data is pushed down to the kernel via the standard PCM interface (/dev/snd/pcmCxDxp). Here, ALSA manages the Ring Buffer.
  3. Platform Driver (SoC DMA/DSP): On the Qualcomm MDM9607 chip, data is not directly pushed to the I2S pin by the CPU. Instead, it is transferred to the digital signal processing unit (DSP/LPASS) via DMA.
  4. CPU DAI (Digital Audio Interface): The I2S interface on the SoC (Primary MI2S) receives data from memory and outputs digital signals (MCLK, BCLK, WS, DATA) externally.
  5. Codec DAI: The TLV320AIC3254 chip receives I2S signals.
  6. Codec Processing: Inside the codec, data passes through an interpolation filter, a DAC (Digital-to-Analog) converter, and an amplifier (Amp).
  7. Analog Output: The analog signal is output to the headphone jack.

3.2. Audio Control Path (Mixer, Codec Registers)

In parallel with the data line, the control line is responsible for hardware configuration. It does not carry audio signals.

  1. Physical protocol: Uses I2C bus.
  2. Kernel mechanism: Codec drivers register kcontrols (Kernel Controls) with the ALSA Core.
  3. Task performed:
  • Power Management (DAPM): Automatically turns on/off the power to the blocks (DAC, ADC, Amp) when there is/is not an audio stream to save power.
  • Register Config: Configures the PLL registers to create the clock and the Volume register to adjust the volume.

4. Linux Kernel Configuration for TLV320AIC3254

To enable drivers and the audio system on the C10QM, changes to the kernel configuration and build system are required.

4.1. Enable Subsystem in Defconfig

Change file .config mdm9607-perf_defconfig (c10qm_linux_4/build/c10qm/eaj_v3.2/linux_change/v2/) and add infomation into Makefile: 

4.2. Disable Audio flag check (AUDIO_ENABLE_FILE)

To prevent the audio module from being skipped during startup, the startup script needs to be modified start_audio_le (path: apps_proc/poky/meta-qti-bsp/recipes-multimedia/audio_dlkm_kernel/files/mdm9607/).

You need to comment (disable) the coding file check flag as:  

4.3. Add support Sound Card into Build System

Change Makefile To ensure mdm9607 is compiled correctly.

  • File: /apps_proc/vendor/qcom/opensource/audio-kernel/Makefile.am. Add to conditional block (Makefile):

  • File: /apps_proc/vendor/qcom/opensource/audio-kernel/Makefile:  

  • Edit file /apps_proc/vendor/qcom/opensource/audio-kernel/asoc

5. Device Tree Integration for TLV320AIC3254

You need to declare a node for the TLV320AIC3254 codec on the I2C bus and configure the sound card to link the components.

5.1. Declarate I2C Controller and Codec Node

Add node tlv320aic32x4 into node i2c_5 (BLSP1 QUP5).

5.2. Declarate Regulator (Source)

Add virtual power nodes if the hardware does not use PMIC for direct control:

5.3. Declarate Sound Card (MDM9607 Audio Common)

Define the sound card to link the CPU DAI and the Codec DAI.

Note: You need to disable any other default sound cards (e.g., sound-9330, sound-9306) to avoid conflicts.

6. Verifying TLV320AIC3254 Driver Operation

6.1. Checking Sound Card Registration

Using cat /proc/asound/cards To confirm that the system has recognized the new sound card.

Result expected:

6.2. Testing Audio Playback Using WAV Files

Configure the Mixer and play the music file to your headphones.

  1. Hardware connection: Plug your headphones into the J4 jack on the CC3200 codec board.
  2. Mixer configuration (Routing): Run the following commands to enable audio routing:
  3. To play music: Push the sound.wav file to the device and run the play command:

 

Read More
PCM vs McASP: Audio Interface Comparison for IoT (Cavli C10QM vs TI CC3200)
February 4, 2026by Tuyền NguyễnTechnology

PCM vs McASP: Audio Interface Comparison for IoT (Cavli C10QM vs TI CC3200)

1. Why Audio Integration Is Critical in Modern IoT Devices
2. PCM Audio Interface Architecture of Cavli C10QM
3.  McASP Multichannel Audio on TI CC3200
      3.1. Flexible Stereo Multi-Channel Audio Interface>
      3.2. Superior Speed anf Accuracy
      3.3. Optimize Processing Performance ARM Cortex-M4-Core
4. Audio Specifications Comparison Table between C10QM and CC3200
5. Hardware Design Considerations for IoT Audio Interfaces
      5.1. Hardware Design for Cavli C10QM
      5.2. Hardware Design for TI CC3200
      5.3. General Noise-Resistant Layout Rules
6. Choosing the Right Audio Interface for IoT Applications
      6.1. When sould you prioritize Cavli C10QM?
      6.2. When is the TI CC3200 the perfect choice?
7. Conclusion: The Future of Wireless Audio Solutions in IoT

1. Why Audio Integration Is Critical in Modern IoT Devices

In the practical implementation of IoT, many problems cannot be solved solely with digital data. When systems need to interact directly with humans, audio and voice become the fastest, most natural, and effective communication channel. Devices such as smart intercoms, cameras with two-way audio, remote monitoring gateways, medical care devices, or emergency alert systems all have clear requirements: stable audio transmission and reception, low latency, and sufficiently good quality under all connection conditions.

From a technical perspective, integrating audio in IoT is not just about “having a microphone and speaker,” but a comprehensive problem involving bandwidth, latency, processing resources, power consumption, and hardware costs. A poorly designed audio system can lead to echo, distortion, significant delays, or even overload the MCU/SoC, directly impacting user experience and product reliability.

Essentially, wireless audio transmission in IoT devices still relies on core signal processing principles (as illustrated in the diagram below). However, with the development of digital technology, modern modules such as the Cavli C10QM using PCM communication or the TI CC3200 using McASP have made audio encoding and decoding much more efficient and higher quality than traditional methods.

Schematic diagram of AM wireless audio signal transmission and reception in IoT devices.

Therefore, choosing the connectivity platform (Cellular or Wi-Fi) and internal audio interface (PCM or McASP) becomes a strategic decision right from the design stage. For devices operating in the field without a fixed network infrastructure, LTE Cat 1 connectivity offers advantages in coverage and stability. Conversely, in indoor environments or systems already equipped with Wi-Fi, a Wi-Fi solution can optimize costs and simplify deployment. Similarly, the use of simpler PCM or more flexible and powerful McASP will directly affect audio scalability, number of channels, clock synchronization, and hardware complexity.

Therefore, the question is no longer “which platform is more powerful,” but rather which solution is more suitable for the actual usage needs. In this context, comparing two typical approaches — Cavli C10QM (LTE Cat 1) and TI CC3200 (Wi-Fi) — helps clarify the trade-offs between connectivity, audio architecture, and system cost, thereby determining the optimal choice for each specific IoT scenario.

2. PCM Audio Interface Architecture of Cavli C10QM

The Cavli C10QM is not only a powerful LTE Cat 1 module but also optimally designed for voice messaging and digital audio applications. The core of the C10QM’s audio processing capabilities lies in its PCM (Pulse Code Modulation) interface.

Hardware Architecture and Chipset

Based on the functional block diagram, the Cavli C10QM is built on the Qualcomm MDM9207 chipset with an ARM Cortex A7 processor. Audio signals are processed through the Modem system (Hexagon DSP) and output through a single PCM port.

Functional block diagram of the Cavli C10QM module integrating PCM communication and Qualcomm chipset.

The use of PCM communication allows the C10QM to transmit raw audio data to external codec chips with the highest fidelity, minimizing latency – a crucial factor in VoLTE voice calls. Additionally, the Cavli C10QM is designed around the Qualcomm MDM9207, a highly integrated LTE Cat 1 SoC, aimed at industrial IoT applications requiring stable connectivity, voice support, and low power consumption. This chipset integrates an ARM Cortex-A7 (32-bit) CPU, handling control, protocol processing, and system management tasks.

Audio processing architecture

A key feature of the C10QM’s architecture is the separate audio processing pipeline between the CPU and modem:

  • The internal Hexagon DSP in the modem is responsible for: Real-time voice processing, noise suppression, echo cancellation, and automatic gain control (AGC).

Hexagon DSP audio processing architecture in the Qualcomm chipset ecosystem.

The audio processing power of the Cavli C10QM comes from Qualcomm’s Hexagon DSP architecture (see system architecture diagram). Unlike conventional CPU audio processing, the Hexagon aDSP is a dedicated processor that separates the audio data stream from other system tasks. This ensures continuous, uninterrupted encoding/decoding (Codec), optimizing performance for VoLTE or industrial intercom applications.

  • The Cortex-A7 CPU only acts as a coordinator, configurator, and application communicator, thereby reducing CPU load and increasing stability for extended VoLTE calls.

Like dedicating an ambulance lane on a highway, the C10QM’s architecture ensures that audio signals always flow as quickly as possible, unaffected by congestion from other application data. The separation of the audio pipeline between the application CPU and the modem system (containing the DSP) in the architecture of the Cavli C10QM (based on the Qualcomm MDM9207 chipset) is an optimal design for industrial IoT, effectively meeting the requirements for low latency and high reliability, which are crucial in IoT voice systems such as intercoms, eCalls, and remote monitoring devices.

PCM Audio Interface

The Cavli C10QM module provides a unique PCM (Pulse Code Modulation) digital audio interface, a deliberate design choice optimized for specialized telecommunications applications. This interface transmits raw, uncompressed digital audio data, directly synchronized with the system clock to minimize jitter and ensure accurate timing for voice calls.

Typically, the PCM interface on the C10QM supports standard specifications such as 8 kHz or 16 kHz (suitable for both narrowband and wideband voice) with a 16-bit sample rate. Additionally, the module offers flexible Master and Slave modes, allowing designers to easily connect to external audio codec chips from reputable manufacturers like TI, NXP, or dedicated audio amplifiers and ICs for voice applications.

The lack of an integrated analog codec offers strategic advantages for developers. It allows for complete control in selecting codec components to meet specific audio quality requirements and optimize the Bill of Materials (BOM) for different product segments. Simultaneously, this architecture makes it easier for the device to achieve VoLTE certifications and carrier approvals due to the separation of functional blocks.

From a system design perspective, this architecture requires a particular focus on hardware. Designers need to add external audio codec chips, leading to the need to design additional analog circuits for microphones, speakers, and amplifiers, and demanding more stringent noise-canceling layout techniques to protect the audio signal. However, these efforts will result in extremely stable voice quality, less reliance on application-level audio processing firmware, and reliable device operation in 24/7 environments.

3. McASP Multichannel Audio on TI CC3200

While the Cavli C10QM focuses on the stability of telecommunication voice calls, the TI CC3200 is a powerful Wi-Fi SoC (System-on-Chip) solution aimed at providing a flexible multichannel audio experience through its McASP (Multichannel Audio Serial Port) interface. This is one of the core components that makes the CC3200 the heart of “Wireless Audio” applications and home entertainment IoT devices.

CC3200 Hardware Overview

3.1. Flexible Stereo Multi-Channel Audio Interface

The TI CC3200’s standout feature is its ability to simultaneously transmit two I2S stereo channels via the McASP data pins. The McASP architecture includes synchronized transmitter and receiver sections, allowing designers to flexibly program the polarities of the clock and frame-sync signals. This is crucial when connecting to high-end audio codecs or amplifiers to create true stereo sound.

While PCM interfaces typically handle mono-channel voice streams, the TI CC3200’s McASP architecture fully supports the I2S Stereo protocol (as illustrated in the diagram). The Word Select (WS) mechanism allows for clear separation of data between the Left and Right channels in real time. This enables the CC3200 to not only transmit voice but also perfectly meet the needs of high-fidelity wireless music streaming applications.

  • WS (Word Select): This is the key signal that creates “Stereo”. When WS is low, it transmits data to the Left Channel; when WS is high, it switches to the Right Channel. The image clearly illustrates this transition.
  • SCK (Continuous Serial Clock): The clock signal controls the transmission speed of each bit of audio data.
  • SD (Serial Data): The actual audio data stream, transmitted in MSB (most significant bit) format first.
  • Multi-channel capability: The image shows how data from the Left/Right channels are “lined up” sequentially on the same transmission line, explaining why the CC3200 can handle high-quality stereo audio.
3.2. Superior Speed ​​and Accuracy

In the world of digital audio, clock speed determines resolution and sound quality. The TI CC3200 boasts impressive specifications with a maximum clock speed of 9,216 MHz in I2S transmission mode. Notably, it incorporates a dedicated fractional divider to generate precise bit-clocks for various sampling rates, minimizing errors and ensuring consistently clear audio signals.

Block diagram of fractional frequency divider

3.3. Optimal Processing Performance ARM Cortex-M4-Core

The CC3200’s audio processing capabilities are powered by an ARM Cortex-M4 processor running at 80 MHz. This architecture allows the device to perform audio signal processing tasks (such as noise filtering and tone control) directly on the chip without overloading the system. Simultaneously, the CC3200 supports a 32-channel µDMA (Micro Direct Memory Access) controller, enabling direct audio data transmission between SRAM and the McASP port without constant CPU intervention. This mechanism not only reduces latency but also significantly saves power for battery-powered IoT devices.

Block Diagram of DMA Controller

With support for both I2S and PCM standards, the TI CC3200 offers maximum flexibility for developers of smart Wi-Fi speakers, high-quality wireless alarm systems, and audio streaming applications.

4. Audio Specification Comparison Table between C10QM anh CC3200

Comparing these two solutions will give system engineers a more thorough understanding of each module’s ability to meet specific audio and voice requirements. Below is a summary of the most important technical specifications based on the manufacturer’s datasheet:

Based on the technical data above, we can draw two completely different approaches:

  • The Cavli C10QM focuses maximally on telecommunication voice performance. Its PCM interface with a clock speed of 2048 kHz and a Sync frequency of 8 kHz is the “gold standard” for voice transmission standards in 4G/2G mobile networks. The architecture separates the audio pipeline to a dedicated DSP, ensuring absolutely stable voice connectivity regardless of the application CPU load.
  • The TI CC3200, on the other hand, aims for a multimedia experience. With a McASP port supporting Stereo I2S and an extremely high clock speed (9.216 MHz), this module goes far beyond the limits of typical voice calls. The presence of a fractional divider allows the device to reproduce audio with multiple sampling rates with extreme accuracy, meeting the standards of wireless music playback devices.

5. Hardware Design Considerations for IoT Audio Interfaces

5.1. Hardware Design for Cavli C10QM (H3)

The Cavli C10QM module requires an external audio codec chip to convert digital data from the PCM interface to analog audio.

  • PCM Pinout Diagram: Important signal pins to note include:
  • PCM_SYNC (Pin 46): Data frame synchronization signal.
  • PCM_DIN (Pin 47): Audio data input.
  • PCM_DOUT (Pin 48): Audio data output.
  • PCM_CLK (Pin 49): PCM synchronization clock.

Design Notes:

  • The reference diagram recommends using 4.7K pull-up resistors connected to the VDD_1V8 power supply on the digital transmission lines.
  • Audio signal lines should be laid out as short as possible to minimize electromagnetic interference (EMI).
  • Use 1uF and 47uF capacitors in the Analog (Mic/Speaker) stage to filter low-frequency noise and stabilize sound quality.
5.2. Hardware Design for TI CC3200 (H3)

For the TI CC3200, the McASP interface offers high flexibility but also requires precise pin configuration (Multiplexing Pins).

Pin Configuration (Mux Pins): The McASP audio interface is multiplexed across multiple pins, for example:

  • MCAFSX (Pin 45): Frame Sync signal.
  • MCACLKX (Pin 62): Main clock for Audio.
  • McAXR0/1 (Pins 50, 52): Multichannel audio data transmission.

Important Power Supply Note:

  • The voltage at the digital pins must be compatible with VIO (typically 2.1V to 3.6V).
  • TI recommends using 0.1uF and 10uF noise filter capacitors near the power supply pins to prevent interference from the RF Wi-Fi module from interfering with the audio transmission.
  • Specifically, the nRESET pin must be kept low until the VBAT power supply stabilizes to ensure the Codec initialization process is correct.
5.3. General Noise-Resistant Layout Rules

From a hardware design perspective, managing electromagnetic interference (EMI) is crucial to ensuring accurate audio quality for IoT devices. Since both the Cavli C10QM and TI CC3200 integrate high-power radio transceivers (LTE and Wi-Fi), designers must strictly adhere to separating analog and digital signal areas on the PCB. Analog audio signal paths to speakers and microphones should be wired as short as possible, avoiding running parallel to or crossing high-speed data paths or areas near antennas to prevent RF interference.

Another important technique is designing a continuous and undivided ground plane beneath the codec chips and PCM/I2S transmission lines, acting as a shield to protect the signal from power supply interference. For high-speed clock lines like McACLK on the CC3200 or PCM_CLK on the C10QM, maintaining a stable line impedance of 50Ω minimizes signal reflections, thereby eliminating static or sudden sound loss. Finally, to enhance the electrostatic discharge (ESD) resistance of the audio interface, the addition of low-parasitic ESD protection devices (such as TVS diodes) is essential to protect the module from physical damage during real-world use.

6. Choosing the Right Audio Interface for IoT Applications

The decision to use Cavli C10QM or TI CC3200 depends not only on technical specifications but also on the operating environment and user experience goals. Each module line is designed to address specific problems within the IoT ecosystem.

6.1. When should you prioritize Cavli C10QM?

You should choose Cavli C10QM for applications requiring high mobility and wide-area connectivity via 4G LTE or 2G mobile network infrastructure. With its separate audio pipeline architecture and PCM communication supporting telecommunication standards such as A-law/U-law, this module is an ideal choice for emergency communication (SOS) systems, elevator intercoms, or vending machines with integrated online voice support. The ability to operate stably in the industrial temperature range from -30°C to +85°C ensures the C10QM operates reliably even in the harshest environments. In particular, if your device needs to make traditional voice calls (VoLTE) without interruption from heavy application processing tasks, the Qualcomm Hexagon DSP architecture inside the C10QM will ensure audio latency is always kept to a minimum.

6.2. When is the TI CC3200 the perfect choice?

Conversely, the TI CC3200 shines in high-quality audio application scenarios (Wireless Audio) within a local Wi-Fi network. Thanks to its powerful McASP interface supporting Stereo I2S audio with clock speeds up to 9.216 MHz, the CC3200 is extremely suitable for developing smart speakers, wireless music streaming devices, or smart home automation systems requiring high-quality voice interaction. With the advantage of a built-in TCP/IP stack and WPA2 Enterprise security support, the CC3200 allows you to build secure audio solutions over IP networks without the need for additional external processors, optimizing the size and cost of battery-powered handheld devices thanks to its low power consumption of only about 4 μA in Hibernate mode.

7. Conclusion: The Future of Wireless Audio Solutions in IoT

The decision between the Cavli C10QM and the TI CC3200 is not simply a matter of choosing between LTE Cat 1 mobile connectivity or Wi-Fi wireless networking. Essentially, this is a problem of choosing an audio processing architecture that best suits the product’s ultimate goal. If your project prioritizes absolute stability and wide-area communication capabilities, the Cavli C10QM with the Qualcomm MDM 9207 chipset is the top choice. This module’s architecture completely separates the audio pipeline via a Hexagon DSP processor, ensuring smooth voice data flow on a dedicated “priority lane,” unaffected even when the Cortex A7 application processor is overloaded. Conversely, the TI CC3200 excels in home entertainment and local area network applications thanks to its McASP interface supporting two I2S Stereo channels. With a maximum clock speed of up to 9,216 MHz, the CC3200 allows for high-quality, high-resolution audio transmission, making it an ideal processing center for wireless speaker systems or smart home systems.

From a hardware design perspective, regardless of the module chosen, optimizing the codec layer still requires strict engineering principles. For the Cavli C10QM, since the module only provides a digital PCM port and does not have a built-in analog codec, designers need to pay special attention to selecting a suitable external codec chip to ensure compatibility with Master/Slave modes and 16-bit linear formats. During PCB layout, PCM or I2S signal paths must be kept as short as possible to minimize jitter and crosstalk from RF blocks. Simultaneously, the use of ceramic noise filter capacitors (such as 33pF, 10pF, 100nF) placed near the VCC power supply pin is mandatory to maintain stable voltage, avoiding unwanted audio distortion during high-speed data transmission and reception.

In short, the future of IoT is strongly shifting towards intelligent voice and audio interaction. A thorough understanding of the Cavli C10QM’s discrete pipeline architecture or the TI CC3200’s flexible multi-channel capabilities will enable businesses to build solutions that are not only robust in data but also excel in audio experience. Investing appropriately in hardware design and selecting the right modules from the outset will be key to ensuring your product meets carrier approval standards and earns the trust of end consumers.

Read More
Scalable Device Provisioning in AWS IoT Using Fleet Provisioning
January 30, 2026by Tuyền NguyễnTechnology

Scalable Device Provisioning in AWS IoT Using Fleet Provisioning

1. Overview of AWS IoT and Device Identity Management
2. Provisioning Mechanisms in AWS IoT
3. AWS IoT Fleet Provisioning Templates Explained
4. Implementation of the Fleet Provisioning Applications
5. Claim Certificate vs CSR: A Comparison in AWS IoT Provisioning
6. Security Considerations for AWS IoT Fleet Provisioning
7. Conclusion – Why Fleet Provisioning is the Best Choice for Scalable IoT 
1. Overview of AWS IoT and Device Identity Management

AWS IoT is Amazon Web Services’ platform that enables the centralized and highly scalable connection, management, and security of millions of IoT devices. Within this ecosystem, Fleet Provisioning plays a crucial role in addressing the challenge of deploying IoT devices on a large scale, especially in mass production scenarios.

What is Fleet Provisioning?

Fleet Provisioning is a mechanism that allows IoT devices to automatically register (onboard) into the AWS IoT Core system upon first power-on, without the need to manually create certificates and configure each device. Instead of creating certificates for each device, hardcoding the certificate and private key into the firmware, and manually assigning policies and Thing Names, AWS IoT Fleet Provisioning allows devices to be configured with minimal initial information (claim certificate or CSR). Upon initial connection, AWS IoT will automatically create a unique certificate, assign policies, create Things, and link related resources. In other words, Fleet Provisioning is a platform for automatically, securely, and scalably onboarding IoT devices.

Note: Avoid hardcoding certificates in firmware: Hardcoding certificates and private keys in firmware is common practice in small Proof-of-Concept (PoC) systems, but it’s unsuitable for real-world IoT systems because:

  • High security risk: If firmware is leaked, reversed, or flashed, the private key is exposed, and all devices sharing the same key can be impersonated.
  • Scalability is impossible: Manually creating and managing thousands/millions of certificates is impractical.
  • Device lifecycle management is lacking: Hardcoded firmware offers virtually no support for revoking, rotating, or re-provisioning devices.

Fleet Provisioning solves these problems by separating the identity provisioning process from the firmware. Large-scale IoT deployments require a well-structured device management strategy. Below are the three most important practical needs that businesses should focus on:

Optimize Mass Production:

  • Firmware Unification: Allows all devices in the same batch to be flashed with a single firmware version.
  • Automated Identification: Solves the problem of not being able to pre-determine the individual serial number, thing name, or certificate for each device during the manufacturing process.
  • Dynamic Registration: Uses Provisioning Templates to automatically generate “things” and grant permissions as soon as the device leaves the factory or is installed in the field, without requiring manual intervention.

Enhance security Private Key:

  • Personalized certificates: Ensure each device possesses a unique certificate and private key pair, eliminating the need for sharing or hardcoding security information.
  • Secure issuance mechanism: CSR-based – Supports direct key pair generation on the device to ensure the private key is never exposed. Claim-based – Uses a temporary certificate (Claim Certificate) for initial connection, then automatically issues a permanent certificate and revokes the temporary certificate’s authority.

Device Lifecycle Management:

  • Re-provisioning: Allows for flexible reconfiguration and reuse of devices for different clients or purposes.
  • Revocation: Timely disconnects and revokes access to devices that are faulty, lost, or show signs of being compromised.
  • Certificate Rotation: Performs periodic key changes to maintain the highest security standards for the system.
  • Systematized Management: Integrates closely with AWS IoT Policies and Thing Management to monitor devices from activation to deactivation.

Fleet Provisioning offers several key benefits to modern AWS IoT systems, most notably the ability to fully automate the onboard device process. Thanks to its template-based provisioning and certificate claim mechanism, devices can register and receive their identity on the first connection without manual configuration. Furthermore, Fleet Provisioning is highly scalable, suitable for systems with thousands to millions of devices operating simultaneously. Each device is assigned a unique PKI-based identity, ensuring high security and preventing certificate sharing. Eliminating manual configuration significantly reduces operational risk and minimizes errors during production and deployment. Additionally, Fleet Provisioning easily integrates into mass production lines and real-world operations, shortening time to market.

2. Provisioning Mechanisms in AWS IoT

Depending on the scale and hardware capabilities, AWS IoT offers three common approaches to device identity provisioning:

  • Manual Provisioning: This is the simplest method, suitable for proof-of-concept (PoC) or demos with a very small number of devices. The process involves creating the Thing and Certificate directly on the console, then manually loading it into the firmware. However, this method is completely unfeasible for mass production due to high operational resource costs and the risk of operational errors.
  • Just-In-Time Registration (JITR): This method allows the device to self-register on the first connection based on a factory-issued Certificate Authority (CA Certificate). This process requires the device to have a sufficiently powerful MCU to generate key pairs and perform complex encryption algorithms (RSA/ECC). While ensuring high security and each device having its own certificate, JITR increases hardware costs and requires a very strict CA management process at the factory.

jitr flow vs jitp flow

  • Fleet Provisioning: Considered the most balanced solution, Fleet Provisioning uses a temporary Claim Certificate for the initial connection of the device. Afterward, the system automatically issues a separate Production Certificate and configures the device using pre-set templates. Its significant advantages include allowing the use of a single firmware version for the entire batch, reducing the computational load on low-cost devices, and supporting systematic device lifecycle management (recall and reissue).

Provisioning Approaches in AWS IoT

Fleet Provisioning is the optimal solution for automating large-scale device provisioning processes, completely eliminating slow and error-prone manual registration operations. This method optimizes factory production by requiring only a single Claim Certificate for the entire batch instead of managing millions of individual certificates. Especially when combined with CSR mechanisms, security is maximized because the private key is generated and remains within the device, never needing to be transmitted over the network. Furthermore, management via Provisioning Templates allows administrators to flexibly configure identifiers, assign security policies, and group devices centrally from the cloud. Thanks to the automatic “registration” process upon initial power-on, devices can automatically switch to their own unique identifiers, ensuring seamless and secure unlimited system scalability.

3. AWS IoT Fleet Provisioning Templates Explained

What is Provisioning Template?

Fleet Provisioning Template is a JSON configuration file in AWS IoT that acts as a blueprint for automating resource provisioning for devices. When a device uses a claim certificate to call a provisioning API over MQTT or HTTPS on its first connection, the system executes this template to automatically identify and configure the device. Specifically, the template details how to create a Thing, issue a new Certificate, assign corresponding security policies, and establish a tight link between those components, making mass deployment secure and consistent without manual intervention.

In Fleet Provisioning, the Provisioning Template allows for:

  • Standardizing how devices are onboarded
  • Completely automating the Thing and certificate creation process
  • Ensuring all devices adhere to the same security policy
  • Reducing operational errors due to manual configuration

A provisioning template typically includes: Parameters (Parameters passed from the device, e.g., serial number, device ID); Resources, the AWS IoT resources created: Thing, Certificate, Policy attachment, Thing–Certificate attachment; Overrides (optional) allow overriding certain attributes when needed. The following is an example image of Provisioning Templates:

example template provisioning

Form Flow:

  1. Device send request provisioning: Call API ReateKeysAndCertificate or RegisterThing, after send parameters SerialNumber
  2. AWS IoT implement templates: Create Thing with the name by SerialNumber, create certificate and private key, assign policy for certificateAttach certificate in Thing.
  3. Device receive results: Receive production certificate, save certificate and private key, finally stop using claim certificate

When designing a Provisioning Template: ThingName should be associated with a serial number or unique ID, the Policy assigned to the device needs to have minimum access restrictions, the Claim certificate should only be used for provisioning, not for operation, and policies should be separated (Claim policy, Production device policy).

4. Implement of the Fleet Provisioning Application

The process flow diagram includes the following steps:

1. Initialization using a Claim Certificate: The device begins connecting to AWS IoT Core via a single Claim Certificate used for the entire production batch. At this step, the device sends a request to create a new identifier ($aws/certificates/create/json) to the system via MQTT/HTTPS, simplifying data loading at the factory.

2. Issuance and Storage of the New Certificate: AWS IoT Core receives the request and automatically generates a unique Certificate and Private Key signed by the AWS CA. After receiving this information, the device writes data to secure storage or via the topic ($aws/certificates/create/json/accepted) for use in subsequent official connections. The device receives the new certificate and writes this Certificate/Private Key pair to its secure storage.

3. Executing the Template and Activating the Identifier: The device sends a configuration activation request along with specific identifiers (such as Serial Number) to the Provisioning Template. Based on this design, AWS automatically creates a Thing, assigns it to the appropriate device group, and assigns corresponding security policies. Next, the device sends a configuration activation request to the topic: $aws/provisioning-templates/{template-name}/provision/json. In this step, it includes the device’s specific identifiers (such as Serial Number).

4. Switching to a Formal Connection: After receiving a successful assignment response, the device disconnects using the old Claim Certificate. Finally, it establishes a new connection using the newly received device certificate, officially joining the system with full privileges and a unique identifier. The successful result is sent back to the device via the topic: $aws/provisioning-templates/{template-name}/provision/json/accepted.

This process saves manufacturers time: instead of loading 10,000 different certificates for 10,000 devices, they only need to load a single identical Claim Certificate. AWS handles the identity separation when the device first goes online.

 

The core difference between Fleet Provisioning by Claim and Fleet Provisioning with CSR lies in where the Private Key is generated and managed.

1. Initial connection using a Claim Certificate: The device makes its first connection to AWS IoT Core using a Claim Certificate. This is a temporary certificate pre-installed for the entire fleet, giving the device basic access to the system topics necessary for registration.

2. Device generates the Key and submits the CSR: Instead of receiving the private key from the cloud, the device generates an internal public/private key pair. It then creates a CSR (Certificate Signing Request) and publishes this request to AWS via the topic `$aws/certificates/create-from-csr/json`. This ensures the private key never leaves the device, providing maximum security.

3. AWS Validation and Certificate Signing: AWS IoT Core receives the request, validates the Claim Certificate, and checks the accompanying policies. If valid, AWS signs the CSR to create a device certificate in .pem format and sends it back to the device via the /accepted topic.

4. Storage and Execution of Provisioning Template: The device receives the signed certificate and, combined with the available private key, writes it to secure storage. Next, it sends its specific identifiers to the Provisioning Template topic. AWS uses this template to automatically allocate resources, such as creating Thing Names, grouping, and assigning official permissions.

5. Completion and Official Connection: After AWS confirms the successful allocation process via the /accepted topic, the device enters its official operational state. From this point on, it temporarily disconnects and uses the unique device certificate it just received to establish a secure and permanent connection to the system.

5. Claim Certificate vs CSR: A Comparison in AWS IoT

compare claim certificate vs csr

Private Key Security

  • In the By Claim method, AWS acts as the creator. While convenient, it means the Private Key exists in transit (as an MQTT payload) before being written to the device’s secure storage.
  • In the With CSR method, the device generates the key. AWS only “stamps” (signs) the device’s public key. This aligns with strict security standards where the Private Key must remain permanently within a secure element or TPM.

Commonalities

  • Both methods begin by using a Claim Certificate to establish the initial “bootstrap” connection with AWS.
  • Both use a Provisioning Template to configure resources such as Thing Name, Policies, and Thing Groups once the unique identity is established.
  • The end result for both processes is that the device obtains a unique Device Certificate for its permanent connection, replacing the initial shared Claim Certificate.

Recommendation: If your hardware (like a Raspberry Pi or an STM32 with cryptographic library support) is capable, you should prioritize the CSR method to ensure the private key is never exposed.

6. Security Consideration for AWS IoT Fleet Provisioning

Security is a core element in Fleet Provisioning, especially when using Claim Certificates as a bootstrap mechanism for a range of devices. Claim certificates are not the device’s permanent operational identity; therefore, the policies associated with them must be kept to a minimum. Specifically, claim certificates should only be allowed to connect to AWS IoT Core and publish/subscribe MQTT topics for provisioning. They should absolutely not be allowed to access operational functions such as publishing telemetry data, manipulating Device Shadows, or performing OTA updates, to avoid the risk of abuse if the claim certificate is compromised.

Furthermore, the device’s private key needs to be strictly protected throughout its lifecycle. The creation and storage of the private key should be done in secure environments such as secure elements, modem key stores, or flash areas protected by TrustZone. The private key should not be printed to logs, transmitted externally in any form, or exposed through debug interfaces or internal APIs. This is a mandatory requirement to ensure the device’s identity cannot be tampered with.

To prevent device cloning, the provisioning process should associate certificate signing requests (CSRs) with unique hardware identifiers such as serial number, IMEI, or hardware ID. The backend can use this information to verify validity and detect unusual registration behavior, thereby preventing a valid certificate from being copied and used on multiple devices.

7. Conclusion – Why Fleet Provisioning is the Best Choice for Scalable IoT

Fleet Provisioning provides a powerful mechanism that simplifies and fully automates the onboarding of devices into AWS IoT. By separating the identity provisioning process from firmware and delegating much of the certificate management responsibility to AWS, Fleet Provisioning allows systems to easily scale up while maintaining high security and efficient device lifecycle management.

Thanks to these features, Fleet Provisioning is particularly well-suited for mass-produced IoT systems, including cellular devices, gateways, and Wi-Fi, where rapid deployment, cost optimization, and long-term operational stability are required. In the context of modern commercial IoT, Fleet Provisioning is not just a technical choice, but a best practice for large-scale AWS IoT systems.

Read More
NB-IoT: Principles and Architecture
January 23, 2026by Tuyền NguyễnTechnology

NB-IoT: Principles and Architecture

1.What is NB-IoT? – Overview of Narrowband IoT
2. NB-IoT Network Architecture
      2.1. LTE Access Network (eNodeB & Uu Interface)
      2.2. Core Network (MME, SGW, PGW)
      2.3. SCEF and Control Plane vs User Plane
3. NB-IoT Deployment Modes
4. NB-IoT Protocol Stack & Key Technologies
      4.1. Physical Layer & Key Technologies
      4.2. Power Saving Mechanisms: PSM & eDRX
      4.3. Data Delivery: IP vs NIDD 
5. Advantages and Limitations
6. NB-IoT Applications 
7. Comparison with Other 

1. What is NB-IoT? – Overview of Narrowband IoT

In recent years, the rapid development of the Internet of Things (IoT) has created an urgent need for communication technologies capable of connecting large numbers of devices with low power consumption and optimal operating costs. In this context, Narrowband Internet of Things (NB-IoT), standardized by 3GPP as an LPWAN technology operating on LTE mobile network infrastructure, targets IoT applications that do not require high data speeds but need reliability and long uptime.

NB-IoT is a Radio Access Technology (RAT) directly integrated into the LTE ecosystem, leveraging eNodeB base stations, the core network, and existing LTE security mechanisms. This technology can be deployed in three models: in-band, guard-band, and standalone, but in all cases utilizes a narrow 180 kHz bandwidth to optimize spectrum efficiency and reduce the transmission power of the end device.

One of the most important characteristics of NB-IoT is its coverage enhancement capability. Thanks to its narrow bandwidth, high power density, and transmission loop mechanism, NB-IoT achieves a Maximum Coupling Loss (MCL) of up to approximately 164 dB, allowing for good signal penetration in environments with high signal attenuation such as basements, concrete structures, or high-density urban areas. This characteristic makes NB-IoT particularly suitable for static IoT applications, large-scale deployments, and applications requiring stable connectivity over extended periods, even in locations where traditional mobile technologies struggle.

Furthermore, NB-IoT’s coverage is expanded by supporting low but stable uplink power, combined with optimized modulation and encoding for channels with high attenuation. This allows an NB-IoT base station to serve devices at the cell edge or in noisy environments while maintaining reliable communication. As a result, NB-IoT effectively meets the needs of deployment scenarios in hard-to-reach or inconvenient locations for maintenance, contributing to reduced operating costs and increased IoT system lifespan.

2. NB-IoT connection process

nb-iot structure

The Narrowband Internet of Things (NB-IoT) network architecture is a technical standard designed to connect a large number of smart devices with low power consumption and wide coverage. The core components of the system include:

  • NB-IoT Devices: These devices are typically smart sensors or metering devices (such as water or electricity meters) that support NB-IoT technology.
  • Electromagnetic Access Network (eNodeB): LTE base stations act as a wireless communication bridge between the devices and the core network.
  • Evolved Packet Core (EPC): This is the central hub where data packets are processed, subscribers are managed, and packet switching services are performed.
  • IoT Platform/Application Server: The endpoint where data is collected, analyzed, and services are provided to end users over the Internet.

NB-IoT systems have a distinct separation in how they handle communication protocols: First, non-IP transmission, meaning data from devices to the core network can be sent in raw form (NIDD – Non-IP Data Delivery) to optimize battery life and reduce device complexity. Second, with IP transmission, where data undergoes packet conversion (IP Packet Conversion) at the core network to ensure compatibility and transmission over standard internet environments. With this architecture, NB-IoT comprehensively ensures secure end-to-end communication from devices to application platforms; wide coverage with good penetration through walls and deep underground, suitable for urban or industrial environments; and large-scale connectivity leading to EPC core network systems designed to manage thousands of simultaneous connections across multiple sectors such as Smart Cities, Logistics, and Energy.

Based on the NB-IoT network architecture, we will delve into the details of the core technical components that enable this system to operate stably and securely. From wireless connectivity at the base station to data processing at the core network, each component plays a specialized role:

2.1. LTE Access Network (eNodeB & Uu Interface)

This is the first receiving layer in the model, responsible for establishing a physical connection with the device:

  • eNodeB (LTE Base Station): These are improved base stations based on the traditional LTE standard, optimized for NB-IoT. They manage radio signal transmission and reception, coordinate resources, and ensure wide coverage for thousands of devices in an area.
  • Uu Interface: This is the wireless connection interface between the device (UE) and the eNodeB. In NB-IoT, this interface is optimized to transmit small packets with extremely narrow bandwidth (Narrowband), minimizing interference and saving energy for the end device.

For example, this diagram shows: eNodeB (evolved NodeB), which are base stations in an LTE/NB-IoT network. In the diagram, the stations are numbered eNodeB#1, #2, #3, forming the radio access network; MME/S-GW: These are entities belonging to the Core Network. The MME manages control, while the S-GW manages user data flow. The interfaces include: Uu interface (not directly displayed by labels but implicitly) is the wireless connection between the device (UE) and the eNodeB stations; X2 interface: Solid lines directly connecting the eNodeB stations to each other. This interface is extremely important for handover and interference reduction coordination between stations; S1 interface: This is a dashed line connecting each eNodeB to the MME/S-GW. It is divided into two types:

  • S1-MME: Used for control signals (Control Plane).
  • S1-U: Used for user data (User Plane).

The entire cluster of eNodeBs and the X2 connections between them are collectively called E-UTRAN (Evolved Universal Terrestrial Radio Access Network). This is the “Access Network” that allows IoT devices to access the telecommunications network.

2.2. Core Network (MME, SGW, PGW)

The EPC (Evolved Packet Core) network acts as the “brain” coordinating the entire data flow:

  • MME (Mobility Management Entity): Responsible for managing mobility, authenticating devices when joining the network, and selecting appropriate service gateways for data transmission.

  • S-GW (Serving Gateway): Acts as a data forwarding anchor point between the wireless access network and the core network. It ensures that packets are correctly routed when devices move or change their connection state.
  • P-GW (PDN Gateway): Is the final connection point of the core network to external networks (Internet/ISP). P-GW performs tasks such as assigning IP addresses to devices (in the case of using IP) and enforcing Quality of Service (QoS) policies.

2.3. SCEF and Control Plane vs User Plane

These are the key components that help differentiate efficient data transmission methods in NB-IoT:

  • SCEF (Service Capability Exposure Function): A specialized component for non-IP IoT devices. SCEF allows the core network to securely transmit small amounts of data through the control plane, eliminating the need for complex IP data session setups.
  • Control Plane: Often used in NB-IoT to transmit even small application data (via NIDD). This is extremely efficient as it reduces redundant connection setup steps, maximizing battery life for sensors.
  • User Plane: The traditional IP-based data transmission path (CIOT Data Plane). It is typically used for applications requiring larger data volumes or standard network protocols when connecting to IoT platforms.

The coordination between these layers creates an end-to-end secure communication cycle, ensuring that data from even the simplest sensors can be securely transmitted to the centralized management platform.

3. NB-IoT Deployment Modes

simulation nb-iot modes

The frequency spectrum of NB-IoT technology allows carriers to flexibly optimize their existing infrastructure: Standalone utilizes a separate frequency band, Guard-band exploits the guarded gaps between carriers, and In-band integrates directly into the existing LTE bandwidth. Each mode has different advantages and disadvantages; for easy comparison, the features are summarized in detail in the table below:

table of nb-iot’s feature

4. NB-IoT Protocol Stack & Key Technologies

nb-iot protocol stack

This diagram illustrates how data and control commands are packaged and transmitted across different layers in an NB-IoT system to ensure synchronization between devices and network infrastructure. In the User Plane, the plane responsible for transmitting the actual user data between the device (UE) and the base station (eNB) is involved. Protocol layers include: PDCP (Packet Data Convergence Protocol) for header compression/decompression and data security; RLC (Radio Link Control) for data segmentation, reassembly, and ARQ error control; MAC (Medium Access Control) for scheduling and coordinating channel access; and PHY (Physical Layer) for transmitting physical signals over the radio space. On the other hand, in the Control Plane, this plane manages network connections, signaling, and control, involving three entities: the UE, the eNB, and the core network (MME). The additional layers include: NAS (Non-Access Stratum), the highest layer, which directly communicates between the UE and MME to manage mobility, authentication, and session establishment; RRC (Radio Resource Control), which manages the radio connection state between the UE and eNB (establishing, configuring, maintaining, and releasing connections); and the lower layers (PDCP, RLC, MAC, PHY), similar to the user plane but used to transmit control information instead of user data.

4.1. Physical Layer & Bandwidth

The physical layer of NB-IoT is specifically designed to optimize cost, energy, and extreme penetration capabilities. The system operates on a total bandwidth of 200 kHz, but actually utilizes 180 kHz, equivalent to a Resource Block in LTE. In terms of multiple access techniques, the downlink uses OFDMA with a subcarrier spacing of 15 kHz, while the uplink uses SC-FDMA supporting both single-tone (3.75 kHz or 15 kHz) and multi-tone (15 kHz) transmission.

In particular, coverage is significantly improved thanks to a Maximum Coupling Loss (MCL) of up to 164 dB, combined with packet repetition techniques to ensure accurate transmission even in extremely weak signal conditions such as deep basements. This process is operated through a system of dedicated physical channels including NPBCH for system information transmission, NPDCCH for control and scheduling, NPDSCH and NPUSCH for user data transmission for downlink and uplink respectively, and NPRACH to support initial network access procedures.

4.2. Power Saving Mechanisms: PSM & eDRX

These are two key mechanisms that enable NB-IoT devices to extend battery life to over 10 years:

  • PSM (Power Saving Mode): Allows the device to enter a deep sleep state while remaining registered with the network without needing to repeat complex connection procedures. In this mode, the device cannot be awakened by the network (Unreachable) until it actively sends data periodically.
  • eDRX (Extended Discontinuous Reception): Extends the signal checking cycle from the base station (Paging). Instead of continuous checking, the device only “wakes up” to listen for control signals during pre-configured intervals, significantly reducing power consumption compared to traditional DRX.

The core energy-saving mechanism of NB-IoT allows devices to operate for many years on a single battery. Below is a detailed description of the components in the diagram:

To optimize battery life for NB-IoT devices, the PSM and eDRX mechanisms play a key role in managing operating state and power consumption. PSM (Power Saving Mode) allows the device to enter a deep sleep state after completing the Tracking Area Update cycle, maximizing power savings because the device is completely unreachable from the network during this period. Meanwhile, eDRX (Extended Discontinuous Reception) extends the interval between device wake-ups for signal checking (paging), allowing the device to maintain a terminal reachable state more flexibly while significantly reducing power consumption compared to traditional check cycles. The seamless coordination between these two mechanisms helps the device balance data transmission and reception needs with the goal of extending battery life for decades.

4.3. Data Delivery: ID vs NIDD

NB-IoT offers two flexible data transmission methods depending on the application’s needs:

  • IP Data Delivery (ID): Data is encapsulated using standard IP protocols (such as IPv4 or IPv6), suitable for applications requiring high compatibility with existing Internet platforms and the transmission of larger volumes of data.

  • Non-IP Data Delivery (NIDD): Allows the transmission of raw data without the IP packet header; data is transmitted through the Control Plane via the SCEF entity, reducing packet size and maximizing battery life for the device. This is optimized for sensors sending extremely small data (a few tens of bytes) and enhances security because the device does not have a public IP address, helping to avoid common cyber attacks.

Unlike conventional IP data transmission (via SGW/PGW), this diagram accurately describes the NIDD route, enabling NB-IoT devices to maximize battery life and enhance security by not using public IP addresses. The presence of SCEF (Service Capability Exposure Function) is a core and unique component found only in the Non-IP data transmission route. It acts as a “gateway” to encapsulate raw data from the IoT device into control messages. Transmission via MME (Mobility Management Entity): In this diagram, data travels from eNB/gNB via the S1AP interface to the MME, then to the SCEF via the T6a interface. This route confirms that data is being transmitted on the Control Plane, a characteristic of the NIDD method for energy optimization. Connection to SCS/AS: After passing through the SCEF, data is transferred to the application platform (SCS/AS) via the T8 interface (based on HTTP). This is how devices without IP addresses can still communicate with servers on the Internet.

5. Advantages & Limitations

Advantages of NB-IoT

The main reasons for choosing NB-IoT connectivity, similar to LTE-M, include low power consumption, efficient spectrum utilization, and low deployment costs. These characteristics make NB-IoT particularly suitable for large-scale and long-term IoT systems.

Regarding power consumption, NB-IoT introduces two key power-saving mechanisms that give it an edge over older mobile networks like 2G, 3G, or 4G in IoT applications. Power Saving Mode (PSM) allows the device to enter a deep sleep state when not transmitting data, while maintaining its network subscription status. Unlike mobile phones – which need to maintain a constant connection to receive calls or messages – IoT devices typically transmit data only in defined cycles and require virtually no downlink. Therefore, they don’t need to send periodic Tracking Area Update (TAU) messages to inform the network of their location, significantly reducing power consumption. With PSM, the device can completely disconnect RF for extended periods without needing to repeat the attach procedure upon waking up.

For applications that still require network data reception capabilities, NB-IoT offers an Extended Discontinuous Reception (eDRX) mechanism. While conventional mobile devices must continuously check the radio channel in very short cycles, eDRX allows for extended paging listening periods of up to tens of minutes. This enables the device to still receive downlink messages such as configuration changes, firmware updates, or remote access, but with significantly lower power consumption compared to traditional DRX mechanisms.

NB-IoT is also designed to use spectrum efficiently. This technology operates on narrow bandwidths, reducing interference and enabling high device density deployment within the same cell. In addition to utilizing existing LTE bands, NB-IoT can also leverage guard bands – the portion of spectrum between LTE channels – to optimize radio resources. This approach allows carriers to expand the number of connected devices without significantly impacting the quality of service for traditional mobile users.

Indoor coverage, according to the Maximum Coupling Loss (MCL) index defined by 3GPP, NB-IoT achieves a theoretical MCL of up to 164 dB, higher than most other LPWAN technologies. This allows NB-IoT signals to penetrate thick building materials and operate stably in high-interference environments. However, to achieve this level of coverage, NB-IoT must use a packet repetition mechanism, leading to certain trade-offs in energy consumption.

LIST OF MCL LPWAN

In terms of cost, NB-IoT uses modems with a simpler architecture compared to broadband LTE or 5G, thereby reducing hardware costs and total cost of ownership (TCO). NB-IoT modems have high global compatibility, facilitating multinational deployments. However, in some cases, NB-IoT devices need to support backup technologies such as 2G when NB-IoT coverage is not yet available, which can increase chipset complexity and cost.

Limitations of NB-IoT

Despite its many advantages for static IoT applications, NB-IoT still has significant limitations, especially when compared to LTE-M, which need to be carefully considered before large-scale deployment.

6. Application of NB-IoT

NB-IoT is a LPWAN technology optimized for IoT scenarios with low data traffic, low transmission frequency, and long battery life requirements. By trading off speed, latency, and mobility, NB-IoT achieves deep coverage, high stability, and minimal power consumption. However, limitations in throughput, roaming, redundancy, and handover make NB-IoT unsuitable for real-time, mobile, or global deployments. Therefore, the selection of NB-IoT should be based on specific application characteristics, rather than viewing it as a universal IoT solution.

Thanks to its stable operation and energy efficiency, NB-IoT is particularly well-suited for large-scale, static IoT systems where each device transmits only a small amount of data over long cycles. Typical applications include smart metering (electricity, water, gas), environmental monitoring (air quality, water level, temperature), smart urban infrastructure (streetlights, parking lots), smart agriculture, and indoor or underground fixed asset tracking systems. In these scenarios, NB-IoT offers optimal efficiency in terms of operating costs, battery life, and long-term reliability.

7. Comparison between NB-IoT & LTE-M

NB-IoT and LTE-M are two LPWAN technologies developed by 3GPP to support large-scale IoT connectivity over mobile network infrastructure. In IoT systems, coverage plays a crucial role, especially for devices deployed indoors, underground, or at the cell edge.

NB-IoT is optimized for deep coverage thanks to its narrow 180 kHz bandwidth and transmission loop mechanism, achieving a Maximum Coupling Loss (MCL) of approximately 164 dB, suitable for static devices in environments with high signal loss. Meanwhile, LTE-M provides wider coverage with better mobile support, having an MCL of approximately 156 dB, suitable for both static and mobile scenarios.

Beyond coverage, the choice between NB-IoT and LTE-M also depends on factors such as speed and latency, mobility, power consumption, device cost, and roaming capabilities. These differences are summarized and compared in detail in following the table:

THE COMPARISON BETWEEN LTE-M VS NB-IOT

 

LTE-M is well suited for IoT applications that require mobility, lower latency, higher data rates, OTA firmware updates, voice support, and global roaming. NB-IoT is optimized for static IoT devices that transmit very small amounts of data, infrequently, and require deep coverage and multi-year battery life. Fundamentally, these two technologies do not directly compete, but rather complement each other within the Mobile IoT ecosystem.

 

Read More
CAN Bus Protocol
January 23, 2026by Tuyền NguyễnTechnology

CAN Bus Protocol

1. Introduction – CAN Protocol Overview
2. CAN Standard & ISO (11898-1, 11898-2, 11898-3)
3. Network Topology & Physical layer
4. CAN Frame Types
      4.1. Data Frame 
      4.2. Remote Frame
      4.3. Error Frame
      4.4. Overload Frame
5. Message fields & Arbitration
6. Error detection & Bus fault handing
7. CAN FD Overview
8. Higher layer protocols on CAN
9. Application
      9.1. CAN Bus (Classical CAN)
      9.2. CAN FD (Flexible Data rate)
10. Conclusion

1. Introduction – CAN Protocol Overview

CAN (Control Area Network) is a highly reliable multipoint serial communication standard first developed by Robert Bosch GmbH, Germany, in 1986 when they were asked by Mercedes to develop a communication system between three ECUs (electronic control units) in a vehicle. Although UART (Universal asynchronous receiver-transmitter) is a widely used protocol, it does not adequately meet the requirements of multi-node systems, high-noise environments, and the demanding reliability requirements of the automotive industry. CAN was designed to address these limitations. The CAN bus operates effectively in high electromagnetic interference environments with twisted pair CAN High and CAN Low wires combined with fault checking and automatic fault detection mechanisms. Devices within the same bus are called nodes; a system can add several nodes, ranging from a few hundred to several kilometers, while still ensuring signal transmission. A key feature of CAN is its ID-based prioritization (arbitration) mechanism, which allows messages to be transmitted earlier without causing data conflicts. It offers high-speed transmission rates of up to 1 Mbits/second to enable time-based control.

Based on Bosch’s technical specifications, version 2.0 of CAN is divided into two parts:

  • Standard CAN (Version 2.0A): uses an 11-bit ID (Identifier).
  • Extended CAN (Version 2.0B): uses a 29-bit ID.

The two parts are defined by different message IDs, with the main difference being the length of the ID code. There are two ISO standards for CAN. The difference lies in the physical layer: ISO 11898 handles high-speed applications up to 1 Mbit/second, and ISO 11519 has an upper limit of 125 kbit/second; larger data sizes meet the needs of modern systems. Thanks to these advantages, CAN buses are widely used not only in automotive but also in industrial, medical, aerospace, and automation fields.

2. CAN Standards & ISO (11898-1, 11898-2, 11898-3)

OSI Layers

The OSI (Open Systems Interconnection) reference model, proposed by ISO, aims to standardize data communication processes in network systems. The OSI model comprises seven layers, each responsible for a distinct function, from physical signal transmission to application-level data processing, enabling different systems to communicate compatiblely and efficiently.

In practice, not all communication protocols fully implement all seven layers of the OSI model. For embedded systems and industrial control networks, especially in the automotive sector, protocol architectures are often simplified to reduce latency, increase reliability, and meet real-time requirements. A typical example is CAN Bus (Controller Area Network); a serial communication protocol designed for distributed control systems where multiple nodes need to exchange data with high reliability and fast response times. CAN does not fully implement all seven OSI layers, but mainly focuses on the two lowest layers:

  • Physical Layer: defines the transmission medium, voltage levels, connection methods, and signal characteristics.
  • Data Link Layer: defines the transmission frame structure, bus access mechanism, error detection, and collision handling.

The remaining layers of the OSI model (Network, Transport, Application, etc.) are usually implemented through higher-layer protocols such as CANopen, J1939, or are defined by the manufacturer.

ISO 11898

To ensure the compatibility and stable operation of the CAN Bus in various environments, the CAN protocol has been standardized in the ISO 11898 standard. This standard details how CAN operates in relation to the layers of the OSI model, specifically:

  • ISO 11898-1: Specifies the Data Link Layer and Physical Signalling mechanism of the CAN protocol, which serves as the core of the CAN Bus architecture. This standard details the structure of the CAN transmission frame, including Data Frame, Remote Frame, Error Frame, and Overload Frame, and defines the bus access mechanism through a contention process based on the priority level of the identifier (ID). In addition, ISO 11898-1 also specifies error detection and handling methods such as CRC, bit stuffing, ACK acknowledgment mechanism and error counters, as well as bit synchronization and data transmission timing techniques. This standard supports both standard CAN with 11-bit identifiers and extended CAN with 29-bit identifiers, ensuring reliable communication between nodes in a CAN network, avoiding data conflicts, and automatically detecting errors during transmission.
  • ISO 11898-2 defines the Physical Layer for High-Speed ​​CAN, commonly known as High-Speed ​​CAN (HS-CAN), to meet the requirements of systems with high bandwidth and low latency. According to this standard, CAN can achieve transmission speeds up to 1 Mbps and uses differential twisted pair CAN_H and CAN_L to enhance noise immunity. The dominant and recessive states are distinguished by differential voltage levels, where CAN_H and CAN_L are approximately 3.5 V and 1.5 V respectively in the dominant state, and approximately 2.5 V in the recessive state. ISO 11898-2 requires the use of 120 Ω termination resistors at both ends of the bus to ensure signal quality, making this standard widely applied in critical control systems such as engine ECUs, ABS, ESP, and automotive drive and safety systems.
  • ISO 11898-3: Describes the physical layer for low-speed, fault-tolerant CAN, also known as Low-Speed ​​or Fault-Tolerant CAN, with the goal of maintaining system operation even in the event of a transmission failure. This standard supports a maximum transmission speed of 125 kbps and allows the CAN network to continue operating if one of the two transmission wires is broken. Unlike high-speed CAN, ISO 11898-3 does not require bus termination resistors and incorporates mechanisms for detecting and isolating faulty nodes to improve system reliability. Thanks to these characteristics, CAN according to ISO 11898-3 is often used in vehicle systems such as door, window, and light control, and applications that do not require high speed but need stability and safety in harsh working environments.

Thus, ISO 11898 serves as a bridge between the OSI model and the practical implementation of CAN Bus, helping to clearly define which layers CAN operates at and ensuring standardization in modern embedded systems and control networks.

3. Network Protocol & Physical layer

In a CAN Bus system, nodes are connected using a bus topology, where all devices share a common transmission line. Each node is connected in parallel to the bus via a pair of CAN_H and CAN_L wires, allowing multiple nodes to participate in communication without a central control device. This topology reduces the number of connecting wires, simplifies the system, and increases scalability. Bus access is controlled by non-destructive arbitration, ensuring that high-priority messages are transmitted first without losing data from other nodes.

Bus Topology model

At the physical layer, the CAN Bus uses differential signaling via two lines, CAN_H and CAN_L, to enhance electromagnetic interference resistance. In the recessive state (logic ‘1’), the voltages on the CAN_H and CAN_L lines are approximately equal and usually around the common-mode voltage, around 2.5 V. When transmitting a dominant bit (logic ‘0’), the transmitter creates a voltage difference between the two lines, where CANH is pulled up to a higher voltage level and CAN_L is pulled down to a lower voltage level. The receiver does not rely on absolute voltage values ​​but decodes data based on the differential voltage difference between CAN_H and CAN_L, helping the CAN system operate stably in high-noise environments such as automotive and industrial applications.

The figure below illustrates the principle of differential signal transmission and reception in the CAN Bus at the physical layer, showing the block structure of the CAN transmitter circuit, the CAN_H and CAN_L voltage waveforms corresponding to the dominant and recessive states on the bus, as well as the operating principle of the receiver circuit based on the differential voltage comparator. Through this mechanism, the CAN Bus ensures reliable information transmission while effectively supporting bus contention and error detection.

The principle of differential signal transmission and reception of the CAN Bus at the physical layer

Furthermore, to ensure signal quality during transmission, CAN Bus requires the use of termination resistors, typically 120 Ω, placed at both ends of the bus. These resistors reduce signal reflections and maintain stable transmission impedance. Bus length and transmission speed are inversely proportional; as transmission speed increases, the allowable bus length decreases. Thanks to the combination of a simple bus topology model and a physical layer using differential communication, CAN Bus achieves high reliability, good noise immunity, and is widely used in embedded systems, especially in the automotive field.

4. CAN Frame Types

4.1. Data Frame

frame data of can

A CAN data frame is the basic communication unit on the CAN bus, used to exchange information between nodes in the system. A CAN frame begins and ends when the bus is idle, ensuring all nodes are ready for data transmission.

The data frame starts with the SOF (Start Of Frame) field, which includes a dominant bit used to synchronize all nodes on the bus and signal the start of a new data transmission session.

Next is the Arbitration Field, which determines the priority level of a message when multiple nodes are transmitting simultaneously. This field contains the Identifier (ID) and the RTR (Remote Transmission Request) bit. The illustration shows both CAN formats: standard with an 11-bit ID and extended with a 29-bit ID. In the arbitration mechanism, messages with smaller IDs have higher priority and are transmitted first without collisions.

Next is the Control Field, which includes bits identifying the frame type (IDE), reserve bits, and DLC (Data Length Code). The DLC indicates the number of bytes of data transmitted in the Data Field, up to 8 bytes for the CAN 2.0 standard.

The Data Field contains the actual information content of the message. Depending on the DLC value, this field can be from 0 to 8 bytes long. This is the main payload used by ECUs to exchange status, control commands, or sensor data.

To ensure data integrity, the CAN frame includes a CRC Field, which contains the CRC error check code. The receiving node recalculates the CRC and compares it to the received CRC to detect errors during transmission.

Next is the ACK Field. If a node receives valid data, it pulls the bus down to the dominant level to send an acknowledgment signal. Failure to receive an ACK will cause the transmitting node to automatically retransmit the message.

The data frame ends with EOF (End Of Frame), a 7-bit recessive, marking the end of the transmission. This is followed by Intermission, a short pause required before any new CAN frames can be sent.

4.2. Remote Frame

Besides Data Frames used for data transmission, Remote Frames are used to request data from any node on the same bus. However, remote frames are rarely used in automotive projects because data transmission is not request-based but primarily proactive, relying on information from the car’s specifications. Similar to Data Frames, the frame is clearly marked as a Remote Frame via the RTR bit, and this frame does not have a data field. Depending on the CAN network implementation, responses may be sent automatically. Simple CAN controllers (BasicCAN) cannot respond automatically. In this case, the Master microcontroller recognizes the remote request and must send data proactively.

4.3. Error Frame

Error Frames are distinctly different from CAN framing rules. They are transmitted when a node detects an error and will cause other nodes to detect the error as well, so they will also send this frame; the transmitter then automatically retransmits the message.

4.4. Overload Frame

Overload Frames are mentioned here for completeness only. They are very similar to Error Frames in format and are transmitted by a node when that node is too busy. Overload Frames are not used frequently, as modern CAN controllers are  smart enough not to use them. In fact, the only controller that would generate an Overload Frame is the now-obsolete 82526.

5. Message fields & Arbitration

In the CAN Bus protocol, data is transmitted as message frames (CAN messages), where each message carries both application data and bus access priority. Unlike node-addressed protocols, CAN uses message-based communication, meaning the message content is determined by an identifier (ID), and any node on the bus can receive the message if that ID matches its configuration.

The arbitration mechanism (bus contention) is a key feature of the CAN Bus, allowing multiple nodes to start transmitting at the same time without data loss. Arbitration takes place in the Identifier field of the CAN frame and is based on the principle of bit-wise non-destructive arbitration. During transmission, each node both transmits its data and monitors the actual state of the bus. Due to the physical characteristics of the CAN Bus, the dominant bit (logic ‘0’) always overwrites the recessive bit (logic ‘1’). When a node transmits a recessive bit but reads a dominant bit on the bus, that node immediately recognizes that it has lost bus access and will stop transmitting, entering a waiting state to try again when the bus is free.

The diagram illustrates the arbitration process when multiple CAN nodes simultaneously transmit messages. At the beginning bits of the Identifier field, the nodes transmit the same value, so the arbitration process continues. When a difference appears at a certain bit position, the node transmitting the recessive bit will be excluded from the dispute, while the node transmitting the dominant bit will continue transmitting. As a result, the message with the smaller binary Identifier will gain bus access and be transmitted completely first.

Illustrating the CAN Bus arbitrage mechanism based on the Identifier field

Thanks to this non-destructive arbitration mechanism, CAN Bus ensures that high-priority messages are always transmitted first without data retransmission, while maintaining the reliability and determinism of the system. This is why CAN Bus is widely used in real-time systems such as automotive control networks and industrial automation, where ensuring the order and latency of communication is crucial.

6. Error detection & Bus fault handing

Bit Error

bit error by transmitted

In the CAN protocol, every time a node transmits a bit onto the bus, it simultaneously “reads back” the bus’s state at that moment. In principle, if the transmitted value (TX) differs from the received value (RX), a Bit Error is detected. In the diagram above, the node is sending bit 1 but reading bit 0, which triggers a bit error. Bit errors can occur due to several reasons:

  • Arbitration Process: This is the normal scenario; if two nodes transmit simultaneously, the node transmitting bit 0 (higher priority) will prevail over the node transmitting bit 1. When the node transmitting bit 1 sees a 0 on the bus, it understands it has “lost” the priority claim and stops transmitting to yield the right of way.
  • Physical Fault: If this occurs in the data field or areas not eligible for adjudication, it could be due to: the CAN line is short-circuited to ground or power, excessive electromagnetic interference (EMI) causes voltage levels to fluctuate across the bus, the transceiver is broken.

When this error is detected (except during the arbitration phase), the node detecting the error will immediately send an Error Flag to notify all other nodes on the network that the current data is no longer trustworthy and needs to be retransmitted.

Stuff Error (Stuffing Error)

stuff error by receiver

To ensure that receivers can maintain synchronization with transmitters, the CAN protocol uses Bit Stuffing: This rule states that after every 5 consecutive bits with the same logic level (all 0 or all 1), the transmitter automatically inserts a reverse-biased bit to create “edges” (voltage level transitions) so that other nodes can readjust their internal clocks, avoiding clock misalignment when encountering a long, constant data stream.

This error occurs when a receiving node detects 6 consecutive bits with the same logic level on the bus (in areas where bit stuffing rules are applied, such as SOF to CRC). In your image, the bit sequence is 00000 (5 bits of 0), then instead of a stuff bit of 1, the bus displays consecutive 1 bits or other errors that violate the rule. When there are 6 bits of the same level (like the red “Discarded Data” segment), the receiving node identifies this as a Stuffing Error.

When a Stuffing Error is detected, the node will send an Error Frame to discard the current message: Error Frame Introduction: The moment the node detects the error and begins inserting error flags onto the bus.

  • Active Error (6-12 bits): If the node is in the “Error Active” state, it will send 6 consecutive Dominant bits (level 0). Because other nodes will also see this 6-bit sequence as violating the Bit Stuffing rule, they will also send their own Error Flag, creating a sequence of 6 to 12 bits on the bus.
  • Passive Error: If the node is in the “Error Passive” state (has encountered many errors before), it will send 6 Recessive bits (level 1). This does not interrupt the bus if other nodes are still operating normally. Delimiter (8 bits): After sending the error flag, the node will send an 8-bit Recessive (level 1) to signal the end of the error frame and prepare for retransmission.

As soon as an Error Frame appears, all previous data in the frame (Data Frame) is considered invalid and discarded by the receiving nodes. The transmitting node will have to retransmit the entire message from the beginning after the connection is stable again.

CRC Error

CAN Node 1 (Transmitter): The node that sends the message. It calculates a value based on the data content and sends it as a CRC Sequence (the transmitted value is X). CAN Node 2 (Receiver): The node that receives the message. Upon receiving the data, it performs a similar mathematical calculation on the received bits to produce the result Y (Calculated message CRC = Y). CAN Bus: The physical transmission medium where the CRC signal is transmitted.

CRC errors are detected at the receiver when the data is altered during transmission: If there is no interference, the value X (sent) should equal the value Y (recalculated). However, if one or more data bits are altered due to electromagnetic interference, the calculated value Y will differ from X. The image caption reads: “CRC Error (CRC value not equal to calculated CRC by receiver)”. This means that when X differs from Y, the receiving node identifies this as a CRC error. One key difference between CRC errors and other errors is the timing of their detection and processing:

  • DEL (Delimiter) area: CRC errors are only checked after the entire CRC string has been received, specifically at the CRC Delimiter (CRC separator bit) location.
  • Response: Immediately after the DEL bit, if the node detects an error, it will not send an ACK (Acknowledge) bit but instead will send an Error Frame to request the transmitting node to resend the data.

Acknowledgment Error (ACK Error)

Unlike other communication protocols, in a CAN network, the receiver is responsible for confirming receipt of the data in the correct format. The transmitter sends a Recessive bit (level 1) at the ACK slot. Then, at the receiver, all nodes that receive the correct message (passing the CRC check) simultaneously pull their bus down to the Dominant level (level 0) at that moment to confirm receipt.

The diagram illustrates the contrast between the transmitted and received signals on the bus:

  • Transmitted Ack (Recessive Bit): This is the signal from the transmitting node. It lets the bus go loose (level 1) and “listens” to see if any node acknowledges the connection.
  • Received ACK (Dominant): This is the actual state on the CAN Bus. When at least one other node receives the data, it overwrites the bus with a 0.
  • Normal result: The transmitting node reads back and sees level 0 (Dominant) even though I sent level 1 → Communication successful.

An ACK Error is acknowledged by the transmitting node when the transmitting node sends a Recessive (1) bit in the ACK slot but upon rereading the bus it is still at the Recessive (1) level, which means that no node on the network acknowledges receipt of that message.

Form Error

An error occurs when the structural components within a CAN data frame are misaligned at the logical level. In the CAN protocol, there are certain positions that must be Recessive bits (level 1) to mark the separation of message parts. A Form Error occurs when a receiving node detects a Dominant bit (level 0) at one of these fixed positions.

In your image, the specific error is indicated as:

Dominant CRC Delimiter: By standard, the DEL (Delimiter) bit immediately following the CRC sequence should always be a 1 (Recessive).

Phenomena: Both CAN node 1 (transmitter) and the CAN bus are displaying a 0 (Dominant) bit at this DEL position. Therefore, the system identifies this as a formatting error.

In addition to the CRC Delimiter position shown in the image, formatting errors can also occur at:

  • ACK Delimiter: The delimiter bit after the acknowledgment slot (ACK Slot).
  • End of Frame (EOF): A 7-bit Recessive sequence that ends a frame.

Similar to other errors, when a node detects a Form Error: It will transmit an Error Frame starting from the next bit.

The message being transmitted will be discarded: The transmitting node will increment the error counter and prepare to retransmit the message.

Bus Fault Handling 

When an error is detected on the CAN bus, the system reacts immediately to protect data integrity and maintain network stability. CAN supports automatic error detection and a hierarchical fault-handling mechanism, enabling nodes to quickly detect anomalies and prevent faulty frames from propagating on the bus.

As illustrated in the figure, when a bit error or stuff error occurs, a node in the error-active state transmits an Active Error Flag, which interrupts the current frame and forces a retransmission. At the same time, the node’s Transmit Error Counter (TEC) is incremented, reflecting the severity of the error.

If the accumulated error count exceeds the predefined threshold, the node transitions to the error-passive state. In this state, the node transmits only a Passive Error Flag (recessive bits), reducing its impact on the bus while still allowing it to participate in communication. If subsequent transmissions are successful, the TEC gradually decreases, enabling the node to recover and return to the error-active state.

This mechanism demonstrates that CAN not only detects transmission errors but also automatically isolates and recovers faulty nodes, ensuring that correctly operating nodes can maintain stable communication. As a result, CAN achieves high reliability and is particularly suitable for safety-critical and real-time systems.

7. CAN FD Overview

CAN is short for ‘Controller Area Network’, and CAN FD is short for CAN with Flexible Data rate. Controller area network is an electronic communication bus defined by the ISO 11898 standards. In 2015 these standards were updated to include CAN FD as an addition to the previous revision, and the new reference number ISO 11898-1:2015(E) was assigned. The standard is written to make the information unambiguous, which unfortunately makes it hard to read because there are no extended descriptions or examples. The information in this tutorial is less formal, and designed to be easier to understand.

Collectively, this system is referred to as a CAN network, with Classical CAN and CAN FD as different Frame Formats supported by the standard.

This diagram provides a visual comparison between two data transmission framework standards in control networks: Classical CAN and CAN FD. Below is a detailed description of the components:

8. Higher layer protocols on CAN

figure 1: data processing

The CANOpen device model is a standardized architecture that enables embedded devices to communicate uniformly within an industrial network. This architecture comprises three core components:

  • The Application Layer: This is where application programs run and device profiles are executed to process data directly from physical input/output ports (Process I/O).
  • The Object Dictionary: This acts as the central data management hub, storing communication objects, manufacturer objects, and device specifications.

Communication Services: This area is responsible for encapsulating and transmitting data over the CAN network using specific protocols such as PDO for real-time data transmission, SDO for configuration, and network management services like NMT, Heartbeat, and SYNC.

The entire model allows for the management of up to 127 nodes (Node-IDs) on the same network, creating high flexibility and compatibility between devices from various manufacturers.

In complex network control systems, the combination of device model and identification structure plays a crucial role in the stable operation of the entire system. Specifically, the CANopen device model provides a logical framework comprising the Application layer, Object Dictionary, and Communication Services to standardize how a device processes data. However, for these devices to accurately “identify” each other on the network without conflicts, the system needs an electronic “identity card” such as the NAME Field identification structure (according to the J1939/ISOBUS standard).

figure 2: identity verfication

Through this 64-bit string, information from the application layer such as device function, manufacturer code, and unique identifier number is tightly encapsulated. This connection allows communication services in the CANopen model to use detailed identifiers to perform automatic address claiming, making it easy for devices to integrate and communicate in real time as soon as they connect to the system.

figure 3: the information to its correct destination

 

The CAN network communication system is a close coordination between device architecture, identity, and communication method:

First, the CANopen device model establishes the internal logic foundation, where data from the Application layer is managed in the Object Dictionary and ready to be transmitted through Communication Services. For a device to join the network, it needs a unique “identity” – a 64-bit NAME field. This structure contains information such as the Manufacturer Code and Function, allowing the device to automatically establish its identity and obtain a unique Source Address without conflict.

Finally, when the actual data is sent, the 29-bit Identity Framework directly coordinates the information on the transmission path. Here, the established source address is combined with the Priority and the number of Parameter Groups (PGNs) to precisely define the data type and destination. This linkage creates a complete cycle: from data processing at the device (Figure 1), identity verification (Figure 2), to shipping labeling to deliver the information to its correct destination (Figure 3).

9. Applications

9.1. CAN Bus (Classical CAN)
  • CAN Bus (Classical CAN) – Automotive: CAN buses are widely used in automobiles to transmit data between ECUs such as the engine, ABS, airbags, transmission, and instrument cluster. For example, data from the Engine Control Unit can be transmitted to the Transmission, ABS, and Dashboard to control and monitor vehicle operation. The biggest benefit is reducing the number of wires in the vehicle and ensuring reliability through bus arbitration and error detection.

  • CAN Bus – Industrial Automation: In industrial automation, CAN connects PLCs, sensors, and actuators. Typical applications include industrial robots, conveyors, and CNC machines. For managing more complex data, higher-layer protocols such as CANopen and DeviceNet are used, making device synchronization and management easier.

  • CAN Bus – Medical Devices: Medical devices such as diagnostic imaging machines or patient monitors use CAN to transmit real-time data. CAN ensures accurate data with low latency, meeting stringent safety and reliability requirements.

  • CAN Bus – Maritime & Aviation: In ships and UAVs, CAN is used to monitor and control engine, radar, and GPS systems. It provides stable communication, is resistant to electromagnetic interference, and is suitable for industrial or maritime environments.
  • CAN Bus – Building Automation: CAN is also applied in smart building control, such as HVAC, lighting, and security systems. Thanks to its stable and robust communication capabilities, CAN helps reduce signal errors and increase reliability for automation systems.
9.2. CAN FD (Flexible Data rate)
  • CAN FD – Automotive & High Data Applications: CAN FD (Flexible Data Rate) is an upgraded version of CAN, supporting larger frames (64 bytes) and higher transmission speeds. In modern automobiles, CAN FD is used to transmit data from cameras, radar, lidar, and infotainment systems. For example, ADAS (Advanced Driver Assistance Systems) systems use CAN FD to ensure real-time data, reduce the number of frames to be transmitted, and increase processing speed.
  • CAN FD – Industrial Automation & High Throughput: In industry, CAN FD helps transmit multiple sensor and actuator data in a single frame, reducing latency and increasing system response speed. This is crucial for industrial robots, CNC machines, or devices requiring real-time data.

  • CAN FD – ADAS & Autonomous Vehicles: CAN FD is the optimal choice for autonomous vehicles and advanced driver assistance systems where data from cameras, radar, and lidar needs to be transmitted continuously at high volumes. The large frame size and high speed of CAN FD ensure that data is processed promptly and accurately.
  • CAN FD – Medical & Electric/Hybrid Vehicles: CAN FD is also used in MRI, CT, or multi-sensor monitoring devices where large amounts of image or data need to be transmitted quickly. In electric or hybrid vehicles, CAN FD helps manage the battery (Battery Management System) and sensors, transmitting battery status, temperature, and current data safely and at high speed.

10. Conclusion

CAN (Controller Area Network) is widely used because it provides reliable, fast, and cost-effective data communication. With its arbitration and error detection mechanisms, CAN ensures that critical data in embedded systems or vehicles is transmitted accurately and consistently, even in noisy environments.

One major advantage of CAN is its scalability and multi-node capability, allowing many devices to communicate on a single bus without excessive wiring, reducing cost and system complexity. Furthermore, with higher layer protocols such as CANopen, J1939, or DeviceNet, CAN not only transmits data but also supports device management, synchronization, and advanced fault handling, making it suitable for automotive, industrial, medical, and automation applications.

The advanced CAN FD provides larger data frames and higher data rates, meeting the demands of modern applications such as ADAS, electric/hybrid vehicles, industrial robots, and medical imaging systems. In summary, CAN is an ideal choice for any embedded system that requires high reliability, speed, and scalability.

Read More
BLE security – Security platform for modern IoT devices
January 20, 2026by Tuyền NguyễnTechnology

BLE security – Security platform for modern IoT devices

1. Why is security necessary in BLE?
2. Security mode & Security Procedure in BLE
3. Authentication, encryption and delegation
4. Example – BLESA Attacks
5. Project on nRF52/nRF5340
6. Conclusion

1. Why is security necessary in BLE?

The widespread adoption of Bluetooth Low Energy (BLE) has played a key role in driving the development of IoT devices, wearables, and smart healthcare systems, bringing unprecedented levels of convenience and connectivity to modern life. With its advantages of low power consumption, reasonable deployment costs, and support across most popular platforms, BLE has quickly become the default choice for billions of connected devices globally. However, alongside this rapid growth are increasingly serious concerns about security and privacy.

Notably, most security risks associated with BLE do not stem from inherent weaknesses in the protocol itself, but rather primarily from how it is implemented in practice. The pressure to shorten time to market, coupled with the complexity of a Bluetooth specification spanning thousands of pages, sometimes forces developers and manufacturers to compromise between convenience, cost, and security. As a result, many critical security mechanisms are either inadequately configured or even omitted, creating subtle but potentially exploitable vulnerabilities.

In the context of Bluetooth Low Energy becoming an increasingly fundamental infrastructure in digital life—from personal devices and healthcare systems to industrial applications and smart infrastructures—understanding, implementing, and comprehensively evaluating BLE security mechanisms is no longer an option, but a necessity. Only when security is properly addressed from the design stage can BLE fully fulfill its role as a secure, reliable, and sustainable connectivity technology for the modern IoT ecosystem.

2. Security mode & Security Procedure in BLE

BLE security is built on two core concepts:

  • Security Mode: defines the overall security strategy, i.e., the level of protection a connection or data requires.
  • Security Procedure: the specific technical mechanisms used to implement that strategy.

In other words, the security mode determines “how much protection is needed,” while the security procedure answers “how to protect it.”

Security Mode 1 focuses on securing BLE connections through pairing and encryption. This mode includes four levels of security:

  • Level 1: No authentication, no encryption – convenient but not secure.
  • Level 2: Unauthenticated pairing with encryption (Just Works) – common but not MITM-protected.
  • Level 3: Authentically authenticated pairing with encryption – MITM-protected through password entry or OOB.
  • Level 4: LE Secure Connections – uses ECDH and a 128-bit key, the highest level of security.

Imagine an attacker being able to secretly modify the on/off switch of a communication device. This represents a potential Man-in-the-Middle (MITM) attack. Authentication helps protect against MITM by ensuring that each participating party can verify the other party’s identity cryptographically. In the BLE world, when you connect your smartphone to an IoT device for the first time, you might encounter a “pairing” pop-up window. Once the two devices are paired, they permanently save the settings and become “linked,” eliminating the need to re-pair each time they attempt to connect.

Passive eavesdropping and Man-in-the-Middle attacks are two of the most common types of cyberattacks involving hacking BLE modules. BLE networks can be attacked through passive eavesdropping, allowing an outside device to intercept data exchanged between devices. For example, an attacker could eavesdrop on data provided by industrial peripheral sensors to a central controller to discover new security vulnerabilities in the system. BLE modules using BLE Secure connections are, by default, protected against passive eavesdropping.

In MITM attacks, an alien device simultaneously assumes both central and peripheral roles, tricking other devices on the network into connecting to it. This can become a problem in large manufacturing complexes because the alien device can inject forged data into the data stream and disrupt the entire production chain. BLE Secure connections offer security against passive eavesdropping, but man-in-the-middle attacks can only be prevented with the right pairing techniques.

The level of security achieved largely depends on the device’s I/O capabilities and the trade-off between user experience and system security. Beyond connection security, BLE also supports data protection in specific contexts:

  • Security Mode 2: uses connection-based data signing to ensure data integrity and authenticity, even without link encryption. This mechanism relies on CSRK and MAC keys to detect spoofing and replay attacks.
  • Security Mode 3: applies to broadcast data, enabling broadcast data encryption using Broadcast_Code, particularly important for modern BLE broadcast applications (Bluetooth 5.4+).

3. Authentication, encryption and delegation

Bluetooth Low Energy security is built on three core mechanisms: authentication, encryption, and authorization. These three layers of protection work closely together to ensure that only legitimate devices can connect, that transmitted data is not exposed or modified, and that resource access is properly controlled.

Authentication in BLE verifies the identity of the connected devices, thereby preventing spoofing and MITM attacks. Authentication is performed during the pairing phase and may require user interaction through mechanisms such as password entry, number comparison, or Out-of-Band (OOB). Specifically, from BLE 4.2 onwards, the LE Secure Connections mechanism utilizes Elliptic Curve Diffie-Hellman (ECDH), enhancing MITM resistance and becoming the recommended authentication platform for modern BLE devices.

Encryption plays a crucial role in protecting data throughout wireless communication. After successful pairing, BLE devices generate secret keys and use the AES-CCM algorithm to encrypt the link, ensuring that data cannot be eavesdropped on or modified by third parties. Encryption helps protect not only application data but also the security keys exchanged during the connection, which is especially important for IoT and medical devices transmitting sensitive data.

Authorization is the next layer of protection after authentication and encryption, focusing on controlling resource access. In BLE, authorization is typically implemented at the GATT layer, where each service or characteristic may require a different level of security, such as only allowing read or write access when the connection is encrypted or authenticated. This mechanism ensures that even if a device has successfully connected, it can only access the resources it has been authorized to access.

The effective combination of authentication, encryption, and authorization determines the true security level of a BLE system. In practice, many security incidents stem not from a lack of these mechanisms, but from misconfiguration or inadequate use, highlighting the importance of thoroughly understanding and correctly implementing BLE security principles from the design stage.

4. Example – BLESA Attacks

A prime example demonstrating the serious weaknesses of Bluetooth Low Energy, even with standard encryption mechanisms, is the BLESA (Bluetooth Low Energy Spoofing Attack) vulnerability, disclosed at the USENIX WOOT 2020 conference. According to the authors from Purdue University and EPFL, BLESA exploits the BLE reconnection mechanism – a feature designed to reduce latency and save energy for previously paired devices. In this scenario, the BLE standard does not require re-authentication of device identity during reconnection, allowing an attacker to impersonate a legitimate peripheral device and send forged data to the central device.

It is noteworthy that BLESA does not require encryption, does not require retrieval of the secret key, and does not rely on hardware errors. Instead, the attack exploits ambiguities in the BLE specification, allowing BLE stacks to implement reconnection mechanisms in various ways, some of which are insecure. Research indicates that BLESA can be successfully implemented on popular BLE implementations, including Linux BlueZ, as well as BLE stacks on Android and iOS, where the research team discovered logic flaws that allow the central device to accept connections from spoofed devices. These findings have been officially confirmed by Google and Apple, demonstrating the actual impact of the vulnerability.

transmission mechanism

According to the article, BLESA is particularly dangerous in common IoT scenarios such as wearables, medical sensors, and smart devices, where reconnection occurs frequently and completely automatically. Given that BLE is being used on billions of devices globally (estimated to reach over 5 billion BLE devices by 2023), BLESA demonstrates that secure initial pairing is insufficient. Without additional measures such as GATT access control, application-layer authentication, or reconnection limitations, a BLE device can still be compromised without the user’s knowledge.

The BLESA case highlights a crucial fact: BLE security depends not only on the encryption algorithm but also heavily on how the standard is implemented and configured in practice. This clearly demonstrates that serious vulnerabilities in BLE can stem from protocol design and connection logic, rather than from cryptographic algorithms, and further underscores the need for comprehensive BLE security assessments, especially in large-scale IoT ecosystems.

5. Project on nRF52 / nRF5340

Pairing & Bonding (Zephyr / nRF SDK)

  • Turn on LE Secure Connections
  • Require MITM protection

Protect GATT characteristic

Bluetooth Security Manager Protocol

On nRF5340, CPUAPP handles the entire BLE security stack, allowing the combination of BLE + Secure DFU + TrustZone to build a multi-layered security system.

6. Conclusion

Only when properly implemented is Bluetooth Low Energy truly a secure wireless communication standard. Throughout the entire BLE connection lifecycle, the pairing phase remains the most sensitive point in terms of security, but it can be effectively protected if the correct pairing model and authentication mechanism are applied. Common threats such as man-in-the-middle attacks or passive eavesdropping mainly stem from weak security configurations, rather than from the BLE protocol itself.

In the development of IoT applications, the choice of hardware and software platforms plays a crucial role in the system’s security. SoCs like the nRF52 and nRF5340 provide all the necessary hardware security features for modern BLE, including LE Secure Connections, accelerated AES encryption, ECDH support, secure memory, and secure boot. When combined with properly deployed BLE stacks and tight coupling processes, these platforms enable the construction of energy-efficient and highly secure IoT systems in fields such as wearables, healthcare, industry, and smart homes.

For businesses considering deploying an IoT ecosystem, understanding and correctly applying security principles from the foundational level is essential. A secure IoT architecture must be built on reliable hardware and correctly configured protocols from the outset. In fact, it is common design and implementation vulnerabilities – not complex encryption algorithms – that cause the majority of serious security incidents and commercial losses.

Read More
How to build an image for STM32MP135
January 14, 2026by Tuyền NguyễnTechnology

How to build an image for STM32MP135

1. Yocto Project in STM32MP135 
2. Environment setup
3. Add a new custom machine to Yocto
4. Add STMicroelectronics Layers to Yocto

1. Yocto Project in STM32MP135

In modern embedded Linux systems, the ability to tailor the operating system to specific hardware platforms is essential for optimizing performance, resource usage, and system reliability. The Yocto Project provides a powerful and flexible framework for building custom embedded Linux distributions that are reproducible, scalable, and maintainable.

This article describes the process of building a minimal embedded Linux system for the STM32MP135 processor on a custom System-on-Module (SOM). The workflow covers environment setup, Yocto Project configuration, custom machine integration, and image generation, enabling a reliable Linux platform tailored to the target hardware.

2. Environment setup

The system was developed on Ubuntu 22.04 LTS, the version recommended by Yocto and STMicroelectronics.

Before starting, you need to update your system to avoid library conflicts:

Yocto requires several tools for cross-toolchain, kernel, and rootfs builds. Important packages include:

  • Compiler & build tools
  • Python 3 and related modules
  • Filesystem and image handling utilities

Installing all these packages ensures a stable build process, especially for initial builds. Packages required by OpenEmbedded/Yocto:

STMicroelectronics recommends using the en_US.UTF-8 locale to avoid errors during the build process:

3. Add a new custom machine to Yocto

1. Download Yocto

Go to the address: $HOME/yocto-labs/

Download the scarthgap version of Poky:

2. Download STMicroelectronics Layers

Go to the yocto-labs directory, download meta-openembedded and meta-st-stm32mp layers:

3. Add new custom machine

Download the patch file to $HOME/yocto-labs/ and apply it

The patch adds a new custom machine (stm32mp1-ies) to the Yocto project. The patch performs the following tasks:

  • Adds a new custom machine configuration to the meta-st-stm32mp layer
  • Introduces a custom device tree for the new machine in the appropriate recipes, including:
    – Trusted Firmware-A – U-Boot
    – Linux kernel
    – OP-TEE
4. Activate the build environment

Export all needed variables and set up the build directory:

4. Add STMicroelectronics Layers to Yocto

Added new layers to Yocto: In the build/conf/ directory, edit the bblayers.conf file. Initially, the file contains the following layers:

Add the following three layers to enable OpenEmbedded and STM32MP support:

After the update, the bblayers.conf file should look like this:

1. Choose a target machine

You must specify which machine is your target (currently we use stm32mp1-ies). Go to $HOME/yocto-labs/build/conf/local.conf and set

2. Build the image

Now that you’re ready to start the compilation, go to the $HOME/yocto-labs/build/ and run: 

Note: The first build process may take several hours, depending on the number of CPUs, available RAM, and Internet connection speed

3. Create the final image for SD Card

Once the build finished, you will find the output images under $HOME/yocto-labs/build/tmp/deploy/images/ stm32mp1-ies/
Execute the following command to create the final image for the SD card:

It will create the file FlashLayout_sdcard_stm32mp13xxae-tcu-fastboot.raw.

4. Flashing the image into the SD Card

Insert the SD card into the PC via an SD card reader

Using Balena Etcher:

 

Insert the SD card into the board, then power on the board.

 

You should see the Linux boot log on the serial terminal.

 

Wait until the login prompt, then enter root as user. Congratulations! The board has successfully booted.

You can verify the Linux kernel version by running

Since we are using the Scarthgap Yocto release, Linux kernel 6.6 is the expected version.

Read More
Edge AI for Predictive Maintenance: Unsupervised Vibration Anomaly Detection on MAX78000

January 7, 2026by Tuyền NguyễnTechnology

Edge AI for Predictive Maintenance: Unsupervised Vibration Anomaly Detection on MAX78000


1. AI Capability of ThingIQ

2. Data Acquisition and Signal Preprocessing

      2.1. Vibration Sensor Overview
      2.2. Signal sampling
      2.3. FFT – Based Feature Extraction

3. AI Model Architecture

      3.1. Model Tensor Description
      3.2. Training

4. Deployment on MAX78000

5. Conclusion

 

1. Al Capability of ThingIQ

In modern industrial IoT systems, sensor data—particularly vibration data—plays a critical role in assessing equipment health. However, traditional monitoring approaches based on fixed thresholds are often inadequate in complex operating environments, where load conditions, rotational speeds, and environmental factors continuously vary.

ThingIQ leverages Artificial Intelligence (AI) as a core intelligence layer within its IoT platform, enabling early anomaly detection and predictive maintenance directly at the edge device, with low latency and high energy efficiency. Building on this foundation, ThingIQ adopts an AI-first approach, in which machine learning models are embedded directly into the IoT data processing pipeline. Rather than merely collecting and visualizing sensor data, the platform focuses on analysis, learning, and inference from real-time sensor streams.

This approach is particularly well suited for large-scale industrial and IoT systems, where operational requirements include:

  • Early anomaly detection;
  • Low-latency response;
  • Reduced reliance on cloud-based inference;
  • Optimized energy consumption.

To enable reliable and data-driven intelligence, the effectiveness of AI models fundamentally depends on the quality and structure of input data. In industrial environments, raw sensor signals are often noisy, non-stationary, and highly dependent on operating conditions. Therefore, a robust data acquisition and signal preprocessing pipeline is a critical prerequisite for meaningful learning and inference. The following section describes how vibration signals are acquired and transformed through signal preprocessing techniques to extract informative representations for subsequent AI-based analysis.

2. Data Acquisition and Signal Preprocessing

One of ThingIQ’s key AI capabilities is vibration-based anomaly detection, built upon a signal processing and deep learning pipeline designed for industrial IoT environments. Vibration data is acquired in real time from accelerometer sensors and transformed into the frequency domain using the Fast Fourier Transform (FFT). Frequency-domain analysis highlights characteristic vibration patterns associated with normal operating conditions of industrial equipment.

After FFT processing and normalization, the data is fed into a Convolutional Neural Network (CNN) Autoencoder, where the model learns to reconstruct normal vibration patterns. The reconstruction error is then used as a quantitative metric to detect operational anomalies.

This approach enables the system to:

  • Detect subtle deviations before physical thresholds are exceeded
  • Adapt to changing operating conditions
  • Reduce false alarms compared to traditional rule-based methods
2.1.  Vibration Sensor Overview
The vibration data is collected using a 3-axis MEMS accelerometer mounted directly on the mechanical structure under monitoring

The sensor measures linear acceleration along three orthogonal axes:

  • X-axis: Typically aligned with the horizontal direction
  • Y-axis: Typically aligned with the vertical direction
  • Z-axis: Typically aligned with the axial or radial direction of the rotating shaft

    Figure 1: Accelerometers Measure Acceleration in 3 Axe

2.2.  Signal sampling

Each axis of the accelerometer produces an analog vibration signal, which is digitized using the MAX78000 ADC.

Typical sampling parameters:

  • Sampling frequency (Fs): 20 kHz – 50 kHz
  • ADC resolution: 12 bits
  • Anti-aliasing filter: Analog low-pass filter applied before the ADC input

The sampling frequency is selected according to the Nyquist rule to ensure that all fault-related vibration frequencies are captured without aliasing.

2.3.  FFT – Based Feature Extraction

After sampling, the vibration signals from each axis (X, Y, and Z) are transformed from the time domain into the frequency domain using the FFT. Each axis is processed independently.

The FFT converts raw vibration signals into frequency bins, where mechanical faults typically appear as distinct spectral components. Only the magnitude of the FFT is used, as phase information is not required for vibration-based fault detection.

This frequency-domain representation provides compact and informative features that are well suited for predictive maintenance and subsequent AI-based analysis.

 

3. AI Model Architecture

3.1.  Model Tensor Description

Technical Description of Model Input and Output:

  • Model Input Shape: [256, 3] (representing [Signal_Length, N_Channels]).
  • Input Details: The input consists of 3 axes (X, Y, and Z), where each axis contains 256 frequency bins (FFT data points).
  • Model Output Shape: [768, 1].
  • Output Details: The final layer is a Linear layer that produces a flattened output of 768 features (calculated as 256 3).

Figure 2: Autoencoder structure, with reconstruction of an example X axis FFT shown

 

3.2.  Training

Figure 3: Input and output tensor shapes and expected location of data

 

In general, a model is first created on a host PC using conventional toolsets like PyTorch and TensorFlow. This model requires training data that must be saved by the targeted device and transferred to the PC. One subsection of the input becomes the training set and is specifically used for training the model. A further subsection becomes a validation set, which is used to observe how the loss function (a measure of the performance of the network) changes during training.

Depending on the type of model used, different types and amounts of data may be required. If you are looking to characterize specific motor faults, the model you are training will require labeled data outlining the vibrations present when the different faults are present in addition to healthy vibration data where no fault is present.

As a result of this process, three files are generated:

  • cnn.h and cnn.c
    These two files contain the CNN configuration, register writes, and helper functions required to initialize and run the model on the MAX78000 CNN accelerator.
  • weights.h
    This file contains the trained and quantized neural network weights.

4. Deployment on MAX78000

Figure 5: mode of operation

 

Once the new firmware is deployed, the AI microcontroller operates as a finite state machine, accepting and reacting to commands from the BLE controller over SPI.

When an inference is requested, the AI microcontroller wakes and requests data from the accelerometer. Importantly, it then performs the same preprocessing steps to the time series data as used in the training. Finally, the output of this preprocessing is fed to the deployed neural network, which can report a classification. 

Figure 6: AI inference state machine

5. Conclusion

By integrating advanced signal processing techniques with deep learning, ThingIQ provides a robust and scalable approach to vibration-based anomaly detection for industrial IoT systems. The combination of FFT-based feature extraction, CNN autoencoder modeling, Quantization Aware Training, and edge AI deployment enables early detection of abnormal behavior with low latency and high energy efficiency.


This architecture allows enterprises to move beyond reactive, threshold-based monitoring toward proactive, data-driven operations, establishing a solid foundation for predictive maintenance and intelligent asset management in large-scale IoT environments.

Read More
ThingIQ – A comprehensive IoT platform
January 6, 2026by Tuyền NguyễnTechnology

ThingIQ – A comprehensive IoT platform

1. What is ThingIQ?
2. IoT platform ThingIQ
3. Integrate AI with ThingIQ
4. Conclusion

1. What is about ThingIQ?

“UPGRADE YOUR IOT FUTURE”

Market tendency – Insight – Action

 

Over the past decade, the Internet of Things (IoT) has undergone rapid development, from simple monitoring systems to infrastructures connecting millions of devices. However, as IoT matures, the core challenge is no longer data collection, but the ability to transform that data into tangible operational value.

The explosion of sensor data, real-time data, and complex data streams has rendered traditional management models ineffective. In this context, integrating artificial intelligence (AI) into IoT platforms is no longer a trend, but a necessary market requirement.

Faced with this reality, ThingIQ defines its vision: to build an IoT platform that not only connects devices but also supports businesses in making intelligent decisions based on data and AI. Instead of focusing on purely displaying data, ThingIQ’s vision is to bridge the gap between operational data and action, where analytical models and machine learning play a central role in anomaly detection, trend prediction, and system performance optimization. Therefore, the ThingIQ platform is conceived as an AI-integrated IoT solution right from the architectural design stage. Instead of building a connected system and then adding AI later, ThingIQ is developed with an AI-first philosophy, where IoT data is processed, analyzed, and continuously learned to generate actionable insights.

ThingIQ is geared towards large-scale IoT systems where stability, scalability, and integration with existing infrastructure are essential. Based on this vision, ThingIQ is built with a clear layered architecture, enabling real-time collection, processing, and analysis of IoT data, while integrating AI models to support intelligent operation.

2. IoT platform ThingIQ

As IoT systems expand from the experimental stage to real-world deployment, businesses quickly face systemic challenges. These pain points don’t stem from individual devices, but rather from management, operation, the environment, and integration capabilities across the entire IoT infrastructure.

ThingIQ is built to directly address these issues through three core solution groups:

  • Intelligent Management & Operations;
  • Environmental & Security Solutions;
  • IoT Connectivity & API Integration.

For businesses operating hundreds to thousands of dispersed assets such as vehicle fleets, machinery, and industrial equipment, data often comes from multiple sources and protocols, lacking standardization and difficult to utilize effectively. Manual monitoring leads to slow response times, reactive maintenance, and uncontrollable costs. ThingIQ addresses this problem with its intelligent Management & Operations platform, enabling real-time fleet monitoring (GPS, speed, fuel level, engine status via OBD-II and LTE SIM) as well as continuous monitoring of industrial equipment. Data is standardized and processed on an IoT cloud platform, enabling businesses to remotely monitor, analyze operating behavior, support predictive maintenance, and improve asset utilization efficiency.

Devices Management interface ThingIQ

 

In environments such as smart buildings, factories, and cold storage facilities, a lack of real-time environmental monitoring can lead to significant risks to quality, safety, and energy waste. Temperature, humidity, and energy consumption data are often fragmented, making it difficult for businesses to meet increasingly stringent standards. ThingIQ provides a comprehensive building, energy, and environmental management solution that enables real-time data monitoring and analysis, operational automation, and threshold alerts. This allows businesses to ensure compliance, protect product quality, reduce risks, and move towards sustainable operations at optimal cost.

In recent years, air quality in Hanoi has consistently been poor, especially during transitional seasons and peak traffic times, with concentrations of fine particulate matter and air pollutants exceeding recommended levels. This situation not only affects public health but also directly impacts labor productivity and the quality of life. ThingIQ’s IoT-based air quality monitoring solution allows for continuous real-time tracking of pollution indicators, CO₂, humidity, and temperature, enabling businesses, urban areas, and management agencies to proactively assess risks, issue early warnings, and implement timely and effective environmental improvement measures.

Air quality in Hanoi at the beginning of 2026

 

One of the biggest challenges for enterprise IoT is the fragmentation of devices, protocols, and systems, which isolates data and makes integration with existing platforms like ERP, MES, or BI difficult. ThingIQ addresses this problem through its IoT API Gateway – a secure and scalable middleware that bridges devices, cloud platforms, and enterprise applications. The gateway supports protocol conversion, centralized device management, and real-time data exchange, enabling businesses to seamlessly integrate IoT ecosystems, maintain openness and scalability, and ensure long-term data security.

3. AI in ThingIQ

ThingIQ integrates AI as a foundational component in its IoT architecture, transforming multi-source sensor and operational data into exploitable knowledge. Machine learning models are deployed directly in the data processing pipeline, allowing the system to learn from the real-world operating behavior of devices and the environment, rather than relying on thresholds or static rules.

The AI ​​in ThingIQ focuses on core analytical problems of enterprise IoT, including contextual anomaly detection, trend analysis, and device state prediction. Through learning from historical and real-time data, the platform supports predictive maintenance, reduces unplanned downtime, and optimizes asset lifecycles.

ThingIQ’s approach aims for AI that is controllable and explainable, ensuring compliance with operational requirements and data security. AI not only serves for display purposes, but also acts as a decision support layer, helping businesses shift from passive monitoring to proactive, data-driven operations.

For example, when comparing two systems, one with AI integration and one without, the advantages of AI applications become clear:

  • For IoT systems without AI: Traditional systems are primarily based on data collection and fixed thresholds. Sensors send data (temperature, humidity, equipment status) to a central platform, where the data is displayed on a dashboard and triggers alerts when predefined thresholds are exceeded. This approach is suitable for basic monitoring but is limited in complex operating environments where operating conditions change constantly. The system only reacts after an incident has occurred, easily leading to false alarms and making it difficult to support optimal operation or proactive maintenance.
  • Case 2: IoT systems with AI (ThingIQ) are integrated into the ThingIQ platform. IoT data is not only monitored but also analyzed contextually. Machine learning models study the normal operating behavior of equipment and the environment, thereby detecting anomalies early even before values ​​exceed thresholds. AI allows for forecasting trends and equipment status, supporting predictive maintenance and operational optimization. Instead of reacting passively, businesses can proactively make decisions based on data and forecasts.

From there, we get a comparison table to better understand the AI ​​features:

4. Conclusion

In the short term, ThingIQ focuses on developing and deploying comprehensive IoT solutions, helping businesses quickly solve real-world operational challenges, optimize asset, environmental, and system management, while ensuring flexible and stable deployment.

In the long term, ThingIQ aims to build an AI-integrated IoT platform as the core data infrastructure for businesses, where data is analyzed in depth to support intelligent decision-making, operational automation, and sustainable growth.

In terms of expertise and commitment, the ThingIQ team possesses comprehensive capabilities ranging from hardware design and development, IoT connectivity system deployment, to cloud integration and operation. By leveraging advanced connectivity protocols and in-depth data analysis, we deliver smarter, more efficient, and future-ready industrial solutions.

ThingIQ is committed to quality, innovation, and customer satisfaction at every stage, from design and implementation to system operation and scaling!

Read More
+84 90 686 2311

[email protected]

7A Thoai Ngoc Hau
Hoa Thanh Ward, Tan Phu District, Ho Chi Minh City

Our mission

Our mission is to enhance value for businesses, provide effective solutions, and create professional software applications that meet the needs of both Vietnamese and international enterprises.

Menu

Industrial Embedded Solutions Joint Stock Company
Registration code: 0318004045
Phone: +84 77 413 5678
Email: [email protected]
Address: 7A Thoai Ngoc Hau, Hoa Thanh Ward, Tan Phu District, Ho Chi Minh City, Vietnam
© 2026 — Industrial Embedded Solutions. All Rights Reserved.