SX126x with address filtering always reports wrong CRC

[jgromes]

Describe the bug
After node or broadcast address filtering on SX126x is enabled, the CRC error IRQ flag will always be set (even if CRC is disabled). This leads to RadioLib always reporting CRC error. The data retrieved also seems to be garbage.

From what I can tell, the CRC should be calculated correctly, at least when transmitting. With address enabled (and set to 0x36, char '6' to easily see it in text prints), I was able to verify that the CRC calculated does match 16-bit CCITT CRC with inversion of the result (radio.setCRC(2, 0x1D0F, 0x1021, true)). Online calculator shows for the input 0x11 0x36 0x48 0x65 0x6c 0x6c 0x6f 0x20 0x57 0x6f 0x72 0x6c 0x64 0x21 0x20 0x23 0x31 0x31 the result 0xC03E, which matches with SDR:

So it should be the case that CRC is calculated over the payload length, address and payload itself, as shown in the datasheet. However, for some reason, this breaks on receiving.

Google search does not return much info, it seems like the node/broadcast adress filtering was never used much on SX126x. Errata doesn't show anything in this regard.

Workaround
Workaround is to not use the built-in node or broadcast filtering on SX126x. Instead, this can be implemented by the user, as data transmitted from other FSK modules with node address (e.g. SX127x) is received correctly. The address byte will be the first byte read from FIFO. With this workaround, CRC checks pass (transmitted from SX127x with target node set to 0x36):

Data[20]: 6Hello World! #20
Packet RSSI: -50.00 dBm
Inst. RSSI:  -109.00 dBm
LoRa SNR:    -20.00 dB

To Reproduce

// add to FSK transmit example after begin
radio.setNodeAddress('6');
radio.setBroadcastAddress('7'); // broadcast address also breaks CRC
radio.setCRC(0); // disabling CRC does not seem to help

Expected behavior
Enabling address filtering shall not break CRC functionality.

Additional info

• MCU: RPi 3B+
• Wireless module type: SX126x (Waveshare LoRaWAN hat)
• Library version 7.0.2

[jgromes]

While debugging this, I also fixed two other problems with SX127x and SX126x FSK addresses, however, neither is the root cause of this issue.

[ClaudiusVi]

I've noticed similar issues and would like to share my experience. About three months ago, I first observed problems with Vollgo SX1262 modules. I then replaced some of them with G-NiceRF LoRa modules, and everything worked fine. In a delivery six weeks ago, G-NiceRF modules were included on the boards, and again, there were no issues.

However, with the most recent batch, which also included G-NiceRF modules, I suddenly encountered the problem that no reception occurs at all. Right now, I have no idea what the cause could be. I've re-checked the old Rev9 and Rev8 boards without finding any clear reason for this. It seems like there's some inexplicable mechanism causing the issue, and currently, I'm completely in the dark regarding this random failure. There are over 30 boards lying around, and none of them are receiving anymore.

I'm using an ESP32-S3 WROOM without PSRAM.

Not sure if this helps, but I'd appreciate any hints that could lead me in the right direction.

[jgromes]

@ClaudiusVi are you sure this is the same problem? The original issue only appears in FSK mode with address filtering, did you also use that? What you're describing seems more like a hardware/manufacturing issue to me.

[ClaudiusVi]

