Skip to main content
Associate II
October 20, 2025
Question

stm32wl incompatibility with other LoRa tranceivers?

  • October 20, 2025
  • 2 replies
  • 716 views

Hi,

 

I have been facing with an issue that like stm32wl LoRa feature is not compability with other transceivers.

However,  had 4 transceivers:

 

1. Esp32-sx126x

2. stm32f429-sx126x

3. stm32wl (x2)

 

First two can easily communicate with each others, they can exchange data even in pingpong structure but they can't send or receive data from stm32wl. In first glance, i don't know why but stm32wl couldn't be set correct syncword. After explicitly writing to its register problem solved and i could just see some thing on scanners (first two were in receiving mode) but always CRC error occurs. When third one was in tx mode and others in rx mode, others rised CRC errors and visa versa...

In other hand (without changing any configuration), stm32wls can communicate with each others. 

And yes i examine and double-double check all parameters of LoRa (like sf,cr,bw,frequency). 

After all question rised is there stm32wl incompatibility with other LoRa tranceivers (Specifically in CRC calculation)?

 

2 replies

Uwe Bonnes
Chief
October 21, 2025

Did you check that the oscillators used provide the accuracy needed? Mismatch in frequency can result in communication failure.

krfAuthor
Associate II
October 21, 2025

If problem is this, wouldn't be same error raise with whenever two stm32wl communicate each others?

And also have you ever tried communication with stm32wl and other transceiver? Like standalone sx1262?

 

Many thanks...

Andrew Neil
Super User
October 21, 2025

@krf wrote:

If problem is this, wouldn't be same error raise with whenever two stm32wl communicate each others?..


Not if your two STM32WLs have the same error !

That would explain how they can communicate with each other, but not with other things.

 

Perhaps give more details of your two STM32WL devices - are they identical designs?

A complex system that works is invariably found to have evolved from a simple system that worked.A complex system designed from scratch never works and cannot be patched up to make it work.
Explorer II
October 21, 2025

Check the value of XTAL_DEFAULT_CAP_VALUE; the default value is very large -- enough to throw the HSE48 HSE32 off-frequency. (As Andrew mentions, if both sides are affected the same way, they'll still be able to communicate.)

See also:

https://community.st.com/t5/stm32-mcus-wireless/stm32wl55-no-rf/m-p/674789#M19086

[Edit: It's the HSE32, not the HSE48.]

krfAuthor
Associate II
October 23, 2025

Hi,

Indeed, i susptected from this. I am going to try change this values but there is a doubt:

To 2 stm32wl board,

First board had 2 capacitor 6.8pF placed externally and for trying i removed them. 

Second board has 2 capacitpr externally 6.8pF and i didn't remove them. 

Software was still same for two board : XTAL_DEFAULT_CAP_VALUE = 0x20

But they can still communicate. It might not be exact problem but i am going try some options with them.

It might be removing external capacitors and setting appropirate internal capacitors or setting internal triming register to 0 and removing external capacitors.

But setting internal trimming registers to doesn't make internal capacitors completely removed. 

From sx126x datasheet - page 24:

Each capacitor can be controlled independently in steps of
0.47pF added to the minimal value:
•0x00 sets the trimming cap to 11.3pF (minimum)
•0x2F sets the trimming cap to 33.4pF (maximum)

 

PS: I compared XTALs we used and used one that in nucleo boards, they are identical as frequency tolerances and load capacitance. There are huge differences in shunt capacitance and drive level. But still there is requirement that should be examine. Which values should be take into account else? Would shunt capacitance and drive level be problem?