Issue with RX Window Configuration for SX1262 on LoRaWAN Network

[nikorainto]

Hello,

I am currently testing the RadioLib and LoRaWAN example on a custom board featuring an STM32L072RB MCU and a Waveshare SX1262 module. The testing environment includes a nationwide set of LoRaWAN gateways utilizing the ThingPark network platform for device management and message logging. ThingPark supports LoRaWAN v1.1.

I observed that my join request appeared in the gateway's log and a response was sent. However, it seems the RX window closes before my device can receive the join acceptance. Additionally, the JoinAccept packet log shows: "Delivery Failed Cause on RX1: Class A: LRC selected RX2(C0)." On my device I can see state being -1116 (RADIOLIB_LORAWAN_NO_DOWNLINK)

Previously, I have been using CubeCell with LoRaWAN v1.0.2 on the same network. When the signal is weak, it can take between 10-15 seconds for the JoinAccept to appear on the device. I'm considering whether this might be the case here as well. I believe that by default, RadioLib waits 5-6 seconds for a response. Should I consider increasing RADIOLIB_LORAWAN_JOIN_ACCEPT_DELAY_1_MS? Does that sound correct?

You can view my current code here: GitHub Link

[StevenCellist]

Hi @nikorainto, the problem appears to be with ThingPark, judging by the upper screenshot as it already reports an error. The main observation is that ThingPark apparently tried to schedule at Rx1 but failed to do so with that error you copied (Class A: LRC selected RX2(C0)).
I have never used ThingPark so I can't comment on what this means - I would recommend you do a Google search or whatever your preferred search engine would be.
But OK, then ThingPark tried to use Rx2 at SF12 - this would be expected to work. Can you turn on RADIOLIB_DEBUG_PROTOCOL flag in your compile options and re-run your test? You would only need to do it once (or maybe twice in case it was a fluke); no need to spam the airwaves with SF12 continuously. It if not work, it not work.

[nikorainto]

I tried to debug this more but seems like dead end. Code does not stop to any breakpoint in any line but instead starts from this

Reset_Handler:  
   ldr   r0, =_estack
   mov   sp, r0          /* set stack pointer */

and when clicking pause it stops to this line

Infinite_Loop:
  b  Infinite_Loop

with following call stack

WWDG_IRQHandler@0x0800c52c (c:\Users\me\.platformio\packages\framework-arduinoststm32\system\Drivers\CMSIS\Device\ST\STM32L0xx\Source\Templates\gcc\startup_stm32l072xx.s:110)
<signal handler called>@0xfffffff9 (Unknown Source:0)
__libc_init_array@0x08010cc0 (\__libc_init_array.dbgasm:1)
Reset_Handler@0x0800c50e (c:\Users\me\.platformio\packages\framework-arduinoststm32\system\Drivers\CMSIS\Device\ST\STM32L0xx\Source\Templates\gcc\startup_stm32l072xx.s:89)

and that keeps repeating if I try continue and pause again 🤔Also nothing special can be seen in terminal debug console. If I run code with just Radiolib parts or only BME280 parts then everything works

[jgromes]

This would deserve a more in-depth exploration with the debugger, but for what it's worth ...

1. On STM32, WWDG is the windowed watchdog, and if I remember correctly, the default implementation of its IRQ handler is an infinite loop. So if the watchdog is being enabled and then timing out (e.g. if some fucntion takes too long without feeding the watchdog), it will trigger the IRQ, hence the infinite loop.
2. However, I also seem to recall that the WWDG_IRQHandler is the point in the interrupt vector that interrupts will jump to if the don't have an IRQ handler. So if there's an interrupt that's missing its handler, it would jump into WWDG_IRQHandler without actually being triggered by the WWDG.

Take the above with a grain of salt, it's been a while since I've seen this behavior of STM32 program ending up in WWDG_IRQHandler

[nikorainto]

Reason for this was found. I had wrong openocd_target defined on my board definition. Had to be stm32l0_dual_bank instead of stm32l0

  "debug": {
    "jlink_device": "STM32L072RB",
    "openocd_target": "stm32l0_dual_bank",
    "svd_path": "STM32L07x.svd"
  },

