DEV Community: Pratha Maniar

The Chip That Has No ADC but Still Knows When Its Battery Is Low

Pratha Maniar — Mon, 20 Jul 2026 13:11:05 +0000

Somewhere out in the field, a tiny battery-powered sensor is quietly dying. No warning light, no alert, nothing. One day it just stops responding, and nobody knows why until someone finally goes and checks it by hand.

How do you stop that from happening? The obvious answer is measure the battery voltage. But what if the chip you are using was never given an ADC(Analog to Digital Converter) to measure anything with?

No ADC means no voltage reading, right? Not quite. Nordic's nRF5x family, including the nRF51 and nRF52 series, has a sneaky little piece of analog hardware built right into the silicon that does not care about your missing ADC at all. It is called POFCON, the Power Failure Comparator, and it solves the whole problem with almost no power budget.

Here is the story of how it works, and why it beats a traditional voltage divider for this job.

The Familiar Way: ADC + Voltage Divider

This is the setup everyone learns first.

Two resistors split the battery voltage down to something the ADC can read
Firmware wakes up, powers on the ADC, takes a sample, powers it back down
The reading gets compared against a lookup table to decide battery health

You get a real number - a full discharge curve, a percentage remaining, whatever you want.

The catch:

The divider leaks current constantly, unless you add a switch to gate it (more parts, more GPIOs, more headaches)
Every ADC read costs power to spin up the analog block, settle, sample, and shut back down

Fine for a device on mains power. Brutal for a coin cell that is supposed to sleep for months.

The Sneaky Way: POFCON

POFCON, short for Power Failure Comparator, is a small analog comparator circuit built directly into the chip's silicon during manufacturing, sitting inside the power management block. It is real hardware, not a software feature - it is there whether you use it or not.

You configure a voltage threshold, and the comparator watches the supply rail against an internal reference. It flags the result the moment the rail crosses the line.

No sampling, no conversion, no ADC involved. It just answers one question: are we above the threshold or below it?

A minimal polling setup at the API level (nRF5 SDK) looks like this:

// Configure the comparator threshold and enable it
nrf_power_pofcon_set(NRF_POWER, true, NRF_POWER_POFTHR_V23); // threshold ~2.3V

// Later, on wake or on a timer, just read the flag
bool battery_low = nrf_power_pofcon_get(NRF_POWER, NULL);

Using nRF Connect SDK / Zephyr instead of the nRF5 SDK? The snippet above is a legacy nRF5 SDK register-level call. In NCS, power-fail detection is configured through devicetree/regulator bindings rather than these direct API calls - check the nrfx_power driver docs for the equivalent on your SDK version before copying this in.

Why this is clever: it uses zero external components and burns almost no power, compared to a divider that leaks current and an ADC that costs power on every read.

No external divider needed - it watches the internal rail directly
No ADC powers up, ever
It exists specifically for chips that skip a full ADC to save die space and cost

This is not a one-chip party trick. Plenty of low-cost, low-power parts skip the ADC for the same reason: cheaper silicon and lower standby current. The name changes depending on who made the chip, but the idea stays the same - a low-power comparator watching the supply rail.

A few places you'll run into it:

Across the Nordic nRF5x lineup (nRF51, nRF52 series, and some nRF24 parts), it's called POFCON, exactly as covered here
On STM8 and value-line STM32 parts, the equivalent is usually a Brownout Detector (BOD) or Low Voltage Detector (LVD)
On other budget Bluetooth SoCs, including parts from vendors like Nations Technologies and Telink, you'll find similar brownout or low-voltage detection hardware, just under their own naming

A quick word of caution before you go looking for one: not every chip has this.

Some very low-cost parts skip both the ADC and any power-fail comparator, brownout detector, or low-voltage detector entirely
Do not assume it's there just because the chip is marketed as low power
Always open the datasheet first, confirm the block actually exists, and check its threshold options before you design your battery monitoring approach around it

The Takeaway: If you just need a "low battery" signal and nothing more, do not reach for an external voltage divider circuit. Check the datasheet for a power-fail comparator, brownout detector, or low voltage detector block first. In Nordic parts that block is POFCON. On other vendors it will have a different name, but it is very likely already sitting there, unused, ready to do this exact job for close to zero extra power.

