LoRa: RX2 DR is ignored and wrong one is applied

[maxgerhardt]

Description

• board type: Nucleo L476RG with RFM95W radio
• latest commit mbed-os
• GCC

I am using the LoRaWAN stack with The Things Network (TTN), which has its RX2 window on SF9BW125, a.k.a DR_3 for EU868 (https://www.thethingsnetwork.org/docs/lorawan/frequency-plans.html), not the actual SF12 standard.

So, I have to modify the LoRaPHYEU868.cpp file in order to change the hard-coded

#define EU868_RX_WND_2_DR          DR_0

to

#define EU868_RX_WND_2_DR          DR_3//DR_0

This worked fine in previous stack versions.

Then, commit b0b0261 broke it.

The radio is now listening in the RX2 window on SF7 (highest possible datarate) instead of the SF9 I want it to listen on, dictated by phy_params.rx_window2_datarate

Previously in LoRaPHY.cpp:523, this is where the RX2 datarate was set:

    params->sys_params.rx2_channel.datarate = get_default_rx2_datarate();

Now this has become

    // RX2 data rate should also start from the maximum
    params->sys_params.rx2_channel.datarate = get_default_max_tx_datarate(); 

Since get_default_rx2_datarate() is never called in any other place, the PHY's RX2 datarate is ignored completely.

The commit message says something about starting on a higher rate for joining a network (aka OTAA?). However, I'm using ABP and this bug still occurs.

When I manually change it back to respect my PHY's RX2 datarate again, it receives packets again as normal.

Without this change, reception is utterly crippled, since TTN lets the gateways mostly reply back in RX2 when a packet is sent on a higher SF. About 90% packet loss when no RX2 packet is received makes the mbed-os LoRaWAN stack unusable in this scenario .

Request:

• Justify the change to ignore the PHY's RX2 datarate but use the highest possible TX datarate for an RX window
• fix code for the ABP codepaths, keep that old code for OTAA if needed

Appendix note:

Actually we're talking about two separate problems here: For TTN, the RX2 window is by-default on the wrong data rate of you're using ABP (SF12BW125). You must edit the PHY's source code file to fix this to SF9BW125 if you want to use TTN on the European continent with ABP. Secondly, after the above referenced commit, ABP is broken even if you edit the EU868_RX_WND_2_DR macro, because the radio now uses SF7BW125 in RX2. Maybe a macro configuration MBED_CONF_FORCE_RX2_DR would be nice?

Issue request type

[ ] Question
[ ] Enhancement
[X] Bug

@hasnainvirk would be great if you'd take a quick a look at it :)

[ciarmcom]

ARM Internal Ref: MBOTRIAGE-1530

[hasnainvirk]

@maxgerhardt Interesting. For OTAA I would expect the Network Server to set the RX2 data rate in join accept message. At any time network server can choose to send a RxParamaSetupReq mac command to set desired data rate for receive windows including RX2. The thing is DR_0 is unfathomably long duration for transmission which is the default data rate for RX2 window. My wild hunch is that there is something inherently wrong with the calculation of offsets and symbol timeout when DR_0 is used. And the issue is prevalent, i.e., everyone is facing this issue. This may suggest why TTN chose to stick with DR_3 for RX2 window. Our attempt to go for higher data rates involved similar reasoning.
The expectation was:
i) The device will adjust to RX_2 data rate if it's not the one we chose to use, either by using DLsettings field in the join accept message, OR
ii) By receiving RXParamSetupReq mac command.

Probably that was a bit presumptuous as we had been using MultiTech's network server for testing and we could configure RX2 data rate that the network server would use. I am not in a position to answer why a network server would not send a Mac command to configure all the non-standard (or say, custom) settings to the devices as soon as possible.
Anyhow, as you rightly pointed out, we need a better solution here. We need a compromise. Let me come up with a solution which may serve our purpose as best as possible.
Thank you for pointing this out.

[maxgerhardt]

@hasnainvirk Good to know that I was right to open this issue. Note though, I am using ABP and not OTAA, so setting RX2 DR from the join accept message never happens. I would have to debug if TTN ever sends me a RXParamSetupReq, but I definitely don't want to rely on the LNS to fix my downlink settings in a MAC command -- that's why I'd just force RX2 DR to one constant value, as it's required by e.g. TTN.

A correction from my original post though: It's actually not important that I modified my PHYEU868.cpp to change the EU868_RX_WND_2_DR, as it's ignored anyway. The unmodified stack would have also listened on SF7, ignoring the original macro value for SF12, with both of them being the incorrect setting for TTN.

[mattbrown015]

Hi @hasnainvirk, this issue tweaked my interest although my situation is not exactly the same as @maxgerhardt's; I'm using OTAA.

Things like this worry me because I've got no way of testing the LoRaWAN stack. Therefore, when my customer reports problems to me I'm going to struggle to find any answers. I'd really like to know more about how to manipulate app servers, network servers and gateways so the end-device can be tested. Do you know of any relevant sources of information?

In an attempt to do my own testing of the RX2 window I've been requesting link checks with every message sent by the end-device this morning. Most of the link check responses come back in the RX1 window but I've seen one link check response sent in the RX2 window and it was received by the end-device.

In other words, I think the RX2 window works for me when using OTAA and TTN. :-)

[hasnainvirk]

@mattbrown015 For OTAA it would always work. Because JoinAccept message includes required DR information for RX2. But I would expect NS to promptly send RXParamSetupReq mac command in case of ABP to make sure that the device is using correct parameters required by that NS. I can understand why TTN chose DR3 as default RX2 data rate but I can't comment on why RXParamSetupReq mac command is not sent (for ABP case). Simplest and fastest solution to this is here #7831.
It just restores the default RX2 data rate. We need some deliberation to figure out a more detailed fix which may make it configurable.

If you are Mbed partner, you can request access to our testing framework.

I am pretty sure that even #7831 wouldn't be the best fix for @maxgerhardt. However, it's better than the regression introduced in my commit.

[mattbrown015]

Hi @hasnainvirk,

If you are Mbed partner

I know that we are an "ARM Approved Design Centre" but I'm guessing that's different to being a "Mbed Partner". The LoRaWAN device I'm working on is a little outside our normal business as a fabless silicon design house.

[AnttiKauppila]

@hasnainvirk @mattbrown015 @maxgerhardt Is this issue resolved and validated?

[hasnainvirk]

@AnttiKauppila Yeah it was resolved in #7831