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 :smile: )

@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.

https://github.com/STMicroelectronics/STM32Cube_MCU_Overall_Offer/issues/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.

[sslupsky]

Just to clarify, the ST stack is built on the Semtech stack. The Semtech stack is hosted publicly. The ST stack is not.

To my knowledge, there isn’t a way to contribute or post issues. This is a problem. I have identified defects in the ST stack and have no way to address these with the developers.

Moreover, I believe Semtech now has direct support within the stack for the MCU used in the Murata module.

[ReiniervdL]

I would like to request a feature to set the 8 channel frequencies used by The Things Network for the 915 MHz USA version. So far I have not seen a working solution for MKR1300 and new MKR1310. With other LoRa modules I can use AT commands to alter the channel frequencies and connect successfully.

US902-928 Used in USA, Canada and South America

Uplink:

903.9 - SF7BW125 to SF10BW125 904.1 - SF7BW125 to SF10BW125 904.3 - SF7BW125 to SF10BW125 904.5 - SF7BW125 to SF10BW125 904.7 - SF7BW125 to SF10BW125 904.9 - SF7BW125 to SF10BW125 905.1 - SF7BW125 to SF10BW125 905.3 - SF7BW125 to SF10BW125 904.6 - SF8BW500 Downlink:

923.3 - SF7BW500 to SF12BW500 923.9 - SF7BW500 to SF12BW500 924.5 - SF7BW500 to SF12BW500 925.1 - SF7BW500 to SF12BW500 925.7 - SF7BW500 to SF12BW500 926.3 - SF7BW500 to SF12BW500 926.9 - SF7BW500 to SF12BW500 927.5 - SF7BW500 to SF12BW500

[mjunior-fitec]

Sorry reaching here late... Anyway, I would like to let my proposal. As I already posted here: https://github.com/arduino/mkrwan1300-fw/issues/17 I really miss commands to use the Multicast and to read/write the channel mask, just like the Murata's AT+CHMASK and AT+MCAST. Just to reinforce, without the channel mask commands I just can't save/restore a LoRa session in the AU915 band, demanding a JoinOTAA on every wake up.

Also, in order to make a reliable device I had to rewrite the joinOTAA function, because it doesn't returns error that might happen and in some cases the modem got stuck in a state that it doesn't send anything on RF and need to be reset. In my implementation I just run a loop with a timeout and if the modem doesn't change the Join Status (AT+NJS), I reset the modem and start the Join process (AT+JOIN) again. This is far from perfect but, at least is minimally reliable.

Another very important improvement would be to have those features as non-blocking. When we go to an almost professional development, callling those blocking functions can do big damage.

[sslupsky]

@mjunior-fitec Have a look at this PR https://github.com/arduino-libraries/MKRWAN/pull/66 and let me know what you think.

It addresses some of the blocking issues.

[mjunior-fitec]

@sslupsky, I just take a quick look and it sounds very interesting, so far. Currently, I have a problem using the modemSend() with confirmation. I can see that many times the ACK package is sent by the Network Server, but the function doesn’t return correctly. Can you tell me how does this getCFS() works? I mean, is it possible to how if a specific packet was acknowledged?

Regards, Marcio Jr.

[sslupsky]

@mjunior-fitec I posted some additional details with the PR so as not to clutter this issue.

[sslupsky]

A few other items come to mind regarding the 2.0 stack:

FUOTA Clock Synchronization A branch that incorporates the development branch (currently v5) of the Semtech stack

[sslupsky]

See also my comments in this issue: https://github.com/arduino-libraries/MKRWAN/issues/69

I suggest this long standing bug needs to be addressed in library 2.0.

[remuslazar]

I do fully agree with your proposal, @facchinm to drop the three features mentioned and move the MKRWAN firmware closer to the official ST stack, as @ruipalma already elaborated. This will also lower the maintenance costs and speedup things. Keeping up with the latest ST stack release will be easier, maybe something which could be even fully automated with some CI.

I also don't think the murata compatibility is a big issue. The average Arduino user will just use the MKRWAN Library and will not care about anything else - if it works.. :)

[sslupsky]

Another consideration comes to mind. Careful thought should be given to supporting FUOTA. So, this suggests that both the SAMD21 and the module must be able to access the flash. Moreover, either the SAMD21 or the module can be an SPI master when accessing the flash.

So, during a FUOTA session, the module should write a SAMD21 firmware update payload and a module firmware update payload to separate images/partitions in the flash. After the firmware update is uploaded, the module and the SAMD21 should access their respective firmware image/partition within the flash and perform an update accordingly.

[ghost]

is "dumb mode" a useful feature? Can it be shipped as a standalone firmware?

If "dumb mode" means a mode, where one can address the SX12xx modem directly, yes please!

[facchinm]

@gom-dot-sh it has some limitations but yes, it's exactly what it does (in current firmware it can be used in conjunction with https://github.com/sandeepmistry/arduino-LoRa).

[remuslazar]

@facchinm any update on that?

[facchinm]

@remuslazar we released MKRWAN_v2 to allow broader testing , but it's still in beta phase and not ready to phase out this one.

[remuslazar]

@facchinm thank you for your feedback! I was not aware about the v2 release, I will try this out, cool!

[remuslazar]

@facchinm what is the status of https://github.com/arduino-libraries/MKRWAN_v2? Still beta or ready for production use? AFAIKS there are no major issues and also the "official" Arduino documentation says that both libraries can be used interchangeably.

I have also tried the _v2 release, no problems so far - unfortunately it does not solve some existing issues using the LowPower library (see https://github.com/arduino-libraries/MKRWAN_v2/issues/24)