> ## Documentation Index
> Fetch the complete documentation index at: https://docs.adsumnetworks.com/llms.txt
> Use this file to discover all available pages before exploring further.

# BLG20x gateway firmware specification

> What the Adsum firmware for the Fanstel BLG20x does: two processors, edge processing, the uplink order, record sizes, over-the-air updates, recovery, the reliability and security tests, and the hardware.

The reference for the firmware on the [BLG20x](/supported-hardware/fanstel/blg20x): what runs on each processor, how it chooses an uplink, what reaches your platform and what it costs, how it is updated and tested, and what this version does not do. Every figure here was measured or verified on the evaluation board.

<div className="adsum-byline">
  <span>Board <b>Fanstel BLG20XE02C-V1</b></span>
  <span>Built with <b>nRF Connect SDK v3.4.0, Zephyr</b></span>
  <span>Measured and verified by <b>Adsum Networks, September 2026</b></span>
</div>

<Card title="BLG20x gateway firmware, datasheet (PDF)" icon="file-pdf" href="https://www.adsumnetworks.com/datasheets/BLG20x-NTN-Relay-Firmware-Datasheet.pdf" horizontal>
  Three pages to read away from the screen or send on: what it does, how it works, how it is tested, and the specifications.
</Card>

## Two processors, one gateway

The radio half listens, remembers, and sends over Wi-Fi where it can. The wide-area half chooses the mobile uplink and delivers. One serial link joins them and carries records, commands and the radio half's updates.

| | Radio half | Wide-area half |
| :- | :- | :- |
| **Processor** | nRF54LM20B, in a Fanstel BM20 module | nRF9151 |
| **Radios** | Bluetooth LE, passive and active scanning, central and peripheral; Wi-Fi 6 through the WM02C (nRF7002), where fitted | LTE-M, NB-IoT, satellite NB-NTN |
| **Owns** | Scanning, access rules, per-device state and rules, the record store, the Wi-Fi uplink, commissioning | The bearer ladder, the byte governor, encoding, time and sequence, the update client |
| **Storage** | 2 MB external flash for the record store | Its own application and bootloader slots |
| **Talks to** | Adsum IoT Coder or the commissioning page, over Bluetooth; your platform, over Wi-Fi | Your data platform, and device management |

Both halves run Zephyr behind their own MCUboot, and the link between them is framed with a sequence number and a CRC-16, with a heartbeat every second. If the link drops, both keep working and the store keeps filling.

## Edge processing, and what each uplink carries

The radio half is an nRF54LM20B, the Edge AI processor of the pair, and it is where data is reduced before anything is sent: per-device state, rules with hysteresis and hold, alerts and digests. **The gateway sends the decision, not the data**, which is what makes a satellite link of a few kilobytes a month usable.

| Uplink | What leaves the gateway | Size |
| :- | :- | :- |
| **Wi-Fi, LTE-M, NB-IoT** | Digests per device, alerts, status and a daily health record | About 1 kB per cycle |
| **Satellite NB-NTN** | Alerts and status only. Everything else waits in flash for a cheaper uplink | One 128 B datagram |

## The bearer ladder

| Rung | Bearer | When |
| :- | :- | :- |
| 1 | **Wi-Fi** | Where the WM02C is fitted and a network is set: 2.4 GHz, WPA2 or WPA3. Free, so first |
| 2 | **LTE-M** | The cheapest cellular, tried first |
| 3 | **NB-IoT** | Narrowband cellular |
| 4 | **Satellite NB-NTN** | The last resort, when nothing terrestrial is in reach |

The ladder is discovered at boot from the SIM, the silicon and the modem firmware. The unit falls to a lower rung after three failed attaches, or when a budget is spent or a rung is removed, and returns to a cheaper one on a schedule: every six hours by default, set per relay. Satellite needs the satellite edition, Nordic's NB-NTN modem firmware, an NB-NTN SIM and a position set at commissioning.

**A rung is removed for a stated reason**, never silently: no access on the SIM, silicon unsupported, modem firmware without satellite, no satellite subscription, disallowed by configuration, locked network absent, or roaming refused.

## Deployment class

| Class | Uplinks | Transport and encoding |
| :- | :- | :- |
| **TN** | Wi-Fi, LTE-M, NB-IoT | CoAP, or MQTT with or without TLS; protobuf or CBOR |
| **NTN** | Satellite only | CoAP; protobuf or CBOR |
| **TN+NTN** | The full ladder | One transport and encoding across the switch, so stored records are never re-encoded |

The class is set at commissioning and fixes the transport and the encoding for the life of the record store: a record written on LTE-M has to be sendable unchanged over satellite.

## What reaches your platform

