Knowledge Base

Frequently Asked Questions


SX1257 can not demodulate LoRa or FSK modulations. It just downconverts a 2 MHz spectrum in the 800 MHz frequency band in raw I and Q signals.

The 4 channels of SX1257 can be freely configured to the same, overlapping or adjacent frequencies.

Using two SX1257 at the same frequency will not improve the reception sensitivity or capacity if both SX1257 share the same antenna. You can use two 180-degree directional antennas oriented one to the north and the other to the south improving sensitivity, or better two omnidirectional antennas separated 1 meter with each other for diversity, mitigating the multipath.

Two signals on the same frequency and the same SF will interfere with each other. If one signal is, for example, 30 dB higher than the other, you will receive only the strongest one.

Two signals on the same frequency and different SF will interfere with each other, but as SF are orthogonal to each other, if one signal is, for example, 12 dB higher than the other, you will receive both signals. If not, you will receive only the strongest one.

There are different types of modules available in the partner eco-system:

  • The first type of module is the simple transceiver module such as manufactured by HopeRF. In this type of module you have an SPI interface to the transceiver, through which you access the registers. All the commands needed to configure the transceiver are in your host controller.
  •  A more advanced type is the full-blown module, such as the Murata type ABZ module, Atim module or Telit module.These modules include a host controller and can be used for single controller applications. They are typically accessed via a UART interface.
  • The last type of module is the modem type, where the LoRaWAN stack is already implemented. Access is done through an AT-type command over a serial UART interface. Companies such as Microchip and USI offer these modems.

Take some time to take a look at the LoRa products and services catalog in the resources area for a full range of modules.

As far as drivers and settings go, you must set the Frf register to the frequency of your liking. This can be achieved with the PC GUI provided.

However, the issue here will be frequency selectivity. Because there is no known ISM band at 140 MHz to our knowledge, there is no such reference design readily available. The RF1IAS and DVK1IAS kits will do a correct job, as they are tuned at 169 MHz and have no high-Q RF roofing filter.

The SX1301 digital baseband chip contains ten programmable reception paths. It is important to understand the differences between those ten demodulation paths (IF0 through IF9) to make the best possible use of the system. 

IF0 to IF7 LoRa channels

These channels are LoRa only. The channel bandwidth of IF0 to IF7 is 125 kHz and cannot be modified or configured. Each channel IF (intermediate frequency) can be individually configured. On each of those channels any data rate from SF7 to SF12 can be received without prior configuration. Several packets using different data rates may be demodulated simultaneously on the same channel.  The SX1301 can simultaneously detect preambles corresponding to all six data rates (corresponding to SF7 to SF12) on all eight channels (IF0 to IF7)=> Up to 48 (= 6 x 8) combinations of channels/spreading factor can be detected at all times.

However, the SX1301 cannot demodulate more than eight packets simultaneously. The SX1301 architecture separates the preamble detection and acquisition task from the demodulation process.

Let’s clarify with an example:

  • an SF7 packet is demodulated on IF0,
  • an SF7 packet is demodulated on IF1,
  • an SF7 packet is demodulated on IF2,
  • an SF7 packet is demodulated on IF3,
  • an SF7 packet is demodulated on IF4,
  • an SF7 packet is demodulated on IF5,
  • an SF7 packet is demodulated on IF6,
  • an SF7 packet is demodulated on IF7,

If a ninth packet is detected (e.g. an SF8 packet on IF0) then it won’t be demodulated as all eight demodulators are currently busy. 

For demodulation, any combination of up to eight packets is possible (e.g. one SF7 packet on IF0, one SF12 packet on IF7 and one SF9 packet on IF1 simultaneously). The eight demodulators are independent and are not linked to the IF channel. Let's look at another example to clarify:

  • an SF7 packet is demodulated on IF0,
  • an SF8 packet is demodulated on IF0,
  • an SF9 packet is demodulated on IF0,
  • an SF10 packet is demodulated on IF0,
  • an SF7 packet is demodulated on IF1,
  • an SF8 packet is demodulated on IF1,
  • an SF9 packet is demodulated on IF1,
  • an SF10 packet is demodulated on IF1,

