iBeacon, Eddystone, Bluetooth, IoT sensor beacons, apps, platforms
We now have the new MG4 Rechargeable Gateway available. This gateway collects advertising data from iBeacon, Eddystone, Bluetooth LE sensor and other Bluetooth LE devices and then sends it to your server by HTTP(S) or MQTT using WiFi (2.4GHz only).
A unique aspect of this gateway is that it has a rechargeable battery that lasts up to 12 hours so that it can operate during a power outage. The in-built memory stores up to 1080 records avoiding data loss during power and/or network loss.
There’s new research on the Design and Implementation of a BLE Gateway Using ESP32 chipset (PDF). Bluetooth Low Energy (BLE) and Long Range (LoRa) are commonly used wireless technologies for IoT devices, useful for their low power use and long range respectively. The mixing of BLE and LoRa in a single gateway significantly improves the flexibility of IoT networks, providing efficient data gathering and transmission.
An affordable, flexible gateway was developed, combining the benefits of BLE and LoRa communication and taking advantage of the ESP32 microcontroller’s capabilities. This setup allows for effective data collection from BLE devices and transmits the consolidated data to an MQTT server or a LoRaWAN cloud.
An initial prototype was produced, which led to a customised solution based on a PCB.
Looking to the future, the author says there’s scope to improve the software and firmware further, optimising the algorithms, reducing power usage, and exploring additional features such as multiple communication protocol support or advanced security measures. Such advancements could offer a more adaptable and reliable solution for users’ wireless communication needs.
However, the necessity of refining this solution is questionable as there are existing solutions, such as the LW003-B LoRaWAN Probe, already available, that solve these issues and productise in a case.
Every now and then, we come across a product that’s a bit different. In this case it’s a very small and reasonably priced gateway, the MG3.
It is designed to gather advertising data from iBeacon, Eddystone and other devices. It sends this data to your server in JSON format using either HTTP(S) or MQTT protocols. The device connected to a 2.4GHz WiFi. To indicate its status, there is an RGB LED integrated into its design.
While the marketing materials mention detecting Minew beacons, it can detect any kind of beacon and, more generally, any Bluetooth device that is advertising. It has the capability to process data from up to 70 devices per second. Although its optimal range is 70 meters in an open space, this range is dependent on the power of the beacons being detected.
The device conveniently uses a standard USB connection for power. It consumes approximately 340mA of power, which decreases to 290mA if the LEDs are turned off.
To change the device settings you use a smartphone app. Please note that currently, the app is only available for Android devices. The settings you can configure include the method of data upload (HTTP(S) or MQTT), server URL, upload interval, RSSI filter, MAC address filter (using Regular Expression), raw Bluetooth filter (using Regular Expression), and time zone settings.
Bluetooth beacons are increasingly being used for asset tracking. Their use in this context differs significantly from their conventional role of in-app triggering. In asset tracking, gateways rather than smartphones are used as detection devices, requiring different configurations for optimum efficiency.
iGS03E Bluetooth to Ethernet gateway
Changing Bluetooth beacon settings requires the manufacturer’s specific application custom-tailored for their devices. These apps adjust the beacon parameters according to specific needs.
A most important setting when using beacons for asset tracking involves is the advertising period. This is the time interval between the broadcasted signals. In the the app detection usecase, a frequent advertising period is required to ensure constant detection by nearby smartphones and particularly for iOS. However, in asset tracking, the scenario is different.
Since gateways, not smartphones, are used for detection, a lower advertising period, ranging from 1 to 10 seconds, is sufficient. Less frequent advertising has the advantage of conserving the beacon’s battery life. It also ensures the server isn’t flooded with duplicate data.
The beacon’s advertising type is another key consideration. iBeacon or Eddystone UIDs are usually used for detection by smartphones due to their compatibility and detection by mobile operating systems. However, when using gateways and servers, the Bluetooth MAC address of the beacon is usually used for identification. Consequently, any advertising type can be selected, eliminating the need for specific compatibility.
Where multiple advertising types are available, it’s essential to ensure that only one advertising type is selected. Even though gateways can utilise any advertising type, using multiple types simultaneously can lead to increased energy consumption by the beacon and more redundant data at the server.
A Bluetooth WiFi gateway is a device that connects Bluetooth devices to a WiFi network. It allows Bluetooth devices, such as sensors, beacons, or other IoT devices, to communicate with a WiFi network and exchange data with other devices on the network or remote servers or the cloud.
Bluetooth WiFi gateways have both Bluetooth and WiFi capabilities and are able to bridge the communication between these two technologies. They are often used in IoT (Internet of Things) applications, where they can be used to connect a variety of Bluetooth devices to a WiFi network, allowing them to communicate with each other and exchange data.
Bluetooth has a relatively short range of up to 100m, so using a Bluetooth WiFi gateway can allow Bluetooth devices to originate data over longer distances. Bluetooth WiFi gateways are easy to set up and configure, making them a convenient solution for connecting Bluetooth devices to a larger network.
The MG3 is a new mini USB Bluetooth-WiFi gateway.
It’s a more affordable version of the G1 with slightly less capability:
The MG3 collects advertising data from all Bluetooth LE devices and then sends JSON data to your server by HTTP(S) or MQTT using WiFi.
The MG3 processes up to 70 Bluetooth devices per second. The maximum range is 70 meters in open space but this depends more on the range of beacons being detected.
Configurable data collection settings include the upload method (HTTP(S) or MQTT), server URL, upload interval, RSSI filter, MAC address filter (RegEx), raw Bluetooth filter (RegEx) and the time zone.
When a Bluetooth WiFi Gateway sends data to a server via HTTP, the gateway has to connect to the server to start a connection and then use that connection to send the data. The connection part starts a new TCP connection with handshaking. Starting a new connection every time data needs to be sent to the server uses network data and creates work for the server.
Some gateways such as the IGS01s have a ‘keep-alive’ setting that allows the connection to be re-used across HTTP requests. This reduces the amount of data used on metered networks such as cellular, reduces possibly metered data throughput at the server and also reduces server loading thus improving performance.
Having said all this, you should consider MQTT if you are really concerned about efficiency and performance.
We have limited quantities of the new INGICS iGS03W Bluetooth WiFi gateway in stock.
The iGS03W listens for beacons, gets their advertising data and forwards it on to your server or an IoT server via TCP, HTTP(S) or MQTT including AWS IoT, Google Cloud IoT and Azure IoT Hub.
It differs from the iGS01S in that it supports greater throughput, Bluetooth 5 Long Range mode (LE Coded PHY) and also includes a wall holder.
Bluetooth WiFi gateways offer MQTT and/or HTTP for sending data to servers/cloud services. We are often asked which should be used. HTTP is what’s used by your web browser to fetch and send data to web servers. In very high level terms, MQTT accomplishes a similar thing but is better optimised for mobile devices and the Internet of Things.
HTTP is very ‘chatty’ which means it’s more complex, code wise, to implement at the sending end and wastes a lot of data and processing power getting information from sender to receiver. You can think of HTTP as wrapping the data within lots other data that gets sent backwards and forwards. MQ Telemetry Transport Protocol (MQTT) came out of IBM, is now an ISO standard and uses lightweight publish/subscribe messaging. It requires a smaller code footprint at the sender and uses less network bandwidth. This matters most when you are trying to get the maximum transactions per second or are being billed for data use.
Bluetooth WiFi gateways are powered via USB and have reasonably powerful microcontrollers so MQTT’s efficient processing doesn’t matter that much. The more efficient processing is more applicable to apps running on mobile devices. For example, Facebook uses MQTT which saves battery life.
However, being lightweight, MQTT offers faster response times and lower data use than HTTP that, while not necessarily being of much of an advantantage for the BLE WiFi gateway, benefits the communications medium and server side. The communications medium, that can sometimes be cellular or be data constrained, uses (and possibly bills) less data. More crucially, the server can process more requests in less time. MQTT tends to be better when connectivity is intermittent, bandwidth is at a premium and throughput is critical.
In summary, MQTT has lower latency and is more efficient. Whether these are required advantages depends on your actual project. If you need more help, consider our development services.
We sometimes get asked if it’s possible to use a smartphone as a gateway to scan for Bluetooth devices. The thinking is usually that workers or users already have devices so why not make use of them?
While it is possible, there are many reasons why you might not want to do this:
The best scenarios are those where you can dictate the phone type, it can be mains (PSU) powered and the phone isn’t owned by a user (i.e. it’s just used as a gateway). It’s almost always better to use a dedicated gateway.
