Illustration of a schematic MCU board, motion axes, and Bluetooth symbol beside the nRF54L15 Support name; not a photo or screenshot.
Original illustration of the library's MCU, IMU, and Bluetooth LE themes, not a hardware photo or screenshot.

Overview Link to section: Overview

I built nRF54L15 Support as portable C libraries for the Nordic nRF54L15 system-on-chip (SoC), which combines a processor and hardware features on one chip. I included examples for the Seeed XIAO nRF54L15 Sense.

Zephyr hardware adapters connect the libraries to an embedded operating system. The portable code can run on a host computer or sit inside an nRF Connect SDK application, using Nordic’s development toolkit.

Memory and hardware calls Link to section: Memory and hardware calls

The library code allocates no heap memory: it does not request extra memory dynamically while running. Callers own the state and buffers (the stored working data), while the Bluetooth service is a singleton, meaning there is one shared instance. Zephyr and the SDK manage their own resources.

Hardware calls run in thread context, within scheduled tasks rather than interrupt handlers. They must be serialized: callers need to keep those calls from running at the same time.

Motion and hardware support Link to section: Motion and hardware support

Orientation and motion readings Link to section: Orientation and motion readings

An inertial measurement unit (IMU) measures motion. My orientation code includes:

  • A Madgwick IMU filter, which combines motion readings to estimate orientation.
  • Quaternion normalization, which keeps the mathematical orientation representation valid.
  • Euler conversion, which expresses orientation as three angles.
  • Wrapped angles, which keep angle values within a repeating range.

Motion support includes an upstream Zephyr IMU adapter and direct LSM6DS3TR-C I2C access (a wired chip-to-chip connection). Readings can use polling (checking for data), a FIFO (first-in, first-out buffer), INT1 notifications (signals on the sensor’s interrupt pin), and suspend/resume.

Stationary gyro calibration adjusts the rotation sensor while it is still, rejecting motion and noise. Records are versioned and CRC-protected, using a cyclic redundancy check to detect corrupted data. Optional Settings/ZMS persistence saves them through Zephyr’s settings and storage systems.

Scheduling and event helpers cover fractional sample deadlines (timing samples at intervals that are not whole clock ticks), missed slots, debounce (ignoring repeated signals from one event), impact candidates (possible impacts), and GPIO wake notifications (signals from input/output pins).

Other hardware adapters Link to section: Other hardware adapters

  • SAADC: analog-to-digital conversion, with raw and millivolt reads and calibration.
  • Switched battery divider: a circuit for measuring battery voltage.
  • PWM: pulse-width modulation, with control of duty (the on-time proportion) and pulse length.
  • Audio: PDM (pulse-density modulation) capture into mono PCM16 (16-bit sound samples), capture cleanup, and PCM signal levels.
  • Temperature: die-temperature reads from the microcontroller (MCU) and IMU chips.

Telemetry and OpenFloat Link to section: Telemetry and OpenFloat

Telemetry means sending measurements to another device. My transport support includes:

  • Fixed-configuration SPI, a wired interface between chips.
  • UART, a serial connection, with receive buffering and recovery when data is lost.
  • COBS/CRC packets: consistently delimited messages with corruption checks.
  • An OpenFloat Bluetooth Low Energy (BLE) service for wireless communication.

On the host computer, Python reference codecs (message encoders and decoders), serial telemetry validation, and a UART packet echo probe (which sends packets back) support testing and integration.

My related OpenFloat Archery project uses bow-mounted motion sensing and a browser dashboard. This library provides reusable orientation, hardware, and telemetry components for that work.

Examples and verification Link to section: Examples and verification

The repository includes 15 firmware examples, native CTest suites (tests run on a host computer), and Python tests. Native tests build the production C code against simulated hardware and operating-system interfaces; the Python packet suite compares 1,028 independent vectors with the built C encoder and decoder.

The reference firmware environment is nRF Connect SDK v3.3.0, targeting xiao_nrf54l15/nrf54l15/cpuapp. The README links the example index, API contracts (the rules applications must follow), integration instructions, and hardware testing setup.

Hardware testing limits Link to section: Hardware testing limits

Hardware validation results and remaining fixture requirements are recorded in the verification record. Those checks document the tested behavior; they do not establish absolute measurement accuracy.

Current release Link to section: Current release

v0.1.0 is an experimental first release, published October 1, 2026. Public APIs (the programming interfaces applications call) may change before v1.0. The code is Apache-2.0 licensed; Nordic SDK dependencies retain their own licenses and are installed separately.