Skip to main content
Bluetooth tags in, your MQTT broker out, over Ethernet with Wi-Fi behind it.
How fast, from nothing?Under 2 hoursFrom an empty folder to this gateway running, hands included.
How fast, from a signed image?About 3 minutesNo build, no SDK, no source. Flash it and judge it.
How many ways out?TwoEthernet first, then Wi-Fi, failing over on its own.
What does it cost to run?Nothing recurringNo SIM, no data plan.
Base Fanstel LEW840F-M2-V3BLE card BT840XE, nRF52840 with a power amplifierBuilt from scratch 25 August 2026, ESP-IDF 5.5.4 and NCS 3.3.1

​
What it is

The black Fanstel LEW840x, closed, with a single 2.4 GHz antenna fitted

One antenna: BLE in, Wi-Fi and Ethernet out

A commercial gateway in its own enclosure, not a development kit. Fanstel offers it with an IP51 enclosure, and with an IP65 one for harsher sites. An ESP32, an Ethernet PHY and a Wi-Fi radio sit in the base, and two M.2 slots take the radios you choose. The M2 slot holds the BLE card that hears the tags. The LN slot takes a cellular card, and on this build it stays empty. The firmware is the same image either way. It reads which cards are fitted at boot, so adding cellular later is a setting and a reboot rather than a rebuild, and what you already configured survives it.

​
Two ways out

1
EthernetcarryingFirst choice. PoE or the DC jack, one or the other.
2
Wi-FistandbyJoined and holding an address, ready to take over.
3
Cellularno card fittedThe slot is empty, so the firmware starts no modem and the console leaves the surface out.
You choose the order. The box moves down it on its own when a link drops, and climbs back when the link returns.

​
What you order

JS1ESP32 console and flash. The UART bridge plugs in here.
JS2BLE card debug header. The development kit’s probe cable goes here.
JS4Ships with a shunt fitted. Leave it seated.
RJ45Ethernet, to a network with DHCP.
One power source only, from the injector or the jack, never both and never back-fed from a development kit.
The kit and the development kit are bench equipment you reuse for every unit you ever build. Only the gateway and its cards are per unit. You do not need an ESP32 development kit at all: the ESP32 is inside the sealed gateway and the bridge is how you reach it.

​
The prompt

Name the base and the card. The agent already has the pinout, and it asks before it assumes.

​
The build, in seven steps

Each step ends in something measured rather than asserted. You are needed at the bench three times.
1
Agree the shapeWhich cards are fitted, what it has to do, and what it must not cost.
2
Check the siliconRead the chips over the debug probe. A printed part number is not proof of what is fitted.
you
3
The BLE scannerBuilt, flashed, and then measured against a live radio at a known distance.
4
The cellular linkNot applicable on this build. The step reports that and hands straight on.
5
The applicationParser, both uplinks, MQTT, the settings surface and the console, in one flash.
you
6
Failover, for realTake Ethernet away and watch what happens, then give it back.
you
7
HandoverFetch the console over the live link rather than trusting a server is running, and write the log.
Step 6, measured
Ethernet awaystream resumed on Wi-Fi in 15.4 s
Ethernet backEthernet carries again, unprompted
Broker connectionheld throughout
Read atan independent subscriber, not the gateway
Honest caveat: the seven steps above were run on 4 and 5 September 2026 on a unit that happened to have a cellular card fitted, which is why step 4 is marked not applicable rather than absent. The Ethernet to Wi-Fi timing is this shape’s failover either way. What nobody has yet run is a boot with the LN slot physically empty.

​
What the board serves

Its own console, from its own flash. No app, no cloud account, nothing to install.
The gateway console Overview tab with Ethernet carrying, both links up, MQTT connected and the scanner filtering

Active uplink, each link's state and address, and whether the broker is connected. The first question, answered without reading a log.

One topic per device, so an ordinary MQTT client subscribed to the tree sees each tag arrive on its own. That is where we check the count, not in the gateway’s own log: a device saying it published is not evidence that anything arrived.

​
What this build does not do yet

  • No over-the-air updates. The partition table is ready for them, two slots in 16 MB, but there is no update path yet, so a firmware change still means a trip to the box.
  • The broker connection is plain TCP. TLS needs a clock first. Without time the handshake fails in a way that looks exactly like a certificate problem. See CRA readiness.
  • LoRa is on the card, not in the firmware. The XE carrier carries a LoRa part this build does not drive. A LoRa line is in preparation; see LoRa and LoRaWAN.

​
Getting this firmware

Three ways in, and you can move between them. Row by row: gateway firmware.

Flash a signed image

Minutes, free with an account. Yours: a licence to run it and judge it, on your own network and your own broker.

Build from licensed source

Module by module, yours to change and to ship. Ask from Settings › Account › Request template source.

Add the cellular card

The same gateway with a third way out. Same image, one setting.

When the air disagrees

The log says one thing and the radio says another. Three layers, one answer.