There are no recommended settings for the FLRC modem, except that higher data rate (throughput) comes at the expense of reduced sensitivity. This is true of all modulation formats, more information on FLRC can be found in the SX1280 Datasheet.
All possible settings described in the SX1280 datasheet are acceptable configurations of the LoRa modem. However, depending upon the requirements of your application, it is certainly possible to configure the modem to one of several setting that will optimize performance.Longest Range Setting: This configuration is achieved by using the lowest bandwidth and highest spreading factor. Note that the increased sensitivity is achieved at the expense of a lower bitrate, so longer time on air.Highest Accuracy Ranging Setting: The highest accuracy ranging setting is achieved by setting the highest bandwidth and the highest spreading factor (1.6 MHz SF 10 in the case of ranging which does not operate at Spreading Factors above this).Lowest Energy / Highest Data Rate Setting: The lowest energy setting of the SX1280 LoRa modem, is to set the SF as low as possible and the bandwidth as high as possible. Note that this increased communication speed, comes at the expense of reduced sensitivity so lower range.
The immunity of the SX1280 LoRa modem varies as a function spreading factor, bandwidth, the type of Wi-Fi interference and the frequency offset between the interferer and the wanted LoRa signal.For some OFDM types of Wi-Fi and with low bandwidth, low spreading factor we can get in excess of 60 dB co-channel immunity. The best mechanism to avoid WiFi interference, in general however, will be to avoid the interference by using unoccupied portions of the band. The image below shows our immunity at SF12 200 kHz as a function of frequency, here we see that on the same channel (0 Hz offset) we still have good immunity (45 dB) as we move further away in frequency (the ISM band is 80 MHz wide) we can get in excess of 100 dB of immunity. There is a little up-tick in the immunity at 0 Hz offset. The reason for this is shown in the second figure. Here the blue trace is the measured WiFi signal spectrum. You can also see here the actual measurement points (red dots). The precise immunity will depend upon the exact power level (here in 200 kHz) of the (blue) WiFi signal. More comprehensive coverage of this topic can be found in our WiFi immunity application note.
To avoid re-work and modification of the component values on the RF output of SX1280 it is necessary to follow the reference design as closely as possible. The harmonic filter of SX1280 (magenta) and impedance match (cyan) in particular need to be replicated identically. Where possible the same family of components as specified in the BOM should also be used. It is possible, in some applications, that VCO leakage in receive mode can be seen. An effective remedy for this is to take the initial precaution of adding series resistances R7 to R10 to the digital lines. Moreover, a 4-layer design allows the DC-DC converter traces to be buried on internal PCB layer 3 (see below) between ground planes on layers 2 and 4.
The simplest technique to calculate the time on air for Master and Slave ranging exchanges is to consult the SX1280 calculator tool (available for download from the Tools and SW area). Under the LoRa tab, simply select the modem SF and bandwidth you intend using. The calculator will then show the LoRa symbol time as illustrated below:
The SX1280 development kit features a pair of antennas. The antennas are used to provide switched diversity to overcome fading, i.e. destructive interference of the wanted RF signal. The triangular patches are used to increase the bandwidth of the antenna and render it more immune to detuning by proximate objects such as a user's hand.
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.
No, LoRa devices can be used like any other RF transceiver in existing applications with custom proprietary protocols. However, using LoRaWAN will significantly improve time to market. The stack, having similarities to 802.15.4, is FCC and ETSI compliant and offers all the security needed by a modern RF protocols (network key, unique Id for each end point, AES128 encryption... ). LoRaWAN also offers the possibility to be used in private AND public networks.
There are changes required at the host interface and specifications for transmitting data in a LoRa system that require changes to the host system software, but with fully integrated modems available in the eco-system, and their well-defined host controller interface, it is actually quite seamless.
The "JoinAccept" message is decrypted by the Application Server (AS) and not the Network Server (NS).
The AS is allowed to see the end-device application data but the NS is not.
The AS exchanges key information with the end-device through the NS (the NS forwards the messages but doesn't understand them).
At the end of the exchange, when the session keys have been calculated, the AS gives the network session key to the NS.
In Europe LBT+AFA ( Listen-Before-Talk + Adaptive-Frequency-Agility ) is not desired or implemented, however in certain regions LBT is mandated.
The Corecell reference design now implements LBT, specifically to be in compliance with regulations in Korea and Japan.
LoRaWAN data rates range for LoRa between 0.3 kbps to 11 kbps, and one GFSK data rate at 50 kbps for Europe. In North America, the minimum data rate is 0.9 kpbs due to FCC rules. To maximize both battery life of the end-devices and overall network capacity, the LoRaWAN network server is managing the data rate and RF output power for each end-device individually by means of an adaptive data rate (ADR) algorithm. The ADR is critical for a high performance network and it enables scalability. A network can be deployed with a minimal investment in infrastructure, and as capacity is needed, more gateways can be deployed and the ADR will shift the data rates higher which will scale the network capacity.
No, LoRaWAN as a protocol is strictly for wide area networks, but LoRa as a lower-level physical layer technology (PHY) can be used in all sorts of applications outside of wide area.
LoRaWAN certification ensures interoperability and compliance with LoRaWAN networks and will be requested by LoRaWAN network carriers. It also entitles the use of the LoRa Alliance Certified logo.
Today, the LoRa Alliance certifies LoRaWAN end-nodes that are compliant with LoRaWAN standard. The LoRa Alliance is aggressively working to bring additional, value-added certification programs to its members. Providing Certification of LoRaWAN features above Layer 2 are regularly being deployed. Features like SCHC and FUOTA are already available.
More information on the LoRa Alliance website: https://lora-alliance.org/lorawan-certification/
The 64 bit Extended Unique Identifier (EUI) is comprised of two parts, the 24 bit Organisationally Unique Identifier (OUI) and a 40 bit serial number. The OUI is allocated by the IEEE, and the serial number by anyone that owns an OUI, together they form the EUI. AppEUI and DevEUI are both special cases of EUI.
FPort values 1..223 are application specific with their meaning being defined by the application provider. The LoRa Alliance has not specified an assignment for any port in this range to a particular application.
The network server will pass the FCnt (specifically the FCntUp) to the application layer as part of the MACPayload Frame header (FHDR) as specified in 4.3.1 of 1.0.3 of the LoRaWAN Specification. The Application Session Key (AppSKey) along with the FCntUp and DevAddr are used in the decryption of the payload data (FRMPayload) as described in 4.3.3 of the LoRaWAN Specification.
This is possible, but there would be a need to convert an existing 802.15.4 or other mesh protocol to use the modulation format. Because of some of LoRa's features such as longer transmission time which increases link budget and the availability of a relay specification, LoRaWAN is usually the best choice.