[nikorainto]

So I got everything working on TTN on a self hosted gateway and getting back to this issue. I found documentation from service provider which states following:

• The device must comply with the LoRaWAN specification (at least 1.0).
• The device must support the EU868 frequency band, at least the three mandatory frequencies of the EU868 band (the rest of the frequencies are communicated to the device either during the Join process (OTAA) or to ABP devices via separate MAC commands).
• The device must have a unique DevEUI identifier, and for security purposes, also a unique encryption key.
• The device must adhere to the duty cycle restrictions as defined by the communications authority, which is typically 1%.
• The device must support the ADR feature (Adaptive Data Rate) and, in general, the message type should be unconfirmed.

Other considerations:

• The spreading factor used in the Rx2 window is only the initial value used in the OTAA device Join procedure and in the first messages of ABP devices. The device must be capable of changing this data rate of the listening window according to what the network commands it, either in the OTAA Join or to ABP devices via MAC commands.
• By default, our network uses a downlink data rate offset value of +2.
• By default, the delay for the RX1 window is 1000ms and for the RX2 window 2000ms. In the Join procedure, the corresponding delays are 5000ms and 6000ms.
• The LoRaWAN channels used by Digita are: (initially, it is most important for the device to understand to use the mandatory channels LC1-LC3 specified by the EU868 spec and the Digita network's RX2 frequency; other channels are communicated to the device via MAC commands):

LC1 868.1 MHz
LC2 868.3 MHz
LC3 868.5 MHz
RX2 869.525 MHz

So as far as I understand all these should be OK right?

Device "model" I selected from ThingPark/Digita portal is: LoRaWAN 1.1 revA - class A eu868, eu433, cn779, kr920, in865, ru864 and there is no specific selections for Frequency plan and Regional parameters version like in TTN portal

[StevenCellist]

Looks about right to me! Weird that it doesn't select a specific plan (e.g. EU868) but the Regional Parameters are included in the 1.1 revA.

Only thing that looks a bit odd to me is the downlink datarate offset of 2 - not exactly sure how that would play out, i.e. if network communicates that by itself or if additional configuration is required.

[K4KDR]

Don't have a specific answer for you, but as I've been learning how to use the various LoRaWAN capabilities in RadioLib, a LOT of useful information has been revealed by un-commenting one or more of the 'debug' lines in /src/BuildOptUser.h

... besides revealing all kinds of LoRaWAN info to point you in the right direction, the debug info that appears in your serial terminal can of course also be a huge help with a module like the BME280, too!

[nikorainto]

There is just an issue that I have only SWD port available on my board and no serial port so I think that option will not work for me 😅

[K4KDR]

I only have a couple of STM32 devices but all of them allow me to connect via a terminal app (using CuteCom on linux) to the device that usually presents itself as something like /dev/ttyACM0. But I'm very much a novice with these modules so perhaps that is not true for all of those boards

[nikorainto]

Yes, I also have some Arduino and STM32 development boards without the LoRa module that work well with serial port debugging. However, I am new to this field also and recently built a custom board with only an SWD port. I thought it would provide the same debugging capabilities, but it seems that I can only rely on breakpoints in the code for debugging 😬

[nikorainto]

I have a separate project for reading BME280 sensor values and it works well. Also I have another with Radiolib and LoRaWAN and that works. Now I'm trying to combine these two but ran into this problem

[HeadBoffin]

I am new to this field also and recently built a custom board with only an SWD port.

You aren't alone in making this error but the only solution is to either bodge two wires on to the side of the chip or re-do your board. Once you have done the development work you can return to your no-serial PCB for deployment. However I'd point ou that the minimum I have on production boards are either pads or 1.27mm header - the SWD connector provides a Gnd, so the minimum is ONE pin for Tx.

Does anyone with more knowledge than me understand what is happening even without having debug logs?

Advanced guessing would be to look at an overlap of pin use. Or as Jan says, use the debugger even if it takes an evening of learning the debugger rather than hoping you can operate it by brute force. Or, as I do, use a bigger / better board for development & debugging and then port it over.