Bluetooth Low Energy (BLE) has become one of the most widely adopted wireless technologies for battery-powered devices, offering reliable communication while consuming only a fraction of the power required by traditional wireless protocols. From wearable electronics and healthcare devices to wireless audio accessories and industrial sensors, BLE enables devices to remain connected for extended periods without sacrificing battery life.
In this Physical AI tutorial, we will train a real robotic arm using Hugging Face LeRobot and imitation learning. The project uses the Seeed Studio SO-ARM101 leader–follower robotic arm and a reComputer J4012 powered by NVIDIA Jetson Orin NX.
We begin by configuring and calibrating the SO-ARM101, followed by teleoperation and dataset collection. We then record 150 human demonstrations, train an ACT policy using LeRobot and test whether the robotic arm can autonomously sort tomatoes and potatoes. This step-by-step LeRobot tutorial covers the complete workflow, including hardware setup, motor configuration, calibration, teleoperation, dataset recording, AI model training, troubleshooting and real-world evaluation. By the end, you will have everything needed to understand and reproduce the robotic learning pipeline used in this project. We have also worked on many projects related to robotics; you can check out our robotics projects for more ideas.
Both the SO-ARM101 robotic arm and the reComputer J4012 are Seeed Studio products. If you are planning to try a similar setup, you can use the links and promotional codes below:
Check out SO-ARM101 Robotic Arm and use the promotional code KGYFKTZT to get $15 OFF
Check out reComputer J4012 and use the promotional code 90QQKB6Q to get 2% OFF.
The following components are required to complete the robotic arm system. These include the mechanical, electronic, power, and communication components needed for operation.
| S.No | Component | Quantity | Purpose |
| 1. | Seeed Studio Leader Arm | 1 | Used by the human operator to teleoperate and demonstrate the required movements. |
| 2. | Seeed Studio Follower Arm | 1 | The actual working robotic arm that follows the leader arm and later runs the trained AI policy. |
| 3. | reComputer J4012-Edge AI Device with NVIDIA Jetson Orin NX | 1 | Main computing unit for training the AI model and running inference on the robot. |
| 4. | USB Camera | 1 | Captures visual observations of the workspace, objects, gripper, and bowls for vision-based learning and control. |
| 5. | 12V Adapter | 2 | Powers the Follower arm motors and the Jetson Orin. |
| 6. | 5V Adapter | 1 | Powers the Leader arm motors (7.4V / 5V motors). |
| 7. | Laptop | 1 | Used for initial setup, teleoperation, dataset recording, and development on Windows. |
| 8. | C-Type USB Cables | 2 | Connect the Leader arm, Follower arm, cameras, and Jetson to the Laptop. |
| 9. | Monitor, Mouse, and Keyboard | Optional | Provides a display and input interface for the reComputer with Jetson Orin NX. |
This section provides an overview of the main hardware and software components used in the project, along with the reason for choosing them.
The SO-101 is a low-cost, open-source 6-DOF robotic arm designed for research and learning applications. It consists of two arms: the Leader arm and the Follower arm. The Leader arm is operated by a human to demonstrate the required movements, while the Follower arm mimics those movements during teleoperation and later executes the trained AI policy independently. This Leader–Follower setup makes it easy to collect high-quality demonstration data for imitation learning.
Unlike many industrial robotic arms, the SO-101 does not come with a separate external robot controller. Instead, it is supplied with two motor driver boards one for the Leader arm and one for the Follower arm and one for the Follower arm. These boards act mainly as a communication and power distribution interface between the computer and the motors.
The SO-101 uses Feetech STS3215 smart bus servo motors. These are not ordinary DC motors. Each STS3215 motor has a built-in motor controller inside the servo itself. This internal controller handles position control, speed control, torque control, and feedback of the current joint position.
Because the intelligence is already inside the motor, the external driver board does not perform complex motion planning. It simply passes commands from the computer to the motors and supplies power. In simple terms, the motor contains the controller, the driver board acts as a communication bridge, and the computer (running LeRobot) sends the target positions.
Different gear ratios are used for different joints to balance torque and speed. The Leader arm typically uses lower-voltage (7.4V) motors so that it can be moved easily by hand, while the Follower arm is designed for actual task execution.
The reComputer J4012 with NVIDIA Jetson Orin NX is a compact and powerful edge computing platform designed for AI workloads. In this project, it is used as the main system for training the imitation learning model and for running the trained policy on the robot.
Its GPU acceleration makes it suitable for training models such as ACT (Action Chunking with Transformers), which would be very slow or impractical on a normal laptop without a dedicated NVIDIA GPU.
Hugging Face provides the ecosystem around LeRobot, including the LeRobot framework, model architectures, datasets and tools for sharing and managing robotics projects.
In this project, the datasets and trained models were primarily stored locally during development, while the Hugging Face ecosystem provides the underlying framework and resources the project uses.
LeRobot is an open-source robotics framework developed by Hugging Face. It provides a complete set of tools required for real-world robot learning, including hardware communication, teleoperation, dataset recording, model training, and policy evaluation. Without LeRobot, we would have to write most of this software pipeline from scratch.
In this project, we use the SO-ARM101 Low-Cost AI Arm Assembled Kit Pro (Leader + Follower) together with Hugging Face LeRobot. The goal of this phase on Windows is to complete motor setup and calibration, teleoperation, dataset recording, and dataset replay.
To begin the software setup, first install Miniconda. Visit the official Miniconda download page, download the Windows 64-bit installer, and run it. During installation, make sure to check the option “Add Miniconda3 to my PATH environment variable”. After the installation is complete, restart the computer. Next, open Command Prompt and create a dedicated environment for LeRobot by running the command below
conda --version
conda create -n lerobot python=3.10 -y
conda activate lerobotIf you get a Terms of Service error, run these commands first:
conda tos accept --override-channels --channel https://repo.anaconda.com/pkgs/main
conda tos accept --override-channels --channel https://repo.anaconda.com/pkgs/r
conda tos accept --override-channels --channel https://repo.anaconda.com/pkgs/msys2After activating the environment, clone the official LeRobot repository and install it with Feetech motor support using the following commands:
git clone https://github.com/huggingface/lerobot.git
cd lerobot
pip install -e ".[feetech]"Verify the Installation:
python -c "import lerobot; print(lerobot.__version__)"A version number (such as 0.4.x or higher) should appear if the installation was successful.
Before configuring the motors, it is recommended to clearly label them. Use F1 to F6 for the joints of the Follower arm and L1 to L6 for the Leader arm. The power supply must be connected carefully. The Leader arm always uses 7.4V motors and should be powered with a 5V adapter, while the Follower arm may use 12V motors depending on the configuration. Both the power supply and the USB cable must be connected, as the USB connection alone does not provide power to the motors.
Connect the 12V power adapter to the Follower arm driver board first, then connect the 5V power adapter to the Leader arm. After that, connect the USB cables from both driver boards to the laptop. To identify the correct COM ports for each arm, run the command below:
lerobot-find-port Then follow the on-screen instructions. Note down the port numbers for both the Follower and Leader arms.
Expected results:
Follower → COM(any number)
Leader → COM(any number)
Once the ports are identified, the motor IDs need to be configured. It is important to remove the daisy-chain connection before setting the ID of each motor; otherwise, errors may occur. Start with the leader arm and run the following command (replace the COM port with your actual port):
lerobot-setup-motors --teleop.type=so101_leader --teleop.port=COM26Follow the instructions carefully and connect one motor at a time. After completing the leader arm, repeat the same process for the follower arm using:
lerobot-setup-motors --robot.type=so101_follower --robot.port=COM23Each motor must be assigned a unique ID from 1 to 6 so that the software can communicate with them individually.
After setting the motor IDs, connect all the motors properly and proceed with calibration. When instructed, gently move each joint front and back and then move it to its minimum and maximum positions. You can also see the joint values changing on the screen. Then Press Enter to save the calibration values. First, calibrate the leader arm using the command:
lerobot-calibrate --teleop.type=so101_leader --teleop.port=COM26 --teleop.id=my_leader_arm
Repeat the same process for the follower arm with the following command:
lerobot-calibrate --robot.type=so101_follower --robot.port=COM23 --robot.id=my_follower_arm
Calibration Tips
Move joints slowly.
Do not force the mechanical limits.
Make sure the correct motor IDs are assigned.
Ensure the arm is properly powered.
If calibration produces unexpected values, stop and verify the motor ID and joint mapping.
Save the calibration only after verifying the joint movement.
Once both arms are calibrated, teleoperation can be tested. Run the following command:
lerobot-teleoperate --robot.type=so101_follower --robot.port=COM23 --robot.id=my_follower_arm --teleop.type=so101_leader --teleop.port=COM26 --teleop.id=my_leader_armWhen the Leader arm is moved, the Follower arm will follow the same movements in real time. Press Ctrl + C to stop teleoperation
To record a dataset without using cameras, use the following command:
lerobot-record --robot.type=so101_follower --robot.port=COM23 --robot.id=my_follower_arm --teleop.type=so101_leader --teleop.port=COM26 --teleop.id=my_leader_arm --dataset.repo_id=semicon/arm_only_v1 --dataset.root="D:/lerobot_datasets/arm_only_v1" --dataset.num_episodes=3 --dataset.single_task="Pick and place small object" --dataset.push_to_hub=false --dataset.fps=30 --display_data=falseMake sure to change the COM port numbers and the dataset root path according to your system. This recording was performed without cameras.
To replay a recorded episode, use the command below:
lerobot-replay --robot.type=so101_follower --robot.port=COM23 --robot.id=my_follower_arm --dataset.repo_id=semicon/arm_only_v1 --dataset.root="D:/lerobot_datasets/arm_only_v1" --dataset.episode=0This will make the Follower arm repeat the motion recorded in the selected episode.
Every time you start working, activate the environment and navigate to the LeRobot folder using:
conda activate lerobot
cd path\to\lerobotAfter this, any of the above commands can be executed.
Even though the robotic arm can perform basic operations such as teleoperation, recording, and replay on Windows, full model training is not practical on this platform. Dataset recording itself can still be done on Windows without major issues. However, training the AI model requires CUDA support for efficient GPU acceleration. If the computer does not have an NVIDIA GPU, or if it has limited RAM, the training process becomes extremely slow or may not run effectively at all. Considering these limitations, the model training process was moved to the reComputer J4012 with Jetson Orin NX. This is explained in more detail in the following section.
Before starting the project on the reComputer J4012, it is important to understand a few key concepts related to AI model training and robot learning.
CUDA (Compute Unified Device Architecture) is a parallel computing platform developed by NVIDIA. It allows software to use the power of an NVIDIA GPU for general computing tasks, not just graphics.
A CPU usually processes tasks one after another, while a GPU can process thousands of smaller operations at the same time. CUDA is the technology that allows AI frameworks to use this GPU acceleration.
This is important because training a model like ACT involves a large number of mathematical calculations. These calculations are much faster on a GPU with CUDA. Since the Windows laptop used earlier did not have an NVIDIA GPU, training was impractical there. That is why the training process was moved to the reComputer J4012 with Jetson Orin NX
In robot learning, different AI models can be used depending on the task:
ACT (Action Chunking with Transformers): This is the model used in this project. It learns from human demonstrations and predicts a sequence of robot actions. It is efficient and works well with smaller datasets.
Diffusion Policy: Generates actions step by step and is useful for complex or precise movements, but needs more computing power.
VLM (Vision-Language Model): Understands both images and text, useful when a robot must follow language instructions.
VLA (Vision-Language-Action Model): Combines vision, language, and actions for more general-purpose robot control. These models are larger and need more data.
For this project, ACT was selected because it is suitable for imitation-learning tasks based on demonstration data and is practical for the relatively focused pick-and-place task used here.
First, the Jetson Orin NX should be flashed with JetPack 6.1 or above for proper software compatibility and performance. To flash the Jetson Orin, follow the official document.
After that, the basic robot setup is done in the same way as on Windows:
Setting motor IDs
Calibration
Teleoperation
Record and replay testing
These steps follow the official Seeed Studio documentation. Checkcheck the document to get the full idea to setup in the linux. Once this basic setup is complete, the next stage is collecting data for the vegetable sorting task.
To make the robotic arm learn the vegetable sorting task, we need to collect demonstration data. This data is recorded in the form of episodes.
What is an Episode?
An episode is one complete demonstration of the task.
For example:
Picking a tomato and placing it in the left bowl = 1 episode
Picking a potato and placing it in the right bowl = 1 episode
The AI model learns by studying many such examples. That is why multiple episodes are required.
Why around 120 episodes?
A single demonstration is not enough for the model to learn reliably. By collecting many episodes, the model sees different small variations in movement, timing, and object handling. In this project, around 120 episodes were collected in three groups:
Tomato only
Potato only
Both objects together
(picture of tomato, potato with the robotic arm)
This helps the model learn both individual object handling and combined sorting behaviour.
The following command is used to record the dataset using only the wrist camera:
conda activate lerobot
lerobot-record \
--robot.type=so101_follower \
--robot.port=/dev/ttyACM1 \
--robot.id=my_follower_arm \
--robot.cameras="{ wrist: {type: opencv, index_or_path: 0, width: 640, height: 480, fps: 30} }" \
--teleop.type=so101_leader \
--teleop.port=/dev/ttyACM0 \
--teleop.id=my_leader_arm \
--dataset.repo_id=local/tomato_potato_wrist_fixed \
--dataset.push_to_hub=false \
--dataset.num_episodes=120 \
--dataset.single_task="Sort the tomato into the left bowl and the potato into the right bowl" \
--dataset.episode_time_s=45 \
--dataset.reset_time_s=15 \
--display_data=trueIf you need to record all the episodes in one go, use the above command. Instead, if you need to collect the datasets in stages, like tomato only first, potato only, then both, follow the commands below:
conda activate lerobot
lerobot-record \
--robot.type=so101_follower \
--robot.port=/dev/ttyACM1 \
--robot.id=my_follower_arm \
--robot.cameras="{ wrist: {type: opencv, index_or_path: 0, width: 640, height: 480, fps: 30} }" \
--teleop.type=so101_leader \
--teleop.port=/dev/ttyACM0 \
--teleop.id=my_leader_arm \
--dataset.repo_id=local/tomato_potato_wrist_fixed \
--dataset.push_to_hub=false \
--dataset.num_episodes=40 \
--dataset.single_task="Sort the tomato into the left bowl and the potato into the right bowl" \
--dataset.episode_time_s=45 \
--dataset.reset_time_s=15 \
--display_data=true
lerobot-record \
--robot.type=so101_follower \
--robot.port=/dev/ttyACM1 \
--robot.id=my_follower_arm \
--robot.cameras="{ wrist: {type: opencv, index_or_path: 0, width: 640, height: 480, fps: 30} }" \
--teleop.type=so101_leader \
--teleop.port=/dev/ttyACM0 \
--teleop.id=my_leader_arm \
--dataset.repo_id=local/tomato_potato_wrist_fixed \
--dataset.push_to_hub=false \
--dataset.num_episodes=40 \
--dataset.single_task="Sort the tomato into the left bowl and the potato into the right bowl" \
--dataset.episode_time_s=45 \
--dataset.reset_time_s=15 \
--display_data=true \
--resume=true
lerobot-record \
--robot.type=so101_follower \
--robot.port=/dev/ttyACM1 \
--robot.id=my_follower_arm \
--robot.cameras="{ wrist: {type: opencv, index_or_path: 0, width: 640, height: 480, fps: 30} }" \
--teleop.type=so101_leader \
--teleop.port=/dev/ttyACM0 \
--teleop.id=my_leader_arm \
--dataset.repo_id=local/tomato_potato_wrist_fixed \
--dataset.push_to_hub=false \
--dataset.num_episodes=40 \
--dataset.single_task="Sort the tomato into the left bowl and the potato into the right bowl" \
--dataset.episode_time_s=45 \
--dataset.reset_time_s=15 \
--display_data=true \
--resume=true
After the dataset is collected, the ACT model is trained using the following command:
conda activate lerobot
lerobot-train \
--dataset.repo_id=local/tomato_potato_wrist_fixed \
--policy.type=act \
--policy.repo_id=local/tomato_potato_wrist_fixed_act \
--output_dir=outputs/train/tomato_potato_wrist_fixed_act \
--job_name=tomato_potato_wrist_fixed_act \
--policy.device=cuda \
--batch_size=4 \
--steps=100000 \
--eval_freq=5000 \
--save_freq=10000 \
--log_freq=100 \
--wandb.enable=false
Why these settings are used:
--policy.type=act → selects the ACT model
--policy.device=cuda → uses GPU acceleration
--steps=100000 → number of training steps
--save_freq=10000 → saves checkpoints regularly
If training is interrupted, it can be resumed from the last checkpoint:
conda activate lerobot
lerobot-train \
config_path=outputs/train/tomato_potato_wrist_fixed_act/checkpoints/last/pretrained_model/train_config.json \
--resume=trueAfter training, the model is tested on the real robot using:
conda activate lerobot
lerobot-record \
--robot.type=so101_follower \
--robot.port=/dev/ttyACM1 \
--robot.id=my_follower_arm \
--robot.cameras="{ wrist: {type: opencv, index_or_path: 0, width: 640, height: 480, fps: 30} }" \
--dataset.repo_id=local/eval_wrist_fixed \
--dataset.push_to_hub=false \
--dataset.num_episodes=1 \
--dataset.single_task="Sort the tomato into the left bowl and the potato into the right bowl" \
--dataset.episode_time_s=600 \
--dataset.reset_time_s=15 \
--display_data=true \
--policy.path=outputs/train/tomato_potato_wrist_fixed_act/checkpoints/last/pretrained_modelIn this step, the robot is no longer controlled by the leader arm. Instead, the trained model controls the follower arm based on the camera input and the learned behaviour. You can check out the model by placing the tomato and potato one by one.
This section provides solutions to the most common problems encountered during the project, along with their possible causes and recommended fixes. Use it as a quick reference whenever an error occurs during setup, operation, or training.
| S.No | Problem | Cause | Solution |
| 1. | Dataset already exists error while starting evaluation | LeRobot does not overwrite an existing dataset folder by default. A previous evaluation dataset with the same name was already present. | Deleted the existing dataset folder using rm -rf and then restarted the evaluation command. |
| 2. | Cameras disconnected during evaluation | USB bandwidth issues or an unstable camera connection caused the system to lose access to the camera devices mid-run. | Reconnected the cameras, verified the indexes using lerobot-find-cameras opencv, and restarted the evaluation. |
| 3. | The training process got interrupted before completion | Long training duration and system interruption stopped the process around intermediate checkpoints | Resumed training from the last saved checkpoint using the --resume=true option instead of restarting from zero. |
| 4. | Arm did not return to home position after evaluation episodes | During policy evaluation without the leader arm, the reset phase has no active control input, so the arm stays in its final position | Manually move the arm back to the starting/home position before each new episode |
| 5. | Magnitude/range error during calibration | Joint was not moved through its full range, or the motor moved too little / too much during calibration | Recalibrate the arm carefully by moving each joint slowly from minimum to maximum position as instructed |
| 6. | Motor ID setup failed / communication error | Motors were still connected in daisy-chain mode while assigning IDs | Disconnect the daisy-chain, connect one motor at a time, set the ID, then reconnect |
While the current system successfully demonstrates imitation learning for tomato and potato sorting, there is still significant room for improvement. The present setup mainly relies on a wrist camera with fixed object positions, so introducing an additional external camera from the top or side can provide better visual understanding and help the robot handle objects placed in different locations more reliably. Beyond laboratory experiments, the same learning pipeline can be adapted for practical applications such as warehouse sorting, educational robotics platforms, and simple industrial pick-and-place tasks. The system can also be expanded to handle a wider range of objects by training it to sort multiple items like different fruits or colored blocks
Adding force or tactile sensing to the gripper would further improve grasp stability, especially when dealing with soft or irregular objects. In the longer term, mounting the arm on a mobile base could allow the robot to perform sorting tasks across different locations rather than remaining restricted to a fixed table setup, making the overall system more flexible and closer to real-world use.
This project showed how a low-cost robotic arm can learn a real task by watching human demonstrations. Using the SO-101 arm and LeRobot, we completed the full process from hardware setup and teleoperation to data recording, model training, and final testing. The robot was trained to sort a tomato and a potato into different bowls. During the project, we worked on both Windows and the Jetson Orin NX, and this helped us understand which steps are easy on a normal laptop and which steps need stronger computing power.
We also faced practical problems such as camera disconnection, training interruptions, and limited performance when both objects were present. By solving these issues step by step, the system became more stable and useful. Overall, this project gives a clear and simple example of how imitation learning can be used to build practical robotic systems with affordable hardware, and it can be extended further for more complex tasks in the future.
From June to July 2026, AI hardware demand affected more than just GPUs, CPUs, and high-bandwidth memory. TrendForce reported that DRAM contract prices would rise by 13%–18% in Q3 2026. NAND Flash contract prices would rise by 10%–15%. The main drivers are AI inference systems and large data center deployments.
The pressure also moved into passive components. Recent market reports show that ordinary MLCC spot prices increased by 15%–20% since late February. High-capacitance MLCCs used in AI servers, including 10µF and 22µF parts, saw average price increases of 50%–60%.
This changes the selection process for engineers and procurement teams. A component is not suitable just because its electrical parameters match the schematic. Before finalizing the BOM, teams also need to check availability, second-source options, validation effort, traceability, and long-term supply risk.
Take Samsung Electro-Mechanics CL10A226MP8NUN# / CL10A226MP8NUNE as an example. This MLCC series is rated at 22µF, 10V, X5R, in a 0603 package. Engineers often use it for power decoupling, compact DC-DC output filtering, communication modules, and dense PCB layouts. But in AI edge devices, server accelerator boards, and industrial control modules, this type of high-capacitance, small-case MLCC should not be selected only by matching “22µF, 10V, 0603.” Engineers should check the following points:
In June, Astute Group reported that demand from AI infrastructure is tightening global MLCC supply. Some lead times now exceed 20 weeks. These constraints are expected to continue into 2027. This means high-capacitance MLCCs should have approved alternatives early in the design stage. Teams should not wait until production demand has already started.
Take the STM32F103C8T6 as a common example for MCU-based control boards. According to STMicroelectronics, this MCU uses an Arm Cortex-M3 core. Its CPU runs at up to 72MHz. It has 64KB of Flash memory. Engineers often use it in motor control, USB, CAN, and general industrial control applications.
MCUs may face long lead times or price pressure. In that situation, it is risky to pick an alternative just because it has the same Arm Cortex-M3 core or a similar package. Engineers need to check several details. They should verify pin definitions and pin multiplexing functions. They should also check ADC channels, PWM outputs, CAN and USB interfaces, and external crystal pins. Flash and RAM capacity, boot mode, debug interface, and software library compatibility also matter.
Temperature grade is just as important. A commercial-grade MCU may work for a consumer device. But industrial and automotive designs often need a wider temperature range. They may also require AEC-Q100-related validation. For mature products, replacing an MCU is not a simple purchasing step. It may involve a schematic.
CPUs and GPUs get the most attention in AI platforms. But the system's overall performance depends on many other components. NVIDIA's GB200 NVL72 is an example. It connects 36 Grace CPUs and 72 Blackwell GPUs. This system uses a rack-scale design with liquid cooling. Such a large platform needs more supporting parts. These include PMICs, MOSFETs, inductors, high-capacitance MLCCs, high-speed connectors, memory devices, PCB materials, thermal sensors, and cooling-control components.
When selecting CPU/GPU peripheral components, teams should check the following points:
One important point to note is that a project can still be delayed even when the main CPU or GPU is secured. A small power, connector, sensing, or memory component can become the actual delivery bottleneck if it has no approved alternative.
Step 1: Re-rank the BOM by supply risk, not only by unit price.
Low-cost MLCCs, small MCUs, connectors, or power components can become production blockers if they are hard to replace. AI hardware BOMs should mark MLCCs, MCUs, PMICs, memory devices, connectors, MOSFETs, inductors, and CPU/GPU power-rail components as priority review items.
Step 2: Build one shared alternative-part validation table.
The technical side should include package, pinout, electrical ratings, temperature grade, certification, lifecycle status, and software compatibility. The procurement side should include stock availability, lead time, date code, packaging condition, price validity, and manufacturer traceability. A part should move into validation only when both sides are acceptable.
Step 3: Move sourcing checks into the design stage.
ECIA’s June Industry Pulse report tracks sales expectations, product cancellations, product decommits, and component lead times across major categories and end markets. This shows why sourcing is now part of engineering decision-making. It is not only a purchasing task after design release.
Teams can use manufacturer data during design, pilot production, and mass production. They can also use official suppliers, other distributors, and the global spot market. They check if key parts are in stock. They check if these parts are traceable. They check if they have reliable replacements. In this workflow, WIN SOURCE can assist with BOM execution. We help procurement teams review supply availability. We help them review alternative options. We help them verify traceability. We help them assess delivery risks. We cover many component types. These include ICs, MLCCs, MCUs, memory chips, power devices, and connectors. Our support is especially useful for parts with long lead times. It also helps with parts in short supply. It helps with obsolete parts. It also helps with small-batch validation.
AI demand is changing how engineers and procurement teams select components. Parameter matching remains the foundation of component selection, but it is not sufficient to support a complete BOM decision. For MLCCs, MCUs, PMICs, memory devices, and CPU/GPU peripheral components, a more reliable selection process should include technical compatibility, supply stability, alternative validation time, and quality traceability before finalising the BOM.
© 2026 Win Source Electronics. All rights reserved. This content is protected by copyright and may not be reproduced, distributed, transmitted, cached or otherwise used, except with the prior written permission of Win Source Electronics.
The Arduino UNO R3 is often the first board people use to learn electronics and programming. Connect an LED, read a sensor, control a motor, upload a sketch, and it can seem like you’ve already discovered everything the board can do.
But there is much more going on underneath.
At the heart of the UNO R3 is the ATmega328P microcontroller. That small chip contains hardware features that many Arduino users never directly use, including an internal temperature sensor, brown-out detection, multiple sleep modes, a watchdog timer, and pin-change interrupts. These are capabilities of the microcontroller that the UNO R3 is built around.
Here are five of the most interesting ones you can actually explore on an Arduino UNO R3.
When you want to measure temperature with an Arduino, you would normally connect an external sensor such as an LM35, TMP36, DHT11, or DS18B20.
But the ATmega328P already has a temperature-sensing circuit inside the microcontroller.
The sensor is internally connected to the ADC, allowing the chip to obtain a temperature-related reading without using an external temperature sensor. The ATmega328P datasheet specifically lists temperature measurement among its peripheral features.
The basic path is:
Internal temperature sensor → ADC → digital reading → Serial Monitor
Connect your UNO R3 to your computer and configure the ATmega328P's ADC to read its internal temperature channel.
Then print the ADC result to the Serial Monitor.
For a visually interesting demonstration, start with the reading on screen and gently warm the microcontroller. You should see the reading change.
You don't need:
This is not a precision thermometer. The internal sensor has significant variation between individual chips, so the reading should be treated as approximate rather than as an accurate measurement of room temperature. So the safest way to describe it is:
“Your Arduino has a temperature sensor inside its main chip.”
Rather than:
“Your Arduino can accurately measure room temperature.”
How to Read the Internal Temperature Sensor in Arduino - Electro Hijibiji
https://www.youtube.com/watch?v=43l6Ibk7Spw
Another capability that doesn't require an external sensor is Brown-Out Detection, or BOD.
The ATmega328P can monitor its supply voltage. When brown-out detection is enabled and the voltage falls below the selected threshold, the microcontroller can be held in reset rather than continuing to operate under an insufficient supply voltage. The chip also provides a brown-out reset flag that allows software to determine that a brown-out reset occurred.
Think of it as a built-in low-voltage protection mechanism for the microcontroller:
Normal supply
↓
Supply voltage falls
↓
Brown-out threshold
↓
MCU reset/held in reset
This can be particularly useful in battery-powered embedded systems, where the supply voltage can change as the battery discharges.
For a controlled demonstration, use an appropriate adjustable power supply and a multimeter.
Gradually reduce the microcontroller's supply voltage while monitoring the system.
A simple visual sequence would be:
5 V → voltage decreases → threshold → reset
Don't experiment by randomly lowering the UNO's 5V rail while the board is simultaneously being powered through USB. Use a controlled setup and understand the board's power path before experimenting.
Arduino Project to Product – Part 4: Optimising Operating Voltage - Shawn Hymel / DigiKey
https://www.youtube.com/watch?v=7a4XYppZ6Bc
This is a useful engineering reference for ATmega328P operating voltage and brown-out detection.
The ATmega328P doesn't have to keep its CPU fully active all the time.
It has six hardware sleep modes:
Each mode disables different parts of the chip to reduce power consumption.
The most interesting mode for low-power applications is Power-down.
Instead of keeping the microcontroller awake while it has nothing to do, you can design a system like this:
Do some work → sleep → wake → do some work → sleep again
This is extremely useful for battery-powered devices.
Imagine a sensor that only needs to collect data once every minute. There is little reason to keep the CPU fully active for the entire minute.
Use an Arduino UNO R3 with an LED and a wake-up source such as a push button.
Show:
Arduino running
↓
Arduino enters sleep
↓
Activity stops / current drops
↓
Wake-up event
↓
Arduino continues
For an even better demonstration, measure the current and show the difference between active and sleep states.
Sleep modes are useful for:
The basic idea is simple:
Don't spend power doing nothing.
Arduino Project to Product - Part 8: How to Put Arduino to Sleep - Shawn Hymel / DigiKey
https://www.youtube.com/watch?v=eQZf5pbEVxE
This is particularly useful because it demonstrates the relationship between sleep mode and power consumption.
This is one of the most useful features for real-world embedded projects.
The ATmega328P includes a hardware Watchdog Timer with a separate on-chip oscillator. The watchdog can be configured with a timeout, and if the software fails to service it before that timeout expires, it can trigger a system reset.
Imagine an unattended robot.
Everything is working:
Sensors → code → motors → communication
Then a software bug sends the program into an infinite loop.
Without a recovery mechanism, the system can remain frozen.
With the watchdog:
Program running
↓
Software gets stuck
↓
Watchdog isn't serviced
↓
Timeout
↓
Hardware reset
↓
Program starts again
The watchdog doesn't actually understand that the program “crashed.” It simply detects that it wasn't serviced in time.
You can deliberately create an infinite loop after enabling the watchdog:
#include <avr/wdt.h>
void setup() {
Serial.begin(9600);
Serial.println("Arduino STARTED");
wdt_enable(WDTO_2S);
}
void loop() {
Serial.println("Running...");
delay(500);
// Simulate a software freeze
while (true) {
}
}The Serial Monitor will initially show:
Arduino STARTED
Running...
Running...
Running...
Then the program stops responding.
After the watchdog timeout, the ATmega328P resets and setup() runs again.
You should see:
Arduino STARTED
again.
That makes a great demonstration because it looks like the Arduino has recovered itself.
Watchdog timers are especially useful in:
If something is supposed to keep running for hours, days, or months without someone nearby to press RESET, a watchdog can provide an important recovery mechanism.
Tutorial: Using the Arduino Watchdog Timer - MAKE Course
https://www.youtube.com/watch?v=BDsu8YhYn8g
The video specifically covers the watchdog timer on the ATmega328P and its automatic timeout/reset behavior.
This is where the sleep feature becomes even more interesting.
The ATmega328P provides Pin Change Interrupts, commonly called PCINT.
On the UNO R3, pin-change interrupt sources are spread across groups of GPIO pins. For example, the ATmega328P uses PCINT groups corresponding to:
D8 - D13
A0 - A5
D0 - D7
Electronoobs' detailed ATmega328P tutorial explains these groups, the corresponding interrupt vectors, and how to configure them.
But the really useful part is this:
Pin-change interrupts can be used to wake the ATmega328P from Power-down sleep.
So you can create this sequence:
Arduino running
↓
MCU enters sleep
↓
Button changes a configured pin
↓
Pin-change interrupt
↓
Arduino wakes
The microcontroller doesn't have to keep executing a loop asking:
“Is the button pressed?”
while it is sleeping.
The hardware can detect the configured change and use the interrupt as a wake-up event.
For example, connect a push button like this:
A0 ───── BUTTON ───── GND
Configure A0 with the internal pull-up resistor and enable the appropriate pin-change interrupt.
Then show:
Arduino awake
↓
Arduino enters sleep
↓
Current/activity drops
↓
Press button
↓
A0 changes state
↓
Pin-change interrupt
↓
Arduino wakes
Normally, your program might repeatedly poll the pin:
Is the button pressed?
Is the button pressed?
Is the button pressed?
That means the CPU has to remain active.
With the sleep + interrupt approach, the CPU can sleep until the hardware detects the configured event.
Pin Change Interruptions ISR | PCINT | Arduino101- Electronoobs
https://www.youtube.com/watch?v=ZDtRWmBMCmw
This video demonstrates pin-change interrupts on the Arduino/ATmega328P and explains the PCINT groups and configuration.
We recently came across reports covered by news outlets about electric vehicles, specifically e-rickshaws, being remotely hacked and stalled in the middle of busy roads. The attackers were using Android apps, some of which were available on the Google Play Store under names like BAT-BMS, Epoch Li-on and Overkill Solar. These apps were apparently able to connect to some specific brands of the Battery Management System (BMS) inside these vehicles over Bluetooth and shut down the power MOSFETs, effectively cutting power to the motor while the vehicle was in motion.
The Indian government responded by removing several of these apps from the Play Store. That seemed like a reasonable first step, but it immediately raised a question for us: does removing the app actually solve the problem, or is the real issue deeper than that?
We suspected the latter. If a third-party app, one not even made by the BMS manufacturer, could gain control over the battery's safety switches, then the vulnerability isn't in the app. It's in the BMS itself. Removing one app from the store doesn't stop anyone from writing another one, or from sending the same Bluetooth commands directly from a laptop or microcontroller.
So we decided to test it ourselves. We purchased three of the most widely used BMS brands in the consumer and light-EV market JBD (Jiabaida), Daly, and JK (Jikong) and set out to determine whether their Bluetooth Low Energy (BLE) interfaces had any meaningful security against unauthorized access. But what we found was more shocking! All three BMS platforms permitted unauthenticated remote control of their safety-critical MOSFETs. An attacker within BLE range can scan, connect, read live battery telemetry, and toggle the charge and discharge FETs without pairing, bonding, password verification, or any other form of firmware-level authentication.
To demonstrate the impact of these findings, we also built a proof-of-concept web application to visually demonstrate this vulnerability, and developed a hardware countermeasure that existing BMS owners can deploy right now to protect their systems. This article covers our complete journey through this investigation.
Before we examine the vulnerabilities identified during this research, it is useful to understand the Bluetooth Low Energy (BLE) concepts that make them possible. While BLE is designed for low-power, short-range wireless communication, it also includes a well-defined data model and several built-in security mechanisms. Understanding these fundamentals provides the context needed to see why the BMS devices we tested are vulnerable.
Bluetooth Low Energy (BLE), introduced as part of Bluetooth 4.0, differs significantly from Classic Bluetooth. Rather than exposing a continuous serial data stream through the Serial Port Profile (SPP), BLE organises communication using the Generic Attribute Profile (GATT). Under the GATT model, a device exposes its functionality through a hierarchy of Services, each identified by a unique UUID (Universally Unique Identifier). Each service contains one or more Characteristics, also identified by UUIDs, which represent individual pieces of data or control interfaces. A characteristic consists of the actual value along with a set of properties that define how it may be accessed.
In practice, a Service represents a logical grouping of related functionality, such as battery telemetry or configuration settings. Within that service, Characteristics expose specific values such as pack voltage, cell temperatures, state of charge, or control commands. BLE identifies these objects using UUIDs, which are 128-bit identifiers typically represented in hexadecimal. Standard BLE services use shortened 16-bit UUIDs; for example, 0x180F identifies the standard Battery Service, whereas vendor-specific implementations generally use custom 128-bit UUIDs.
Each characteristic also advertises one or more access properties that determine how a connected client may interact with it. The Read property allows a client such as a phone or laptop to retrieve the current value stored by the device. The Write property enables the client to send data or commands to the device, making it the mechanism through which configuration changes or control operations are typically performed. Some devices additionally support Write Without Response, which omits the acknowledgement normally returned by the device, improving throughput at the cost of reliability. The Notify property allows the device to asynchronously push updates to subscribed clients without requiring repeated polling, making it the standard mechanism for streaming live telemetry such as voltage, current, and temperature measurements.
BLE also includes a comprehensive security architecture designed to prevent unauthorized access. Pairing establishes a trusted relationship between two devices using methods such as Passkey Entry, Numeric Comparison, or Out-of-Band authentication. Once pairing has been completed, Bonding allows the generated security keys to be stored so that future connections can be established securely without repeating the pairing process. These keys are then used to enable Encryption, protecting all subsequent communication over the BLE link. At the application layer, Authorization provides an additional level of access control by allowing the device to determine whether a connected client is permitted to perform sensitive operations, such as modifying configuration parameters or issuing control commands.
The most important observation for this research is that BLE already provides the mechanisms necessary to secure sensitive devices such as Battery Management Systems. The vulnerabilities described in the following sections do not arise from weaknesses in the BLE protocol itself; rather, they resulted from manufacturers choosing not to implement pairing, encryption, authorization, or other available security controls, leaving critical functionality accessible to any nearby BLE client.
We began our investigation not with code or protocol analysers, but with the official manufacturer of mobile apps. Our goal was simple: before we try to bypass anything, let's see what security the manufacturers themselves claim to provide.
JBD offers two apps that behave similarly. When a user connects to a JBD BMS as a guest, they can view battery information but cannot access control functions. To gain full control, the user must register a JBD account and bind the BMS device ID to that account. The binding is stored on JBD's cloud servers, and the app checks the cloud database for ownership before granting control access.
Here's the problem: if a BMS owner purchases the unit and does not register and bind it to their account, anyone else can create their own JBD account and bind that BMS to theirs, at which point they get full control through the official app itself. More importantly, even this account-binding mechanism is only enforced by the app. The BMS hardware itself, the JBD DP04S007 we tested, accepts control commands from any connected BLE device without authenticating anything. JBD does not provide any on-device password authentication option on the models we tested.
Daly's official app does not require account creation. Any user can connect directly to the BMS. To access control functions like FET toggling, the app prompts for a password. The default password is `123456`, and users can change it. The password is stored on the BMS hardware itself.
However, our testing on the Daly 4S12V60A confirmed something important: the BMS firmware accepts control commands over BLE regardless of whether a password has been sent in the session. The password prompt exists only in the app's user interface. It is a client-side gate. If you bypass the app and send the control command directly to the BLE characteristic, the BMS executes it without question.
JK's app follows a similar pattern to Daly. Users can connect and set a password to protect their BMS, and the password is stored on the BMS hardware. But once again, direct BLE command injection bypasses this password entirely. The JK-B2A8S20P we tested processes write commands to its control characteristics without checking any authentication state. The password is only verified by the official app, not by the firmware.
After confirming that all three brands had either no app-level security or trivially bypassable security, we needed to verify whether the underlying BLE protocol itself enforced any restrictions.
Our approach involved connecting to each BMS and enumerating all GATT services and characteristics to identify which ones are used for data exchange. We analysed the properties of each characteristic to determine which support Write (for sending control commands) and Notify (for receiving telemetry). To characterise the BLE interface, we performed protocol analysis using publicly available resources and controlled experimentation. Once reliable communication had been established, we verified normal telemetry functionality before assessing the control operations.
For responsible disclosure reasons, we are deliberately not publishing the specific BLE service and characteristic UUIDs, the command byte sequences, or the frame structures used by any of the three brands. What we can say is that all three follow a broadly similar pattern: the client writes a binary command frame to the BMS's writable characteristic, and the BMS processes it and sends a response back via notifications. The command frame contains a header marker, a target address byte, a command ID, a data payload, and a checksum. Telemetry commands return pack voltage, current, cell voltages, temperatures, SOC, and MOSFET states. Control commands toggle the charge and discharge MOSFETs.
The fundamental finding is simple: the BMS firmware does not distinguish between a legitimate user and an attacker. Any device that can establish a BLE connection and write the correct bytes to the correct characteristic can issue control commands.
The following table summarises our findings across all three BMS brands side by side.
| Security Dimension | JBD (DP04S007) | Daly (4S12V60A) | JK (B2A8S20P) |
| BLE Pairing Required | No | No | No |
| BLE Bonding / Encryption | None | None | None |
| App Password Protection | Account binding (cloud) | Yes (user-configurable) | Yes (user-configurable) |
| Password Stored On | JBD cloud servers | BMS hardware | BMS hardware |
| Password Enforced by BMS Firmware | No | No | No |
| Direct BLE Command Accepted | Yes - unrestricted | Yes - unrestricted | Yes - unrestricted |
| Telemetry Readable Without Auth | Yes | Yes | Yes |
| FET Control Without Auth | Yes | Yes | Yes |
| Third-Party App Control | Yes (Epoch Li-ion, Overkill Solar) | So far, none (Official Only) | So far, none (Official Only) |
| Firmware-Level Authentication Mechanism | None detected | None detected | None detected |
The bottom line is that all three brands fail at the most fundamental level. The BMS firmware itself has no mechanism to verify that the device issuing control commands is authorised to do so. The "security" offered by their official apps is entirely cosmetic; it exists only in the app UI and can be bypassed by anyone who communicates directly with the BLE interface.
All testing was conducted in a controlled laboratory environment using our own equipment. We used a 4-cell (4S) 18650 lithium-ion battery pack connected to an Electronic Load Measurement Tool for safe, controlled discharge testing. The BLE host was a Windows PC with a Bluetooth adapter running Python with the `bleak` BLE library. The three BMS units under test were the JBD DP04S007, the Daly 4S12V60A, and the JK-B2A8S20P. We verified MOSFET state changes through both BLE telemetry readback and physical measurement of load current on the electronic load.
To make this vulnerability tangible and visually demonstrable, we built a proof-of-concept web application called BMS Analyser. The app runs as a local web server on a PC with Bluetooth capability, and any device on the same WiFi network (a phone, tablet, or another laptop) can open its browser and interact with the BMS in real time. This approach lets us demonstrate the vulnerability to the viewer by seeing live battery data and interactive MOSFET toggle switches on their phone screen.
The backend is written in Python using Flask. Since BLE operations are inherently asynchronous (using the bleak library), we run a dedicated asyncio event loop in a background thread. Flask's synchronous request handlers submit BLE coroutines to this loop and block until the result is available. This bridge pattern lets us keep the simplicity of Flask's REST API while still performing non-blocking BLE operations under the hood.
We designed the BLE communication layer around a clean driver abstraction. An abstract BMSDriver base class defines the interface: scan, connect, disconnect, get_telemetry, set_charge_fet, and set_discharge_fet and three concrete implementations, JBDBLEDriver, DalyBLEDriver and JKBLEDriver, encapsulate all the brand-specific protocol details. Each driver handles BLE service discovery, command frame construction with proper headers, addresses, payloads and checksums, notification response parsing, and the protocol quirks unique to each brand. For instance, Daly streams cell voltages across multiple notification frames that need to be reassembled by frame number, while JK sends 300-byte cell info responses that arrive in BLE MTU-sized chunks and must be accumulated before parsing.
The frontend is a single-page HTML/CSS/JavaScript application that polls the backend every 1.5 seconds for telemetry data. It presents a BLE scanner panel where you select a brand and scan for nearby devices, with signal strength indicators and a scrollable device list. Once connected, a live telemetry dashboard shows pack voltage, current, power, SOC percentage with an animated progress bar, individual cell voltages rendered as a bar chart, and temperature readings. Below that sits the MOSFET control panel: two toggle switches for the charge and discharge FETs, with colour-coded status cards that update in real time.
One practical challenge sometimes in the UI is toggle switch glitching. Because telemetry is polled every 1.5 seconds, there's a race condition: when a user toggles a FET, the command takes 1-2 seconds to propagate to the BMS hardware. If a telemetry poll completes during that window, it reads the old MOSFET state and overwrites the switch position back, causing it to visually bounce between states.
Discovering a vulnerability without proposing a solution is only half the job. So we developed a hardware-based security shield that existing BMS owners can deploy immediately, without any modifications to their BMS itself.
BLE peripherals like these BMS units typically support only one active GATT connection at a time. This is a fundamental limitation of most BLE peripheral firmware stacks; once a client is connected, the device stops advertising and rejects additional connection attempts. We realised we could exploit this limitation defensively: if a trusted device permanently occupies the BMS's only BLE connection slot, no attacker can connect.
The ESP32 BMS Protector is a small, inexpensive microcontroller. We used the Seeed Studio XIAO ESP32-S3 for its tiny form factor that connects to your BMS via BLE and holds the connection 24/7. By maintaining the active BLE GATT session link, the protector keeps the connection slot occupied. Because the BMS's single connection slot is now permanently occupied by the ESP32, any external device, whether it's an attacker's phone or a malicious app that tries to scan and connect, will either not see the BMS at all or get a connection-refused error.
When you legitimately need to use your phone app or the BMS Analyser to check battery status, you can temporarily release the lock by pressing the ESP32's built-in BOOT button or by using its built-in Wi-Fi web portal. The protector disconnects from the BMS, giving you a configurable window (default: 5 minutes) to connect with your normal tools. Once the timer expires, the ESP32 automatically reconnects and re-locks the BMS.
On first power-up, the ESP32 has no saved configuration, so it enters CONFIG mode and creates a Wi-Fi access point called BMS-Shield-Setup. You connect your phone to this AP, open a browser, and a captive portal lets you select your BMS brand (JBD, Daly, or JK), scan for nearby BLE devices, and select your BMS from the list. The ESP32 saves this to non-volatile storage and reboots into LOCKED mode. From then on, it automatically connects to your BMS on every boot and holds the connection.
The onboard LED communicates the current state visually: a double-blink pulse in CONFIG mode, solid ON when locked and connected, slow blink when attempting to reconnect after a dropped connection, and fast blink during the temporary release window. A long press (5+ seconds) on the BOOT button triggers a factory reset, clearing the saved configuration and returning to CONFIG mode.
The proposed solution is a mitigation rather than a permanent fix. It requires additional hardware for each BMS unit, and consumes a small amount of standby power. Additionally, a determined attacker with specialised radio equipment could potentially jam the BLE connection to force a disconnect. While these limitations make the workaround practical for many applications, they highlight that the underlying vulnerability remains within the BMS firmware itself.
The long-term solution must come from BMS manufacturers through the implementation of proper BLE security. At a minimum, devices should support BLE pairing with passkey entry, requiring a unique numeric passkey during the initial connection to prevent unauthenticated access. BLE bonding should be enabled so that only previously paired devices can reconnect, and all BLE communication should be encrypted using AES-CCM to protect against eavesdropping and packet injection.
At the firmware level, the most critical improvement is robust command authentication. Before executing any safety-critical command such as MOSFET control, parameter modification, or factory reset, the firmware should verify that the connected device has successfully authenticated using a secure challenge-response mechanism rather than relying on a plaintext password transmitted over BLE. Permission levels should also be separated, allowing unauthenticated users to read battery telemetry while restricting control functions exclusively to authenticated devices.
The BLE security vulnerability we discovered across JBD, Daly, and JK BMS units is not an edge case or an obscure protocol weakness. It is a systemic design failure, a conscious decision (or oversight) by manufacturers to ship thousands of units with no authentication on safety-critical control functions. The technology to fix this has existed for over a decade in the BLE specification itself. Pairing, bonding, encryption, and authorisation are all well-defined, well-supported standards. The missing ingredient is not capability; it is priority.
We hope this research serves as a signal to the BMS industry that security cannot be an afterthought. Until manufacturers respond with proper firmware-level security, the ESP32 BMS Protector offers a practical, deployable defence for the thousands of vulnerable units already in the field.
Our recent Community Webinar featured Yatin Varachhia, Co-founder & CEO at Nosh Robotics, a company that makes a robot that cooks food. He previously worked as a design engineer at Analog Devices and has co-founded two companies. The session was held on a Sunday, with more than thirty people watching live, and included a question and answer segment.
At electronica India 2026, Nitin Jain, co-founder of 1Buy.AI, sat down with Aswinth Raj, editor of CircuitDigest, for an episode of electronica Xchange to discuss the role of artificial intelligence in procurement and its impact on India's supply chain.
CP PLUS, the surveillance brand under Aditya Infotech, traces its origins to 2007. That year, the company decided to enter the surveillance technology space, with a vision of CCTV cameras becoming commonplace across India. What was then considered a luxury item for select businesses has since become, as M.A. Johar, President of Strategic Business at CP PLUS, put it, "a necessity" for hotels, small shops, and large projects alike.
We're all familiar with live GPS tracking; it tells us where a vehicle or device is right now. But what if the system could do more than just show the location? That's where geofencing using IoT comes in. Imagine receiving an instant alert the moment a vehicle leaves home, reaches college, enters the office, or moves into a restricted area. Instead of repeatedly checking a map, the system itself notifies you whenever something important happens. Think about it: if you're tracking a vehicle, do you really want to keep opening the app and checking its location every few minutes? Most of the time, you only care about specific places and important events.
For example, you might want to know when a vehicle reaches college, leaves the office, arrives home, or enters an area that is restricted. Rather than watching the location all day, it would be much easier if the system could automatically inform you whenever these events occur. In this project, we build a complete IoT geofencing system using the GeoLinker GL868_ESP32 board: an ESP32-S3 paired with a SIM868 GSM modem. That's exactly what geofencing helps us do. It allows us to create virtual boundaries around important locations and detect when a device enters or leaves them. By combining geofencing with live GPS tracking, we can build a smarter location-monitoring system that not only tracks a device but also keeps users informed at the right time. Let's dive in and see how to do that. Before that, visit the GeoLinker wikipage to learn about the full spec and get to know the full details of the GeoLinker.
The system begins by powering on the GeoLinker. Then the board will search for the SIM card and connect to the network, and then keep the board outside for a bit. This ensures the board connects to the satellite for the GPS. Before deploying the code to the board, you should configure multiple geofences by specifying the latitude, longitude, and radius of each zone. In this project, four geofences are created: Home, College, Office, and Restricted Area. Once initialization is complete, the GPS module continuously acquires the current location of the device. The obtained coordinates are then compared with the boundaries of all the configured geofences to determine whether the device is inside or outside each zone.
The system continuously monitors the device's movement and checks for any change in geofence status. When the device enters a geofence area, the system detects the event and generates an alert. Similarly, when the device exits a geofence, another alert is generated. For normal zones such as Home, College, and Office, an SMS notification is sent to the registered mobile number whenever an entry or exit event occurs. These alerts help the user know the movement of the tracked device in real time.
A separate geofence is created for the Restricted Area. Whenever the device enters or exits this zone, the system sends an SMS notification and additionally triggers an automatic phone call. The phone call ensures that critical security-related alerts receive immediate attention and are not missed by the user.
The device periodically uploads its location and signal strength to the CircuitDigest Cloud every 30 seconds, enabling real-time tracking and remote monitoring through the dashboard. This allows the user to view the device's live location and status remotely through the cloud dashboard.
*Note: Not only these, but we also have several example codes like advanced tracking, call triggering, automatic sleep code, etc., which are available in the examples of the Arduino IDE. Spare some time and take a look at those worth exploring if you want to extend this IoT geofencing system project.
The components below are the components which are essential ones used to make the geofencing alert system.
| S.No | Components | Purpose | Alternatives |
| 1. | Geolinker Board | GeoLinker GL868_ESP32 is a production-ready, open-source development board that combines an ESP32-S3 and SIM868 GSM modem, used for tracking purposes. | - |
| 2. | IoT / Normal Nano SIM Card | Airtel M2M IoT SIM recommended (3 months free data with board purchase). Any 2G-compatible SIM works. | Regular 2G SIM |
| 3. | 3.7V Li-Ion / LiPo Battery | Used for powering the board | LiPo pouch battery |
| 4. | USB-C Cable | Programming, testing & charging | - |
The hardware requirements for this system are minimal. Only the GeoLinker board and a battery are required for operation. The enclosure is optional and is used only for protection and improved appearance. Once the battery is connected to the GeoLinker board, the system automatically powers up and begins the initialisation process.
The code is written with the required libraries for GeoLinker and GPS. It also contains the sections where the coordinates need to be modified to ensure that geofencing works correctly according to the requirements. Different alerts are triggered based on the location. Additionally, the data is sent to the CircuitDigest Cloud at a specified interval.
#define DEVICE_ID "YourDeviceID"
#define API_KEY "YourAPIKey"
#define ALERT_NUMBER "Yournumber"
#define GPS_TIMEOUT 30000UL
#define GPS_MAX_RETRIES 3
#define GPS_POLL_INTERVAL 5000UL
#define CLOUD_SEND_INTERVAL 30This section contains all the important configuration settings used throughout the program. It defines the device ID, cloud API key, alert phone number, GPS timeout period, polling interval, and cloud upload interval. Keeping these values in one place makes the system easier to configure and maintain without modifying the main logic.
struct GeofenceZone {
const char *name;
double latitude;
double longitude;
double radiusMeters;
bool restricted;
bool insideNow;
};
GeofenceZone zones[] = {
{ "Home", 12.971600, 77.594600, 150.0, false, false },
{ "College", 12.934500, 77.626000, 200.0, false, false },
{ "Office", 12.958000, 77.650000, 200.0, false, false },
{ "Restricted Area", 11.011158, 77.013307, 200.0, true, false },
};This section defines all the geofences used in the system. Each geofence contains a name, centre coordinates, radius, and alert type. The radius determines the size of the virtual boundary, while the restricted flag specifies whether the zone should generate only SMS alerts or both SMS and phone call alerts. All geofences are stored in an array, allowing the system to monitor multiple zones simultaneously. You should change the long and lat in the GeofenceZone zones[] section in the code for your requirements.
static bool getValidLocation(GPSData *gps) {
for (int retry = 0; retry < GPS_MAX_RETRIES; retry++) {
uint32_t start = millis();
while (millis() - start < GPS_TIMEOUT) {
GeoLinker.update();
if (GeoLinker.getLocationNow(gps) && gps->valid) {
return true;
}
delay(25);
}
}
return false;
}This function is responsible for obtaining the current GPS location from the GeoLinker module. The system continuously attempts to acquire a valid GPS fix within a specified timeout period. Multiple retries are performed to improve reliability in areas where satellite signals may be weak. Once a valid location is obtained, the coordinates are passed to the geofencing logic for further processing.
double dist = haversineDistance(
gps->latitude,
gps->longitude,
zones[i].latitude,
zones[i].longitude);
bool nowInside = zones[i].insideNow ?
(dist <= exitThresh) :
(dist <= enterThresh);
if (nowInside != zones[i].insideNow) {
zones[i].insideNow = nowInside;This section forms the core of the project. The system calculates the distance between the current GPS location and each geofence using the Haversine distance formula. The calculated distance is then compared with the geofence radius to determine whether the device is inside or outside the zone. Whenever the status changes, the system identifies it as an entry or exit event and prepares the corresponding alert.
static void sendGeofenceAlert(
const char *zoneName,
bool entered,
bool restricted,
GPSData *gps,
bool hasLoc) {
buildAlertMessage(msg,
sizeof(msg),
verb,
zoneName,
gps,
hasLoc);
sendReliableSMS(ALERT_NUMBER, msg);
if (restricted) {
pendingCall = true;
}
}This function is responsible for generating notifications whenever a geofence event occurs. A detailed alert message containing the event type and location information is first created and sent via SMS. If the geofence is marked as a restricted area, the system additionally schedules a phone call to the registered number.
*Note: A spoof code is also available in the GitHub repository, so you can go through it and test the system while sitting in one place.
The following are the problems that were faced while building the system and the different solutions that were used to overcome them. You can take a look at them and use these solutions if you encounter similar problems.
| Problem | Cause | Solution |
| SMS alerts are not received | SIM card not registered on the GSM network or insufficient SMS balance | Check network registration status and ensure the SIM card has sufficient SMS balance and signal strength. |
| Phone call alert is not triggered for the Restricted Area | Incorrect phone number configuration or call service unavailable | Verify the alert phone number in the code and ensure the SIM card supports voice calling. |
| No GPS location is obtained | Weak GPS signal or indoor operation | Move the device outdoors with a clear view of the sky and wait for GPS satellites to lock. |
| Continuous false entry/exit alerts | GPS drift or geofence radius set too small | Increase the geofence radius and ensure GPS accuracy is sufficient for the application |
| System resets unexpectedly | Insufficient power supply during GSM transmission | Use a fully charged 3.7V Li-ion battery capable of supplying peak GSM current requirements |
| Device shows incorrect geofence status after restart | Previous geofence state not stored correctly | Verify NVS memory operation and ensure geofence states are saved properly before power loss. |
| The call is triggered, but not getting sms or vice versa | Maybe your number is not whitelisted. | Make sure to whitelist your registered number for the call and sms too. |
The live tracking of the GeoLinker board is shown below. The board continuously acquires its current GPS coordinates and transmits the location data to the Circuit Digest Cloud at intervals of 30 seconds.
The figure below shows the virtual boundaries (geofences) that have been created for the system. The coordinates corresponding to these geofence areas are defined in the program code that was flashed into the GeoLinker board. These geofences represent specific locations, such as Home, College, Office, and Restricted Areas. Whenever the system enters or exits any of these predefined boundaries, the corresponding alerts are triggered automatically
This screen displays the live tracking information received from the GeoLinker board. It includes important parameters such as the current date and time, latitude, longitude, speed, and battery percentage (when a battery is connected to the system). Additionally, the payload section contains further details transmitted by the device, providing comprehensive information about its status and location.
The figure below shows the entry and exit alerts generated for the different geofencing areas. Whenever the device enters or exits a predefined geofence, the system automatically sends an SMS notification to the registered user. The alert message includes the type of event (entry or exit), the name of the geofence area, and the live GPS coordinates of the device at that moment.
Additionally, if the device enters or exits a Restricted Area, the system generates an SMS alert similar to the alerts used for normal geofence zones. However, to ensure that critical notifications are not missed, the system also automatically places a phone call to the registered user. This dual-alert mechanism provides an additional layer of security by immediately drawing the user's attention to important events occurring within restricted zones. As a result, the user is informed through both SMS and voice call notifications whenever the device crosses the boundary of a Restricted Area. We also built an ESP32-based Interactive Voice Response (IVR) System using our GeoLinker board. Take a moment to see how it brings voice interaction and remote connectivity together
Watch the Multi-Geofencing System in action as it detects and monitors multiple predefined geographic zones in real time using IoT technology. This live demo showcases accurate location tracking, instant geofence event detection, and seamless system performance.
The table below summarises the different applications of the proposed system and its limitations. Understanding these applications helps identify potential use cases, while the limitations provide insight into the factors that may affect the system's performance and reliability.
| S.No | Applications | Limitations |
| 1. | Fleet management for logistics and delivery services | Requires GPS signal availability for accurate location tracking |
| 2. | Monitoring entry and exit of vehicles from homes, offices, and campuses | GPS performance may be affected in tunnels, underground areas, or dense urban environments |
| 3. | Personal vehicle safety and anti-theft monitoring | SMS and call delivery may be delayed if network connectivity is poor |
| 4. | Real-time location-based notification systems | Continuous GPS and GSM operation increases power consumption |
| 5. | Restricted area monitoring and security applications | Requires periodic maintenance of the SIM card and data services |
In conclusion, this project shows how GPS tracking can be made more useful by adding geofencing capabilities. Instead of simply displaying the current location of a device, the system is able to recognise important location-based events and notify the user automatically. By creating multiple virtual boundaries and monitoring them continuously, this multi-geofencing system using IoT can detect when a device enters or exits specific zones and respond immediately. This system demonstrates the effective integration of GPS, GSM, cloud connectivity, and geofencing into a single system. It also highlights how automated alerts can reduce the need for constant manual monitoring. We also did an interesting project on parcel tracking. Feel free to check out our How to Build a Smart Parcel Tracking System Using IoT project.
Download the complete source code, circuit schematics, and project files to build your own IoT-based Multi-Geofencing System.
⇥ How does the system know when a device enters or leaves a zone?
The GPS location of the device is continuously compared with the coordinates and radius of each geofence. When the device crosses the boundary, an entry or exit event is detected.
⇥ Why is geofencing useful?
Geofencing helps users receive automatic notifications based on location events instead of constantly checking the device's location on a map.
⇥ What happens when a geofence is crossed?
The system automatically generates alerts. In this project, SMS notifications are sent for normal zones, while SMS and phone call alerts are generated for restricted areas.
⇥ Why is a phone call used in the restricted area?
A phone call provides immediate attention and reduces the chance of missing an important security-related alert.
⇥ Can multiple geofences be created?
Yes. The system supports multiple geofences such as Home, College, Office, and Restricted Area, and can monitor all of them simultaneously.
⇥ What technology is used to determine the location?
The system uses GPS technology to obtain the real-time location of the device.
⇥ How often is location data uploaded to the cloud?
The device uploads location data to the cloud every 30 seconds under normal operating conditions.
Looking for more Raspberry Pi AI projects? Explore our CircuitDigest Cloud tutorials on Face Detection, Object Detection, and Helmet Detection. Each project includes detailed instructions, source code, hardware setup, and cloud-based AI implementation.
How to Build a Face Detection System Using a Raspberry Pi and CircuitDigest Cloud
This project is based on the same concept, in which we have built a Raspberry Pi face detection system without any complex setup. We only need a Raspberry Pi, a USB camera, and an account in CircuitDigest Cloud.
How to do Object Detection with Raspberry Pi Using CircuitDigest Cloud
That is exactly what this Raspberry Pi object detection project demonstrates. You can build a fully working object detection system on a Raspberry Pi without collecting a dataset, labelling images, or training any machine learning model.
How to Build Helmet Detection with Raspberry Pi Using CircuitDigest Cloud
So, what if there were a compact system that could make this task easier, provide accurate results, and reduce the burden on traffic police? That's exactly what this system does; here we used the Raspberry Pi, a powerful controller that can process data, analyse the images, and give the results instantly.
Modern server and data center design places increasing demands on the physical interconnect layer. At 112 Gbps and beyond, connectors are no longer treated as simple passive components; their design has a direct impact on crosstalk, impedance continuity, and mechanical integrity across the system. The following provides a technical overview of four Amphenol interconnect product families designed for high-speed data center and networking applications.
ExaMAX covers the 25 Gb/s to 56 Gb/s range, making it relevant for current-generation data center and AI infrastructure. Its beam-on-beam contact geometry is notable for two reasons: it avoids pin damage during mating, and it brings mating force down by 65% relative to blade-and-beam designs. The latter has practical consequences in dense backplanes where aggregate insertion force across hundreds of pins becomes a real mechanical concern.
Pitch options are 2 mm for density-constrained layouts and 3 mm where quad routing is preferred. The 3 mm option allows high-speed, low-speed, and power to share the same connector, which reduces PCB complexity and cost. The system spans a wide range of board architectures, including backplane, midplane, orthogonal, cabled, coplanar, and mezzanine, and is qualified against OIF, PCIe, SATA, Fibre Channel, InfiniBand, Ethernet, SAS, IBTA, and IEEE standards.
Where ExaMAX is a general-purpose high-speed platform, HD Express is built around a specific target: PCIe Gen 6. The connector is optimized for 85-ohm systems and surrounds each differential pair's mating beams with ground shielding on all four sides. At Gen 6 signal speeds, that level of per-pair isolation is necessary to maintain acceptable crosstalk margins.
The modular single-wafer construction keeps costs manageable while making incremental system scaling straightforward. Press-fit termination is used throughout, which simplifies board assembly in server, storage, and supercomputer designs where soldering at this connector density would introduce process complexity.
AirMax VS takes a different approach to isolation. Rather than surrounding differential pairs with metal shielding, it relies on air as the dielectric between adjacent conductors. The absence of metallic shields brings weight and cost down while the design still maintains signal integrity across the 12.5 Gb/s to 25 Gb/s range.
The family covers three generations: VS, VS2, and VSe. The VSe is the current performance tier, supporting 25 Gb/s with an open pin field design. Importantly, VSe is backward compatible with VS and VS2 footprints, so existing PCB layouts can be retained when upgrading. This makes the family practical for telecom, industrial, and storage applications where hardware longevity and multi-generation support are requirements rather than nice-to-haves.
XCede is designed for flexibility across both impedance and scale. It supports 85-ohm and 100-ohm configurations on the same mating interface with backward mate compatibility, and is available in 2, 3, 4, 5, and 6-pair variants supporting up to 82 differential pairs. That range accommodates deployments from small switching hardware up to large wireless infrastructure and external storage systems.
One cost-reduction feature worth noting is the availability of embedded capacitors within the connector body itself, which lowers overall system cost. The design also incorporates integrated power and guidance modules and is built for mechanical longevity in field-deployed hardware.
The above families represent four distinct approaches to high-speed interconnect design, each targeting different performance requirements, architectures, and application lifecycles. Detailed specifications, datasheets, and ordering information are available via the Mouser product links below.
Your email is safe with us, we don’t spam.
Be a part of our ever growing community.