=> In the example above , the eight packets will be correctly demodulated simultaneously if the minimum required SNR per SF is respected and the following constraint on IF0 and IF1 channels is met:

  •  either IF0 and IF1 use a different radio interface
  •  or, if IF0 and IF1 use the same radio interface, then the difference between IF1 frequency and IF0 frequency must be lesser than 2.6 MHz.

To be more precise: [(IF1+125kHz/2) - (IF0-125kHz/2)] < 2.6MHz, assuming IF1 > IF0

IF8 LoRa channel

This channel is LoRa only. The demodulation bandwidth can be configured to be 125, 250 or 500 kHz. The data rate can be configured to any of the LoRa available data rates (SF7 to SF12) but, as opposed to IF0 to 7, only the configured data rate will be demodulated.   

IF9 (G)FSK channel

This channel is connected to a GFSK demodulator. The channel bandwidth and bitrate can be adjusted. The demodulator characteristics are essentially the same as the GFSK demodulator implemented on the SX1232 and SX1272 Semtech chips. This demodulation path can demodulate any legacy FSK or GFSK formatted signal.

No specific study has been run by Semtech on the performance of LoRa in rain. However, there is literature documenting the impact of rain on 1G and 2G cellular systems, which essentially use the same UHF frequencies. Therefore, the impact of rain on the performance of LoRa can be considered low.

The tradeoff is quite complex, but in principle the sensitivity of the PA output is inversely proportional to the load-impedance required to obtain the output power.

  •  On PA_BOOST, regulated PA, we're getting 17 dBm with only about 1.65 V of DC bias, in order to maintain it from 1.8 to 3.7 V. This calls for a fairly low load impedance (P=V^2/Z).
  • On RFO, we are targetting much lower power, 14 dBm, with direct attach to VBAT, nominally 3.3 V. Therefore, the load impedance is much lower.

You can grasp that a mismatch at the antenna will have less impact on RFO than it does on PA_BOOST (less impedance transformation). The OCP block is here to limit the current drain, protecting your power supply or battery in case of severe mismatch conditions.

The RSSI (Receive Signal Strength Indication) value corresponds to the estimation of the received input power signal at the antenna seen by the gateway. There is no block at the antenna to perform this estimation, but a baseband RSSI “sx1301_rssi“ is estimated inside the SX1301 chip. Then the RSSI (at the antenna) is calculated by subtracting the gain of the Rx chain “Rx_gain” to the baseband_rssi:

sx1301_rssi = Input_level_antenna (=RSSI) + Rx_gain

This implies that RSSI =  sx1301_rssi – Rx_Gain.

The RSSI value is read from the SX1301's packet buffer and is then summed with the rssi_offset:RSSI = sx1301_rssi + rssi_offset => so rssi_offset = -Rx_gain

The accuracy of the RSSI value depends of two factors: 

  1. The estimation error of the signal envelope power done by the SX1301 
  2. The estimation error of the Rx gain

The Rx gain includes analog gain (from antenna to ADC block) as well as digital gain. The analog gain, by nature, can change from one gateway to another one. “rssi_offset” can then be used to calibrate/compensate any Rx gain variation.

The RSSI parameter can be used for following features: 

  • Rx AGC (managed by the gateway itself) 
  • ADR (Adaptive Data Rate)
  • Downlink message (to choose the best path/GW when corresponding uplink message has been received by several gateways)

Path loss in the sub-GHz spectrum is now well studied and documented, thanks to analysis done by the cellular industry over the last few decades.

Both line-of-sight and urban-type models are available, such as the Friis formula for line-of-sight, and COTS-231 for urban environments.

Path loss estimations are compared to the link budget of the LoRa technology, which can be estimated by summing the effective radiated power of the transmitted (typically 14 dBm in Europe and Asia), and the sensitivity of the received (down to -137 dBm).

Depending on the network server used, the antenna gain offset calculation is done in the server or in the gateway. In recent versions of the packet forwarder, there is an entry in the"global_conf.json” file that looks like this: “antenna_gain”: 0, /* antenna gain, in dBi */ 

