[LoRaWAN] Fix for unreliable first transmits (fixed band regions)#1706
Conversation
|
Awww man, not this rabbit hole again. I'll need to dig into the regional parameters and test suite again for this. A lot of this stuff has been very carefully tuned and even the slightest modification breaks stuff. So either that has already happened or there's a misunderstanding of the specification by one (or both) of us. |
|
I feel your pain, I feel your pain. Plan B is to call my Prime Minister and do lobbying for Canada915 dynamic band. In case it helps, I modified calculateChannelFlags() to add logging : And this is what I got without this PR. The code after Debug output
|
|
I assume you set a specific subband? |
|
Yes. SPI log of a transmit not seen by the gateway
|
|
Rest assured that I cannot read SPI logs. I can only read the protocol debug info. Any chance you have the protocol debug info related to that transmission? |
Protocol debug info of a transmit not seen by the gateway
Please note that it's not from the same run as the SPI log in my last post (and also different from previous log). |
|
Oh. I had ADR disabled for debugging. Enabling ADR makes Protocol debug info
|
|
Right. So I didn't want to merge this without understanding the issue, but I've traced it down. Before join, any one channel can be used and the datarate is calculated based on the random channel that is picked. Upon join, the datarate is selected and a channel is picked on random as long as it supports the datarate (so vice versa). However, the order before this PR is that activation is set after channel flags are calculated. So a datarate is fixed by the join but the channels are calculated as if any datarate could be used. This means that a channel can be selected that is not available for this datarate, but then the datarate is still used. This emerges for the 500kHz channel if a 125kHz datarate is used. It could happen the other way around too, which is more dramatic but very infrequent. This PR does correctly resolve the problem. Merging, thank you! |
|
As a demonstration, the "missing uplink log" shows 904.6MHz which is a 500kHz-band channel, but it is used with a 125kHz datarate. |
|
I was about to ask you if you needed some water or carrots while down there, but I'm glad to know you're already out! Do you want to add a comment to make sure it doesn't get flipped back in the future? It does look better the original way and it's tempting to put it back the way it was. (I can do a PR if it saves you time.) Thanks a lot for your help. This project and the team behind it are truly amazing. |
|
I'd like myself some carrots ;) |
For regions using
RADIOLIB_LORAWAN_BAND_FIXED(US915, AU915, CN470), calculateChannelFlags() gets an early return duringactivateOTAA()becausesessionStatusis set toRADIOLIB_LORAWAN_SESSION_ACTIVEafter callingcalculateChannelFlags().activateOTAA()
calculateChannelFlags()
So the rest of
calculateChannelFlags()is skipped.This leads to the first transmits randomly not working (I usually get one of the first 8 transmits not seen by the gateway) until
calculateChannelFlags()gets called again when all flags are set. This time, the early return is skipped (isActivated()returns true). After that, every transmit works ok.