Troubles connecting to LoRaWAN on a STM Cortex-M0+ board and mbed SX1272 shield

[krabrab]

This is a follow up to #1730 at the request of @StevenCellist.

• if you get a compilation error relating to dwt_init();, you have an outdated version. Alternatively, simply remove the line from the file.

I have verified the following in an area with a known TTN coverage:

• for scanGuard under 350, err -1116 gets thrown (see the logs), for any higher, the RX window is missed. The log contains integrated timestamps for all I know to satisfy your concerns. And I believe the Core to be stable enough to support precise enough delayMicroseconds(). I have disabled the SPI printouts, they should not affect anything.

Attempt to join via OTAA: https://gist.githubusercontent.com/krabrab/9e3f200f50fd2b0f1f0a1a7e7a5a1b9a/raw/0162973b627302414ac43c154eee8af092aab49f/lorawan2.log

[StevenCellist]

I would like to see your PC terminal timestamps, not integrated timestamps. Your clock may provide precise microseconds, but your clock may not be perfectly paced.
How are you sure that there is "known TTN coverage"? Do you have a second device that is able to join with strong signal? Or are you just relying on TTNMapper?

[krabrab]

The following screen capture is the best I can currently provide, I have ongoing troubles with installing minicom on my system.

I am in direct line of sight to a public gateway that's still online according to ttnmapper (last heard an hour ago).

[StevenCellist]

Except for it being a screenshot (we prefer formatted text), this is great, thank you.
Rx window timing is all good, no need to play with the scanGuard.
TTNMapper may tell it is online, but are you certain that its location is right? I have a gateway that 80% of the time is at my work location, but sometimes moves to a different location for a few days or weeks and I can't be bothered to always update the map. So unless you have a known working device that joins with decent signal - or have your own gateway - this cannot be relied on unfortunately.

[krabrab]

I do prefer formatted text as well... I have managed to find a helpful hand with a STM32WL55JC1 to lend me and upon installing the official stm32duino LoRaWAN library and the "LoraSendAndReceive" example, I was instantly able to send and receive packets in the same area my setup has failed. I don't have much of a record of that besides my JSON Console log which I am not too eager to share as it contains the geolocation of the gateway, among other things. If it's of interest, I might try looking for ways to use RadioLib on it as well.

I have also performed tests on a different (in serial numbers only) board, shield, and antenna with no change in behaviour. This further rules out (at least for me) any possibility of an one-off hardware failure.

[olivierouellet]

To enable terminal timestamps in Arduino IDE 2.3.8 :

• click on Serial Monitor (upper right, magnifying glass icon)
• click on Toggle Timestamp (clock icon)

If there's no Join Request on TTN, the problem is a transmit problem on your node (board) or a receive problem on the TTN gateway (too far, no line-of-sight, ...).

If the TTN gateway sees a Join Request and sends back a Join Accept, then you have a receive problem on your node or the gateway is not sending a good downlink (but that's less likely).

If you have a receive problem you can:

• increase scanGuard
• modify SystemClock_Config for your STM32
• play with RADIOLIB_CLOCK_DRIFT_MS (but that's another story and it's unlikely your Nucleo board has a significant drift)

for any higher, the RX window is missed

What do you mean by this? You should get an error code if the receive window is missed for node.activateOTAA. The node must receive something with node.activateOTAA . After that, for any node.sendReceive, if the gateway has no downlink to send back to your node, you won't receive anything (normal behaviour).

[krabrab]

I can see no signs of life on the TTN console, I am not able to get the direct logs of the particular gateway (see my previous post). When setting a too high scanGuard value, I get the following:

[11.216353] RLB_PRO: Window too late by 14 ms
Join failed - RADIOLIB_ERR_NO_RX_WINDOW (-1105)

I have evaluated the ABP example as well (with a fresh devaddr and keys) as well to rule out a receive problem and yet no signs of life are shown on the TTN console. I thus suggest a transmission problem on the board itself. I will try to obtain a different specimen of this setup to rule out any potential hardware issues as well as a different antenna.

[olivierouellet]

I checked the clock config for your variant in stm32duino and it seems ok.

Do you define SPI pins anywhere in your code for your NUCLEO-L073RZ ? They are not defined for your variant. Try to add this at the beginning of your code :

#define PIN_SPI_SS           PA4
#define PIN_SPI_MOSI         PA7
#define PIN_SPI_MISO         PA6
#define PIN_SPI_SCK          PA5

[krabrab]

Adding the definitions has not changed anything. I have additionally tried to set the SPI pins directly (STM32duino extends the API):

#include <SPI.h>
...
SPI.setMISO(PA6);
SPI.setMOSI(PA7);
SPI.setSCLK(PA5);
SPI.setSSEL(PA4);

with no visible effect (not even at the TTN console) at a place where the STM32WL55 transmits and receives without a problem. Setting different pins hangs, so I suspect the SPI pinout is correct in some way. Switching the Module pins (Replacing D2 with D3 and vice versa) results in TX timeout, so I suspect these pins are correct as well.

[StevenCellist]

If you enable the DEBUG_BASIC output, you should see the logs as below by @olivierouellet and it will show if your radio is found.

[olivierouellet]

Well, it seems the log output of SX126x::findChip is different than SX127x::findChip so you won't have RLB_DBG: Found SX127x. I thought the debug output was all the same. Sorry for that.

If you don't get SX127x not found! then you should be okay.

The last thing I would try is enable RADIOLIB_VERBOSE_ASSERT (uncomment #define RADIOLIB_VERBOSE_ASSERT ) and see if something shows up.

[krabrab]

I don't get any such error unless I physically remove the radio from the board. No assert seems to be triggered during compilation or runtime. After enabling the build option in BuildOptUser.h, no change in behaviour is perceivable. I have verified that the changes get written through by temporarily disabling regular debug output, which got reflected. I have tested this behaviour in an environment where the other board can connect without a problem. See #1739 (reply in thread) for more info on that.

[olivierouellet]

For my SX1262, this is what I get in the logs :

[3.103998] RLB_DBG: Found SX126x: RADIOLIB_SX126X_REG_VERSION_STRING:
...
[3.119838] RLB_DBG: M   SX126x

I don't see the first part in the log you provided. Could you post the full log?

[krabrab]

My logs are full as in using the "Copy Output" button and pasting it directly. I can see no such "Found ..." line.

To reiterate, I am using the Radiolib/LoRaWAN/LoRaWAN_Starter example, where my modem object is defined explicitly as an SX1272 Module. I am not using RadioBoards. I tried redownloading the library with a new sketch, where I only changed the radio module number, the keys, and the SPI pin definitions as suggested by your previous comment. The resulting log is identical to the previous one, minus the compilation time. I will try again tommorow to test in TTN coverage.

[StevenCellist]

Probably check / swap antennas.. I have some 915MHz and 433MHz and 2.4GHz that sometimes get mixed up if I don't pay attention. But I'm a bit out of ideas here honestly.

[olivierouellet]

Change the antenna. The one that comes with the module didn't work for me. I had to swap it for another one.

Got it to work with same board and same module :

SX1272 radio = new Module(D10, D9, D8, D7);