The Real Tradeoff

	ADC + Voltage Divider	POFCON
What you get	Actual voltage value	Above or below threshold, nothing else
Detail level	Full discharge curve possible	One fixed threshold
Power cost	Divider leaks current, ADC costs power per read	Barely anything
Setup effort	Calibration, lookup tables	Set a threshold and move on
Good for	Battery percentage, health tracking over time	A simple low-battery flag, cheap

If you need the full story of your battery's life, use an ADC. If you just need to know when to shout "replace me," POFCON wins on power every single time.

Wrapping Up

Low-power design is always a game of tradeoffs. The instinct is usually to reach for an ADC by default, but hardware like POFCON is a good reminder that less is sometimes more when battery life is on the line.

Secure Firmware Updates with a Secure Element: Building Trust Into the Bootloader

Pratha Maniar — Fri, 22 May 2026 10:33:13 +0000

Imagine your embedded device is deployed somewhere in the field - a smart meter, an industrial sensor, a vehicle ECU. You find a critical bug. You push a fix. The device downloads the new firmware over the air and flashes it.

But here's the uncomfortable question: how does the device know that firmware actually came from you?

Anyone sitting on the same network could send a firmware package. A compromised update server could serve a malicious binary.

Without a proper trust mechanism, your device is one bad OTA away from running someone else's code.

This is the problem a Secure Element solves - and this post walks through exactly how it works, from the chip itself to the bootloader verification flow.

What Is a Secure Element?

A Secure Element (SE) is a small, tamper-resistant chip whose one job is to safely store cryptographic keys and run crypto operations - without ever exposing those keys to the outside world.

Think of it as a locked safe soldered onto your board. Even if an attacker gets full control of your main CPU, dumps your flash, or probes your bus lines, the keys inside the SE remain out of reach.

It protects against:

Physical attacks (chip probing, decapping, glitch injection)
Software attacks (privilege escalation, memory dumps)
Side-channel attacks (power analysis, timing attacks)

Common SE chips used in embedded systems: ATECC608A, SE050, TPM 2.0.

What Can a Secure Element Do?

A secure element is not just a key storage box - it is a self-contained cryptographic engine. Here is what it can do:

1. Key generation and storage - private keys are created and stored inside the chip and never leave it, not even during factory programming

2. Digital signatures (ECDSA - Elliptic Curve Digital Signature Algorithm / Ed25519) - signs or verifies data using stored keys; the core operation behind firmware verification

3. Key agreement (ECDH - Elliptic Curve Diffie-Hellman) - two parties derive a shared encryption key from exchanged public keys, without the secret ever crossing the wire

4. Symmetric encryption (AES - Advanced Encryption Standard) - encrypts and decrypts data directly on-chip; used to protect firmware package contents in transit

5. Hashing (SHA-256 - Secure Hash Algorithm) - computes a fixed 32-byte fingerprint of any data; one byte changed equals a completely different hash

6. True random number generation (TRNG) - hardware entropy source for generating nonces, session keys, and signature randomness

7. Monotonic counter - a number that only goes up, never down, even across power cycles; blocks firmware downgrade attacks

8. Certificate storage - stores X.509 certificates to prove device identity during TLS(Transport Layer Security) or OTA authentication

Why Firmware Updates Need Signature Verification?

When a device receives an OTA update, it has no way of knowing by default whether that firmware is genuine or has been tampered with.

An attacker could:

Intercept the OTA transfer and swap in malicious firmware
Replay an older, vulnerable firmware version
Extract a key from plain flash memory, sign a fake binary, and serve it

Signature verification closes this. The firmware is cryptographically signed by the manufacturer before it ever leaves the build system. The bootloader verifies that signature on the device before touching a single flash sector. If verification fails, nothing gets flashed.

The Secure Element is what makes this guarantee solid - the verification key lives inside hardware-protected storage, not in flash memory where it can be read or replaced.

The Verification Flow - Step by Step

On the Manufacturer Side

