Application port

[xoseperez]

Sometimes you have different devices reporting to the same application different data. The TTN backend allows you to tell one from the other in the decoder based on the application port the message has been sent to.

The current implementation of the MKRWAN does not allow to set the application port. In the STM32 firmware, it is weirdly handled in the lora_send method as a prefix in the message buffer. But MKRWAN uses the UTX and CTX entry points that bypass that check. This results in a random application port depending on what is on the memory location the appport variable points to.

I have added the option to specify the application port by using SEND entry point in the sendMessage method along with CFM to set the confirmation flag. Sadly, the method bound to SEND in the STM32 firmware (at_Send) does not "follow" the stream as the CTX or UTX do (at_SendV2 or at_SendV2Confirmed) so I have to pass the message as a string and this fails when the buffer has a byte 0.

I have pushed my tentative code here: xoseperez@cb94498 but I think this should be fixed in the STM32 firmware.

[xoseperez]

I have pushed another commit that fixes the previous issue with payloads that contain a \0 avoiding the sendAT method.

I'm sending you a PR since I think this functionality is worth it and it is completely backwards compatible. This might change in the future if the mkrwan1300-fw for STM32 changes.

[facchinm]

Hi @xoseperez,
the UTX and CTX commands were chosen to provide a single library for both our firmware and Murata official one. By taking a look at the Murata specification (the document is still under NDA, sorry) there is a specific command to set the port, outside the SEND function. The command is AT+PORT, I'll implement it in the FW and then in the library by using your PR as a starting point. Thanks a lot!

[facchinm]

I just uploaded a new firmware with Murata-like functionalities, the setPort API was fine so I merged part of your commits too. Thank you for your help!