LoRa LPWAN 410 MHz to 470 MHz FPC Antennas
LoRa LPWAN FPC antennas offer a wideband coverage of 410 MHz to 470 MHz
RHP50000 Radiation-Tolerant 12.5 A Silent Switcher® 2 Buck Regulator
RHP50000-CSL: buck DC/DC converter providing up to 12.5A output current from a 2.25V to 5.5V input
XtremeSense™ TMR technology
Highest magnetic sensitivity, lowest power consumption, smaller size compared to Hall, AMR, and GMR
5 Hidden Features of the Arduino UNO R3 You Probably Didn’t Know
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.
1. Your Arduino Can Measure Its Own Temperature
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
How to Demonstrate It
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:
- An LM35
- A DHT11
- A TMP36
Any other external temperature sensor
The sensing circuit is already inside the microcontroller.
One Important Catch
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.”
Video Reference
How to Read the Internal Temperature Sensor in Arduino - Electro Hijibiji
https://www.youtube.com/watch?v=43l6Ibk7Spw
2. Your Arduino Can Detect When Its Supply Voltage Gets Too Low
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.
How to Demonstrate It
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
Safety
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.
Video Reference
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.
3. Your Arduino Can Literally Go to Sleep
The ATmega328P doesn't have to keep its CPU fully active all the time.
It has six hardware sleep modes:
- Idle
- ADC Noise Reduction
- Power-save
- Power-down
- Standby
- Extended Standby
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.
How to Demonstrate It
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.
Why is this Useful?
Sleep modes are useful for:
- Battery-powered sensors
- Remote data loggers
- Portable electronics
- Environmental monitors
- Low-power embedded systems
The basic idea is simple:
Don't spend power doing nothing.
Video Reference
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.
4. Your Arduino Can Restart Itself When Software Gets Stuck
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.
How to Demonstrate It
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.
Where is this Useful?
Watchdog timers are especially useful in:
- Robotics
- IoT devices
- Remote sensors
- Industrial controllers
- Security systems
- Unattended embedded systems
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.
Video Reference
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.
5. Your Arduino Can Wake Up When a Configured Pin Changes
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.
How to Demonstrate It
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
Why is this Different from Normal Button Reading?
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.
Video Reference
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 Tested JBD, Daly & JK BMS After the E-Rickshaw Hack — The Vulnerability Is in the Hardware
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.
A Brief Primer on BLE
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.
Our Investigation
Testing the Official Apps
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 - "JBD BMS" and "XiaoXiang Electric"
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 - "DALY BMS"
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 - "JK BMS"
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.
Going Deeper: Protocol-Level Analysis
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.
Comparative Vulnerability Analysis
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.
Our Test Setup
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.
Demonstrating the Vulnerability: The BMS Analyser App
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.
Architecture
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.
Driver Abstraction
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 User Interface
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.
The Solution: BMS Protector
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.
The Core Insight
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.
How It Works
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.
Limitations and Recommendations
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.
GitHub Repository
Conclusion
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.
Lessons from Building a Hardware Startup with Yatin, Nosh Robotics
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.
How AI Is Transforming Electronic Component Procurement | 1Buy.AI's Nitin Jain
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 on Building an Indigenous Surveillance Stack for India
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.
How to Build an IoT-Based Multi-Geofencing System for Smart Tracking
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.
Table of Contents
How Multi-Geofencing Using IoT Works
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.
Component Requirements for IoT Geofencing System
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 | - |
Hardware Configuration of Geofencing Using IoT
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.
Code Explanation for the Multi-Geofencing System Using IoT
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.
Troubleshooting the GPS Geofence Alert System
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. |
Output Demo of the GPS Tracking System Using IoT
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
Live Working Demo of the Multi-Geofencing IoT System
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.
Applications and Limitations of the Multi-Geofencing System Using IoT
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 |
Conclusion for the IoT Geofencing System Project
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.
IoT Geofencing System GitHub
Download the complete source code, circuit schematics, and project files to build your own IoT-based Multi-Geofencing System.
Frequently Asked Questions
⇥ 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.
Related Raspberry Pi AI Projects Using CircuitDigest Cloud
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.
Amphenol's Interconnect Solutions: A Technical Overview of ExaMAX, HD Express, AirMax VS, and XCede
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 High-Speed Interconnect System
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.
HD Express Interconnect System
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 Connectors
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 Backplane Connectors
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.
Availability
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.