Hi, Today, I found some older boards, an earlier release, as well as a Heltec LoRa board. However, I didn't use the Heltec library but rather the Arduino library, which we used as a monitor. Both our board and the monitor successfully received the encrypted JSON file, and the data was displayed correctly. After that, I used an older library ( the last one before 7.00) and uploaded the programs to other boards – and it worked again. However, it was a bit tricky since two boards with G-NiceRF chips showed an FSK transmit error 2. Based on this clue, I was able to identify the issue, and I've since tested 12 different boards for transmission and reception without errors. As mentioned before, there seems to be an issue with the Vollgo SX1262 module, likely due to the module quality. I'm using FSK mode with an 8-byte sync word and receiving data via interrupt. I suspect this issue could also be related. Tomorrow, I plan to test RadioLib versions 7.01 and 7.02. There seems to be an error in release 7.10, possibly related to CRC or something else, but since we don't have a LoRa signal logger, we can't determine this precisely. One important note is to always turn off the Serial Monitor in the Arduino IDE when changing libraries. At the moment, we haven't switched to VS Code (Visual Studio) yet, which we plan to use for programming the main controller. Our configuration is as follows: // ESP32 - SX126x Pin Configuration // https://docs.espressif.com/projects/esp-idf/en/release-v5.3/esp32s3/api-reference/peripherals/spi_master.html // SPI Pin Assignments for ESP32 S3 (IO_MUX): // // Pin Name GPIO Number (SPI2) // ------------------------------ #define LoRa_CS_GPIO10 10 // 10¹ LoRa Chip Select (CS0/NSS) #define LORA_DIO1_GPIO15 15 // LoRa DIO1 Interrupt #define LoRa_MISO_GPIO13 13 // 13¹ LoRa MISO (Master In Slave Out) #define LoRa_MOSI_GPIO11 11 // 11¹ LoRa MOSI (Master Out Slave In) #define LoRa_RST_GPIO14 14 // LoRa Reset #define LoRa_SCK_GPIO12 12 // 12¹ LoRa Serial Clock (SCK) #define LoRa_DIO_2_BUSY_GPIO16 16 // LoRa DIO2/Busy Pin #define LORA_DIO3_RXE_GPIO17 17 // LoRa DIO3/RXE // Notes: // ¹ These GPIO numbers are for the default SPI assignment of the ESP32 S3. // FSK Mode Variables float fskFrequency = 868.0; float fskBitRate = 4.8; float fskFrequencyDeviation = 5.0; float fskRxBandwidth = 156.2; int fskOutputPower = 10; int fskPreambleLength = 16; float fskTcxoVoltage = 3.3; bool fskUseRegulatorLDO = false; float fskCurrentLimit = 60.0; uint8_t fskSyncWord[] = { 0x02, 0x23, 0x45, 0x67, 0x89, 0xAB, 0xCD, 0xEF }; // Different in EEPROM depending on the region, identical for sending and receiving Von: Jan Gromeš ***@***.***> Gesendet: Donnerstag, 7. November 2024 21:38 An: jgromes/RadioLib ***@***.***> Cc: Claudius Viviani Privat ***@***.***>; Mention ***@***.***> Betreff: Re: [jgromes/RadioLib] SX126x with address filtering always reports wrong CRC (Issue #1268) @ClaudiusVi<https://github.com/ClaudiusVi> are you sure this is the same problem? The original issue only appears in FSK mode with address filtering, did you also use that? What you're describing seems more like a hardware/manufacturing issue to me. — Reply to this email directly, view it on GitHub<#1268 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/APH6OZGYISAV6ZQTRHLA73LZ7PFRDAVCNFSM6AAAAABP2M6LJ6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDINRTGE3DKNZRGU>. You are receiving this because you were mentioned.Message ID: ***@***.******@***.***>>

[ClaudiusVi]

Hi @jgromes,

We checked today and found that the issue only occurs with version 7.10. The problem is not present in version 7.02.

During development, we switched from the SX1276 to the SX1262 because the SX1262 is newer and offers more features. After comparing the datasheets, this seemed like a better choice, especially because the SX1276 caused major issues on the Raspberry Pi 5. The I/O chip on the Raspberry Pi 5 runs over PCI, which led to problems, so we switched to the SX1262.

We checked the registers and found the following: Both chips offer the capability to configure an 8-byte sync word, but the specific register addresses differ. Here is a table of the registers for the 8-byte sync word on the SX1262 and SX1276:

Byte SX1262 Register Address SX1276 Register Address
Byte 1 0x06C0 0x28
Byte 2 0x06C1 0x29
Byte 3 0x06C2 0x2A
Byte 4 0x06C3 0x2B
Byte 5 0x06C4 0x2C
Byte 6 0x06C5 0x2D
Byte 7 0x06C6 0x2E
Byte 8 0x06C7 0x2F

It seems that there is a small bug somewhere in the code of version 7.10 that is causing this issue. Hopefully, this information helps to locate the bug.

[ClaudiusVi]

P.S.: We tested the modules with different SPI controllers: SPI, SPI2 (commonly referred to as HSPI), and SPI3 (commonly referred to as VSPI). The default controller used in our program is SPI2 (HSPI), but we also tried using SPI directly.

[jgromes]

@ClaudiusVi I think you are describing a different issue. The original problem has no relation to sync word; only to address filtering and CRC being enabled. Please open a new issue for this, including all the information in the issue template.

I would also like to point out that the SPI interface of SX127x and SX126x series is completely different; most SX126x commands are not sent via SPI registers.