> ## 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 first run, step by step > A complete first run on the Fanstel BLG20x: from an unflashed board to a gateway sending its own readings to your platform, and a command travelling back. No prior knowledge of the board or of Adsum IoT Coder assumed.
How many steps?EightTwo of them wait on the unit's own radio cycle.
What gets flashed?Both halvesThe Bluetooth half and the wide-area half, each from its own probe.
Where do readings go?Your platformYour own tenant. Nothing of ours in the path.
What do you need to know?Nothing yetNo prior knowledge of the board or of Adsum IoT Coder.
Gateway Fanstel BLG20XE02C-V1 Firmware the BLG20x evaluation pair Captured by Adsum Networks, 17 September 2026
The board, what the firmware does, and every way to have it. ## What you are building The BLG20x is a **gateway**. It listens for small Bluetooth sensors around it, keeps what they say, and forwards it over a mobile network to a platform you choose. Nothing you do here writes any of your data to Adsum. ### The hardware The BLG20x is made and sold by [Fanstel](https://www.fanstel.com/blg20cbwg20c), as a desk- or wall-mount unit with the radios, antennas and power supply already in the box. This guide was captured on a **BLG20XE02C-V1**; the other models in the family run the same evaluation firmware. | Part | What it is | What it does in this run | | :- | :- | :- | | Bluetooth module | Fanstel **BM20**, built on Nordic's **nRF54LM20B** (Bluetooth 6.0) | Hears your sensors, keeps what is worth keeping, and is what the commissioning page talks to | | Cellular modem | Nordic **nRF9151**: LTE-M, NB-IoT and NB-NTN satellite | Attaches to the mobile network and sends the readings to your platform | | Power | USB-C, adapter and 2 m cable included | Plug it in. No battery to charge | | Enclosure | IP51, 90 × 65 × 28 mm | For indoor use: a bench, a shelf or a wall | The family has five models, which differ in antenna, output power and extra radios: **BLG20BC**, **BLG20BF** (better antenna), **BLG20XE** (adds a power amplifier), **BWG20BF** (adds Wi-Fi 6) and **BLG2H20F02C** (Wi-Fi 6 and a CAN port). The firmware uses Wi-Fi where the module is fitted and a network is set; it does not use CAN. Datasheets, models and ordering are on [Fanstel's BLG20 page](https://www.fanstel.com/blg20cbwg20c). The important thing to understand before you touch it: **this board is two computers, not one**, and almost every confusing moment in a first run comes from forgetting that. Sensors advertise to the Bluetooth half, which passes digests over a two-wire link to the wide-area half, which sends them over the mobile network to your platform. Sensors advertise to the Bluetooth half, which passes digests over a two-wire link to the wide-area half, which sends them over the mobile network to your platform. ### Adsum IoT Coder, in one paragraph Adsum IoT Coder is a VS Code extension. For this run it does three jobs: it knows the procedure for this board, it fetches and verifies the firmware images, and it drives the programming commands with your approval. You can do every step by hand instead (the commands are in this guide), but the extension is what stops you flashing the wrong chip. ## What you need *about 20 minutes to gather* | You need | Why, and what to watch | | :- | :- | | **The BLG20x board** with **two debug probes**, one on each SWD header | Two chips, two probes. They are not interchangeable and the labels will not save you | | A **SIM** in the board, on a plan that allows LTE-M or NB-IoT | The wide-area half needs a network to attach to | | Nordic's **`nrfutil`** on your PATH | Everything that touches the chips goes through it | | **VS Code** with the **Adsum IoT Coder** extension, signed in | The BLG20x card appears once your account has access to this board | | **Chrome or Edge** on a desktop, or Chrome on Android | Commissioning uses Web Bluetooth. **No browser on iOS can do it** | | A **ThingsBoard** account (free), or another device-data platform | See below. Get this **before** you start: it is the one prerequisite that interrupts the run | | A **BLE sensor** within a few metres | Anything that advertises. You will need its address | The BLG20x board, component side, with an nRF54LM20 DK and an nRF52840 DK above it, each connected to the board by a 10-pin ribbon cable The same setup from the other side of the BLG20x board, showing where the two ribbon cables plug into its debug headers **The two probes on the bench.** Each DK reaches one half of the gateway over a 10-pin ribbon cable to that half's debug header; USB-C powers the board. **A DK's name says nothing about which half it programs:** here the nRF54LM20 DK is cabled to the nRF9151 half and the nRF52840 DK to the nRF54LM20B half. That is why step 2 reads the silicon behind each probe before anything is written. ### ThingsBoard: what it is, and why you need it **ThingsBoard** is an IoT platform: a service that devices send their readings to, and that stores them, charts them on dashboards, raises alarms on them and sends commands back. It is open source, and **ThingsBoard Cloud** is the same software run as a hosted service, so there is nothing to install. The gateway needs one because it only *collects*. It keeps readings locally, but a gateway that only keeps them is a logger: it needs somewhere off-site to send them, a place to look at them, and a way to reach the unit when it is in the field. In this run ThingsBoard is where three things happen: * **Step 6**: the unit's readings arrive, each with the device's own timestamp; * **Step 7**: you send a command back to the unit from the device's page; * the **device token** ThingsBoard issues is what the unit presents to prove it is yours. **The account is yours, not ours.** The readings go from the gateway straight to your tenant. Adsum is not in that path and never sees your data. ### Where to create the account | Your data should live in | Sign up at | | :- | :- | | North America | [thingsboard.cloud/signup](https://thingsboard.cloud/signup) (the one used in this guide) | | Europe | [eu.thingsboard.cloud/signup](https://eu.thingsboard.cloud/signup) | Pick the region when you sign up; your devices and data stay in it. The **Free** plan is enough to evaluate one gateway: 5 devices and 1 million data points a month, no card required. ThingsBoard's current plans are on its [pricing page](https://thingsboard.io/pricing/). The firmware is set up for ThingsBoard, but it is not tied to it. The unit sends **CoAP with a protobuf payload**, so any platform that accepts those will do. If you use another one, what changes is the host, the port, and how you define the device on your side. **Create it now, not at step 6** You will need a tenant, a device profile, a device on that profile, and the **device token** it issues. Five minutes up front keeps the board work unbroken. ## The whole run at a glance Eight steps. Two of them wait on the unit's own radio cycle, which is where most of the waiting is. Eight steps: install, flash, commission, set class, admit a sensor, data plane, command back, done. Steps four and eight wait on a radio cycle. Eight steps: install, flash, commission, set class, admit a sensor, data plane, command back, done. Steps four and eight wait on a radio cycle. ## Step 1a: Start the run Open VS Code, open the Adsum IoT Coder panel, and open a folder for this project. The panel offers a few ways in; you want the one for this board. The Adsum IoT Coder panel listing suggested runs The BLG20x card offering to build it yourself or use the licensed demo images **If you do not see the card** The card appears when your account has access to this board, or when a BLG20x is detected on a probe. If neither is true, ask for access from the panel; it names what you are asking for. ## Step 1b: Install the images *about 2 minutes* The install lists what it will write, checks each file against a recorded hash **before** writing it, and states the firmware's limits before anything lands on disk. The three limits of the evaluation firmware stated before installing The install command listing bundle members The two hex images and the licence file in the project explorer A table of the three installed files and their paths ## Step 2: Flash both halves *about 5 minutes* Two chips, two images, and they must not be swapped. **Take the probe serial numbers from the tool's own list**, never from the kit's name or the header's label. The agent asking to read both probes before programming anything A table mapping each probe serial number to the chip it reaches and the image it gets ### The wide-area half: three commands, one session, nothing in between **Why the order matters more here than anywhere else** Erasing this chip clears the word that keeps its debug port open, and **on this part a cleared word means locked**. Neither the bootloader nor the application writes it back. So: program, write the word back, and only then reset. Program with no reset, then write the protection word back to unlocked, then reset. A reset before the write leaves the part locked. Program with no reset, then write the protection word back to unlocked, then reset. A reset before the write leaves the part locked. ```bash theme={null} nrfutil device program --firmware nrf9151/merged.hex \ --serial-number --options reset=RESET_NONE nrfutil device x-write --address 0x00FF8000 --value 0x50FA50FA \ --serial-number nrfutil device reset --reset-kind RESET_SYSTEM --serial-number ``` **The Bluetooth half** is the same without the middle command: program with `reset=RESET_NONE`, then reset. **Never press the board's reset button** Both halves share one reset line. A reset the probes did not initiate takes down both debug ports until the probe boards are re-powered. Reset through `nrfutil` instead. ## Step 3: Commission the unit *about 10 minutes* Commissioning gives the unit its place, its name and key, its network, its platform and its sensors. It happens over Bluetooth, in one of two places: **Adsum IoT Coder**, at your desk, or **a browser**, on an installer's phone at the site. Both write the same settings with the same checks, and everything written is **read back from the unit's own account of itself**. Nothing is trusted because a button was pressed. ### From Adsum IoT Coder From 0.5.1, the **Hardware** page in Adsum IoT Coder lists the units it hears under **Gateways in range** and takes each one through four steps: pair, claim it for this computer, check its firmware, commission it. **Commission it** opens a session. The agent reads what the unit already holds and asks one question at a time for what it cannot read: where the unit is, its name, the Wi-Fi, the mobile network and its class, the platform. It writes each setting, reads it back, starts the unit and checks that it is working, then goes on to the sensors the unit should admit. Gateways in range: LBG20x AD50, window open and paired; 1 paired with its two firmware versions, 2 claimed by this computer, 3 up to date with Check again, 4 not commissioned with Commission it * **The key is shown once.** The session also adds it to `adsum-fleet-register.csv` in your workspace, with the unit's name and identity. Keep that file: it is the only place the key exists. * **The answers that repeat are kept.** A site profile, `adsum-site.json` in the workspace, holds the naming pattern, the network, the platform and the Wi-Fi name, so the next unit needs only its position, the Wi-Fi passphrase and the platform's token. It never holds a password, a token or a key; those are asked each time. * **A commissioned unit says how it is doing.** The fourth step then reads commissioned with the unit's own verdict (working, not working yet, still checking), its (i) holds the position, how it sends and where, and **Change…** opens a session to change any of it. * **A claimed unit is updated from this computer.** Claiming locks the unit's service port to this computer's key. The browser page still commissions it, and points here for its firmware. The same unit commissioned: 4 commissioned, still checking, with Change ### From a browser The NTN-GW Commissioner, at [commission.adsumnetworks.com/ntn-gw/](https://commission.adsumnetworks.com/ntn-gw/), does the same in Chrome over Web Bluetooth, for an installer with a phone or a laptop. Nothing is installed and nothing is served from your machine. The commissioner page before connecting, with a QR code for opening it on a phone **The unit only listens for five minutes** A commissioned gateway advertises for five minutes after power-on and after each disconnect, then stops. If the chooser is empty, **hold DFU1 for 3–5 seconds** and press Connect again. Open the chooser *first*, then press the button if you need to. The operating system asking for the passkey shown on the page The unit panel showing identity, firmware and what the unit exposes **A newer demo firmware, from the same page** When the unit runs an older demo release, the first line after Connect says a newer one is out from Adsum Networks. **Upgrade** installs it over Bluetooth, the Bluetooth half first, in about six minutes, and the unit keeps its settings. Keep the page open and the device near the unit until it says Upgraded. If it stops, nothing breaks: the unit keeps the firmware it runs, and Upgrade again continues. #### Position, name, credential The board has **no GNSS receiver**, so the position is written here and is permanent until the unit is re-commissioned. Every method carries an uncertainty and the unit refuses a position without one: a coordinate that cannot say how wrong it might be is worth nothing later. A position written to the unit and read straight back, with coordinates masked The credential shown once, and the commission button Every written field compared against the unit's read-back, all matching ## Step 4: Set the deployment class *about 5 minutes* **From Adsum IoT Coder, this step is part of Step 3.** The session asks for the class with the mobile network (mobile only, mobile with satellite backup, or satellite only) and writes the policy and the class in the order the unit accepts. The panel below is the browser's. Commissioning does **not** set the class, and the build's default is the full ladder. The class fixes the transport and the encoding for the life of the record store, because a record written under one bearer has to be sendable, unchanged, under any bearer the unit might fall back to. The deployment class panel with class, transport, encoding, endpoint host, port, APN and device token **Narrowing has an order, and the unit will refuse you** 1. **Network policy**: untick satellite under *Allowed accesses* **and** clear it from the *Ladder* rungs. Unticking alone is not enough. 2. Write the policy, and read it back. 3. **Then** write the Deployment class. Widening is the reverse: class first, then policy. The unit refusing the class write and naming the rule The class written and read back as terrestrial only ## Step 5: Admit your sensor *about 5 minutes* **A commissioned unit with no access list ingests nothing.** That is deliberate: on a metered link, admitting whatever happens to be nearby is a bill somebody else writes for you. An advertisement is admitted only if the expected list or a rule names it; otherwise it is counted and dropped, or held in quarantine. An advertisement is admitted only if the expected list or a rule names it; otherwise it is counted and dropped, or held in quarantine. The quarantine listing advertisers heard but not ingested, including a rotating one To admit one device you know, use the **expected list**, one entry per line: ```bash theme={null} D2:14:97:21:15:C9, any, kitchen probe, 1 ``` `ADDRESS, profile, label, short id`. Then **Write the expected list**, then **Read from the unit**. Three things that will otherwise surprise you: * **Writing replaces the whole list.** It is not an append: send every entry you want kept, every time. * **An entry admits its device on its own**, no rule needed, and fixes its short id by list order, so numbering is identical on every unit given the same list. * **A rotating address is refused**, by line number. A reserved slot would point at something that stops existing. **Do not use "Admit what I see" for one device** It is the quarantine's bulk button and admits everything the unit has heard: on a bench, mostly strangers' phones. On the evaluation firmware that spends your ten-device allowance, the set survives restarts, and it can be cleared only five times in the unit's life. The expected list written to the unit and read back The access counters showing one expected device, one heard, and over a million dropped The network block showing the rung, effective ladder, network, band and cell ## Step 6: Send readings to your platform *about 10 minutes, plus one radio cycle* A reading travels from the sensor through both halves, over CoAP with a protobuf payload, to a device on your tenant identified by a token. A reading travels from the sensor through both halves, over CoAP with a protobuf payload, to a device on your tenant identified by a token. ### On your tenant A device profile with CoAP transport and protobuf payload highlighted Creating a device on the CoAP protobuf profile The device's access token, masked in this guide ### On the unit Back on the Deployment class panel: transport **CoAP / DTLS-CID**, encoding **protobuf**, your host and port, APN blank unless your SIM needs one, and the token pasted in. The data plane written to the unit and read back, with the token excluded from the comparison Telemetry keys arriving on the platform, each with the device's own timestamp **Stop here and you have a working gateway** It hears your sensors, keeps their readings, and sends them to your own platform on its own schedule. The code to look for is `2.01`: the platform took the reading. The uplink block showing last result 2.01, when, datagram size and next cycle ## Step 7: Send a command back *one radio cycle* Everything so far travelled outwards. This step goes the other way, and it is the only step that proves you can reach into a deployed unit from your desk. Outward, readings travel from the sensor to your platform. Inward, a command travels from your platform to the Bluetooth half, and only the Bluetooth half's log proves it arrived. Outward, readings travel from the sensor to your platform. Inward, a command travels from your platform to the Bluetooth half, and only the Bluetooth half's log proves it arrived. On your tenant, add a **shared attribute** to the device: key `cmd`, type string, value `clear_latch`. Adding a shared attribute with key cmd and value clear_latch The unit reads its shared attributes on its next radio cycle: **up to about fifteen minutes, usually a few**. The status panel's `NEXT CYCLE` is your wait. Rebooting to hurry it only restarts the clock. The Bluetooth half logging that it received the command and acted on it **Delete the attribute afterwards.** The unit acts on a shared attribute at *every* cycle while it stays set. ## When something looks wrong These are the ones that cost real time, with what they actually mean. | What you see | What it usually is | | :- | :- | | **The Bluetooth chooser is empty** | The five-minute advertising window has closed. Hold DFU1 for 3–5 seconds and press Connect again. Only if it is *persistently* empty should you suspect the browser's Bluetooth permission. | | **A log read returns nothing** | Not a dead chip. Both halves share one newest-first buffer and the Bluetooth half prints every ten seconds, so it crowds the other out within seconds. **Fetch the log immediately after the moment you care about.** Confirm a half is alive by something it cannot fake: its attach, its uploads, a command it acted on. | | **A log line contradicts the page** | Check the line's timestamp against the time of your action. A line is evidence only if it is *after* the thing you are asking about. Where the page has read a value back from the unit, that read-back outranks any log. | | **The log clock jumps back to zero** | It is a 32-bit microsecond counter and wraps every **71 minutes 35 seconds**. A wrap, not a restart. Take uptime from the status record. | | **A configuration write is refused** | The unit is protecting itself and nothing changed on it. The message names the rule; for a class change the usual cause is a network policy still allowing something the class does not. | | **Two different firmware versions** | Expected. The halves version independently and both numbers are right. The commissioner's `fw` badge is the Bluetooth half's. | | **`strings` finds nothing in a `.hex`** | Intel HEX stores the payload as hexadecimal *text*. Decode to binary before searching it. | | **The modem will not attach after several resets** | The modem bans attach for about half an hour after repeated resets without a clean shutdown, and the ban is invisible unless event reporting was armed first. Wait it out; resetting again restarts it. | | **Readings never arrive, no error anywhere** | Almost always the profile: a CoAP device against an MQTT profile, or the wrong payload type. Check the two fields in the profile before anything else. | ## What this firmware will not do **Evaluation firmware** It hears your sensors, keeps their readings, and sends them to your own platform, with the three limits below, and those limits are in this build only. **No device-management client:** this unit will not appear in a console and is not updated over the mobile network; that part is fitted per build. A newer demo release still installs over Bluetooth, from Adsum IoT Coder or the commissioning page. | Limit | What it means in practice | | :- | :- | | **Ten devices** | The first ten this gateway hears become its set. An eleventh is still scanned and still listed, it is simply not carried off site. The set survives a restart; you can clear it and start again five times in the unit's life. | | **10 MB a month**, mobile | A gateway left running uses well under this. If it is ever reached, uplink waits for the next month and everything else keeps working. | | **10 KB a month**, satellite | The whole satellite package. Only alerts and status go that way; firmware never does. | **There is no time limit, and restarting the unit resets none of this.** Nothing here ever asks you to reboot, and you should not, because the modem blocks attach for about half an hour after repeated resets. ### Ways on from here * **Our verified build** for the units you ship * **The source of our firmware**, the Bluetooth half or both, with the advanced knowledge to build on it and customise it * **We build it for you** Ask for details on any of these from the Adsum panel and we reply within a business day. *** Captured on a BLG20XE02C-V1 with the published evaluation pair, verified on macOS. Coordinates and credentials in the figures are masked for this page; on your own unit they appear in full. The board, the firmware, and every way to have it. What a satellite link is good for, and what it costs. Commission a BLG20x from Chrome, over Web Bluetooth. A production licence, the source, or a build made for you. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.