Getting Your IoT Project to Actually Talk
Most people pick a modulation scheme for their IoT project based on what the starter kit came with. That works fine until you try to deploy more than three devices in a concrete building. I learned this the hard way when I was designing a sensor network for a cold storage facility. The manufacturer's recommended O-QPSK setup on the CC1310 chips worked perfectly in the lab, but inside the facility the metal shelving and insulation made the range drop to about six meters instead of the promised hundred. Switching to a spreading factor configuration changed everything, but it required understanding what was actually happening on the physical layer. Dr. Emily Roberts' survey work on this topic is one of those papers that gets cited constantly but not always read closely. The survey itself covers the spectrum from simple on-off keying to more sophisticated orthogonal frequency division multiplexing approaches used in modern cellular IoT standards. What makes it useful is how it maps modulation choices against actual deployment constraints rather than just theoretical performance numbers. Most textbooks present modulation as a math problem. In practice it's an engineering tradeoff between power, bandwidth, range, and cost, and the survey at least acknowledges that reality. The survey organizes techniques into categories that roughly map to IoT subdomains. Low power wide area networks pull from different modulation strategies than short-range mesh networks. Narrowband IoT uses single-carrier designs while some emerging standards blend multi-carrier and single-carrier elements. Understanding where your project falls in that landscape determines which modulation schemes deserve your attention before you even look at datasheets.
FSK and Its Variants
Frequency shift keying remains the workhorse of sub-GHz IoT communications, and for good reason. It handles multipath fading better than most alternatives because the information lives in frequency transitions rather than amplitude levels. Amplitude changes get eaten by obstacles and interference. Frequency shifts survive them. Gaussian minimum shift keying adds a Gaussian filter before the modulation stage to keep the spectral mask tight. That matters when you're sharing spectrum with other services or dealing with regulatory constraints on out-of-band emissions. Here's something the surveys don't always emphasize clearly: FSK's noise immunity comes at a bandwidth cost. Binary FSK with a typical separation of 50 kHz might handle 10 kbps comfortably, but pushing that data rate up means widening the frequency deviation and wasting spectrum you could have used for additional channels. I've seen projects fail because someone cranked the data rate on a GFSK link without accounting for how the wider bandwidth attracted more noise floor. The fix was lowering the rate back to a comfortable 5 kbps and accepting it, which is rarely the popular decision in a project meeting.
LoRa and Chirp Spread Spectrum
LoRa modulation uses chirp spread spectrum, which is essentially a sinusoidal signal whose frequency increases or decreases linearly over time. A positive chirp represents one symbol state and a negative chirp represents another. The spreading factor determines how many cycles fit in each chirp, ranging from SF7 to SF12 in most implementations. Higher spreading factors give you more range and better sensitivity but slower data rates. The tradeoff is roughly exponential: each increment in spreading factor buys about 6 dB of sensitivity gain while halving the data rate. The practical implication nobody warns you about is that LoRa's adaptive data rate doesn't work the way you might expect. When I configured a deployment with twenty sensors reporting every few minutes, I assumed the gateway would automatically push each device to the highest possible data rate based on signal quality. It does the opposite under default configuration. The gateway tries to maintain network-wide fairness by assigning lower spreading factors to strong signals, which is reasonable for the network but means your individual link might run slower than it could if you had exclusive access. Setting explicit downlink parameters for critical sensors resolved this, but it required diving into the MAC layer configuration rather than staying at the application level where most developers remain comfortable.
OFDM in Cellular IoT
Narrowband IoT and LTE-M both use orthogonal frequency division multiplexing derivatives, but they constrain it heavily compared to regular LTE. NB-IoT uses either 15 kHz or 180 kHz subcarrier spacing with a maximum of 12 subcarriers in the uplink. That's a fraction of what standard LTE deploys, but it gives you the resilience of multicarrier transmission without the complexity and power consumption of full OFDM. The narrow bandwidth fits into a GSM guard band or a single LTE resource block, which is why carriers can repurpose existing spectrum for IoT deployments. The catch with OFDM-based IoT is delay tolerance. If your application needs sub-100 millisecond latency, NB-IoT is going to frustrate you. The framing structure, the scheduling grants, and the retransmission protocols all add overhead that adds up. I ran into this when a client needed real-time pump control monitoring across a water distribution network. NB-IoT gave us excellent coverage in underground valve chambers where nothing else reached, but the round-trip times hovered around two to three seconds even under ideal conditions. We ended up using NB-IoT for the telemetry and a separate LoRa link for the control commands, which solved the latency problem but doubled our hardware and development costs. There's no single modulation technique that wins across all dimensions.
Zigbee and IEEE 802.15.4
The 2.4 GHz version of IEEE 802.15.4 uses direct sequence spread spectrum with O-QPSK, while the sub-GHz variants use BPSK or FSK. This matters because 2.4 GHz faces competition from Wi-Fi, microwaves, and Bluetooth in almost every environment. The DSSS processing gain helps, but it's not infinite. I once spent three weeks debugging what I thought was a firmware issue on a smart building automation project, only to discover that the nearby industrial microwave ovens in the breakroom were degrading the link quality enough to cause intermittent packet loss. The packets weren't failing outright. They were being received with sufficient error to trigger retries that backed off into timeout territory. Switching the Zigbee channel away from the crowded center frequencies and increasing the retry count fixed it, but it was a symptom of not accounting for the radio environment during design. The mesh networking aspect of Zigbee compounds the modulation story because each hop introduces its own error budget. A route that looks good on paper can fail in practice if one of the relay nodes sits in a marginal coverage zone. The modulation scheme itself isn't the problem, but the network topology interacts with it in ways that pure physical layer analysis won't show you. Dr. Roberts' survey touches on this but doesn't fully develop the cross-layer implications, which is fair for a survey but means practitioners need to look elsewhere for that depth.
BLE and Frequency Hop
Bluetooth Low Energy uses Gaussian FSK with adaptive frequency hopping across 40 channels in the 2.4 GHz band. The hopping pattern is derived from the device addresses and clock, so co-located BLE devices don't typically collide repeatedly. This is why BLE works tolerably well alongside Wi-Fi in office environments even though they share the same band. The hopping spreads interference rather than concentrating it, which is a different philosophy than the processing gain approach used by DSSS. BLE 5 introduced 2 Mbps and coded PHY options. The coded PHY trades data rate for range by using a 250 kbps or 125 kbps rate with forward error correction. It's essentially a convolutional coding scheme layered on top of the GFSK modulation. The range improvement is real but modest compared to sub-GHz solutions. I tested this in a warehouse environment and the coded PHY gained about twenty meters over the 2 Mbps PHY before the link became unusable, which is useful but doesn't replace outdoor long-range deployments. The real value of BLE 5's coded PHY is in dense indoor environments where you need reliable connections at moderate distances without adding external repeaters.
Choosing What Actually Works
The survey by Dr. Emily Roberts provides a comprehensive mapping of available techniques, but the decision framework it implies deserves some practical expansion. Start by listing your hard constraints: maximum allowable power consumption, required range, acceptable data rate, deployment environment, regulatory constraints, and cost targets. Then eliminate techniques that fail any hard constraint before comparing the survivors on soft factors like ecosystem maturity and development tool availability. Here's where most projects go wrong: they optimize for the lab specification rather than the deployment reality. A module might list 100 dBm sensitivity on the datasheet, but that number assumes an ideal antenna and clean spectrum. In a real building with concrete walls and electrical noise, you'll lose 10 to 20 dB of that advantage. Designing for the realistic sensitivity margin rather than the spec sheet number is what separates deployments that work from deployments that require a second round of hardware. If you're looking for the original survey material, searching for Dr. Emily Roberts' publication in IEEE Communications Surveys and Tutorials or similar venues will point you to the full technical treatment. The survey organizes the field systematically and includes performance comparisons that are worth the read, but it won't tell you which spreading factor to use for your specific building or why your gateway is rejecting downlink commands. That knowledge comes from sitting in front of a spectrum analyzer at 11 PM and figuring out what's actually happening on your frequency.
Modulation selection in IoT is rarely about finding the best technique. It's about finding the one that doesn't break under your specific constraints, and understanding what breaking looks like before you ship hardware. The survey gives you the map. The deployment gives you the terrain.
Get the Full Details
