No. ADR does not override the frequency channel but enable the use of the pre-configured channels through a channel mask. 

The maximum number of uplink channels is dependent on the PHY band in use. PHY bands like the European one handle a maximum of 16 channels. 3 default channels which can't be modified + 13 channels which can be created/deleted/enabled/disabled. PHY bands like the US915 handles a maximum of 72 channels. They exist all the time but can be enabled/disabled according to the local regulator rules. PHY bands like the CN470 handles a maximum of 96 channels. They exist all the time but can be enabled/disabled according to the local regulator rules. The channels are defined as described below. Channel frequency between 100 MHz and 1.67 GHz in 100 Hz steps. Data rate range (min. and max.)

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.

Capacity is, first and foremost, a consequence of the number of packets that can be received in a given time. A corecell SX1302 based design with 8 channels can receive approximately 1.5 million packets (50Byte) per day using LoRaWAN protocol.

So, if your application sends one packet per hour, then a single SX1302 gateway can handle about 62,500 end devices.

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.

LoRaWAN uses primarily the 125kHz BW setting, but other proprietary protocols can utilize other BW settings. Changing the BW, SF, and CR changes the link budget and time on air, which results in a battery lifetime versus range tradeoff.

Please refer to the online LoRa Calculator:  LoRa Modem Calculator

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).