Firmware binary is compiled, and a version header is attached (version number, hardware revision, and magic bytes).
A SHA-256 hash of the entire firmware is computed - a fixed 32-byte fingerprint of the binary.
That hash is signed using an ECDSA private key stored in a Hardware Security Module (HSM - Hardware Security Module) on the build server. The result is a signature.
Package is uploaded to the OTA server. The final package ships as:

{ firmware binary + version header + ECDSA signature }

On the Device Side - Inside the Bootloader

1. Firmware package arrives and is written to a staging area in flash.
   (Primary firmware slot is untouched at this point.)

2. Bootloader reads the firmware header:
   - Magic number   → is this a valid package format?
   - Hardware rev   → is this firmware built for this exact hardware?
   - Version number → is this newer than what is currently running?

3. Bootloader computes SHA-256 over the full firmware binary.
   → 32-byte hash of exactly what was received.

4. Bootloader hands the hash + the signature to the Secure Element:
   SE.verify(hash, signature, public_key)

5. Secure Element runs ECDSA verification internally:
   - Uses the public key it has stored inside it
   - Mathematically checks whether the signature was produced
     by the matching private key over this exact hash
   - Returns PASS or FAIL - nothing else leaves the SE

6a. PASS:
    → Erase the primary firmware slot
    → Copy firmware from staging to primary slot
    → Increment the SE monotonic counter (locks out older versions)
    → Reboot and jump to new firmware entry point

6b. FAIL:
    → Erase the staging area
    → Boot the existing firmware as a safe fallback
    → Log the failure for reporting on next server connection

The key insight: the private key that signed the firmware on the build server never exists on the device. Only the public key is on the device - locked inside the SE. A public key can verify signatures but cannot create them. So even if an attacker fully dumps the device's flash, they cannot forge firmware that passes verification.

Anti-Rollback: Why a Valid Signature Is Not Enough

Here is a subtle attack worth understanding. Firmware v1.2 had a vulnerability - you patched it in v1.3. But v1.2 was real firmware, signed by your real private key. Its signature is completely valid.

An attacker replays the old v1.2 package. Signature check passes. Device flashes vulnerable firmware. You are back to square one.

The fix is the SE monotonic counter - a number stored inside the SE that only ever increments.

SE stores: minimum_allowed_version = 1.3

Bootloader receives firmware v1.2:
  1.2 < 1.3  →  REJECTED, even though signature is valid.

After successfully flashing v1.4:
  SE increments counter → minimum_allowed_version = 1.4
  This cannot be undone by software.

Because the counter is inside the SE, no software attack - not even a full OS compromise - can reset it.

Conclusion

Firmware security is not just about encryption or passwords. It is about establishing a chain of trust - from the moment code leaves your build system to the moment a device executes it.

The Secure Element is the hardware anchor of that chain. The private key stays with you. The public key stays locked in silicon on the device. The bootloader does the verification. And the monotonic counter makes sure there is no going back.

How Does a Fingerprint Turn Into a Secure Digital Identity?

Pratha Maniar — Fri, 19 Dec 2025 06:58:47 +0000

Fingerprint-Based Security: From Capture to Secure Matching

In a world where passwords are forgotten, stolen, or guessed, biometrics provides a far more reliable form of security, an identity based on who you are. Among all biometric technologies, fingerprint recognition remains the most widely deployed due to its accuracy, speed, and ease of use.

But what really happens when a finger touches a sensor?
How does a physical pattern on human skin turn into a secure digital identity?

Let’s explore the complete journey, from fingerprint formation to secure matching.

1. What Is a Biometric System?

A biometric system identifies or verifies an individual using unique biological traits. Fingerprints are especially effective because they are unique, permanent, and easy to capture.

Biometric systems operate in two main phases:

Enrollment – registering a user’s biometric data.
Authentication – verifying identity using live input.

2. Ridges and Valleys: The Foundation of Fingerprints

A fingerprint is made up of alternating raised lines (ridges) and depressions (valleys) on the surface of the skin.

Ridges are the elevated portions that make contact with a surface.
Valleys are the spaces between ridges.

These ridge-valley patterns form unique shapes such as loops, whorls, and arches, which are determined before birth and remain stable throughout life.

3. How a Fingerprint Image Is Generated