| Record | What it is | Size |
| :- | :- | :- |
| **Digest** | One record per device per window, on terrestrial uplinks | 52 B |
| **Alert** | Raised with hysteresis and hold, sent with its age, at least once | 13 B |
| **Status** | The heartbeat: devices seen and missing, store depth, uplink, quota | 30 B |
| **Health** | Once a day on terrestrial uplinks: resets, attaches, drops | 76 B |
| **LTE-M cycle** | Up to eight records in one confirmable POST | 1,028 to 1,066 B |

Sizes are in protobuf, measured. CBOR is also supported. Records are confirmable: they leave the gateway only when your platform acknowledges them.

**A satellite datagram is 128 B**, the largest the satellite uplink accepts: 46 B of CoAP header, token and path, 53 B of payload carrying one status and two alerts, and 29 B of headroom. One real datagram was sent and acknowledged over a geostationary NB-NTN service on 13 September 2026.

## Devices, access and records

| | |
| :- | :- |
| **Access rules** | Up to 32 ordered rules, each ending in drop, count or quarantine |
| **Expected devices** | A list of up to 128, named before they are heard, each admitted on its own |
| **Rate ceilings** | Per device, so one noisy advertiser cannot fill the store |
| **State and rules** | Per device, with hysteresis and hold, so an alert is raised once rather than flapping |
| **Record store** | External flash, released only on acknowledgement; alarms are never overwritten, and every dropped record is counted |
| **Time** | 64-bit timestamps, and a gateway sequence that survives reboots |

## Commissioning, in five steps

<Steps>
  <Step title="Connect">Pair over LE Secure Connections, from Adsum IoT Coder or a phone's browser. A new device pairs only after a 3-second button hold.</Step>
  <Step title="Position">The phone's fix, typed, or surveyed, with its uncertainty.</Step>
  <Step title="Credentials">Name the unit and give it its data platform token.</Step>
  <Step title="Commission">Class, network policy, rules and expected devices.</Step>
  <Step title="Verify">Read the unit back and compare it field by field.</Step>
</Steps>

Every write is validated on the unit and refused with a reason. The [first run guide](/supported-hardware/fanstel/blg20x-first-run) walks the whole sequence on a real board.

## Updates over the air, and recovery

Updates arrive **over Bluetooth** at the desk, both processors from Adsum IoT Coder or the commissioning page with every setting kept, and **over LTE-M and NB-IoT** in the field, so a security fix or a new feature reaches the relay with no site visit. Images are signed, for both halves, with a test boot that confirms behind a health gate and rolls back automatically if it does not. Over the mobile network the radio half is updated through the wide-area half. An update never travels over satellite: it waits for a cellular uplink, so the satellite allowance is never spent on firmware. A relay claimed with your computer's key takes images from no one else. Measured on the hardware: both processors over Bluetooth in 337 seconds; 409 kB downloaded over LTE-M in 129 seconds, swapped, tested and confirmed.

| What happens | What the firmware does |
| :- | :- |
| **A processor hangs** | Its hardware watchdog reboots it and the cause is reported |
| **The link between the halves drops** | Both keep working, the store keeps filling, neither reboots |
| **An update does not confirm** | The previous image is restored at the next boot |
| **A configuration fails three boots** | The previous configuration returns, and the roll-back is reported |
| **Power is lost** | Acknowledged records are already in flash; the byte odometer is written before each send |
| **The modem is barred from attaching** | The unit reports it and waits. It never answers with a reset |

## Tested to prove it

Industrial grade is a claim about tests, so these are the tests the firmware goes through on the real board, not in a simulator. A version you customise goes through them again.

### Reliability: does it keep working?

<div className="adsum-fig">
  <div className="adsum-lanes">
    <div className="adsum-lane"><b>Function</b><span>Every feature, end to end, on every release, across a library of Bluetooth devices, SIMs and networks.</span></div>
    <div className="adsum-lane"><b>Failover</b><span>Each uplink lost and recovered, LTE-M to NB-IoT to satellite and back; SIM, network and roaming refusals.</span></div>
    <div className="adsum-lane"><b>Stress</b><span>The full device list, floods of Bluetooth traffic, bursts of alerts, a full store, weak and patchy signal.</span></div>
    <div className="adsum-lane"><b>Durability</b><span>Soak runs for days; thousands of power cycles, cold boots and brown-outs; flash wear; memory watched for leaks.</span></div>
    <div className="adsum-lane"><b>Fault injection</b><span>Power cut mid-write and mid-update, a corrupted image, a bad configuration, a stalled processor. It must recover alone.</span></div>
    <div className="adsum-lane"><b>Updates</b><span>Every release applied over the air from the last one, interrupted, resumed, confirmed, and rolled back.</span></div>
  </div>
</div>

### Security: can it be broken into?

