Skip to content
hw.dev
hw.dev/signal/kaga-fei-es4l15ma1-ble6-uart-api-2026
SignalCNX Software

KAGA FEI Puts a UART Command API on BLE 6.0, Collapsing the Firmware Problem for IoT Teams

KAGA FEI ships the nRF54L15 with pre-loaded firmware and a UART command API, turning BLE 6.0 integration into a board bring-up task instead of a firmware project.

#embedded#tools
Read Original

The default path for adding BLE to a new product is: pick a Nordic nRF, write the firmware, debug the stack. That path is correct for products where BLE behavior is custom. For products where standard BLE connectivity is a means to an end -- industrial sensors, medical wearables, asset trackers -- it is months of firmware engineering that does not appear in the final feature list. The KAGA FEI ES4L15MA1 changes the calculation: nRF54L15 inside, pre-loaded firmware, command-based UART API out of the box. 8.55 x 3.25 x 1.00 mm.

The nRF54L15 is a serious SoC: Cortex-M33 at 128MHz, RISC-V co-processor for software-defined peripherals, BLE 6.0 with Channel Sounding and AoA/AoD, 256KB SRAM, 1.5MB NVM. The KAGA FEI firmware layer sits on top and exposes the BLE stack, bonding, and radio through UART commands. The application processor sends AT-style commands; the module handles the stack. This is the same pattern that made ESP-AT modules the default answer for Wi-Fi in cost-sensitive designs -- hardware capability abstracted behind a serial interface so the application team never touches the radio firmware.

BLE integration drops from a firmware project to a board bring-up task. For teams where BLE 6.0 Channel Sounding ranging is the feature and not the product, this removes the radio stack expertise from the critical path entirely. The module teams at Nordic and Silicon Labs that sell to the same market on a full-SDK basis now have a readiness bar to match: a command API with the same scope as this one, or they are slower to integrate by default.