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.

[tonbor]

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.

Got the same problem. No result with Heltec sx1262 with library 7.1 but no problem with 7.02 and older see: matthias-bs/BresserWeatherSensorReceiver#203

[ClaudiusVi]

We have observed the CRC error issue in version 7.1.0 of RadioLib, but decided not to pursue it further for now, as we are using version 7.0.2 until it is resolved. The following potential causes were identified in the source code:

1. In the new version, a change was made to the setFrequency() method. In version 7.0.2, this function called setFrequency(freq, true), while the current version implements a modified frequency management. This change could impact CRC calculations in FSK mode. Additionally, an automatic image calibration is now performed when frequency changes, which could affect CRC checks, especially if the calibration is not properly tuned for FSK mode.

2. The introduction of the new beginLRFHSS() mode in version 7.1.0 extends the functionality of the SX1262. These new methods could indirectly affect previous FSK functionalities, especially if internal hardware registers or configurations used for multiple modes have been modified.

3. The issue description mentioned that enabling address filtering leads to constant CRC errors. This suggests that the internal address filtering of the SX1262 chip may be faulty. A software-based implementation of address filtering could help to work around this problem.

[jgromes]

@tonbor @ClaudiusVi while I appreciate the discussion, I remain unconvinced it is on-topic for this issue. This specific problem only appears when enabling address filtering together with CRC. as shown in my original post. From your posts, I am unable to check whether you are using address filtering - if not, it is a different issue.

If you are able to replicate the CRC being broken without enabling address filtering then please open a new issue with all the relevant information, especially the minimum code needed to replicate - thank you!

@ClaudiusVi regarding your suggestions:

1. I don't see the relation between frequency configuration and CRC filtering, feel free to elaborate where exactly you see this link.
2. Same point as for the frequency configuration - how exactly is LR-FHSS implementation related to (FSK) CRC? The argument that "new methods could indirectly affect previous FSK functionalities" is applicable to everything.
3. That is what I suggested as a workaround in my original post.

[StevenCellist]

As a quick guess: does it help subtracting another 8 bits from the maxDetLen for the address?

[tonbor]

As a quick guess: does it help subtracting another 8 bits from the maxDetLen for the address?

Well the fix #1350 did not work for me, had to go back to 6.6.0 to get things working again. Got the same problem. No result with Heltec sx1262 with library 7.1 but no problem with 7.02 (now 6.6.0) and older see: matthias-bs/BresserWeatherSensorReceiver#203

[StevenCellist]

Are you commenting on this specific issue with FSK with addresses, or without addresses as in #1350?
And did you update to the latest GitHub commit, or just to 7.1.0? Because yesterday's changes are not in an official version yet

[tonbor]

just to 7.1.0 Op di 17 dec. 2024 15:30 schreef StevenCellist ***@***.***>:

…

Are you commenting on this specific issue with FSK *with addresses*, or without addresses as in #1350 <#1350>? And did you update to the latest GitHub commit, or just to 7.1.0? Because yesterday's changes are not in an official version yet — Reply to this email directly, view it on GitHub <#1268 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AKD7IIUMNFIGVQLQDOC54Q32GAYQNAVCNFSM6AAAAABP2M6LJ6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKNBYGYYTKMBTHA> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[jgromes]

@tonbor I am nearly certain you are talking about a different issue. It is likely you have encountered #1350 (which as @StevenCellist says is fixed in master, but not released yet). But this issue in its very title about CRC error when address filtering is enabled. At no point have I seen you confirm that is what you are using.

Just to be sure, I have also tested 6.6.0 (which by your own admission works), and sure enough, this issue is still present there.

@StevenCellist unfortunately it looks like this is unrelated to #1350. No preamble detector length has any effect on this, including completely disabling it.

[jgromes]

I spent a bit more time on this, and my conclusion is that address filtering on SX126x is just broken in the hardware. First of all, it doesn't actually filter anything - setting a different node address on SX1261 receiver, the device still receives all traffic. Next, there is the behavior described in this issue - if the AddrComp field of setPacketParamsFSK is set to anything other than 0, wrong CRC will be always reported, even if CRC on the receiver is disabled. That leads me to believe that the CRC error is used by the SX126x device to report more than just failed CRC check.

I also tried sending some manually constructed FSK packets with CRCs calculated over different parts of it (e.g. skipping the length byte or the address byte, or both) and it still did not change anything.

In light of all of that, I dropped support for SX126x address filtering. The workaround described in my original post still applies. It could be added to RadioLib directly to emulate address filtering in software, but I don't see the need to do so until there are some genuine use cases for it.

[ClaudiusVi]

Hello Jan Gomes,

Just a short note: With version 7.1.1, we no longer encounter any CRC issues.
Thank you for your work on RadioLib!

Best regards

[tonbor]

@tonbor I am nearly certain you are talking about a different issue. It is likely you have encountered #1350 (which as @StevenCellist says is fixed in master, but not released yet). But this issue in its very title about CRC error when address filtering is enabled. At no point have I seen you confirm that is what you are using.

Just to be sure, I have also tested 6.6.0 (which by your own admission works), and sure enough, this issue is still present there.

@StevenCellist unfortunately it looks like this is unrelated to #1350. No preamble detector length has any effect on this, including completely disabling it.

with 7.1.1 no issues anymore, thanks