Library update for ST fw version 1.3.1 + Band selection at runtime

[giulcioffi]

MKRWAN.h has been updated to be compliant with version 1.3.1 of ST fw.
Some functions have been renamed, while others have been deleted because not supported anymore.
Lora error and reply messages have been updated.

"Set" functions (+FUNC=) and "get" functions (+FUNC=?) have been rearranged to work with the new pattern of the fw.

The library has been updated to support also frequency band selection at runtime, so that the user can instruct the fw from the Arduino sketch to correctly set the frequency for his/her region. This is automatically handled by the function _bool begin(lora_band band).

[facchinm]

Here's the first implementation of the library based on ST fw 1.3.1 .
We added runtime band switching capability to the original fw leaving (almost) everything else untouched.
This follows proposal 1 in #64

This addresses a bunch of other issues too (like #69)

It would be great if users (from different parts of the world) could test it in actual scenarios, to make sure there's no outstanding mistake.

@sslupsky @mjunior-fitec @remuslazar @deanpretorius @TechNyquist @giampiero7 @kraef @conradholt @almarion @ldesomer @xoseperez @sabas1080

[sslupsky]

Has the firmware been updated to work with this?

[sslupsky]

Ok, I see it as a branch at the mkrwan1300-fw repo. Some changes need to happen here as well.

[facchinm]

The MKRWANFWUpdate_standalone already contains a precompiled version of the firmware; the PR on mkrwan1300-fw repo is coming 🙂

[tohlh]

Hello everyone, I am currently testing this firmware for AS923 region. The whole process is done by only entering AT commands.

This is my AT Command sequence:

1. AT+BAND=0, 0 for AS923
2. AT+ADR=0
3. AT+DR=2/3/4/5 (I only tested these DRs)
4. AT+JOIN
5. AT+NJS=?
6. AT+SENDB=2:payload

I noticed a few things throughout these tests.

1. The DevEui changes from a861xxxxxxxx8a07 to 3535xxxxxxxx8a07 when I run on firmware 1.3.0. Where xxxxxxxx are all different.
2. When ADR is set to true, I could only send at most 8 bytes at when I set DR to 4. However the LoRa server shows that the payload is sent at DR2, which is not expected.
3. These are the payload sizes that I tried to send and actually received, ADR is false, port is 2:

#	Data Rate	Sent payload size	Outcome
1	2	=< 11 bytes	Received as sent
2	2	> 11 bytes	Nothing received
3	3	=< 53 bytes	Received as sent
4	3	> 53 bytes	Nothing received
5	4	=< 125 bytes	Received as sent
6	4	> 125 bytes	Nothing received
7	5	=< 127 bytes	Received as sent
8	5	127, 128 bytes	Nothing received
9	5	129 bytes	Only first byte received
10	5	>= 130 bytes	AT_TEST_PARAM_OVERFLOW

Tests 1-6 are as expected according to LoRaWAN Regional Parameters v1.0.2 pg 41. Tests 7 - 10, however, are not expected as DR 5 can at most send 242 bytes of data, according to the above.

Hope my findings help. This firmware is much better than v1.2.0 IMO, I hope it can be released officially soon. Thanks!

[tohlh]

Hope my findings help. This firmware is much better than v1.2.0 IMO, I hope it can be released officially soon. Thanks!

UPDATE: I tried sending 242 bytes with AT+SEND at DR5, and it worked, I believe this is due to the AT command length limit. But this payload will only be sent successfully from the third attempt onward.

In fact, I noticed this pattern:

Data Rate	Upload MAC Payload Size (M) (UplinkDwellTime = 1)	Sent 1	Sent 2	Sent 3
2	19	11	M - 11	M - 8
3	61	11	M - 11	M - 8
4	133	11	M - 11	M - 8
5	250	11	M - 11	M - 8

Every time, when I try to send the payload on the first attempt, I am always limited to 11 bytes, regardless of what data rate I am on.

On the second attempt, the limit will always be maximum payload size - 11 bytes.

On the third attempt, the limit will always be maximum payload size - 8 bytes (which is normal).

May I know what could have possibly happened? Thank you.

[facchinm]

Hi @tohlh ,
thanks for testing! I can only answer question 1. since we did not investigate the internals of the firmware yet (it's as much stick to ST reference as possibile).
In fact, we used to change the default DEVEUI to arduino's (arduino/mkrwan1300-fw@f043f68).
Once we finalize the testing phase I think we should restore that commit to avoid needing to reregister the boards.

[CLAassistant]

All committers have signed the CLA.