Definition
Bluetooth IoT uses BLE (Bluetooth Low Energy, Bluetooth 4.0+) to connect nearby IoT devices. BLE operates in the 2.4GHz ISM band, with very low power consumption (button batteries can last several months), suitable for wearables, beacons, sensors, etc. Bluetooth Mesh (2017) expands networking capabilities, supporting multi-hop, broadcast, and multicast; Bluetooth 5.x increases speed (2Mbps), range (up to several hundred meters), and broadcast capacity, complementing Zigbee, Thread, Wi-Fi in short-range IoT.
Core Features
- Ultra-low power consumption: Connection intervals can be configured, with microampere-level current during sleep, suitable for battery-powered devices.
- Short range: Typically 10–100 meters, Bluetooth 5 Long Range mode can reach several hundred meters.
- Native phone support: Smartphones natively support BLE, facilitating device configuration, data collection, and close-range interaction.
- Mesh networking: Bluetooth Mesh supports Friend, Relay, and Low Power nodes, enabling multi-hop and large-scale deployment.
Hybrid networking with cellular.
Bluetooth handles close-range device connections, while cellular handles wide-area backhaul. Typical architecture: A Bluetooth gateway aggregates data from multiple BLE devices and uploads it to the cloud via LTE-M , Cat.1 , or other cellular networks. SimtoLink provides a one-stop connectivity solution for "Bluetooth gateway + IoT SIM cards" hybrid scenarios.
Typical Use Cases
Wearable devices, beacons, smart locks, medical devices, asset tracking, indoor positioning, smart home, etc. SimtoLink focuses on cellular IoT, complementing Bluetooth, and supports hybrid networking solutions.
Bluetooth IoT is mostly used for short-range device connections, while SimtoLink focuses on cellular IoT SIM cards and cloud platforms, providing connectivity services for devices that need wide-area networking. For hybrid networking scenarios (such as Bluetooth gateways + IoT SIM card uploads), SimtoLink can provide a one-stop connectivity solution, enabling data integration between local Bluetooth devices and the cloud.
Connection interval and slave latency together set the average current
After a low-energy Bluetooth connection is up, both sides wake on the connection interval to exchange data, and the radio stays off the rest of the time. A longer interval lowers average current and also lengthens the wait for a command. Slave latency lets the slave skip several intervals before it answers. That suits a sensor and does not suit an actuator that must unlock at any time. The two parameters have to be read together. An interval of 200 milliseconds with latency zero, and an interval of 50 milliseconds with a latency of three, do not offer the same chances to be awake. Changing only the device name in advertising does not change current in the connected state.
If the supervision timeout is shorter than the real wake rhythm, the master decides the link is lost and scans again, and the battery account gets worse. To judge whether the connection parameters are reasonable, capture the wake count over an idle stretch, not only the signal strength at the moment the connection succeeds. When a phone is the master, the system may rewrite the interval. An embedded master has to write it in a connection-update request itself.
When the advertising channels are full, a scanner keeps failing to find the device
Advertising uses three fixed channels, and it shares 2.4 GHz with wireless LAN. If a site has many beacons on a very short advertising interval, advertising packets fill the three channels, and a new device’s advertisements collide with scan requests. The symptom is intermittent failure to find a device that is very close, and recovery as soon as the surrounding beacons are turned off. The condition is that advertising success tracks beacon density in the area, not distance alone. Setting the interval as sparse as the service allows relieves collisions better than raising transmit power.
Extended advertising and long-range mode take more time slots. Long range trades coding for sensitivity, so one advertisement occupies the air longer and neighbors are more crowded. Turn long range on only for asset tags that need distance. Dense indoor tags should stay at the standard rate, or discovery delay in the whole room gets worse together.
Delay adds hop by hop as the relay count grows
Bluetooth Mesh has no traditional routing table. A relay node broadcasts the network message again. Each hop waits for an advertising event. If the hop limit is too high, messages keep echoing inside the network. If it is too low, a corner node never receives them. A low-power node is not awake often and relies on a friend node to cache for it. After the friend node drops, the low-power node looks offline for a window of time. To separate a relay problem from a backhaul problem: if a phone next to the node can read the data directly and the cloud cannot, the gap is usually the stretch from the mesh to the gateway. If the phone cannot read it either, the node itself or the relay is at fault.
A SimtoLink IoT SIM card sits in the Bluetooth gateway and carries aggregated data out of the local network. The card being online does not prove that every Bluetooth slave is in the network. The platform should show gateway attach status and the latest Bluetooth hop time separately. Restarting only the cellular module will not fix advertising collisions or a friend-node cache. Reconfiguring only the connection interval will not fill in the uplink from the gateway to the cloud.
Pairing material and connection parameters live in two memories
Low-energy Bluetooth pairing creates a long-term key, stored on both the master and the slave. Connection interval, slave latency, and supervision timeout are the result of each connection update, and they are not necessarily still there after a disconnect. Clearing only the Bluetooth cache on the phone leaves the pairing record in the slave. The next attempt keeps prompting to pair, or refuses outright, because the keys do not match. Changing only the connection parameters, without pairing again, leaves the key usable, while current and delay change. Split the work: if it will not connect and keeps asking to pair, check the bond records on both sides. If it connects but reacts slowly or uses too much power, check the current connection parameters, not the pairing record.
When a gateway is the master, its bond table has a limited size. Past that size the oldest slave is pushed out. A few tags then need to pair again every few days, and the others stay normal. That is not a cellular-card problem. A SimtoLink card only connects the gateway and the cloud. The bond table is inside the Bluetooth master. If only a minority of slaves drop on a cycle and gateway attach stays normal, export the bond table and the latest connection parameters instead of replacing the IoT SIM card. When the gateway is replaced, the bonds must be migrated or rebuilt, or every slave stays on the old key.