This ”antenna_gain” can be used to compensate the gateway Tx Ouput Power “rf_power” by the gateway itself, not by the network server. Indeed, the “rf_power” field for each entry of the Tx LUT, defined in the “global_conf.json” too, corresponds usually to the conducted Tx Output Power, not the radiated one.

For instance, the “rf_power” along with its gain fields (“pa_gain”,“mix_gain” and"dig_gain”) can come from a generic/conducted (i.e. without any antenna) calibration performed at production time. So, afterwards, you can define the ”antenna_gain” in the"global_conf.json” configuration file to take into account any gain of the antenna mounted on the gateway in the field.

In the packet_forwarder program of the gateway, the “antenna_gain” field is subtracted from the “rf_power” field for all Tx LUT entries as follow: final_rf_power = rf_power - antenna_gain.“antenna_gain” must be a signed 8-bit integer, from -128 to +127.

The frame counter within LoRa is never reset to 0 on the network server and end-device side, as this would indicate a fault condition and would be considered as a security issue. In a word, for all devices the frame counter should keep going up.

The sensitivity of the LoRa Technology does not depend on the environment in which it is installed. However the propagation will be much worse underground, due to penetration loss. As a first guess, you could estimate 20 to 30 dB of penetration loss for underground systems.

The maximum bitrate in LoRa is with SF7/bandwdith 500 kHZ and we will be at around 21 kbit/s while HD1080p video bitrate is around 5 Mbit/s in a wire without any handling of packet loss. The LoRaWAN protocol is unfortunately not made for this kind of application.

Let's get the maths going:

One picture with 640 x 480 pixels and 8 bit color code (which is not great) would give you three bytes per pixel (R,G,B color code). This would lead to 921.6 kB of raw data to transmit without any overhead (preamble, header, frame counter,etc). This is a huge amount of data, even at 50 kbit/s, and would take several minutes to send between two devices.

The usually accepted simplification consists of taking into account the Signal to Noise Ratio (SNR) and combining it with RSSI.

  • if SNR > 0: packet power = RSSI
  • if SNR < 0: packet power = RSSI + SNR

RSSI and SNR expressed in dBm and dB respectively.

No, it may marginally pick up, but in principle the bandwidth and spreading factor must be coherent for the Channel Activity Detection (CAD) to work.

The following data shows the impedance of the two antennas on the SX1280 development kit, with the impedance matching. Here we see in excess of 16 dB of return loss which is good for a portable antenna.

The figure below shows a representation of the antenna system diversity performance, based upon the measured antenna S Parameters. (Based upon the method of Blanch et al). Here the red threshold indicates poor diversity performance, black acceptable diversity performance and green good, i.e. useful, antenna diversity performance. 

The final plots show the simulated radiation patterns of the two diversity antennas. The pattern corresponding to the highlighted antenna (with the pattern in the same orientation as the board image).  

Semtech provides full API documentation on the core elements of the solution such as the decryption and the solver. This makes it simple to provide the fully integrated scalable solution.

Final validation of a product will often require certified approval from an international or regional regulation office (typically ETSI, FCC or ARIB depending on the region).

One of the tests required is the Continuous Wave radio test (also called Tx-Cw) which is described in another article.

Another test requires setting the radio in continuous modulated signal to measure the spectral occupation taken by the radio signal when transmitting packets. To this aim, it is often required for the radio to transmit pseudo-random binary PN9 or PN15 payloads. There is no easy way to perform this test and the only solution is to create the payloads on the companion MCU and then send the packets one by one, with a different PNx sequence generated from the MCU. Here, care must be taken in the time between packets which will have an influence on the spurious emissions generated by the PA ramp-up and down in quick succession.

Source code lists are available to licensees. Other items made available are test routines, procedures and scripts for hardware and software. Test results are provided within the test reports provided to the licensee.

There is not a lot of field data available on different types of antenna yet. All field trials to-date have been conducted with 5dBi omni-directional antennas. Trials have been executed with the two diversity antennas placed in different polarizations and it was found that two vertical antennae spaced at one meter horizontally were significantly better than placing one horizontally and one vertically. No data is available on using sectored antenna with LoRa location at this time.