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.

The description of the PHY header is best found in the datasheets of the PHY devices, namely SX1276 and SX1272 RFICs from Semtech.

In explicit header mode, the header carries three values:

• the Coding Rate (CR) of the forthcoming payload
• the size of the forthcoming payload
• if the forthcoming payload is appended by a CRC-16 or not

You can find more detailed information on the LoRa header in sections 4.1.1.6 "LoRa Packet Structure" of theSX1272 and SX1276 datasheets.

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 best way is certainly to restore factory defaults by using the DFuse utility and the factory-default binary file, both provided with the LoRaMote Configuration Utility, along with an instruction set in the LoRaMote user guide.

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.

There is no definite answer to this question as it depends on four dimensions:

• RSSI/SNR of the received packets (simultaneous reception on the same channel)
• Time-on-Air of the packets (equivalent to data rate, the longer the packet, the longer one demodulator of the gateway is used)
• Frequency of the packets (two packets with the same data rate and the same RSSI/SNR will collide unless they are on two different frequencies).
• Number of times per day an end device will send a packet (taking resources another node could use)

ADR is well suited for static end-devices. ADR is not recommended for mobile end-devices as the propagation radio path might change too rapidly.

Recommended practices include the use of "Blind ADR". 

The network server and application server are software entities that control higher level aspects of a LoRaWAN application. The gateway and end device look after the physical layer connection, the network server looks after the protocol and the application server looks after the application level control and data. All are required.

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.

Typically all LoRaWAN makers use 4/5, but strictly speaking the coding rate is not enforced in the LoRaWAN specification. The choice is up to you.

One way of improving your packet success rate is to use the LoRaWAN "confirmed frames". When implemented, confirmed frames will make devices request an acknowledgement. It is however not recommended to widely use confirmed frames for sensor traffic, as typically the ratio of uplink versus downlink traffic should not exceed 1%.

For sensor data collection, it is advised to implement packet repetition and to send, in every packet, not only the last sensor data, but also the previous and the one before. This maximizes the amount of data you collect, without creating too much downlink traffic.

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.