STM32WL55 Transmitting Corrupted Packets in LoRa Mode

[tmiya]

I am using three Nucleo-WL55JC1 boards running software based on the dual-core SubGHz-pingpong example in LoRa mode.

The SDK I am using is STM32CubeWL Ver. 1.5.0.

The settings used are BW=125 kHz and SF=10.

The first board initiates the sequence, transmitting a 16-byte packet every 10 seconds and then switching to receive mode.
The second board acts as a receiver and sends a response upon receiving a packet.
The third board is receive-only and monitors the communication status.

 

If the second board does not send a response, the first board transmits packet without issues.
However, if the second board does send a response, the first board sometimes fails its subsequent transmission, depending on the timing of that response.

 

If the second board responds within approximately 150 ms of receiving the packet, the first board operates correctly.
If the second board responds after a longer interval, the first board may fail to transmit the next packet.
Observation with a spectrum analyzer shows that the radio signal is being transmitted, but it cannot be received as a valid packet.
The transmission immediately following a failed attempt always succeeds.

Since the third (receive-only) board also fails to receive the signal, I believe the issue lies with the first board's transmission.

 

I would like to ensure that the first board can transmit successfully even if it receives a response delayed by more than 150ms; are there any solutions or points I should check?

 

 

[tmiya]

Correction: The length of the packet transmitted by the first board is 52 bytes, not 16 bytes.

[Filippo_Malleo]

Hi tmiya,

the fact that the failure is timing dependent is strange, I would expect a systematic behavior.

What do you mean with “corrupted packet”? wrong payload content, wrong payload length, wrong CRC, etc

In any case, to narrow down the root cause, I suggest you to provide exact radio settings: CRC enabled/disabled, packet lenght enable/disable, etc.

In general, when switching from Rx to Tx or viceversa, a SetTXConfig() or SetRxConfig() is needed in order to have the right register configuration, expecially when using CRC.

So, run the Radio.RadioSetTxGenericConfig() before the Radio.Send() and the Radio.RadioSetRxGenericConfig() before the Radio.Rx() if the radio was in RX or TX state respectively.

BR,
Filippo

[Christopher44]

I’d check the RX-to-TX state transition and pending IRQ flags first. Since the next transmission always succeeds, it sounds more like a timing or radio-state issue than a corrupted packet. Comparing the behavior with the original CubeWL ping-pong example could also help isolate where the problem starts.

[Christopher44]

I’d check the RX-to-TX transition and any pending IRQ/status flags first. Since the failed transmission is followed by a successful one, it sounds more like a radio-state or timing issue than the packet itself. Comparing the delayed-response case with the original CubeWL ping-pong example may help pinpoint where the state gets stuck.

[tmiya]

Hi Filippo,
Thank you for your reply.

I mentioned "corrupted packets," but since I don't have a LoRa analysis tool, I haven't been able to verify the details.
However, because multiple receivers are unable to receive the packets, I suspect there is an issue with the transmitted packet.
(Is there a way to use the NUCLEO-WL55JC1 as a LoRa analyzer?)

I am using the device with the following settings:
For transmission:

Radio.SetTxConfig(
	MODEM_LORA,
	13,								//power
	0,								//dummy
	0,								//BW:125k
	10,								//SF:10
	1,								//CR:4/5
	12,								//preamble len
	0,								//valiable payload len
	true,							//use CRC
	false,							//not use FH
	0,								//dummy
	false,							//not invert I/Q
	4000);							//timeout

For reception:

Radio.SetRxConfig(				
	MODEM_LORA,
	0,									//BW:125k
	10,									//SF:10
	1,									//CR:4/5
	0,									//dummy
	12,									//preamble len
	12,									//SYNC timeout
	0,									//valiable payload len
	0,									//dummy
	true,								//use CRC
	false,								//not use FH
	0,									//dummy
	false,								//not invert I/Q
	true);								//continuous Rx

Radio.SetMaxPayloadLength(MODEM_LORA, 255);

I use the following code for transmission:

Radio.Standby();
if (Radio.IsChannelFree(
	920600000,
	200000,
	-88,
	6)){
		Radio.SetTxConfig(~~~~~~
		Radio.Send(dt, len);
}

And I use the following code for reception:

Radio.Standby();
Radio.SetRxConfig(~~~~~~
Radio.Rx(4000);

In OnTxDone(), the same code as above is used to start reception.

 

You suggested using `Radio.RadioSetTxGenericConfig()` and `Radio.RadioSetRxGenericConfig()` in your reply;
is using `Radio.SetTxConfig()` and `Radio.SetRxConfig()` not a good approach?

 

[tmiya]

Hi Christopher44,

Thank you for your advice.

OK, I'll check it later.

 

Note:

I am using the Cortex-M0+ code exactly as it is.

I am only modifying the M4 code.

[tmiya]

I found a solution.

It started working fine after I added `Radio.SetMaxPayloadLength()` after `Radio.SetTxConfig()`.

 

I also tried the original ping-pong app, and adding a delay caused no issues.

Thank you.