MKRWAN library 2.0 - call for proposals

[facchinm]

After reviewing the various issues with this library and fw https://github.com/arduino/mkrwan1300-fw I decided it was probably a better idea to investigate with the community about the next steps (before taking a decision from above).

Questions:

• are you happy with the current API set? I'd avoid polluting the library with getters and setters but it looks like everyone have different needs (that the defaults cannot accommodate)
• is compatibility with Murata module still needed?
• is "dumb mode" a useful feature? Can it be shipped as a standalone firmware?
• is runtime band selection a useful features? Could it work if there were like 8 different firmwares, one per band, and the user chooses its own?

If none of these three features is useful, I propose to compile ST stack with default settings for all the different bands, ship the "updaters" in a particular folder, instruct the user to flash its own before doing anything else, rewrite the library to accept ST-style end of line and AT command set.

For reference, the firmware is here, and the commands exposed are

#define AT_RESET      "Z"
#define AT_DEUI       "+DEUI"
#define AT_DADDR      "+DADDR"
#define AT_APPKEY     "+APPKEY"
#define AT_NWKSKEY    "+NWKSKEY"
#define AT_APPSKEY    "+APPSKEY"
#define AT_JOINEUI     "+APPEUI" /*to match with V1.0.x specification- For V1.1.x "+APPEUI" will be replaced by "+JOINEUI"*/
#define AT_ADR        "+ADR"
#define AT_TXP        "+TXP"
#define AT_DR         "+DR"
#define AT_DCS        "+DCS"
#define AT_PNM        "+PNM"
#define AT_RX2FQ      "+RX2FQ"
#define AT_RX2DR      "+RX2DR"
#define AT_RX1DL      "+RX1DL"
#define AT_RX2DL      "+RX2DL"
#define AT_JN1DL      "+JN1DL"
#define AT_JN2DL      "+JN2DL"
#define AT_NJM        "+NJM"
#define AT_NWKID      "+NWKID"
#define AT_CLASS      "+CLASS"
#define AT_JOIN       "+JOIN"
#define AT_NJS        "+NJS"
#define AT_SENDB      "+SENDB"
#define AT_SEND       "+SEND"
#define AT_RECVB      "+RECVB"
#define AT_RECV       "+RECV"
#define AT_VER        "+VER"
#define AT_CFM        "+CFM"
#define AT_CFS        "+CFS"
#define AT_SNR        "+SNR"
#define AT_RSSI       "+RSSI"
#define AT_BAT        "+BAT"
#define AT_TRSSI      "+TRSSI"
#define AT_TTONE      "+TTONE"
#define AT_TTLRA      "+TTLRA"
#define AT_TRLRA      "+TRLRA"
#define AT_TCONF      "+TCONF"
#define AT_TOFF       "+TOFF"
#define AT_CERTIF     "+CERTIF"
#define AT_PGSLOT     "+PGSLOT" 
#define AT_BFREQ      "+BFREQ"
#define AT_BTIME      "+BTIME"
#define AT_BGW        "+BGW" 
#define AT_LTIME      "+LTIME"  

If we decide to follow this direction a bit of help from the community will be needed.

Feel free to express your concerns/suggestions here (a single post each is appreciated 😄 )

@sslupsky @deanpretorius @TechNyquist @giampiero7 @kraef @conradholt @almarion @ldesomer @xoseperez @sabas1080

[sabas1080]

@wero1414

[sslupsky]

I think it would be a better idea to consider following the Semtech stack directly? I think Semtech recently added native support for the ST micro used in the Murata module. Would following the Semtech stack enable more timely updates?

I will give some careful thought to this and post more later.

Thank you for the opportunity to provide some input.

[facchinm]

@sslupsky ST stack is based on the semtech one (https://github.com/Lora-net/LoRaMac-node) with an AT protocol over it.
Version 1.2.2 reports

Implements LoRa Mac from Semtech/StackForce develop branch (17-Jun-2019 commits, 4.4.2 release candidate)
https://github.com/Lora-net/LoRaMac-node/tree/6231a5d65806142a6f887e6183227b8da9e49238

So it is quite up to date

[sslupsky]

@facchinm The ST stack is not on hosted on a public repository. How would we post issues and make PR's for this stack ? Note, 4.4.2 was released Jul 19, 2019. ST stack has not been updated yet.

[sslupsky]

@facchinm ST has a github account which appears to have fairly extensive support for their mcu's. Perhaps they would consider moving the stack to github?

[sslupsky]

I created an issue on the ST overall mcu repo.

STMicroelectronics/STM32Cube_MCU_Overall_Offer#1

[giampiero7]

Hi,
I would just suggest to design the library to give full access to the underlying FW features, and then add utility methods to simplify things. Moreover, there should always be a non-blocking way to do things...

[sslupsky]

@giampiero7 I agree it is preferable to have a non blocking API. This is a problem with the current library especially for low power applications.

What do you mean by "full access to the underlying FW features"? Are you referring to the Semtech stack as the "underlying FW"?

[giampiero7]

Yes

[ruipalma]

I think the murata should ship with the I-CUBE-LRWAN as default as possible.
The I-CUBE-LRWAN as a very nice manual and documentation, and there are a lot of devices in production with this firmware.
I don't know if its possible to put the same amount of effort on a fork of that firmware.
The API should adapt to the original firmware, even with limitations.
One can use the murata with the intended AT commands if needed.
The keyword here is support, and trust to make production devices.

It would be nice to have a reference like this one:
Examples of AT commands on I-CUBE-LRWAN

[sslupsky]

@ruipalma. Unfortunately the ST library is not yet hosted in a public repo and that is a big problem if we want to contribute.

[ruipalma]

AFAIK the CMWX1ZZABZ+LoraWan stack is certified by the LoraWan Alliance:
"Compliant with the LoRa Alliance™ specification protocol, named LoRaWAN® version V1.0.3 March 2018"

CMWX1ZZABZ-078

We don't have a public rep, but it's open source, so it's possible to change the source as needed.

The current rep, have a low contributing rate. And it's understandable, the LoraWan stack it's a complex stack, and it requires a lot of programming effort.

The CMWX1ZZABZ have only one job on the mkrwan1300. To do the LoraWan communications, and do it well, if its good enough to the LoraWan Alliance it should be good for us.