Hello: I would like to propose some changes to the lora api and I want to see if folks had any comments or issues with the following proposal.
The basic issue is the ability to set the transmission data rate on a per port basis. This presents some complications in the code which seem to be unncessary. Consider the following API: lora_app_port_cfg(uint8_t port, uint8_t datarate, uint8_t retries). The main reason for having this API was to allow the developer to set the data rate and retries for the message being sent. This came from the reference code and the ability to set the retries and data rate in the McpsRequest API. Looking at the code in more detail, I have come to the conclusion that the McpsRequest should not contain the data rate. Not quite sure about the retries but certainly not the data rate. Here are my reasons: 1) If ADR is turned on (Data Rate Adaptation) setting the data rate in the port has no effect. The code must then handle this properly. Not tricky and adds very little extra code but is something that has to be dealt with nonetheless. 2) The data rate set in the original McpsRequest is not necessarily the data rate at which the frame will be sent if there are retries and the frame is confirmed. The lorawan stack will automatically lower the data rate when confirmed frames are sent and not acknowledged. While this is not mandatory in the specification, they strongly urge implementations to lower the data rate after 2 failed confirmed attempts. While I do think the lorawan spec approach leaves something to be desired and is an area where improvements can be made, the main point here is the behavior of the lora stack. The developer sends a confirmed frame on a port and that port uses data rate X. There are failures and the data rate gets lowered to Y. The specification says that future transmissions should start at Y but the current code will set all new McpsRequests to the data rate specified in the port. 3) Generally, I do not think the application developer is going to want to mess with the data rate at all. If they do, there is a way to do this that makes more sense with the current implementation and that is to simply set the MIB element MIB_CHANNELS_DATARATE. While this will still change if confirmed frames fail, the application developer can change the data rate used whenever they want and the code becomes less complicated. 4) Setting the data rate on a per-port basis is just overkill. I cannot imagine the application wanting to change the data rate on a per port basis. Specific code changes based on this proposal: 1) Remove the data rate from the Mcps Request structure 2) Remove the data rate from the port structure. As always, comments/suggestions/thoughts always welcome. Thanks! PS I think a similar case can be made for specifying retries. I am going to investigate that a bit more and if folks are fine with the current proposal, retries will probably go away as well.