<div className="adsum-fig">
  <div className="adsum-lanes">
    <div className="adsum-lane"><b>Boot and update</b><span>Only signed images start. Tampered, unsigned and downgraded images are refused.</span></div>
    <div className="adsum-lane"><b>Hardening</b><span>Debug ports locked in production; no open shell, no default password, no secret left in the image; keys in secure storage.</span></div>
    <div className="adsum-lane"><b>Bluetooth</b><span>Pairing, replay and man-in-the-middle attacks; unauthenticated writes refused; a flood cannot fill the store.</span></div>
    <div className="adsum-lane"><b>Network</b><span>Encrypted transport checked; malformed, oversized, replayed and spoofed messages refused.</span></div>
    <div className="adsum-lane"><b>Fuzzing, pen test</b><span>Malformed data thrown at every input for hours; static analysis; a penetration test of each major release.</span></div>
    <div className="adsum-lane"><b>Supply chain</b><span>A software bill of materials (SBOM) from the real build, scanned against known vulnerabilities on every release.</span></div>
  </div>
</div>

Radio type approval and electromagnetic compliance belong to the hardware: FCC, ISED and CE are pending at Fanstel.

## CRA readiness

**Security fixes are free for five years** from each licence's first download: the support period the EU Cyber Resilience Act asks of a manufacturer. **Every production licence includes the evidence pack**: the certificate, the test report, an SBOM in SPDX for each build, the advisory register and VEX, with the secure-by-design posture the [CRA readiness check](/cra-readiness) reports and the update, roll-back and vulnerability-handling behaviour described on this page. The demo carries none of it. Licences are per relay at [www.adsumnetworks.com](https://www.adsumnetworks.com/licensing/).

## The hardware, from Fanstel

| | |
| :- | :- |
| **Cellular and satellite** | Nordic nRF9151, supporting LTE and NTN satellite, with a pre-installed internal LTE antenna |
| **Bluetooth and Edge AI** | Fanstel BM20 module on the Nordic nRF54LM20B, Bluetooth 6.0: Cortex-M33 at 128 MHz, 2036 KB flash, 512 KB RAM, and an Axon NPU for edge AI. Models with a chip antenna, a PCB antenna, or a power amplifier |
| **Storage** | 2 MB external flash, on the Bluetooth side |
| **SIM** | Nano-SIM socket, with an eSIM footprint |
| **Models** | BLG20BC and BLG20BC02C: one image, the Wi-Fi found at boot. BLG20BF and BLG20XE: ask us |
| **Wi-Fi 6** | Fanstel WM02C module (nRF7002) on the BLG20BC02C: 2.4 and 5 GHz; the firmware's first uplink where a network is set |
| **Positioning** | No GNSS on the BLG20XE02C: the position is set at commissioning |
| **Controls** | Reset and DFU buttons, indicator LEDs, a buzzer; one SWD header per processor |
| **Power** | USB-C, with a USB-C AC adapter and a 2 m cable |
| **Size and mounting** | 90 × 65 × 28 mm, desk or wall mount |
| **Operating temperature** | −40 to +80 °C |
| **Ingress protection** | IP51 |
| **Certifications** | FCC, ISED and CE pending at Fanstel, who designs, makes and sells it: [fanstel.com](https://www.fanstel.com/blg20cbwg20c) |

Hardware facts are Fanstel's, from [fanstel.com](https://www.fanstel.com/blg20cbwg20c) and the schematic Fanstel publishes for the BLG20. The BLG20 comes in several models, so check the one you order.

## Flash, read from the shipped images

| Image | Used of the partition |
| :- | :- |
| nRF9151 application | 393.3 of 448 KB |
| nRF9151 bootloader | 29.6 of 64 KB |
| nRF54LM20B application | 352.0 of 512 KB |
| nRF54LM20B bootloader | 53.6 of 62 KB |

## What this version does not do

* **The evidence pack** comes with the production licence, not with this demo version. See [CRA readiness](#cra-readiness).
* **The modem firmware** is installed before deployment and cannot be updated in the field.
* **No GNSS fix**: the BLG20x's position is set at commissioning. For a relay that finds its own, see the [LBG20x](/supported-hardware/fanstel/lbg20x).
* **Evaluation images** carry no production signing keys yet, so no security claim is published for them.
* **Radio, capacity and power figures** are published for the shipping configuration once it is confirmed.

<Note>
  Figures were measured on the evaluation configuration, a BLG20XE02C-V1 board.
</Note>

<CardGroup cols={2}>
  <Card title="The BLG20x" icon="microchip" href="/supported-hardware/fanstel/blg20x">
    The board, the firmware, and every way to have it.
  </Card>

  <Card title="The first run, step by step" icon="route" href="/supported-hardware/fanstel/blg20x-first-run">
    Flash both halves, commission, and see readings on your platform.
  </Card>

  <Card title="Datasheet (PDF)" icon="file-pdf" href="https://www.adsumnetworks.com/datasheets/BLG20x-NTN-Relay-Firmware-Datasheet.pdf">
    Three pages, for reading away from the screen.
  </Card>

  <Card title="Satellite IoT: NB-NTN" icon="satellite" href="/satellite-ntn">
    What a satellite link is good for, and what it costs.
  </Card>
</CardGroup>


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.