lora
I'm a bit confused with LoRa. I understand the CSS modulation with the chirps, but I don't get what chips are. Are chips parts of the chirps?
I saw another topic on this, but the difference is not clear. As I understand it now, is that chirps consist of chirps. Is that correct?
Thank you!
LoRa is a chirp-based spread-spectrum modulation. A symbol is a chirp.
To generate symbols/chirps, the modem modulates the phase of an oscillator. The number of times per second that the modem adjusts the phase is called the chip rate and defines the modulation bandwidth. Chip rate is a direct subdivision of the quartz frequency (32 MHz).
Example for 125 kHz LoRa:
125 kHz modulation bandwidth
= 125000 chips per second
= 8 µs per chip
modulation bandwidth < occupied spectral bandwidth < channel spacing (typ 200 kHz)
Basic chirps are simply a ramp from fmin to fmax (up-chirp) or fmax to fmin (down-chirp). Data-carrying chirps are chirps that are cyclically-shifted, and this cyclical shift carries the information.
The spreading factor defines two fundamental values:
The reason is that a symbol, with a length of N chips, can be cyclically shifted from 0 to N-1 positions. The "reference" position is given by the un-shifted symbols at the beginning of the LoRa frame. So this cyclical shift can carry log2(N) bits of information. If N is a power of two, the math works nicely.
Example for SF 7
A SF 7 symbol is 128 chips long
= 1.024 ms @125kHz modulation bandwidth
= 512 µs @250kHz modulation bandwidth
= 256 µs @500kHz modulation bandwidth
A 128-chip long symbol can by cyclically shifted from 0 to 127 positions, and that shift
carries 7 bits of raw information:
~ 6.8 kbps raw @125kHz modulation bandwidth
~ 13.7 kbps raw @250kHz modulation bandwidth
~ 27.3 kbps raw @500kHz modulation bandwidth
Due to noise, this modulation/demodulation process introduces errors, and that's why an error correction code is added. For a typical payload, 25% (CR1) or 50% (CR2) of redundancy is added before modulating chirps. In practice, the data sent by the user is also mixed to get better error correction properties.
Raw data-rate and error correction define the nominal data-rate. To get the effective maximum data-rate a device can transmit at, you have to take into account:
Edit:
I have added (in red) the boundaries of chirps so that the effect of cyclical-shifts is easier to understand. Except for a few special symbols at the end of the preamble signaling a start of frame, all chirps in a LoRa frame are the exact same length. Frequency seems to "jump around" quite a bit, but there is no discontinuity in phase that would lead to copious amounts of unwanted harmonics all around the band.
Better late than never, I guess.
"Standard" LoRa and specifically LoRaWAN are not designed to support many densely packed independently operated networks like WiFi does (for example)
WiFi is quite short range, that's why you're under the impression that it handles high density better. When the size of a network barely goes beyond the walls of an apartment, it's quite easy for dozens of networks to cohabitate in the same building.
In a dense urban setting, WiFi effective range is around 20m. In the same setting LoRaWAN reaches around 1km. That's 2500 times more area for a given "cell" (more on that later) and the density has to be understood relative to the surface covered. Having hundreds of LoRaWAN gateways per square-km would be equivalent to having half a dozen of WiFi APs per room... and I think LoRaWAN was designed to handle that case much better than standard WiFi was¹. ;)
I would like to know how SEMTECH plans for the LoRa Picocells - at a density of say one per household - manage to avoid the collisions, blocking each other or otherwise interfering with each other that can happen if two radios (nodes or gateways) transmit on the same combination of frequency and spreading function (SF) at times close enough that they effectively overlap.
Side note ².
At the MAC/LLC level, LoRaWAN, like WiFi, use variable data-rate to optimize capacity. In LoRaWAN, this essential function is called "adaptive data rate" or ADR. In both cases, when a device is "close" (in the radio sense, so when it has a good link margin) to a gateway or access point, a higher data-rate is used, with the following benefits:
At high data-rate, a LoRaWAN network can use FSK modulation instead of LoRa, so you get the same range/spectral efficiency/interference problem as with all the legacy systems.
In both LoRaWAN and WiFi it's possible to decrease RF TX power, but it's only used when data-rate has reached the max, as it's preferable, from a network/interference point of view, to transmit faster at nominal power than to transmit at lower power and nominal speed.
Like the SX1301, the SX1308 is an array of receivers. On each radio channel of a given LoRaWAN network (200kHz channel width, 125kHz LoRa modulation bandwidth) the SX130x listen for six different data-rates simultaneously. That way, a device can send a frame to the network without having to reserve a time-slot or negotiate a predetermined data-rate with the network beforehand³, a process that is quite energy consuming. The SX130x always listen on all channels, all data-rates.
LoRa has primarily been optimized for low power, low data rate, low update rate, and long distance applications. Currently the best way to avoid these limitations is for multiple independent users to work with one or a few gateway providing services.
A home-by-home gateway implementation with from kilometer to tens of kilometer range would certainly lead to some problems, and since power is often available in homes, if there are any externally powered nodes they would not have the practical constraint of infrequent transmission to conserve battery life.
One of the specificity of LoRaWAN is that the "core" of the radio network is not the gateway, but a level above, the network server. If neighboring gateways are connected to the same server, they act as a single network. If not, they act as independent networks. In my opinion, you end-up with three different scenarios:
Lots of people buy gateways with stand-alone network servers, and use them with sensors in and around their home. Each independent network uses 3-4 channels and try to pick a different set of channels than the close neighbors (like WiFi). In that scenario, most sensors use the highest data-rate. Some sensors in unfavorable environments use lower data-rates but none are stuck at minimum speed (~300 bits/s). LoRaWAN can handle tens of thousands of low duty-cycle / high data-rate per square km. Interference would be low.
Lots of people buy gateways⁴ to connect to sensors beyond their home environment (eg. car or pet trackers) and use community networks (eg. The Things Network) for coordination. In this scenario, a high density of coordinated gateways allow all sensors in the community network to minimize data-rate. Devices can roam freely on the area covered by the network. Link reliability is high due to spatial diversity provided by the many scattered gateways. Encrypted data payloads from and to devices are transported on the community network, but only the owner of the device get access to clear-text payload. Regional frequency coordination can be handled on an ad-hoc basis by community and corporate network managers. Interference would be low assuming only a small number of networks share an overlapping region.
Lots of people buy single-channels gateways (all devices stuck to the lowest data-rate), or use standard gateways after disabling ADR, or use standard gateways with stand-alone network servers to connect to a large number of distance devices. In that scenario thousands of devices are stuck at the lowest data-rate, using as much time-on-air as they're legally allowed to use, draining their battery fast and not having a great reliability. Corporate private networks would still work for the site they're designed to cover but corporate public network would be limited to application that can handle packet losses of more than 20%.
Overall, I'm quite optimistic, as the migration from stand-alone networks to coordinated network requires a low effort, no change in hardware, and is transparent for the devices. But if you combine a high density of people and/or sensors, fierce individualism (not wanting to coordinate with a community, no interest in sharing spectrum) and magical thinking (long range = I can stream audio from kilometers away) you're in a "tragedy of the commons" kind of situation.
¹: To come back to your initial statement, for WiFi, each access point is normally an independent radio network, interference is an issue, high density leads to poor data-rates, and handover between APs is not handled gracefully. In dense WiFi deployments (eg. WiFi in stadiums, or when telcos use WiFi to serve residential customers from a water tower), access points rely on using dozens of independent channels in the 5 GHz band, proprietary magic sauce, GPS coordination, proprietary seamless handover, etc, with an external "server" in charge of managing the network.
²: Semtech doesn't write protocols nor do network planning. Semtech does the PHY layer and design chips to handle the PHY layer, period. LoRaWAN was a collaborative effort from the very beginning, and it is now in the hands of the LoRa Alliance.
³: That's why so-called "single channels" LoRaWAN gateways you might see popping up here and there are an heresy. You have to have this simultaneous multi-channel and multi-data-rate capability to be able to have a robust and salable network.
⁴: Practically, it makes sense for community to group-buy gateways, as a handful of gateways per city block is enough to provide coverage and capacity for the kind of applications LoRaWAN was designed for.
Best Answer
The CSS modulation uses "chirps" to spread the spectrum (i.e. the signal's center frequency increases during the entire transmission, while bandwidth remains constant).
In contrast, CDMA systems use "chips" to spread out the signal. Here, the center frequency remains constant, but bandwidth of the transmitted signal around the center increases, and different chip sequences can be used to separate channels.