When a finger is placed on a fingerprint sensor, ridges touch the surface while valleys remain slightly away.

Depending on the sensor type:

Capacitive sensors detect electrical differences between ridges and valleys.
Optical sensors detect reflected light from ridge contact points.
Ultrasonic sensors map depth variations using sound waves.

This interaction creates a contrast-rich image, where:

Dark areas usually represent ridges.
Light areas represent valleys.

This raw image is the digital representation of the fingerprint’s physical structure.

4. Pre-Processing: Enhancing Ridges and Valleys

The raw fingerprint image may contain noise due to finger pressure, moisture, or skin condition. To improve clarity, the system performs preprocessing, which includes:

Contrast normalization.
Noise reduction.
Ridge enhancement.
Binarization (ridges vs valleys).
Thinning (reducing ridges to single-pixel width). These steps sharpen the ridge-valley structure, making feature extraction more reliable.

5. Feature Extraction: Identifying Unique Points

Rather than storing the entire fingerprint image, the system extracts distinct features, mainly minutiae points.

Minutiae occur where:

A ridge ends.
A ridge split into two (bifurcation).

Each minutia is defined by:

Its location.
Its orientation.
Its type. A fingerprint typically contains dozens of usable minutiae, which together form a unique digital signature.

6. Enrollment: Creating a Secure Fingerprint Template

During enrollment:

Minutiae are extracted from each scan.
A stable reference template is generated.
The template is encrypted and stored securely.

7. Secure Storage: Protecting Biometric Identity

Because biometric data cannot be changed like a password, security is critical. Modern systems use:

Encrypted template storage.
Secure elements or trusted execution environments.
Hardware-based cryptographic protection.

This ensures fingerprints cannot be reconstructed even if storage is compromised.

8. Authentication: Matching Ridges and Patterns

During authentication:

A live fingerprint is captured.
Its features are extracted.
The live template is compared with the stored template.

Matching algorithms align ridge patterns, compare minutiae relationships, and compute a similarity score. Access is granted only if the score crosses a secure threshold.

9. Accuracy and Anti-Spoofing Measures

To prevent fake fingerprints, systems use liveness detection, checking factors like skin conductivity, ridge deformation, and depth/texture variations to ensure the fingerprint comes from a real, live finger.

Conclusion

Fingerprint biometrics use unique ridge and valley patterns to create a secure digital identity. From image capture to minutiae extraction and encrypted matching, every step ensures accuracy, privacy, and security.

What seems like a simple touch is actually a powerful combination of biology, signal processing, cryptography, and embedded engineering, making fingerprints one of the most trusted security mechanisms in modern systems.

A Deep Dive Into ESP-CSI: Channel State Information on ESP32 Chips

Pratha Maniar — Wed, 19 Nov 2025 12:21:23 +0000

Most people know Wi-Fi only as a way to connect phones, laptops, and IoT devices to the internet. But Wi-Fi can do much more.

Espressif’s ESP-CSI (Channel State Information) technology allows ESP32-series chips to “sense” what is happening in the environment using only Wi-Fi signals-no cameras, no radar, no extra sensors.

Every Wi-Fi signal changes as it passes through a room.
People, walls, furniture, movement-everything affects the signal slightly.
ESP-CSI captures these tiny changes in the Wi-Fi channel and turns them into meaningful data.

This makes it possible to detect:

Human presence
Motion
Gestures
Indoor positioning
Environmental changes

And all of this works using only an ESP chip and Wi-Fi.

Why Is ESP-CSI Better Than RSSI?

Normally, Wi-Fi devices only report RSSI (Received Signal Strength Indicator), which is a single number representing signal strength.
However, CSI provides much more detailed information, including:

How each frequency of the Wi-Fi signal was changed.
How much it was absorbed or reflected.
How much noise is in the environment.
How the signal phase rotated.
How the signal was delayed.

Aspect	RSSI	CSI
What it shows	Overall signal strength (one value)	Detailed channel info (amplitude + phase per subcarrier)
Detail Level	Low	Very high
Sensitivity	Detects big changes only	Detects tiny movements (even breathing)
Use Cases	Basic connection quality, coarse location	Motion sensing, presence, gesture, indoor positioning
Interference	Easily affected	More stable if environment doesn’t change
Accuracy	Low	High

