Golioth’s Bluetooth-to-Cloud development continues to roll out new features for private access users, including offering a range of solutions for shuttling bluetooth data up to the cloud. As more customers build sensor-rich devices for agriculture, smart buildings, and asset tracking, Bluetooth Low Energy (BLE) is the protocol of choice for low-power, short-range communication. But there’s still a missing piece in many deployments: how do you reliably bridge BLE sensors to the cloud with off-the-shelf options?
That’s where Bluetooth gateways come in.
Over the past few months, we’ve been evaluating a variety of BLE gateways, some that pair with Wi-Fi or Ethernet, others that speak cellular, and running them through their paces with Golioth. Our goal was simple: find a reliable, flexible, and developer-friendly solution that we can confidently recommend to customers building BLE-enabled fleets.
Defining a Great BLE Gateway
At Golioth, we think of networks in terms of devices (your sensors and actuators) and gateways (the last hop to the cloud). Gateways can be:
-
Managed — fully onboarded in Golioth with OTA updates, logging, settings, and policy control.
-
Unmanaged — authenticated to Golioth but only relaying data for endpoints that don’t run our SDK.
A gateway is any device that connects directly to Golioth, typically over cellular, Wi-Fi, or Ethernet, and forwards traffic for local BLE nodes. For the newest Bluetooth-to-Cloud capabilities, that means the gateway needs to be able to forward data wrapped in Pouch, our new innovation in the space of non-IP communication. It’s also possible for Gateways to forward non-Pouch traffic, but we’ll be focusing on the most enhanced version of data transfer (ie. Pouch) for the near future.
The BLE Gateway Landscape
You’ll find plenty of Zephyr-compatible dev boards, Nordic’s nRF9160 DK and the Thingy91:X among them that technically fit the bill. We love these boards for rapid prototyping and POCs: they pair the nRF52840’s BLE prowess with an nRF91 Series LTE-M/NB-IoT modem.
But most teams aren’t in the business of maintaining custom hardware stacks. They want a turnkey gateway that just works. That’s why, even though you can cobble together a solution from dev boards, we don’t recommend it for production.
Our Top Pick: Ezurio Sentrius MG100
After testing, we recommend the Sentrius MG100 from Ezurio for industrial BLE + cellular deployments. Here’s why:
-
Zephyr-Ready: First-class support in Golioth’s Zephyr SDK, so you can hit the ground running.
-
Proven Hardware: nRF52840 for BLE Central; Sierra HL7800 for LTE-M/NB-IoT.
-
Off-the-Shelf Reliability: No soldering irons or custom enclosures, just unbox and deploy.
-
Customizable: Optional branding and packaging, so it fits right into your product lineup.
With the MG100 + Golioth, you get a hardened, field-ready gateway that delivers the “set-and-forget” experience you and your customers expect.
Next Up: BLE + Wi-Fi/Ethernet Gateways
A microcontroller-based cellular device in an industrial enclosure doesn’t fit every application space. In our next post, we’ll explore the world of BLE + Wi-Fi/Ethernet gateways, as well as discussing more about the processing needs of particular gateways.
We’re continuing to enhance our BLE gateway tooling, improve reference firmware, and if you are building a connected product, sign up for Golioth’s Bluetooth-to-Cloud Connectivity private access program, or join us in the forum to tell us more about your use case!
Evaluated it, discarded it (a few years back, maybe they’ve updated it?).
I don’t know why, but for some reason the concept of an NB-IoT device being a gateway while also being truly low power has escaped every gateway maker on the market.
We did end up with the dreaded “custom hardware”. There’s nothing stopping the MG100 from doing what we did, it’s just decisions made in hardware design rendering it unsuitable for “years on battery power” for no good reason. As far as I remember, the HL7800 would have been a decent choice*, except the MG100 decided to use always-on UART between the BLE and LPWA modules, with no additional lines connected to implement a way for bidirectional wakeup between modules.
That meant that the onboard battery, instead of providing months of supply (too little for us, but enlarging the battery would have been trivial) provided days at best, rendering a capable battery-powered gateway into a wall-powered-with-UPS one.
IIRC, there were other pointlessly-high-quiescent-current situations on the board too. Single-microamp Iq voltage regulators are not even expensive anymore, yet I see so many designs where the power supply is the single largest idle load on the battery.
If Sentrius wants to prove me wrong, I’m open to be corrected. Again, my experience with them is a few years ago (read: positively ancient).
* IIRC, they have decent documentation available, if behind a login wall for no good reason. We went with nRF9160, simply because we could use the same SDK on both BLE and LPWA.
ST had a freshly released LPWA module also, but the actual SoC was only accessible through their middleware, with no AT command manual available to mere mortals, and of course the middleware was utter nonsense, and support non-existent.