An issue with the custom hardware in p2p and LoRaWAN mode

[Mahendra Sondagar]

Hello ST Community,

I hope all are doing well...

I am making one application of Smart meter, in which I am building and WAN network

The hardware is intended to work in LoRaWAN and p2p mode in the different time frame

For our application, we have chosen STM32WLE5CC SoC, on our custom hardware

After PCB fabrication, while testing our custom nodes we find some difficulties in LoRa P2P mode and LoRaWAN mode.

The node is designed to operate in the South African region so we selected the EU868 frequency band for our design.

We design the custom board in a 4-Layers stack-up. We also implement impedance matching for RF traces where required.

The design Stackup is here:

 

impedance trace width according to our PCB manufacturer (PCBWay) are here:

 

 

We made an RF network using the following reference:

 

The schematic of my design is shown here:

We are facing some problems while testing our custom nodes and the problem are described below

Testing Procedures we follow are:

P2P MODE:-

1st Case:-

We test our custom node with Nucleo-WL55JC1. The setting we made here in both boards are..

Freq: 868MHz, CR: 4/5, SF: 7, BW: 125 KHz, PL: 8, TX Power: 14dBm

Result:-

The data is not received from Nucleo to the custom board and gives an "RX P2P ERR" message. The data we transmit from custom to Nucleo also gives the same result.

2nd Case:-

We test our 2 custom boards with each other.

Results:-

Data from both ends are transmitted and received perfectly without any error.

LoRaWAN Mode:-

1st Case:-

We set DEVEUI, APPEUI, APPKEY, DEVADDR, APPSKEY, NWKSKEY, and other parameters using the server

login credentials.

Result:-

Joining request Fail.

QUESTIONS:

1) What mistake we are making while testing, are we doing some wrong settings in some of the

parameters?

2) Is our RF network design OK or do we need some changes in our RF network peripheral values?

Can anyone help me here?

All suggestions and comments are welcome :)

Thanks

Mahendra Sondagar

[Tesla DeLorean]

That they work together suggests it's a frequency issue.

What on earth is going on with your TCXO circuit? It makes no sense, you have it wired like a crystal.

You should only need OSC_32MHZ_IN connection to STM32.

Check/confirm frequency.

State specific part used for TCXO, provide link to data sheet.

[Mahendra Sondagar]

Hi.. @Community member​ 

First of all Thanks for the prompt reply...

We have not used TCXO crystal. 

The crystal part no. is NX2016SA-32MHZ-EXS00A-CS06654

The datasheet is attached here

Pl. let me know if any further information is needed

Thanks

Mahendra Sondagar

[Tesla DeLorean]

Omit L8 / C38, pin 2 / 4 on the XTAL should be ground, you have one of those pins connected, so should go via the case.

Validate the frequency. If you can escape via MCO / PA8 pin or similar.

Or divide as MCU clock via one of the TIM.

Make sure the HSE clock starts, and HSE_VALUE reflective of the frequency.

[Mahendra Sondagar]

Hi.. @Community member​ 

Thanks for the revert

In our design, we do not use TCOX xtal. The L8 was the Do not Place (DNP) component. and the x'tal pins 2 & 4 are internally connected.

We tested the HSE clock on PA8/MCO pin and got the 32MHz clock. I have shared the waveform.

 

Pl. let me know if you need any further information

Thanks

Mahendra Sondagar

[Tesla DeLorean]

Did the forum migration not pull the images, that's disappointing..

The waveform looked fine as I recall.

You might want to check how the receivers work in USA 915 plan modes, this might help determine where the issue is.

My take-away currently is the custom boards can communicate with each other, and the problem is communicating with other/similar boards. So assuming the frequency generation is solid, the next thing would be to look at modulation and other settings to assure they are the same between working/not-working board implementations. And that the frequency-plan, and it's implementation, is consistent between the two platforms. For this I'd assume US 915 would be the most consistent, most worked-on solution. Checking if it works would check that off the list, and then 898 can be focused on.

[Alexander Czajor]

---

@Tesla DeLorean wrote:

Did the forum migration not pull the images, that's disappointing..

---

Hi @Tesla DeLorean, 
welcome to the new platform. We'll have to tidy up few things and these images are one of them. 
Give us a few days.