Other IoT (Besides BLE)

I wanted to let you know that there are other IoT protocols out there besides BLE. We hear a lot about BLE, and last time, I wrote a lot about the operation of BLE.

This time I want to write about other alternatives. This isn’t going to be a comprehensive list but, hopefully, will give you a flavor of what is out there.

Where to start? Well let’s start with Wi-FI. Wi-Fi operates in 2.4GHz and 5GHz (and soon 6GHz, but we’ll ignore that for now). Most people don’t automatically register Wi-Fi with IoT but there are IoT devices out there that use Wi-Fi.

Most IoT protocols run on top of 802.15.4 or a variant of it. These protocols are ideal for IoT systems.

IoT protocols that use 2.4GHz include Bluetooth/BLE, Zigbee and WirelessHART. These operate in the same frequency space as 2.4GHz Wi-Fi.

We also have CBRS (private LTE) operating around 3.6 MHz.

Most of the rest of the more common protocols* operate Sub-1GHz. Usually operating around 800-900+MHz (country dependent in many cases). This is where you will find Z-Wave, LoRa, Thread, and HaLow.

Let’s have a high-level overview of WirelessHART, LoRa, Thread and HaLow.

WirelessHART operates in the 2.4GHz ISM band and is designed to be low-power and have long battery life. Used in industrial and especially refinery industries. Here is a link to a great overview of WirelessHART by my colleague and friend, Troy Martin: https://www.youtube.com/watch?v=FkoY5NF0fVY

LoRa stands for Long Range. It is designed to allow communication between 2 points (P2P) over long distances. LoRaWAN is based on LoRa and is the protocol for building a network.

Thread is a mesh-based system based on 802.15.4. It runs on IP(v6) and is designed to create device-to-device, or device-to-cloud communications. Thread builds on top of 6LowPAN, which is IPv6 over Low-Power Wireless Personal Area networks.

HaLow was created by the Wi-Fi Alliance and is sometimes called Wi-Fi for IoT. It is based on 802.11ah and thus runs below 1GHz (S1G). It has low-power and long-range, penetrating walls and building due to its operation below 1GHz. It is designed to be very power efficient, running for years on coin cell-type batteries. Like other Sub-1GHz protocols the exact frequencies that HaLow runs on is region dependent.

Well there you go. Now you know more about IoT and some of the various protocols that exist to support it.

See you next time!

===

About NC-Expert

NC-Expert is a privately-held California corporation and is well established within the Wireless, Security, and Collaboration industry certification training, courseware development, and consulting markets.

Led by its Founder and CEO, Rie Vainstein, NC-Expert has won numerous private contracts with Fortune level companies around the world. These customers have depended on NC-Expert to train, advise, and mentor their staff.

So remember, if you are looking for the best IT training just call us at (855) 941-2121 or contact us

The post Other IoT (Besides BLE) appeared first on NC Expert.

NC-Expert Blog

Wi-Fi Myth Series - Myth #12: Auto Channel Selection ALWAYS Knows Best

By Rie Morgan • August 28, 2026
Automatic Channel Selection sounds like one of those features we should simply be able to trust: the APs monitor the RF environment, the Controller gathers data, an Algorithm considers interference, utilization, neighboring APs, channel availability, and other metrics, then Radio Resource Management (RRM) does its “thing” and selects the best channels. Wonderful! One less problem for the wireless engineer to worry about... except RF rarely cooperates with anything quite that neatly! Modern RRM systems are remarkably capable, and automatic channel selection can dramatically simplify the management of large wireless environments, but an algorithm can only make decisions based on the information it collects, the parameters it has been given, and the objectives it has been designed to optimize. That makes automation a powerful engineering tool. It does not make it the engineer.

Wi-Fi Myth Series - Myth #11: Interference Is Always Someone Else’s Wi-Fi

By Rie Morgan • August 20, 2026
When Wi-Fi performance suddenly deteriorates, interference is often the first culprit to be suspected and, when this (interference) enters the conversation, attention tends to turn immediately toward neighboring Wi-Fi networks. “Someone must have installed another AP.” “The office next door is probably using our channel.” “There are too many SSIDs around here.” Sometimes, this diagnosis is exactly right, but RF interference has a much larger cast of characters than just neighboring APs. In fact, some of the most frustrating wireless problems occur when the interfering device isn’t speaking 802.11 at all! The spectrum doesn’t particularly care whether the energy occupying it came from an enterprise AP, a Bluetooth headset, a microwave oven, or something considerably stranger. To a Wi-Fi radio trying to communicate, unwanted RF energy is simply unwanted RF energy. Wi-Fi Has to Share the Neighborhood The 2.4 GHz band has always been something of an RF “community center”. Wi-Fi operates alongside Bluetooth, Zigbee and other technologies, while various consumer, industrial, medical, and electronic devices may also generate energy within or around the same spectrum. Microwave ovens are perhaps the most famous example. Their emissions can interfere with 2.4 GHz Wi-Fi, particularly when clients are operating nearby. Bluetooth devices, cordless equipment, wireless cameras, sensors, and other transmitters can also contribute RF energy. Some interferers transmit continuously. Others appear periodically. Some hop frequencies. Others produce wideband noise. That last category can be particularly entertaining to troubleshoot... in the very specific sense of “entertaining” that wireless engineers use when they have been staring at spectrum analysis for three hours! The important point is that interference doesn’t need to understand Wi-Fi to disrupt it.

Wi-Fi Myth Series - Myth #10: The AP Is Up, So the Wi-Fi Must Be Fine

By Rie Morgan • August 13, 2026
There is something wonderfully reassuring about seeing a row of green APs on a wireless dashboard: APs connected; radios operational; no obvious alarms; everything green. Excellent! The Wi-Fi must be fine... Except, of course, the users are complaining that Teams calls are breaking up, handheld scanners keep disconnecting, authentication takes forever, and someone in Accounting has discovered that turning Wi-Fi off and back on again temporarily fixes everything. Welcome to one of the more persistent myths in enterprise wireless: if the AP is up, the Wi-Fi must be working. An operational AP tells us something useful... but it tells us surprisingly little about the experience of the clients actually using the network. “Up” is an Infrastructure State When a monitoring platform reports that an AP is up, it usually means the infrastructure can communicate with it. It tells us: - the AP has power - its Ethernet connection is functioning - it may have established its management or CAPWAP connection - its radios are probably operational - it hasn't disappeared into the networking equivalent of a “black hole” ...all good things. But none of those things proves that a client can successfully use an application. Consider what still has to happen after the AP proudly announces its existence. A client must: discover the WLAN associate authenticate obtain the appropriate network configuration reach its default gateway resolve DNS access the required network resources, and maintain sufficient RF performance to exchange data reliably. Depending on the environment, that journey may involve: 802.1X RADIUS DHCP DNS VLANs ACLs firewalls roaming mechanisms upstream switching WAN connectivity cloud services ...and several other systems waiting for their opportunity to make your afternoon more “interesting”. ;-) The AP actually being operational is merely one part of that chain!