Currently lora stack will automatically send an empty uplink message to lora gateway in case of:
- Node received message with pending bit set.
- Node received MAC command which requires instant response (sticky MAC command)
- Node received confirmed message in class C mode
This commit makes this configurable via config item
"automatic-uplink-message": {
"help": "In case of pending bit, class c confirmed message or sticky MAC command, stack will automatically send empty uplink message",
"value": true
}
Default value is true. If sending an empty message fails, stack will send event AUTOMATIC_UPLINK_ERROR application.
If automatic uplink sending is disabled, stack will send application UPLINK_REQUIRED -event to indicate
application should issue a new uplink to gateway as soon as possible.
Any data structure used in LoRaWANBase class should be available
in a separate header in order to make the code easy to port and
easy to read as the developer doesn't need to know about all the
internal data structures being used in Mbed LoRaWAN stack.
Bug was reported by @tpet93 and it was correctly diagnosed that channels
were not being set in the phy_params structure. This commit fixes the bug
and sets up channels correctly.
This is a fix for issue #6389.
Currently when application receives RX_DONE event from stack, it has to provide the correct port
value to receive method in order to read the received message. The problem is that current
API does not provide any way to know in to which port message was received.
This commit introduces a new receive() method, which instead of checking these values, will return
them to application.
Fix compilation of compilance test and at the same time refactor compliance
test handler. Renamed mcps_request as test_request as it is only used for
compliance test. Also fixed a bug with null buffer in send_compliance_test_frame_to_mac.
- This is internal change, no functionality has been changed
- LoRaWanInterface cleaned up and code moved to LoRaMacStack
- Compliance code in LoRaMacStack moved to EOF
- Green tea tests have been run manually
- Doxygen updated accordingly
LoRA: reorder class members
This API can be used to runtime change device class.
Please note that only class A and C are supported at the moment.
Trying to set class B will return LORAWAN_STATUS_UNSUPPORTED.
Fix set_device_class documentation
fix documentation
1. Do not stop the 2nd window timer, as it is not running.
2. Wait for the OnAckTimeout event, before setting MacDone
3. Process for class c also the 2nd window timeout part, as we do
not have a 2nd window timer.
Removed the while loop checking the return value from set_next_channel
(GitHub Issue https://github.com/Lora-net/LoRaMac-node/issues/357)
The new return values are:
LORAWAN_STATUS_OK : A channel has been found.
LORAWAN_STATUS_NO_FREE_CHANNEL_FOUND : No free channel has been found (AS923 and KR920 regions)
LORAWAN_STATUS_DUTYCYCLE_RESTRICTED : No channel found due to the duty-cycle or JoinReq back-off restrictions. Trial must be delayed.
LORAWAN_STATUS_NO_CHANNEL_FOUND : No channel has been found. Re-enabled the default channels.
- Internal changes only
- reset function is created to LoRaPHY to reset LoRaMAC parameters with default values
- Doxygen updates for newly created functions
- This is internal logic only and there are no functionality changes
- Some compliance test stuff have been moved to end of files
- Some internal data structures removed as useless after refactor
- get_phy_params function was very heavy weight and needed to be refactored.
- switch-case clauses have been refactored to be functions now and the complexity of the usage has been improved a lot.
- There are no functional changes, this is internal only change