How Zephyr Can Help You Build Greener MCU-Based Systems

Lessons from Witekio’s Internal Sustainability Initiative

At Witekio, we’re committed to building embedded software that not only performs—but lasts. As part of our internal Green Development initiative, our teams have been exploring ways to reduce the energy footprint of embedded systems, especially those built around microcontrollers (MCUs).

In a recent hands-on session, we focused on the Zephyr real-time operating system and demonstrated how small software changes—when done thoughtfully—can make a big impact on power efficiency. Using real hardware and realistic scenarios, we showed how battery life can be stretched from a few days to several years without any changes to the physical design.

This is more than a technical challenge. It’s part of our commitment to sustainability. The embedded devices we help build often live in remote, hard-to-access locations. Every additional day of battery life reduces maintenance, minimizes waste, and contributes to greener engineering.

Why Power Optimisation Is Often Overlooked

In the race to ship features and hit deadlines, power efficiency is often pushed to the end of the development cycle—or ignored entirely. That’s understandable. Power management can feel complex, the impact isn’t always immediately visible, and performance usually takes precedence.

But when embedded systems are deployed at scale—whether in consumer wearables, medical devices, smart cities, or agriculture—those extra microamps add up fast.

Optimising MCU power consumption offers:

• Longer battery life
• Fewer field replacements and less maintenance
• A lower environmental impact
• Cost savings across production and support cycles

The Setup: Zephyr, BLE, and Environmental Sensing

📷▪ Nordic dev kit NRF52840 interfaced with SHT30 sensor over I2C lines.

▪ The sensor is also powered by a GPIO pin from NRF52840.

📷▪ Nordic dev kit NRF52840 interfaced with SHT30 sensor over I2C lines.▪ The sensor is also powered by a GPIO pin from NRF52840.

To test our power-saving techniques, we built a small but realistic demo system:

• MCU platform: Nordic NRF52840-DK
• Sensor: SHT30 (humidity & temperature) via I²C
• OS: Zephyr RTOS
• Power measurement: Nordic Power Profiler Kit 2

The initial application was a standard Zephyr Bluetooth sample that periodically polled sensor values and broadcasted them via BLE. No optimisations were applied—just the defaults, including a connected console and frequent Bluetooth advertising.

Baseline measurements:

• BLE advertising: 800 µA → ~5.2 days of battery life
• BLE connected: 630 µA → ~6.6 days of battery life

Power vs Time

Step-by-Step Optimisation with Zephyr

We applied a series of incremental software optimisations using Zephyr’s configuration options, device tree features, and power management subsystems. Each change brought measurable improvements:

1. Disable Unused Peripherals

By default, the UART console was enabled for debugging—but it consumes power even when not in use. Disabling it saved over 400 µA (including the high-frequency clock it requires).

• Result: 115 µA average → 36.2 days battery life

2. Increase BLE Advertising & Connection Intervals

Slowing down BLE communication drastically reduced radio activity. Zephyr allows flexible tuning of these intervals.

3. Use Sensor More Intelligently

• We reconfigured the SHT30 sensor:
• Switched from autonomous periodic mode to “single-shot” triggered readings
• Lowered measurement repeatability (less precision, but more than enough for our demo)
• Result: 19.9–30.6 µA → 150–209 days of battery life

4. Use Advertising-Only Model

Instead of maintaining a BLE connection, the device just advertises sensor values periodically—cutting out unnecessary radio receiver use.

• Result: 17.2 µA → 242 days

5. Shrink Advertising Packet Size

By reducing the length of the BLE advertising payload (e.g. shortening the device name), the radio stays on for less time per transmission.

Result: 15.4 µA → 271 days

6. Implement “System Off” Mode

The biggest gain came from switching the application logic: instead of always running, the MCU wakes up every 15 minutes, takes a measurement, advertises it, and then returns to deep sleep (system off mode).

This requires a cold boot each time, but dramatically cuts power use between measurements.

Result: 3.13 µA → 1331 days (3.6 years)

Practical Takeaways for Greener MCU Design

Optimizing your system doesn’t require exotic hardware. With the right approach and a real-time OS like Zephyr, you can extract massive gains from your existing platform.

✅ Use power only when needed✅ Select the right sleep mode for your scenario✅ Tune your peripherals, interfaces, and operating intervals✅ Don’t assume defaults are efficient✅ Use Zephyr’s built-in features to manage power domains and sleep states

Even incremental improvements can yield meaningful results—especially when multiplied across thousands or millions of deployed devices.

Building a Culture of Sustainable Engineering

This project was part of our broader internal efforts to make sustainability a real part of our development lifecycle—not just a buzzword.

By embedding power-awareness into design from day one, we help customers build smarter, greener products with longer life cycles and lower environmental impact.