{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreihfwvruo2sltgktu3txqk4nuyflbeat42nakogmcmgmbnf7ntkdxe",
    "uri": "at://did:plc:r6wd44ykivsom67rysktxcfb/app.bsky.feed.post/3mkn5qzdv6bh2"
  },
  "coverImage": {
    "$type": "blob",
    "ref": {
      "$link": "bafkreicoi5rwieff3gzzwz2sh6qiielffti7o3dovwgq362x5kkypmbs54"
    },
    "mimeType": "image/jpeg",
    "size": 157878
  },
  "description": "LoRa is just the radio. LoRaWAN turns it into a network. Here’s what it adds, and what it takes to get long-range IoT data flowing from sensor to screen.",
  "path": "/lorawan-in-practice-building-long-range-wireless-for-iot/",
  "publishedAt": "2026-04-29T13:00:06.000Z",
  "site": "https://www.technodabbler.com",
  "tags": [
    "Semtech",
    "LoRa Alliance",
    "LoRa",
    "Inside LoRa: Exploring the Future of Wireless IoT with the SX1262How far can a sensor whisper? LoRa bridges the gap between Wi-Fi and cellular, sending data across kilometers on milliwatts of power. We test its design, spectrum, and limits.TechnodabblerAlex Denault",
    "LoRaWAN Network Explained with Cases | TEKTELICLearn what LoRaWAN® is, how it works, device classes, benefits, and how it compares to Zigbee, NB-IoT, and other IoT options.TEKTELICTEKTELIC",
    "Helium",
    "Is the Helium LoRaWAN Network a Success or a Failure?The Helium Network uses blockchain to power decentralized, low-cost IoT connectivity. Discover how it works, its rapid adoption, and whether the model can stay profitableTechnodabblerAlex Denault",
    "ChirpStack",
    "thousand of other gateways",
    "the Dragino Dashboard",
    "Learn more"
  ],
  "textContent": "Most wireless protocols weren’t designed with IoT in mind. Wi-Fi is fast but power-hungry. Bluetooth is low-energy but limited in range and scale. Cellular networks cover long distances, but come with high costs, complex provisioning, and power demands that small battery-powered devices can’t afford.\n\nLoRa takes a different approach. It offers long-range, low-power radio communication using unlicensed spectrum. It’s a good fit for sensors, meters, and trackers that only need to send small amounts of data a few times per hour. But to turn LoRa into a functional network, something else is needed.\n\nThis article explores what LoRaWAN adds to the picture, how it’s structured, and what it takes to actually use it, starting from the hardware and ending with real-world data in a dashboard.\n\n## **What LoRaWAN Adds to LoRa**\n\nLoRaWAN originated in 2015 as a specification developed by Semtech and a group of early adopters seeking to formalize how long-range, low-power devices could communicate over shared spectrum. This effort led to the formation of the LoRa Alliance, a nonprofit consortium that now oversees the standard. The Alliance coordinates regional frequency plans, certification programs, and interoperability testing to ensure devices and networks from different vendors can work together. Today, it includes hundreds of member organizations ranging from hardware makers to national telecom operators.\n\nLoRa provides efficient radio communication for long-range, low-power and low-bandwidth wireless data transfer. But as a physical layer protocol, it stops short of offering anything resembling a network. There’s no built-in addressing, no security model, and no guarantee of message delivery. In this raw state, LoRa is best suited for point-to-point or single-purpose applications. LoRaWAN addresses these gaps by defining a MAC-layer protocol that sits above the LoRa radio layer. It specifies how devices identify themselves, how data is encrypted, how acknowledgments are handled, and how messages are routed through a network of gateways to a centralized server.\n\nInside LoRa: Exploring the Future of Wireless IoT with the SX1262How far can a sensor whisper? LoRa bridges the gap between Wi-Fi and cellular, sending data across kilometers on milliwatts of power. We test its design, spectrum, and limits.TechnodabblerAlex Denault\n\nEvery LoRaWAN device has a globally unique identifier (DevEUI) and exchanges session keys with the network server upon joining. Messages are encrypted end-to-end using AES-128 and authenticated via message integrity codes. The protocol supports both confirmed and unconfirmed messaging, with built-in retry logic that balances reliability against limited airtime budgets.\n\nLoRaWAN conserves energy by structuring communication around sleep cycles. End devices stay dormant nearly all the time, waking only to send one message and briefly wait for one or two messages, typically one and two seconds after the transmission. These windows give the network a narrow opportunity to deliver a message to a device. If no message arrives, the device powers down again. This design allows a sensor to operate for years on a small battery. Gateways, meanwhile, play a passive role: they listen continuously across multiple channels and spreading factors, forwarding any message they hear.\n\n## **Core LoRaWAN Architecture: Devices, Gateways, Servers**\n\nA LoRaWAN network is built around a simple but effective star-of-stars topology. At the edge are the devices that transmit data using LoRa: sensors, trackers, meters. They simply transmit, and any gateway in range will pick up the signal. Gateways act as transparent bridges. Unlike Wi-Fi access points or cellular towers, they don’t authenticate devices or manage sessions. Instead, they continuously monitor multiple channels and spreading factors, capturing LoRa packets and forwarding them unaltered and unprocessed to a central network server.\n\nA typical LoRaWan setup is composed of sensors, one or more gateways, a network server and an application layer for capturing and visualizing data.\n\nAt the center of the network sits the LoRaWAN Network Server (LNS). This is where protocol enforcement happens. The server deduplicates packets received by multiple gateways, validates message integrity, manages encryption keys for each device, and schedules message sending. It’s also responsible for enforcing sleeping cycles and adapting data transmission speeds to optimize airtime and range.\n\nLoRaWAN can be deployed campus-wide, accross several miles.\n\nWhile the LNS handles the mechanics of the network, application data is forwarded separately, often to an MQTT broker, a HTTP endpoint, or a cloud service. This separation of concerns gives developers flexibility, allowing them to focus their application without worrying about encryption or routing. Meanwhile, network operators can optimize the network to maximize distance, bandwidth and power efficiency. As such, a LoRaWan deployment can typically be scaled up to more devices by adding gateways.\n\n### **LoRaWAN Device Classes: A, B, and C**\n\nNot all LoRaWAN devices work the same way. The protocol defines three “classes” that describe how a device talks and listens. Each class balances power use with how often the device is available to receive messages.\n\n**Class A** is the default for most devices. It’s designed to save power. A sensor sends its data, then waits quietly for a short time, usually one or two seconds, to see if the network has anything to say back. If no message arrives, the device goes back to sleep. This is ideal for things like weather stations or soil sensors that only need to report a few times a day and don’t expect constant updates.\n\n**Class B** devices wake up more often. In addition to listening after sending data, they check in at regular intervals. This makes it easier for the network to send them messages even when they haven’t just transmitted something. It uses more energy, but it’s a good fit for systems that need occasional updates from the network, like a street sign that might need new information a few times every hour.\n\n**Class C** devices are always ready. They keep their radios on and listen all the time, unless they’re actively sending something. This allows the network to reach them immediately, but it burns through power. These devices usually need to be plugged in, and they’re used for things like remote controls or automated valves: cases where you want instant response.\n\nEach class represents a tradeoff. Longer battery life means less flexibility in communication. Faster communication means more power use. LoRaWAN gives developers and device makers options, depending on what they need their device to do.\n\n### Typical Devices and Typical Deployments\n\nThe most common LoRaWAN devices fall into two broad categories: environmental sensors and location trackers. Environmental sensors include those for temperature, humidity, CO2, water level, air quality, and soil moisture. These devices are typically used in smart agriculture, facility monitoring, and public infrastructure. For example, a single soil sensor in a vineyard might transmit data every hour for years without requiring maintenance. Temperature and humidity sensors are also widely used in cold chain logistics and smart buildings to ensure climate conditions remain within defined ranges.\n\nLocation-aware devices use GPS and periodically send position data over LoRaWAN. These are deployed in fleet management, livestock monitoring, and asset tracking. Because LoRaWAN enables wide-area coverage with minimal power, it's ideal for moving devices that only need to check in occasionally. Asset tags can last months or even years on a single battery, making them more practical than cellular alternatives for intermittent location updates.\n\nLoRaWAN Network Explained with Cases | TEKTELICLearn what LoRaWAN® is, how it works, device classes, benefits, and how it compares to Zigbee, NB-IoT, and other IoT options.TEKTELICTEKTELIC\n\nAn impressive article on different LoRaWAN sensors and deployments.\n\nCommon deployment environments include agriculture, where sensors track weather, irrigation, and soil health; industrial facilities that use LoRaWAN for equipment telemetry and predictive maintenance; and municipal settings where smart city applications like parking monitors, street lighting controllers, and waste bin sensors benefit from long-range, battery-friendly connectivity. In each of these cases, LoRaWAN's strength lies in connecting many low-data, long-life devices to a central system with minimal infrastructure.\n\n### Deployment Choices : Public vs Private\n\nOnce the basics of LoRaWAN are in place, devices, gateways, and a network server, the next decision is where that infrastructure lives. Some developers rely on public networks that are already deployed. Others run everything themselves. Both approaches have tradeoffs in cost, control, and coverage.\n\n**Public networks** like The Things Network (TTN) and Helium offer access to existing LoRaWAN infrastructure. If a gateway is nearby, you can register your device and start transmitting without deploying hardware. TTN is community-run and free to use, making it popular among hobbyists, researchers, and education projects. It has usage limits, but it's more than enough for many small applications, like weather monitoring.\n\nThe Thing Stack, configure to collect temperature data from a Dragino sensor.\n\nHelium, by contrast, is commercially structured and powered by cryptocurrency. The network is made up of independently owned gateways, and each operator is rewarded with crypto tokens when their hardware provides coverage or helps move data. This incentive model led to a rapid global buildout: at its peak, Helium had hundreds of thousands of LoRaWAN gateways deployed in cities and towns around the world. To use the network, developers pay per message using a credit system, but they gain access to this broad coverage without having to install or maintain their own gateways.\n\nIs the Helium LoRaWAN Network a Success or a Failure?The Helium Network uses blockchain to power decentralized, low-cost IoT connectivity. Discover how it works, its rapid adoption, and whether the model can stay profitableTechnodabblerAlex Denault\n\nLearn more about Helium, the crypto-based LoRaWAN network\n\n**Private networks** are the opposite. Here, the developer controls the gateways, the network server, and the backend services. This adds complexity, especially in deploying a set of gateways, but allows full control over data routing, performance, and security. Open Source stacks, like ChirpStack, make it possible to run a private LoRaWAN deployment on a local server, a cloud VM, or even a Raspberry Pi. This is common in agriculture, industrial monitoring, or any case where infrastructure must be self-contained.\n\nChirpStack is the common solution for a private deployment.\n\nThe right choice depends on your project. If you’re testing a sensor or deploying a single node, public infrastructure may be all you need. But if you’re planning to deploy in a remote location, or require data privacy, having more control can make a difference.\n\n## Exploring a LoRaWAN Setup\n\nAt Technodabbler, we set out to see how much effort it would take to get a basic LoRaWAN setup working. The experiment started with two devices: a Heltec LoRaWAN Gateway (HT-M7603), a compact indoor unit designed to handle traffic from local sensors, and a Dragino LHT65S E3, a battery-powered temperature and humidity sensor equipped with an external probe. The goal was simple: collect temperature readings from the Dragino and get that data into a usable format.\n\nThe Heltec LoRaWAN Gateway (HT-M7603) require both a network connection and power to operate. Although Wifi is supported, the ethernet connection is much more reliable.\n\nOur first attempt, favoring a private network, involved setting up a ChirpStack server and connecting the Heltec gateway to it. We never got that working, either due to firmware quirks or missed network settings. Instead, we pivoted and connected the gateway to The Things Network. Instantly, our gateway joined a thousand of other gateways, contributing Things' large-scale LoRAWan network. Configuration instructions were easy to find, and setup only took a couple of minutes.\n\nThe next step was connecting the Dragino sensor, which mostly consisted of registering its DEUI number with the network server. Now, any gateway connected to the Thing Network can hear the sensor and will record its metric. Conveniently, the newly setup gateway assumes this role, and temperature data is forwarded to the network server.\n\nThe Dragino LHT65S E3 temperature sensor, deployed on a balcony.\n\nBut raw LoRaWAN payloads aren’t readable by default. The protocol just passes along a string of bytes: a payload formatter is required to transforms it into usable data, like Celsius instead of hex values. TTN provides a way to define these formatters per device using Javascript, which made it easy to decode the sensor’s output. Decoders for more common LoRaWAN devices are readily available on the internet.\n\n\n    function str_pad(byte){\n        var zero = '00';\n        var hex= byte.toString(16);\n        var tmp  = 2-hex.length;\n        return zero.substr(0,tmp) + hex + \" \";\n    }\n\n    function Decoder(bytes, port) {\n    var Ext= bytes[6]&0x0F;\n    var poll_message_status=(bytes[6]&0x40)>>6;\n    var Connect=(bytes[6]&0x80)>>7;\n    var decode = {};\n\n    if(Ext==0x09)\n    {\n      decode.TempC_DS=parseFloat(((bytes[0]<<24>>16 | bytes[1])/100).toFixed(2));\n      decode.Bat_status=bytes[4]>>6;\n    }\n    else\n    {\n      decode.BatV= ((bytes[0]<<8 | bytes[1]) & 0x3FFF)/1000;\n      decode.Bat_status=bytes[0]>>6;\n    }\n    ...\n\nBeginning of the payload decoder for the Dragino LHT65S\n\nNext came the backend. This was one of the more surprising parts: Dragino doesn’t offer a platform for visualizing data from their sensors. They build the hardware, but leave integration to the user. Our first solution was to create a basic Python application, the Dragino Dashboard, that pulled data from TTN and wrote it into a MySQL database. It worked, but wasn’t ideal.\n\nDragino Dashboard, a python application that collects telemetry and stores it into a database.\n\nThat led us to explore hosted IoT platforms. We landed on **Datacake** , which provides a web-based dashboard for visualizing sensor data, including pre-built templates for common LoRaWAN devices. After about an hour of setup, we had TTN forwarding sensor readings directly to Datacake, where they appeared in clean graphs and tables.\n\nDatacake configured to collect data for our Dragino temperature sensor.\n\nThe experience made it clear: LoRaWAN is powerful, but setting up a full data pipeline still takes some legwork. With the right tools, though, even a small home lab can run a complete long-range wireless sensor system.\n\n## **Trading Convenience for Capability**\n\nWorking with LoRaWAN often feels like assembling a Lego set built by four different companies: each using slightly different plastics, tolerances, and instructions. The pieces technically fit together, but not always cleanly, and never on the first try. The radio, the network server, the payload format, and the data visualization layer each come from separate ecosystems. Getting them aligned requires patience, documentation digging, and a willingness to experiment.\n\nAnd yet, once assembled, the result is remarkably solid. LoRaWAN might not offer instant gratification, but it delivers long-range, low-power networking that can scale from a garden sensor to a city-wide deployment. Its design choices, strict timing, asynchronous communication, lightweight payloads, reflect real-world constraints. The temperature sensor deployed in our experiment, for example, is expected to run for ten years on the supplied battery, without ever needing a recharge or a network reconnection.\n\nDespite its rough edges, LoRaWAN continues to thrive because it solves real problems in the field, without requiring expensive infrastructure or ongoing service fees. It’s a protocol that asks more effort at the beginning, but delivers more over the long run.\n\nHave you deployed a LoRaWAN sensor in the wild? How did you set it up? If you're thinking about deploying your own gateway, check out our article on testing and comparing antennas. It’s a crucial step in getting reliable range from your deployment.\n\n\n                            Learn more\n                        ",
  "title": "LoRaWAN in Practice: Building Long-Range Wireless for IoT",
  "updatedAt": "2026-04-29T13:00:06.000Z"
}