LoRa (and the standardized embodiment LoRaWAN) and NB IoT are both LPWAN technologies. The 3GPP consortium drives the standardization of NB IoT, targeting operation in licensed spectrum whereas LoRaWAN is an open standard targeting unlicensed spectrum operation driven by the LoRa Alliance. As there are material differences between the technologies, the addressable markets and use cases are not  identical. Overall the vision of the LoRa Alliance is that both technologies are complementary and suitably empoloyed based on the specific properties of a given customer use case and/or application. You can download the public whitepaper which explores these trade-offs here.

Tx Power: this should be done with a power-meter or a spectrum analyzer (SA). If using the latter, make sure that the RBW (Resolution Band Width) is made large enough (typically 1MHz for a LoRa BW of 125kHz) to integrate the whole power during CSS modulation. Ensure that the transmitter is set to Tx Continuous mode for this test.

• Channel masks should be checked with a SA, according to the latest EN 300-220.
• Spurious emissions and harmonics should be checked as with any other RF transmitter, also in accordance with the European norm.
• Sensitivity measurement should be performed with a Packet Error Rate (PER) test, as opposed to Bit Error Rate (BER) test, because of the nature of the LoRa modem. At present, none of the instrumentation vendors supports LoRa modulation natively (unlike Wi-Fi or BT for instance). Therefore, we need to use an Arbitrary Waveform Generator (ARB) to perform this test. Semtech supports Rohde &Schwarz's (R&S) SMBV100A ARB, and can provide pre-calculated frame in .wv format in order to perform tests.

LoRa (short for long range) is a spread spectrum modulation technique derived from chirp spread spectrum (CSS) technology. Semtech’s LoRa is a long range, low power wireless platform that has become the de facto wireless platform of Internet of Things (IoT).
Beecham Research predicted in their 2023 report that LoRa will be the remain the leading LPWAN technology (34% share for 2027) with a CAGR of 17.6% (2021-2027).

LoRa is the most suitable technology for long range, high capacity systems on the fragmented battery operated wireless market for sensor networks, smart cities, smart metering, security systems, smart home, and industrial control.

With our LoRa RF platform, we have developed a 2-way wireless solution that complements M2M cellular or WiFi infrastructure, and provides a low-cost way to connect battery operated and mobile devices to either the network infrastructure or end point.344rfv 

To visit Semtech's LoRa website click here.

Yes, LoRa and LoRaWAN can support the IPv6 protocol and UDP with an adaptation layer called SCHC and standardized by the LoRa Alliance and the IETF. SCHC is a compression and fragmentation mechanism that was specified in 2020 and makes LoRaWAN capable to support internet-based applications such as DLMS protocol used in smart metering,  or CoAP for supporting protocol like LwM2M. Compared to 6LoWPAN that was designed in 2005 for enabling IP over 802.15.4 and for home automation application mainly , SCHC brings much better efficiency for constrained networks than 6LoWPAN does. Actility (a LoRa partner) and other partners are enabling applications using SCHC on top of LoRaWAN.

The LoRa modulation itself is a physical layer (PHY) that can be used in all network topologies. A mesh network topology acheives range extension at the cost of reduced network capacity, increased synchronization overhead and reduced battery life (due to synchronization overhead and hop traversal). The increased link budget and range capability off LoRa removes the  need for a mesh network architecture to extend the range for most applications, so a star topology was chosen for LoRaWAN to optimize the network capacity, battery lifetime and ease of deployment. Mesh networks based on LoRa can be pertinent for some use cases, such as linear infrastructure monitoring, but these topologies are not natively supported by the LoRaWAN specification.

The FIFO of most LoRa transceiver devices is 256 bytes deep in LoRa mode. In theory, all the 256Bytes can be used for TX or RX. However, with a low data-rate configuration, the time on air with a 256byte payload will be very long (several seconds or even longer), which is not good for resisting fading and high interference environments. This is not a robust configuration in most environments so it is suggested that if a long payload is desired with a low data-rate then the packet be split into a few shorter packets. 

The time on air calculation method is given in the datasheet for every LoRa part, however, we also offer the LoRa Calculator which can be accessed via the Semtech website which automates this process for you and has also been extensively tested - so avoiding many of the typical calculation pitfalls.

The RegPktRssiValue and RegRssiValue are both useful in LoRa mode. RegPktRssiValue refers to the packet RSSI level, and the RegRssiValue is similar to the RSSI that can be found in (non LoRa) FSK mode. As you know, LoRa can demodulate the packet below the noise floor (PktRssi result) then CurrentRssi will then be equal to or more than the noise floor.

