DecodingLora

From RevSpace
Revision as of 22:35, 17 January 2016 by Bertrik Sikken (talk | contribs)
Jump to navigation Jump to search
Project DecodingLora
DecodingLora Project.jpg
Status In progress
Contact bertrik
Last Update 2016-01-17

This page is about understanding the LoRa RF modulation format.

LoRa is an abbreviation of Long Range, meaning it is an radio modulation format that gives longer range than straight FSK modulation. This is achieved by a combination of methods: it uses a spread spectrum technique called Chirp Spread Spectrum (CSS) and it uses forward error coding (in combination with whitening and interleaving).

To transmit or receive LoRa signals, you need to buy hardware that supports this modulation format.

The goal of this project is to collect more detailed information on the LoRa modulation and packet format. A concrete result could be that someone writes software which makes it possible to receive and decode LoRa signals with a cheap software defined radio, like rtlsdr.


Modulation basics

The LoRa modulation appears to be defined by the following basic parameters:

  • the bandwidth BW, meaning the difference in minimum and maximum frequency
  • the spreading factor SF, this is a measure for the number of bits encoded per symbol
  • the coding rate CR, this is a measure for the amount of forward error correction

Additionally the following settings can be changed:

  • preamble length and SyncWord value
  • whether an explicit header is sent with the message, this header contains information about the parameter of the rest of the message (payload length, the CR parameter, CRC presence)
  • presence of a 16-bit CRC
  • the LowDataRateOptimization bit

On the air I have seen the following waveforms:

  • a series of up-chirps at the start of a message (preamble), the number of up-chirps corresponds to the PreambleLength registers
  • two up-chirps with a chirp-phase corresponding to the contents of the SyncWord register
  • two down-chirps at the end of the preamble (sync-pattern)
  • data-chirps, these consist only of up-chirps (like the preamble), but with a jump in the "phase"/timing of the chirp. The frequency shift of this jump likely encodes one symbol representing several data bits (SF bits per symbol).

One symbol has a length in time of (2^SF)/BW. Chirps seem to have a constant chirp rate for a specific modulation setting, both when going up and down. When the frequency of a chirp reaches the end of the band, it "wraps around" to the other side. One chirp nominally covers the entire bandwidth BW once during one symbol time.

Investigation

Gqrx bw0 cr2 sf12.png

The image on the right shows the LoRa spectrogram for a short message as recorded by gqrx, when sending a 1-byte payload (with settings SF=12,BW=8,CR=4/8, implicit header). At the bottom of the spectrogram you can see the preamble consisting of 10 up-chirps and 2 down-chirps. At the top of the spectrogram you see the data portion of the signal, consisting solely of up-chirps.

Since the LoRa signal is basically a single carrier being swept over a certain bandwidth in a specific way, it is possible to recover the frequency by FM demodulation of the signal generated by a Semtech chip. This allows for a more compact representation of the signal for analysis.

The approach used on this page is to receive the LoRa signal with an inexpensive rtlsdr receiver, FM-demodulate it in SDR-application qgrx and record the resulting output in the audio application Audacity.

Some thoughts on analysis:

  • For simplicity, the output length of the forward error coding parameter CR can be chosen to be equal to the symbol size SF. This way each 4-bit input nibble should result in exactly one output symbol. For example use CR=4/6 with SF=6, CR=4/7 with SF=7, CR=4/8 with SF=8,
  • make the payload equal to the PRNG sequence, such that the whitening effect of the PRNG is cancelled out, possibly making analysis easier.
  • vary the payload with a walking-bit sequence, so the shuffling order of the interleaver can be analysed.

payload contents

Audacity bw0 cr4 sf8.png

The image on the right shows the audio captured in audacity from an FM-demodulated LoRa-signal (with settings BW=8kHz, CR=4/8, SF=8, implicit mode, 1-byte payload), with the single-byte changed from 0x00 (top) to 0xFF (bottom). In the highlighted area, some differences can be seen between the FM-waveforms.

preamble length

Some experimentation shows that when the preamble length n is set to 0 through the register interface, we still see 2 up-chirps and 2 down-chirps (plus 1/4th of a up-chirp) in the preamble on-air. This is consistent with the preamble timing formula in the datasheet, which states that the preamble is (n + 4.25) symbols long.

Actually the final two up-chirps in the preamble encode for the 'SyncWord'.

sync word

Lora syncword.png

Something that is not mentioned in the RFM95 datasheet, but is mentioned in the SX1276 datasheet, is the SyncWord setting in register 0x39. The datasheet mentions a default setting of 0x12 and a LoRaWAN setting of 0x34.

Modifying this setting results in the following changes to the FM waveform just before the reverse chirps. From top to bottom: 0x00, 0x12, 0x34, 0xFF. It seems the setting influences the "starting value" of the two chirps just before the reverse chirps. The starting value appears to be closely related to the low nibble of the sync word (with 0xF corresponding to half the symbol time).

This setting only has influence on the preamble/sync, there is no influence on the rest of the packet.

CRC

Lora crc.png

The datasheet suggests that CRC can be turned off and on through bit RxPayloadCrcOn (mistake in datasheet: Rx should be TX?) in register RegModemConfig2 (0x1E). The image on the right shows the effect of turning it off (top) and on (bottom).

Oddly enough, this doesn't seem to influence the length of the transmission.

Settings: BW=8,CR=4/8,SF=8, 1 byte payload (0x00).

Header

Lora header.png

A header can be specified. This header tells the receiving end about the length of the payload, presence of CRC and coding rate of the rest of the message. The header itself is encoded with a coding rate CR=4/8.

The image on the right shows the effect of turning it on (top) and off (bottom).

The difference in length is about 8.4 symbols.

Settings: BW=8,CR=4/8,SF=8, 1 byte payload (0x00).

Payload size

Lora payload.png

The image on the right shows the FM-demodulated signal with varying payload. A payload size of 1 (0x00) on top and a payload size of 2 (0x00 0x00) on the bottom.

Curiously, the size of the transmission is exactly the same.

LowDataRateOptimize bit

Lora lowdatarate.png
Lora lowdatarate4.png

Register 0x26, bit 3 contains a LowDataRateOptimize setting, which should have some influence on the number of payload symbols transmitted according to the datasheets.

The image on the right shows the effect of turning it off (top) and on (bottom) Settings: BW=8,CR=4/8,SF=8, 1 byte payload (0x00), implicit mode, no CRC.

The image below it shows the effect of turning it off (top) and on (bottom) with the same settings, except now a payload of 4 bytes 0x00.

So, I see no difference in over-the-air length with payloads of 1 and 4 bytes when this bit is modified.

Recordings

See here for some IQ recordings of the LoRa signal.

The filenames contain a code for the LoRa modulation setting which was used for each recording. This should mostly be obvious. For example, a postfix of BW21CR48SF6PL64x00 means the following:

  • BW21: Bandwidth is approximately 21 kHz (20.8 actually)
  • CR48: Code rate is 4/8
  • SF6: Spreading factor is 6
  • PL64x00: Payload is 64 bytes of 0x00

The files were recorded on ms windows using sdr# v1.0.0.1111 at a sample rate of 1024 kHz.

External links

Retrieved from ‘https://revspace.nl/wiki/index.php?title=DecodingLora&oldid=8026’