NTN-GW Commissioner v3.9.4
no unit
fw ?
DEMO
—
Each one says what it keeps and what it loses.
The buttons above send the common case. These are the same five commands with their own arguments spelled out: a specific device and rule to clear, a rung to pin, a warm reboot on its own.
| Parameter | Value | On this unit |
|---|
Parameters live: connect to see what this unit supports
Bluetooth half
Cellular half
This computer lost sight of the unit while it restarted. Pick it again in Chrome's list: the upgrade goes on by itself.
Stand next to the unit. Everything is written over Bluetooth and read back from the unit itself.
Refreshed every five seconds, including the cellular half's state mirrored across the inter-chip link. The mirror carries its own age: if it stops arriving the mirrored groups grey out and say how old they are, because a number with no age is the one that gets believed.
Step 1 of 7
Pick the gateway you are standing next to. When asked, type its passkey.
Best on an Android phone in Chrome. iPhones have no Web Bluetooth.
Open this on a phone. Scan with the camera and open the link in Chrome: Web Bluetooth needs Chrome on Android; iOS has none. The same page, the same address, no install:https://commission.adsumnetworks.com/ntn-gw/
Defaults for every unit on this site. Saved on this device; export it to carry it to another phone.
The same link as the button above; these are its own id'd controls and a fuller readout.
| Parameter | Value | On this unit |
|---|
Stand at the unit. Every reading carries this position, and the satellite network needs it.
A coordinate that cannot say how wrong it might be is worth nothing later, so every method carries an uncertainty and the rules differ by method. The unit refuses a position without one. These are the same write as the button above, with the method, altitude and floor spelled out.
The device's own reported accuracy is the uncertainty. A phone with GPS outdoors gives a few metres; a laptop positions itself from Wi-Fi and will be tens of metres out. The tool will say which it got.
The unit's own receiver takes the fix and keeps it as the position; its reported accuracy is the uncertainty. With the GNSS antenna's sky view a fix usually comes in under a minute; a cold start is allowed ten.
The name is what your dashboard shows; the key is how the platform trusts this unit.
Made from the name; change it only if your platform gave you one.Save name and key above is the write; the identity pattern and the key length are set in the site profile (step 1's settings).
The label is how the unit appears on a dashboard; the identity is what the server knows it by. The key is generated here and shown once. The fleet register is the only other place it exists. The same write as the button above, with the identity pattern and key length spelled out.
How the unit sends its data.
Satellite has a monthly allowance in kilobytes. Over satellite the unit sends a short summary, not every reading.
The step is done when the network is saved.What the SIM allows, and in what order. Everything here narrows what the SIM and the modem can do; nothing here can widen it.
Not in this firmware yet: greyed until a build takes them. The rows below are the specification for the next one.
| Parameter | Value | On this unit |
|---|
Where the data goes.
Not encrypted: the password travels in the clear on this network. Fine for a demo, never for a site.
Not over your Wi-Fi. This unit's firmware cannot carry MQTT over the Wi-Fi link yet, so MQTT goes over the mobile network and spends SIM data. Pick CoAP to use the Wi-Fi.
Any CoAP platform. Using ThingsBoard? It needs the BLG20 device profile once per account: download it.
The class fixes the transport and the encoding for the life of the record store: a record written under one bearer has to be sendable, unchanged, under any bearer the unit may fall to. MQTT and JSON are terrestrial only; the unit refuses either on a class that includes satellite.
The unit never reads a token back. It is this unit's data-plane credential, so the read returns that field zeroed and the read-back check skips it. Leave the box blank on any later edit and the unit keeps the token it holds, as long as the server address stays the same.
The unit stores only sensors on its list. These are the ones it hears now. Untick any that are not yours.
What the gateway listens with. Every one of these is a site decision, which is why it is configuration and not a firmware build. Passive is the default: an active scan sends a scan request to every advertiser it hears, which gets the scan response and makes this unit visible to anybody listening. Coded PHY roughly doubles range at a quarter of the throughput and needs a longer window to catch a given advertiser (§23: 57.5 ms against 21.5 ms). Periodic sync receives a scheduled train without scanning for it at all.
A combination this firmware cannot do is refused with a reason, never silently reduced. If the controller refuses one after the firmware accepted it, the Sessions panel's Scanner row says reduced. That is the case worth looking for, because a site that thinks it is scanning Coded and is not has a hole in it.
An instrument that only speaks when connected (a cuff, a scale, a logger) is captured by a session profile: how to find it, how to secure it, what to read, for how long and how often. The gateway opens at most CONFIG_BT_MAX_CONN − 1 at once and never takes the commissioning link's slot, so writing an ambitious profile cannot lock you out of the unit you are standing next to.
One slot per write. A profile is 90 bytes and eight of them would not fit one read, so choose a slot, read it, edit it and write it back. session_max_s is a hard disconnect enforced by the gateway, not a hope about the instrument.
| service | characteristic | decoder | read | subscribe | history | generic: field / offset / type / ×÷ |
|---|
Write only. This unit has no way to read a credential back (the characteristic has no read property at all), so nothing typed here can ever be recovered from the gateway. Keep it where you keep the rest of the site's keys. What the panel can show is the shape of the store: how many are held, how many pairings were refused, and whether a device is in backoff (Status → Sessions).
What this gateway will and will not ingest. Rules are evaluated in the order below, first match wins; anything no rule matches hits the terminal rule. Only an admitted advertisement gets a short id, a row in the device table, a digest and a record in the store: everything else is counted and forgotten, counted and kept out, or held in the quarantine for you to look at.
A unit with no list here ingests nothing. An uncommissioned unit quarantines what it hears, so you can see the site before you write a list; a commissioned one drops it. That is deliberate: on a metered (or satellite) link, auto-admission is a bill somebody else writes for you. If the store has stopped growing, read Status → Access → Terminal rule before you suspect the radio.
| # | action | MAC prefix | addr type | company id | UUID16 | payload prefix | profile | rate/min | dedupe s |
|---|
A field left blank is not matched on. A rule with every field blank matches everything, which is how "admit the lot" is written. The MAC prefix is 1 to 6 bytes, written the way it is printed (AC:23:3F), and the payload prefix is up to 8 bytes of hex, matched against the manufacturer or service data after the company id or the UUID.
The site's tags, listed before they are heard. An entry admits its device on its own (no rule needed) and pre-assigns its short id in list order, so the platform's numbering is stable from the first advert and is the same on every unit given the same list. One per line: AA:BB:CC:DD:EE:01, profile, label, short id; profile, label and short id may be left off.
An address that rotates is refused here, with a reason. Pre-assigning a short id to an address that will not exist in fifteen minutes is exactly how a site accumulates ghost rows and presence alerts that can never clear.
Unknown advertisers this unit has heard and not ingested: up to sixteen, least recently seen evicted, with a sample of what each one last said decoded by the parsers this firmware has. Nothing here is stored, digested or numbered.
| address | identity | heard | RSSI | last seen | what it said |
|---|
A rule turns a stream of readings into two events: one enter and one exit. Hysteresis is what stops a value sitting on the threshold from alarming sixty times a minute. The condition ends at a different value from the one that started it. Hold is how long a state must last before it is reported at all. Latch keeps it raised until somebody clears it (Troubleshoot → "Clear a latched alert"). Renotify repeats it while it is raised, on the one interval below.
A rule set is applied at the next window boundary, not at the write. The read-back is what is in force, so it may still show the previous set for up to one window. That is the unit being honest, not a failed write.
| id | device | field | when | value | hysteresis | hold, s | severity | flags |
|---|
Sends the short-id table to the cellular half again, and publishes it as a device attribute on the next terrestrial window.
| Parameter | Value | On this unit |
|---|
Read it over, then start the unit. The status at the top then says when you can leave.
Start the unit and check above sends this write. The unit refuses this until it holds a position and a credential. This board has no satellite receiver, so a unit installed without a coordinate cannot use the satellite bearer at all. The same write as "Start the unit and check" above.
Read the unit's own account of itself and compare it with what was written. Green is a match; anything else is the unit disagreeing, and the unit is right.
The last lines both halves printed, newest first. On this board LTE-RESET and BLE-RESET are the same wire, so a debugger on one chip resets the other. This is the only way to read either half's log on a live unit. Fetching asks the cellular half for its ring over the inter-chip link, which costs about 600 ms of a wire that is also carrying records, so it is rate-limited to one fetch every ten seconds.
Entered by holding DFU1 through a power-on on an uncommissioned unit. It only reads: the next power cycle leaves no trace of it, and a commissioned unit refuses it (it cannot be run by command). Everything below goes on the unit's label. Also reachable from Troubleshoot.
Every unit commissioned from this device. This is the record the platform side needs: the identity and key for the data plane, the position and provenance for the audit trail. Export it before you leave the site.
| when | unit | label | identity | key | lat | lon | ±m | method | fw | by |
|---|
This cannot be undone from here. It wipes the credentials, the bonds, the device credentials, the session profiles, the configuration (both copies), the rules, the device table, the stored state and every unsent record. It keeps the byte odometer, the store's wear count and one audit line saying when this happened and which paired device asked for it. The unit ends uncommissioned with its window open, and reports "decommissioned" on its next terrestrial window.
Two lights, one per half of the unit. Colour is the state, the blink is the activity; every state is also distinguishable by pattern alone. From PLAN-2026-09-12-leds-buttons.
| LTE light (cellular half) | means |
|---|---|
| amber, slow 1 s blink | not commissioned, waiting for you |
| blue, 200 ms every second | searching for the network |
| green, one flash every 5 s | registered, resting between cycles: the normal state |
| solid blue, then green ×2 | sending, then acknowledged |
| red ×3 | a send failed; it will try next cycle |
| cyan where blue would be | on the satellite bearer |
| cyan, one flash every 3 s | satellite: waiting to attach, can take minutes |
| cyan / red alternating | satellite allowance used up; still working on cellular |
| amber ×2 then cyan | satellite refused: no commissioned position; set one |
| red, one flash every 2 s | data allowance exhausted, parked. This needs a visit |
| red / amber alternating | the modem is under a network attach ban: do not reset it, it clears itself in ~30 min |
| solid red | fault |
| BLE light (Bluetooth half) | means |
| off, green flash every 10 s | scanning normally |
| blue, slow breathe | commissioning window open, connect now |
| solid blue / fast blue | connected / waiting for you to enter the passkey |
| green flash + tick | a write was accepted |
| red ×2 + buzz | a write was refused: read status to see why |
| green ×3 + rising chirp | commissioned |
| three ticks, once | first data sent after commissioning, you can leave |
| amber flash every 5 s | store filling; the cellular half is behind |
| red flash every 2 s | the link between the two halves is down |
| Cue light (one colour, inside the case: a service light, seen with the lid off) | means |
| self-test verdict, on the BLE light | green ×3: both halves answered and a SIM is present; red ×2: the cellular facts are missing. Every cue below also has its light above; the cue light only adds to them |
| one short flash | a write was accepted |
| one long flash | a write was refused: read status to see why; in the factory self-test, the cellular half's facts are missing |
| three flashes | commissioned; in the factory self-test, both halves answered and a SIM is present |
| two flashes | identify |
| three flashes, then steady for a minute | first data sent after commissioning, you can leave |
| on for a moment at power-on | the lamp test |
| dark | nothing to say: it is quiet between cues, as a sounder is. The BLE light's green flash every 10 s says the unit is running |
| The button (the small one; the other resets everything) | does |
| tap | identify: both lights white ×3, two ticks; the LTE light replays its state brighter for 5 s |
| hold, release between 3 and 8 s (blue at 3 s) | open the commissioning window (or close it if it is open). A commissioned unit keeps it open for 5 minutes; an uncommissioned one keeps it open |
| hold 10 s, red flash every second from 8 s | factory reset: wipes everything the site gave it (position, credential, configuration, rules, sensor lists, stored records, every pairing) and reboots. Release before 10 s to cancel |
| hold while powering on | asks for the factory self-test (an uncommissioned unit only) |
NTN-GW Commissioner v3.9.4 · field tool v2 · built with Adsum IoT Coder · powered by Adsum Networks
Commissions an Adsum gateway from a Chrome tab over Web Bluetooth: no cable, no app, no phone signal needed. This tool, and the gateway firmware it commissions, were generated with Adsum IoT Coder from Adsum Networks, firmware that arrives already wired to the production tooling a device needs.
a05c0001-9e5f-4b6a-9f3a-2d1c7e4b8a01, characteristics …0002 to …0016; status2 version 7, 8 or 9bluetoothctl first (Chrome on Linux cannot type a passkey). On Windows, pair it in Windows settings first. iOS has no Web Bluetooth.https://commission.adsumnetworks.com/ntn-gw/: the published copy; scan the QR at the toptools/commissioner.html in the gateway firmware tree: one file for both gateways, no dependencies. Firmware: src/bm20-ble/src/provision.c