For more details about how to calculate these two RSSI Values, please refer to the Semtech API or latest LoRa datasheets.  

When you start your design, check the DIO Mapping in both the LoRa mode and FSK mode. You can find the DIO Mapping information in all Semtech LoRa® product datasheets. The DIOs do not function as normal (typical) MCU GPIOs. There are some special interrupt signals (or clock outputs) to indicate the event or status of the chipset, which can make your firmware design easier to implement. In theory no DIO connections are required and status can be determined via polling registers . We suggest that DIOs be connected for external interrupt functionality which saves on the resource loading of the MCU and facilitates low-power operation as the MCU can sleep while the transceiver is perofming specific Rx or Tx operations.  Please consult the relevant Application Notes for your intended use-case to ensure appropriate DIO connectivity (see https://semtech.my.salesforce.com/sfc/p/#E0000000JelG/a/3n000000qSrD/TTy2.JY2wDC_DmYJIGdb4mJ8j.66wodDoZwTcoieTUc).

No, the maximum packet length is 256 bytes in LoRa mode

In LoRa mode, even if the CRC is wrong the payload will be filled into the FIFO. Bit PayloadCrcError must be checked before fetching the payload to know its integrity. In Explicit Header mode, there is a small probability that a false detection creates a "ghost" packet. Either the false header has CrcOn bit turned on, and then the payload will be wrong, and the modem will flag it as a PayloadCrcError condition, so packet can easily be filtered out. Or the false header has CrcOn disabled, in which case the mode will consider the packet as a good one. These infrequent bad packet will have a random length (extracted from the false header info), and can be easily filtered by the host, for instance by seeing that their size is unexpected.

First of all, check the frequency offset caused by the crystal between the two devices. The BW, center frequency, and data rate are all derived from the crystal frequency.

Second, check the software/firmware settings on both sides for frequency, bandwidth, spreading factor, coding rate and packet structure to ensure they are the same. Employ a "divide and conquer" technique: focus on detecting a preamble, then sync word (if applicable) and once successful, progress to reception of an entire packet.

If it is just for measurement, you can use the Frequency synthesis TX (FSTX) mode as listed in the LoRa register table to generate a CW tone based on the LoRa configuration.

Normally, a +/-10ppm XTAL is good enough for most designs with a bandwidth of 62.5kHz or higher. For bandwidth (BW) less than 62.5kHz, a TCXO is strongly suggested. For more details please refer to AN1200.59 Application note for selecting the optimal clock

The following article provides guidelines and suggestions to test a LoRa system:  Expert Series: Testing Devices Featuring LoRa® [How To] 

1. Please make sure that you connect the right pin (PA_Boost) set for 20dBm output. There are two output ports for each band. One is high power port called PA_boost, another is high efficiency port called RFO.
2. Then, check the configuration in SW. Three registers should be configured correctly: RegPaConfig, RegOcp and RegPaDac. This means that you should select the right pin for proper output in SW, then set the right value refer to power level you need.
3.  Confirm they match per the Semtech reference design to make a good layout. This is important to achieve the maximum output power possible.

Yes, it is no problem. The LoRa device can be switched from FSK to LoRa (and vice versa) via simple SPI opcodes. This has no effect on the performance or reliability of the device. A LoRa device can be configured and reconfigured to any of the parameters as specified in the corresponding datasheets and or user manuals (if applicable). 

The +20dBm specification is for the output power at the pin of the chip. The band-pass filter and RF switch have insertion loss characteristics as in any RF system. Achieving +19dBm at the antenna is typical performance after matching and filtering.  

Instead of using a Received Signal Strength Indicator (RSSI) method to identify if a signal is present, the CAD is used to detect the presence of a LoRa signal by correlating on the signal properties. It has the capability to differentiate between noise and a desired LoRa signal. The CAD process requires two symbols, and if the CAD is detected, the CAD_Detected interrupt will be asserted and the device will stay in RX mode to receive the data payload. See Application Note AN1200.48 for details on the implementation of CAD for the SX1261/62 family of products.

The output power that can be achieved depends upon the programmed output power and what components are in the Tx signal path. We ordinarilly specify our output power at the IC output, this means that subsequent filtering and switching may impart additional RF losses. For a typical design implementation featuring an RF switch and harmonic filtering - we expect that you should be able to achieve the programmed output power minus apprximately 0.5 dB at the RF connector.