LoPy not obeying data rate requests from network

[jcaron]

An alternative to the method in the previous post could be (and that would probably be a lot cleaner) to have setsockopt of the data rate just send the MIB_CHANNELS_DATARATE MIB set request, rather than store that data rate in the socket and pass it along with every send. Haven't quite explored the ramifications of such a change.

[daniel]

@jcaron thanks for the detailed feedback!

I have a patch ready with the following fixes:

1. Correct ADR functionality by simply doing the following in modlora.c:

-                        // set the data rate before checking if Tx is possible
-                        mibReq.Type = MIB_CHANNELS_DATARATE;
-                        mibReq.Param.ChannelsDatarate = task_cmd_data.info.tx.dr;
-                        LoRaMacMibSetRequestConfirm( &mibReq );
+                        if (!lora_obj.adr) {
+                            // set the data rate before checking if Tx is possible
+                            mibReq.Type = MIB_CHANNELS_DATARATE;
+                            mibReq.Param.ChannelsDatarate = task_cmd_data.info.tx.dr;
+                            LoRaMacMibSetRequestConfirm( &mibReq );
+                        }

2. sftx value in lora.stats() also updated for unconfirmed frames.

3. For me Tx time is correct, but I have added a small patch to improve it a bit, specially when a downlink is received.

4. The LoRa join logic when the DR is forced is fixed as well, it will attempt the selected data rate and will lower it on the following attempts as specified by the LoRaWAN specification.

5. What's the issue with NVRAM save/restore?

Cheers,
Daniel

[jcaron]

Hi @daniel, thanks for the update.

1. That's indeed an approach. I feel the LoRaWAN spec is quite unclear as to what "ADR enabled" means (it basically says either the node or the network can decide to use it), but it working when adr is set would probably work for me. I haven't checked, if adr is not set, would the stack reject a LinkADRReq for a different data rate, or acknowledge it but ignore it?

   Also, even if adr is set, there are probably scenarios where you would want to set an initial data rate but then let the device/network control it up and down.

2. While you're in lora.stats, adding TX time on air, TX power and TX frequency would be useful. The first two are easy, the last one seems a little bit tricker than I expected. Adding whether a MAC command was received in response could also be useful.

3. Using SF12, it always takes about 8 seconds, and a bit more if there's a downlink in response (8.5 and 8.7 seconds depending on the received downlink, I haven't quite checked if that's consistent with the downlink length). Unless I'm mistaken, it should be about 1.5 seconds for the uplink, up to 2 seconds for RX2, plus the downlink reception time if any.

4. Haven't checked the details, but the network showed be having received a MAC command in the following uplink (after save/sleep/restore), but it wasn't properly decoded. I'll try it again later and let you know the details.

A few things that could be helpful:

• add an option on the LoRa constructor to enable debug mode, and log (just printf) the raw packets received/sent with all details (SF/DR, frequency, power, and full packet hex dump...) when the mode is enabled.

• I would pass the equivalent of lora.events(), and possibly lora.stats() directly as a parameter to the callback. LoRa is slow enough that we shouldn't quite risk a race condition, but still...

• add callbacks for successful join and MAC command received.

• maybe an option to read the current data rate (getsockopt maybe, but it should retrieve the actual data rate used by LoRaMac, not the one set via setsockopt).

An important remark: the Semtech stack is tested and certified, but there have been quite a few instances where higher-level issues (deep sleep, this data rate issue...) have broken LoRaWAN compliance. Not sure how that works (i.e. if that involves $$$), but making sure releases undergo actual compliance tests (both with or with deep sleep, and in the case of deep sleep, both the "external" (Deep Sleep Shield / PyTrack / PySense) and "internal" deep sleep) would help make sure the modules actually work as intended in that respect. With all the additional regions that's quite a lot of tests, but it would definitely help.

Thanks!

[jcaron]

Not directly related to the original problem, but it seems there's an issue again with keeping the frequencies received from the network. Not sure yet if that's related to deep sleep or not, and haven't confirmed the details, but network logs only show the three basic frequencies (for EU868) since I upgraded.

Any indication of where this could be coming from?

If that's indeed again a firmware problem, this would reinforce my remark above: making sure the LoRaWAN stack is fully tested and passes compliance tests should really be part of the release process to avoid all these issues.

[jcaron]

Just confirmed the channels issue.

LoPy 1, EU868 region. Starts with the default channels (868.1, 868.3, 868.5). The network sends a CFList in the Join Accept adding three channels (865.1, 865.3, 865.5).

Just after join, sending frames uses all 6 channels.

Just do nvram_save() and nvram_restore() and the LoPy reverts to sending only on the original channels.

It appears even though the channels themselves are saved and restored, the channel mask isn't, and is reset to the default 3 channels.

Saving the channels mask is non trivial, as the size of the channels mask is region-dependent and there does not seem to be an interface to get it at the moment, so it requires changes to all regions to feed back the information to the relevant places...

[jcaron]

Also confirmed that if a LinkADRAns is queued before sleep, there's an issue when it is sent after sleep. The network sees there was a MAC command, but states "unknown" instead of the decoded MAC command, so I suppose there's a problem with it.

Haven't quite traced the details of this yet, though. The relevant data seems to be correctly saved to and restored from NVRAM, but it must somehow get overwritten somewhere between the restore and the actual send.

[jcaron]

This post is deleted!

[jcaron]

Regarding the delay it takes to send a frame, it looks like it's the network sending a 5 second delay in the Join Accept message. I'll take that one up with them.

So the open issues are:

• channels mask save/restore
• issue with LinkADRAck sent after a save/sleep/restore cycle.

Continuing my investigations on that one...

[jcaron]

@daniel for the MAC command save/restore across deep sleep, the issue is that in modlora.c, when the MAC command buffers are restored, the length is set to 15 before calling modlora_nvs_get_blob. However, the buffers are 128 bytes long, so those calls fail, and the buffers are (silently) not restored.

Easy fix: set length to 128 (it should really be LORA_MAC_COMMAND_MAX_LENGTH, so it should probably be retrieved together with the buffer pointers) before each of the calls to modlora_nvs_get_blob.

[jcaron]

Oh BTW @daniel you fell into the same trap I did... :-( Sadly UpLinkFrequency is not filled out and is always 0 so lora.stats() does not reflect the actual TX frequency. It's quite a bit more difficult to dig it out, however retrieving the channel should be somewhat easier.

[jcaron]

Hi @daniel, just wanted to make sure these two issues will be addressed in the next release:

• save/restore channel mask
• fix MAC command buffers restore

Let me know if you need/want issues filed in GitHub and/or PRs.