stm32wl communication data error with SX1278

[sinlatansen]

  Hello ST experts, I have recently taken up a LORA wireless communication project, previously the transmitter side was using ebyte's lora module based on SX1278 and the receiver side was using a combination of STM32L1 and SX1278, they have been working well at 408MHz. my work switched the receiver side to STM32WLE5J8 for better integra , I designed the PCB myself but there are some flaws. Although I could boot the chip properly, I ran into some problems.

My STM32WLE5J8 can receive the data sent by the SX1278, it shows the RSSI and SNR of the received signal, but the data can't pass the CRC checksum, based on the log of the SUBGHZ-PINGPONG routine, which shows IRQ_CRC_ERROR and HDR KO. after I turned off the CRC checksum on the transmitter and receiver side, I saw my exactly what kind of error data is being received. When I set the payload size to 111, I tried transmitting single bytes, multiple bytes, and 111 bytes. The receiving end would receive the correct number of bytes, but the data would be incorrect, and the value of the error would generally be stable, with occasional values that were different and incorrect.

Specific examples of errors are listed below:
I sent hello and should have received 68 65 6c 6c 6f, but instead I received 78 A5 67 78 44.
I send {0x11,0x11,0x11,0x11,0x11,0x11} and receive 21 86 13 15 48 instead.
I send 0x11 and receive 21. and may have other incorrect values when the antenna is blocked, but when the antenna transmits well it will be a stable 21.

The following is the initialization of the SX1278 on the transmitter side.

tLoRaSettings LoRaSettings =
{
408000000, // RFFrequency
20, // Power
9, // SignalBw [0: 7.8kHz, 1: 10.4 kHz, 2: 15.6 kHz, 3: 20.8 kHz, 4: 31.2 kHz,
// 5: 41.6 kHz, 6: 62.5 kHz, 7: 125 kHz, 8: 250 kHz, 9: 500 kHz, other: Reserved]
7, // SpreadingFactor [6: 64, 7: 128, 8: 256, 9: 512, 10: 1024, 11: 2048, 12: 4096 chips]
1, // ErrorCoding [1: 4/5, 2: 4/6, 3: 4/7, 4: 4/8]
false, // CrcOn [0: OFF, 1: ON]
false, // ImplicitHeaderOn [0: OFF, 1: ON]
0, // RxSingleOn [0: Continuous, 1 Single]
0, // FreqHopOn [0: OFF, 1: ON]
4, // HopPeriod Hops every frequency hopping period symbols
100, // TxPacketTimeout
100, // RxPacketTimeout
111, // PayloadLength (used for implicit header mode)
};

The following is the CUBEWL-based initialization on the receiver side.

#define USE_MODEM_LORA 1
#define USE_MODEM_FSK 0

#define RF_FREQUENCY 408000000 /* Hz */

#ifndef TX_OUTPUT_POWER /* please, to change this value, redefine it in USER CODE SECTION */
#define TX_OUTPUT_POWER 14 /* dBm */
#endif /* TX_OUTPUT_POWER */

#if (( USE_MODEM_LORA == 1 ) && ( USE_MODEM_FSK == 0 ))
#define LORA_BANDWIDTH 2 /* [0: 125 kHz, 1: 250 kHz, 2: 500 kHz, 3: Reserved] */
#define LORA_SPREADING_FACTOR 7 /* [SF7..SF12] */
#define LORA_CODINGRATE 1 /* [1: 4/5, 2: 4/6, 3: 4/7, 4: 4/8] */
#define LORA_PREAMBLE_LENGTH 12 /* Same for Tx and Rx */
#define LORA_SYMBOL_TIMEOUT 5 /* Symbols */
#define LORA_FIX_LENGTH_PAYLOAD_ON false
#define LORA_IQ_INVERSION_ON false

#elif (( USE_MODEM_LORA == 0 ) && ( USE_MODEM_FSK == 1 ))

#define FSK_FDEV 25000 /* Hz */
#define FSK_DATARATE 50000 /* bps */
#define FSK_BANDWIDTH 50000 /* Hz */
#define FSK_PREAMBLE_LENGTH 5 /* Same for Tx and Rx */
#define FSK_FIX_LENGTH_PAYLOAD_ON false

#else
#error "Please define a modem in the compiler subghz_phy_app.h."
#endif /* USE_MODEM_LORA | USE_MODEM_FSK */

#define PAYLOAD_LEN 111

I should have made sure the common lora communication parameters were consistent. But I'm not quite sure if parameters like LoRa preamble length, SyncWord I'm setting wrong, I'm only familiar with STM32WL's cubemx configuration method.

Overall, if it's not a lora parameter configuration issue, it could be due to my hardware design. The main hardware design error is that the TCXO I chose for the STM32WL has an actual peak-to-peak value of only 0.2, which is much less than the minimum peak-to-peak value written in its datasheet, which is 0.8. Whereas the STM32WLE5 reference manual requires a HSE peak-to-peak value of greater than 0.4. So even though the serial port of the STM32WL is currently, and the led is all working fine, I don't know if this is causing the lora communication error, please help me, I appreciate it!

[STTwo-32]

Hello @sinlatansen 

I suggest you perform the same test using the NUCLEO-WL55JC2 as sender to ensure that the problem comes from the receiver. If so, I suggest you use the AN5408 to validate your SW migration. If your SW and peripherals are working fine. You may should verify carefully your HW design which is most probably the source of this issue.

Best Regards.

STTwo-32 

[sinlatansen]

thank you for your reply. I tried using stm32wle5j8 on the transmitting end, and it successfully established communication with my receiving board, which verified that the hardware design of the receiving board is still working enough.
I think the problem still lies in the compatibility issue of lora communication between sx1268 and stm32wl. There is very little information on the Internet, and most people will choose to use the same module for the transmitter and receiver.
I have tried my best to configure the lora communication parameters of both parties correctly, but I still can't find the problem.

[STTwo-32]

It is Always a good idea to use the same module. But if you steel want to have a working connection on your system. It will be a good idea to contact directly semtech or one of our FAE's to have a firect support on your request.

Best Regards.

STTwo-32