How Does ESP-CSI Work?

Wi-Fi uses OFDM, which splits one Wi-Fi channel into many smaller frequencies called subcarriers. Each Wi-Fi packet carries amplitude and phase information for every subcarrier.

When these subcarriers travel through the environment, they get affected by:

People absorbing energy.
Moving objects shifting the wave pattern.
Walls reflecting the signal.
Furniture and air slightly bending the waves.

The ESP chip measures two things for each subcarrier:

Amplitude-how strong the signal became.
Phase-how much the wave rotated or was delayed.

Together, this forms the CSI (Channel State Information) array.

When someone moves:

Amplitude values fluctuate.
Phase values shift in characteristic patterns.
Even small movements cause detectable changes.

These tiny variations act as “clues” about what happened in the environment. The ESP device captures this at the PHY layer, then exposes it to the user through CSI callback events in Espressif’s API.

Features of ESP-CSI

1. Detailed Channel Insights
CSI provides amplitude and phase information for every Wi-Fi subcarrier, giving much more detail than a single RSSI value. This allows precise sensing of environmental changes.

2. No Extra Hardware Required
Works on standard ESP32-series chips (ESP32, S2, C3, C6, etc.) using built-in Wi-Fi no special sensors or NICs needed.

3. High Sensitivity
Can detect both large movements and very small changes, such as breathing or slight object shifts.

4. Real-Time Processing
ESP chips can analyze CSI data locally and instantly, enabling fast responses without needing external servers.

5. Flexible Operating Modes
Supports multiple ways to collect CSI, including sniffer mode, router-based CSI, and device-to-device communication for advanced setups.

6. Stable and Robust
CSI amplitude data stays reliable even with typical indoor interference like chargers or other electronic devices.

7. Easy Software Integration
Fully supported in ESP-IDF and compatible with Espressif cloud tools, with open-source utilities to process and analyze CSI data.

Where Is ESP-CSI Used?

Human activity detection: Detect presence, movement, gestures, or even subtle actions like breathing-useful for security, elder care, and smart homes.

Indoor positioning: Provide accurate indoor location tracking for people or devices in buildings like malls, airports, and hospitals.

Environmental monitoring: Sense small changes in the environment through Wi-Fi signal variations.

Intrusion detection: Act as a motion sensor to detect unauthorized movement without cameras.

Asset tracking: Track the real-time location of important items in places like warehouses or hospitals.

Smart home automation: Enable location-based actions, such as auto-adjusting lights, AC, or appliances.

Chip Performance Ranking

Espressif categorizes the CSI capability of its chips approximately in the following order.
ESP32-C5 ＞ ESP32-C6 ＞ ESP32-C3 ≈ ESP32-S3 ＞ ESP32.

Meaning:

Newer chips, like C5 & C6, → better CSI quality.
C3 & S3 → good general performance.
Original ESP32 → lowest but still works.

How Can ESP-CSI Be Implemented?

Espressif provides three ways to obtain CSI data.

Method 1: Getting CSI from a Router (get_router_csi)

Setup: One ESP device + a router.
Process: ESP sends ping packets to the router. The router replies with packets containing CSI information. ESP receives those packets and extracts CSI (amplitude, phase, etc.). This is the simplest method-ideal for beginners.

Method 2: Exchanging CSI Between Two ESP Devices (get_device_csi)

Setup: Two ESP chips + router acting as a relay.
Process: Both ESP devices send ping packets to the router. The router forwards packets to the correct device. When Device B receives a ping from Device A, it replies with CSI. Device A then extracts CSI information.

Method 3: Getting CSI Using a Dedicated Packet Sender (get_broadcast_csi)

Setup: A device that sends broadcast packets + multiple ESP receivers.
Process: The transmitter sends broadcast packets on different Wi-Fi channels. All ESP devices (in monitor mode) receive these packets. Each ESP extracts CSI data independently.

Want to dive deeper?
Check out Espressif’s official CSI documentation here:
https://docs.espressif.com/projects/esp-techpedia/en/latest/esp-friends/solution-introduction/esp-csi/esp-csi-solution.html