SDR With sigfox STM32L0 Discovery kit LoRa as node.

[Stianje]

Hello, I hope this post finds you well. I am currently working with an SDR and a STM node for testing purposes. I have been receiving packages through the RX chain, but have noticed that they are being flagged as "Header checksum invalid!". I have been trying to troubleshoot this issue by receiving the packages before the header check, and they are encrypted following the LoRaWAN documentation. I have successfully decrypted the package, but it does not seem to match the expected output. I was wondering if the RX chain in this repository follows the LoRaWAN documentation? Any insight or guidance would be greatly appreciated.

[tapparelj]

Hello @Stianje, This repository only implements the LoRa physical layer, not the LoRaWAN MAC layer. If you send messages from a device following the LoRaWAN specifications, you should be able to detect the frame, decode the explicit header correctly and recover the payload, however the payload will contain a MAC header (prepend by LoRaWAN) and still be encrypted. I'm surprised the header checksum test fails as it let me think the configuration you did is mostly correct as the preamble gets detected. If I remember correctly, LoRaWAN devices use the sync word 0x34. Did you set it up in the frame sync block? Can you double check the spreading factor and the bandwidth you use at both the transmitter and receiver?

[Stianje]

Thanks for the quick response, I have been testing for a bit and have not been able to resolve the issue with the header checksum. I am trying to use the SDR as a gateway and have it publish the data. I have the sync word setting in the Frame sync block is set to "0x3444". I am using the STM32 ICube end_node code for the node. As a beginner in this topic, I am having trouble locating the spreading factor and bandwidth settings in the STM code, but I believe they should be set to default values of SF7 and BW125k.

GNU Radio Companion:

Running w/ waterfall:

I would greatly appreciate any additional information or guidance you can provide on this issue.

[tapparelj]

I see a few things here:

• I've never had the chance to use a LoRa node using the 4Bytes sync word format (that your node seems to use given the value 0x3444 you want to use), can you set the sync word to 0x34 in the frame sync block as it should match the 0x3444 set in the STM node? This repo uses the 2 bytes format.
• The sample rate, bw and os factor configuration has some issue. If you use a sample rate of 2MHz in the oscmocom source, set the bandwidth to the same value. Next, in the frame sync, set the bandwidth to 125kHz(this is the LoRa signal bandwidth) and the os_factor to 8 (2MHz/125kHz). you can also remove the samp_rate variable if you don't use it.

Let me know if the issue changes

[Stianje]

Ok, thanks again for taking the time. I changed as you said.

This is the updated GNU:

Updated results with frame sync block sync word 0x34: I do not get any output on this...

In the cmwx1zzabz_0xx.list STM32 file:

[tapparelj]

sorry, can you set the os_factor to 16 not 8 (of course 2MHz/125kHz is not 8, my bad)

[Stianje]

No problem, Still not any output...

Updated result:

[tapparelj]

I am a bit surprised by the look of the waterfall, as nothing in it looks like a LoRa frame, but more like some FHSS modulation. If you don't mind, could you use something like cubicSDR to have a good waterfall view of the spectrum?. (In order to check if what you transmit )

[tapparelj]

as an example this is the signal received for sf7 and sf12

[Stianje]

I encountered some difficulties during the installation of CubicSDR. However, after some troubleshooting, I discovered that the problem seemed to stem from the spreading factor (sf) value in the STM code. It turns out that the default value for sf in the code is not SF7 as I initially assumed, but rather SF12. Once I made this correction, I noticed improvement. I will continue to work on this issue, but I wanted to share this information in case it helps others who may be facing the same problem. Based on my current understanding, does this solution seem correct to you?

Progress:

A packet decoded:

[tapparelj]

Yes, the header is found and the checksum is correct. In addition if the CRC is valid, it means that you received the entire payload correctly. Then you have to decode the payload yourself as it's encoded by the MAC layer, which is not implemented in this repository for now.

[Stianje]

Thank you for your hard work and guidance. We were able to successfully resolve this. I'm closing this issue now.