A robot at the far end of a site finds its route blocked. It is past the edge of the building's Wi-Fi, the nearest teammate is two aisles and a concrete wall away, and the air is crowded with motors, chargers and other radios. The message it needs to send is short: route B3 blocked, task T7 released. That fits in a few dozen bytes.

It does not need a fast link. It needs a link that arrives, through distance and through noise.

That is why we've started looking at LoRa. In an earlier update, we described a Node PCB design with a separate LoRa radio alongside its main processor. Our fleet architecture post argued that networking should be chosen around a workload, not a radio label. This update explains what LoRa is, why its chirps suit robot teams, where its limits are, and how we plan to test it when prototyping begins.

What is LoRa?

Imagine a slide whistle. Each note starts low and sweeps smoothly up to high. Now imagine you could start the sweep at different points, wrapping back to the bottom when you hit the top. A listener who knows the pattern can tell where each sweep started, even if the sound is faint and the room is noisy.

That rising sweep is called a chirp, and it is the core of LoRa.

LoRa, short for Long Range, is a radio modulation technique developed by Semtech. It is built on a method called chirp spread spectrum. Instead of sending each piece of data on one narrow frequency, LoRa spreads it across a band as a chirp. Semtech describes it as the physical layer: the part that turns bits into a radio signal and back again.

Spreading the signal costs speed but buys robustness. The receiver knows what shape to expect, so it can pick a chirp out of noise that would swamp a simpler signal. Microchip's overview summarizes the trade: better sensitivity in exchange for a lower data rate.

LoRa typically runs in licence-exempt sub-gigahertz bands. In Canada and the United States, that is the 902–928 MHz band. Lower frequencies generally travel farther and pass through obstacles better than 2.4 GHz signals, which is part of why LoRa can reach kilometres outdoors with modest power.

How a chirp carries data

Each chirp is one symbol. Data is encoded in where the chirp starts within the band. Three settings shape how that works:

  • Spreading factor (SF): how long each chirp lasts. LoRa commonly uses SF7 to SF12. Each step up doubles the chirp's duration and lets each symbol carry one more bit, but the net data rate roughly halves.
  • Bandwidth: how wide a sweep each chirp covers, commonly 125, 250 or 500 kHz. Wider is faster but less sensitive.
  • Coding rate: how much error-correction is added. More correction recovers more damaged packets, at the cost of extra symbols.

Longer chirps give the receiver more signal to work with. The Things Network's documentation lists typical receiver sensitivity at 125 kHz improving from about −123 dBm at SF7 to about −137 dBm at SF12. In practical terms, a higher spreading factor can hear a much weaker signal.

The same documentation notes a useful property: signals using different spreading factors on the same channel are close to orthogonal. Two transmissions at SF7 and SF9 can often overlap without destroying each other.

Frequency over time. Four identical rising chirps form the preamble, then three data chirps each start at a different frequency, rise to the top of the channel, wrap to the bottom and continue.The preamble's identical chirps let a receiver find the signal; each data chirp's starting point carries its value. Illustrative and simplified from a real LoRa frame.

Why chirps suit robot teams

The chirp is the part of LoRa that caught our attention. It gives two properties at once, and both matter for swarms.

The first is reach. Robot teams spread out. A scout explores the edge of an area, a relay holds a position in the middle, and a worker sits at a station far from either. Coordination depends on findings reaching the robots that can act on them, even when those robots are not close by. A radio that can hear very weak signals extends how far a single hop can go, which means fewer relays between a discovery and the teammate who needs it.

The second is noise tolerance. Because the receiver knows the exact shape of a chirp, it can recover a signal that is weaker than the background noise around it. The Things Network notes that LoRa can demodulate below the noise floor, down to a signal-to-noise ratio of about −20 dB at SF12. Places where robot teams work are rarely quiet: warehouses full of motors and Wi-Fi, industrial sites, and disaster zones with damaged infrastructure. A link that keeps working when the band is noisy is valuable exactly where coordination matters most.

Those two properties come from the same mechanism, and so does the cost. Longer chirps hear farther and through more noise, but they take longer to send.

Bar chart of time on air for one 64-byte packet, rising from 118 ms at SF7 to 2,794 ms at SF12, with receiver sensitivity improving from −123 dBm to −137 dBm.Each spreading factor step roughly doubles the time a packet spends on air, in exchange for hearing a weaker signal. Calculated with Semtech's time-on-air formula; sensitivity values from The Things Network. Not measured.

Where LoRa could fit in ECITON-R

This is a proposed role. LoRa has not been selected as an ECITON transport.

The Node architecture separates the message router, which decides what a message is for, from the transport manager, which chooses an available connection. LoRa would be one option the transport manager can choose, suited to a specific kind of message:

  • Good candidates: task claims and releases, short findings like a blocked route, heartbeats, regional summaries, and alerts that must arrive when other links are down.
  • Poor candidates: maps, images, raw sensor streams, and anything that needs frequent updates from many robots at once.

Under this design, a robot's decision layer would never need to know which radio carried a message. It would know the message's cost and whether it was delivered. Airtime would become an explicit part of each robot's communication budget, alongside bytes, energy and compute.

A host robot connects through an adapter to the ECITON-R Node's decision logic, message router and transport manager. The transport manager can send over Bluetooth LE for nearby updates, or over LoRa for small, long-range messages.The proposed split: the decision layer chooses what to say, and the transport manager chooses how to send it. Not a measured or deployed configuration.

The prototyping board

For our first experiments, we plan to use the RAKwireless RAK4630. It is a small module that pairs a Nordic nRF52840 processor with a Semtech SX1262 LoRa transceiver, and it supports the 915 MHz band used in North America. That is the same arrangement as our Node design: a Nordic processor with a separate LoRa radio. Working on the RAK4630 first lets us develop firmware and radio behavior on proven hardware before our own board is assembled.

The nRF52840 also supports Bluetooth Low Energy. One module therefore offers a short-range link and a long-range link, which gives the transport manager a real choice to test.

What we need to prove

The first question is narrow: can a small, useful message reliably reach the right teammate over LoRa, and change what that teammate does?

After that, we need to understand how LoRa behaves as more nodes share the channel. Collisions, half-duplex timing, relay traffic and regulatory limits all reduce real capacity below the calculated best case. A two-node bench link cannot establish what a fleet can do.

We also need to know when LoRa is the wrong choice. A good transport manager should fall back to a faster link when one is available, and reserve long-range airtime for the messages that need it.

If you have built LoRa systems for mobile robots, or tested sub-GHz radios in busy indoor spaces, we would like to hear what you found. You can explore Swarm Lab and follow ECITON Robotics as we start testing on real hardware.

Image credits: Meshtastic spectrum, medium fast, Tinux, CC0. Used unchanged. Images 2, 3 and 4 by ECITON Robotics.

Sources