This package proposes an implementation in C of the driver for LR11XX radio component.
The driver is split in several components:
This component is used to update the firmware.
This component is used to read / write data from registers or internal memory.
This component is used to interact with system-wide parameters like clock sources, integrated RF switches, etc.
This component is used to send / receive data through the different modems (LoRa and GFSK) or perform a LoRa CAD (Channel Activity Detection). Parameters like power amplifier selection, output power and fallback modes are also accessible through this component.
This also exposes features for Sigfox. Bluetooth®-Low-Energy-Beaconing-Compatibility is also provided in this component for LR1110/LR1120.
This component provides LR-FHSS related functions.
This component is used to configure and initiate the passive scanning of the Wi-Fi signals that can be shared to request a geolocation.
This component is used to configure and initiate the acquisition of GNSS signals that can be shared to request a geolocation.
This component is used to set and derive keys in the internal keychain and perform cryptographic operations with the integrated hardware accelerator.
This component is used to configure and operate the device's LoRa Round-Trip Time of Flight (RTToF) feature.
Each component is based on different files:
The HAL (Hardware Abstraction Layer) is a collection of functions that the user shall implement to write platform-dependent calls to the host. The list of functions is the following:
When the chip wakes up from sleep mode with retention, a parameter is not reconfigured properly. This misconfiguration can lead to an unexpectedly high adjacent channel power in all subsequent transmissions.
The issue appears only in LoRa modulation, for all bandwidths except for 500kHz and 800kHz.
The following firmware versions are affected:
The workaround is to reset the bit 30 in the register 0x00F30054 when the chip wakes up from sleep mode with retention.
This workaround does not solve the case where LR11XX_RADIO_MODE_SLEEP is configured with lr11xx_radio_auto_tx_rx and the chip is set to Rx mode. This is dues to the fact that the workaround cannot be applied before the subsequent transmission, automatically launched by the chip after waking up from sleep mode with retention.
The first implementation - enabled by default in the driver - adds an implicit call updating the parameter to each function that could set the chip in transmission - directly or not -:
lr11xx_radio_set_tx_with_timeout_in_rtc_steplr11xx_radio_set_tx_infinite_preamblelr11xx_radio_set_rx_with_timeout_in_rtc_step - in case lr11xx_radio_auto_tx_rx has been enabledlr11xx_radio_set_cad - in case LR11XX_RADIO_CAD_EXIT_MODE_TX has been set with lr11xx_radio_set_cad_paramsThis implementation can be disabled by defining the macro LR11XX_DISABLE_HIGH_ACP_WORKAROUND. This disabling will be useful when, in the future, a new firmware integrating a fix is released and does not require the workaround anymore.
The main advantage of this implementation is that it is transparent to the user who only needs to update the driver without changing its application. The main drawback is that the implicit call is done systematically even when not required.
The second method requires the user to explicitly call the function lr11xx_radio_apply_high_acp_workaround when the chip wakes up from sleep mode with retention (note: to ease the implementation, it can be called when the chip wakes up from any sleep mode).
This method requires the macro LR11XX_DISABLE_HIGH_ACP_WORKAROUND to be defined so the implementation 1 of the workaround (enabled by default) is disabled.
The following firmware versions are affected:
When the chip ends a reception in the 2.4 GHz band, a parameter is not reconfigured properly. This misconfiguration will prevent a subsequent GNSS scan from working properly.
It is important to note that if the chip enters one of the following state between the reception in the 2.4GHz band and the GNSS scan, the parameter is properly reconfigured and the limitation does not appear:
The workaround is to set the bit 4 in the register 0x00F30024 when the chip ends a reception in the 2.4GHz band before launching a GNSS scan.
This workaround is not needed when using any LR1110 firmware version. Nevertheless, it does not prevent a LR1110 from working properly if the workaround is not deactivated.
The first implementation - enabled by default in the driver - adds an implicit call updating the parameter to each function that could set the chip in GNSS scan mode:
lr11xx_gnss_scanThis implementation can be disabled by defining the macro LR11XX_DISABLE_MIXER_CFG_WORKAROUND. This disabling will be useful when, in the future, a new firmware integrating a fix is released and does not require the workaround anymore.
The main advantage of this implementation is that it is transparent to the user who only needs to update the driver without changing its application. The main drawback is that the implicit call is done systematically even when not required.
The second method requires the user to explicitly call the function lr11xx_gnss_apply_mixer_cfg_workaround when the chip ends a reception in the 2.4GHz if a GNSS scan is planned after, without going through one of the states specified in the description of this limitation.
This method requires the macro LR11XX_DISABLE_MIXER_CFG_WORKAROUND to be defined so the implementation 1 of the workaround (enabled by default) is disabled.