ARMmbed
/
mbed-os
mirror of https://github.com/ARMmbed/mbed-os.git
1
0
Fork 0
Code Issues Projects Releases Wiki Activity
mbed-os/features/lorawan/LoRaWANStack.cpp

1076 lines
38 KiB
C++
Raw Normal View History

Adding LoRaWANStack class to control MAC and PHY LoRaWANStack class is our controller layer on top of our current MAC and PHY layer. It provides services to an implementation of LoRaWANBase class. It is a singleton class owing to the fact that the mac layer underneath is not a class object. Instead, it uses the MAC via setting mib, mlme, mcps requests and getting responses back from the mac layer using confirmations and indications. In essense this class is a special handle for mac layer underneath which is predominantly reference design based. In future we may refactor the LoRaMac.cpp code to make it object oriented and cleaner. At one end, it binds the application selected radio driver with the PHY layer and at the other end it provides services to upper layers handling the mac via well defined APIs. For proper selection of a PHY layer, user must use Mbed config system. For this purpose an mbed_lib.json is provided which can be overriden by the user defined mbed_app.json. By default the EU868 band is selected as a PHY layer. User must set relevant keys for the selected connection mechanism.
2017-11-27 13:17:18 +00:00
/**
/ _____) _ | |
( (____ _____ ____ _| |_ _____ ____| |__
\____ \| ___ | (_ _) ___ |/ ___) _ \
_____) ) ____| | | || |_| ____( (___| | | |
(______/|_____)_|_|_| \__)_____)\____)_| |_|
(C)2013 Semtech
___ _____ _ ___ _ _____ ___ ___ ___ ___
/ __|_ _/_\ / __| |/ / __/ _ \| _ \/ __| __|
\__ \ | |/ _ \ (__| ' <| _| (_) | / (__| _|
|___/ |_/_/ \_\___|_|\_\_| \___/|_|_\\___|___|
embedded.connectivity.solutions===============
Description: LoRaWAN stack layer that controls both MAC and PHY underneath
License: Revised BSD License, see LICENSE.TXT file include in the project
Maintainer: Miguel Luis ( Semtech ), Gregory Cristian ( Semtech ) and Daniel Jaeckle ( STACKFORCE )
Copyright (c) 2017, Arm Limited and affiliates.
SPDX-License-Identifier: BSD-3-Clause
*/
#include <string.h>
#include <stdlib.h>
#include "platform/Callback.h"
[IOTCELL-279] Using Application provided EventQueue The EventQueue thread in LoRaMac.cpp is disbanded and the LoRaWAN protocol is redesigned to store a pointer for an application provided EventQueue. It means that now the stack runs in the same thread as application. Application provided EventQueue is used to defer ISRs from radio driver and timer callbacks as well as the application events are queued to the same event loop.
2017-12-11 10:20:11 +00:00
#include "events/EventQueue.h"
Adding LoRaWANStack class to control MAC and PHY LoRaWANStack class is our controller layer on top of our current MAC and PHY layer. It provides services to an implementation of LoRaWANBase class. It is a singleton class owing to the fact that the mac layer underneath is not a class object. Instead, it uses the MAC via setting mib, mlme, mcps requests and getting responses back from the mac layer using confirmations and indications. In essense this class is a special handle for mac layer underneath which is predominantly reference design based. In future we may refactor the LoRaMac.cpp code to make it object oriented and cleaner. At one end, it binds the application selected radio driver with the PHY layer and at the other end it provides services to upper layers handling the mac via well defined APIs. For proper selection of a PHY layer, user must use Mbed config system. For this purpose an mbed_lib.json is provided which can be overriden by the user defined mbed_app.json. By default the EU868 band is selected as a PHY layer. User must set relevant keys for the selected connection mechanism.
2017-11-27 13:17:18 +00:00
#include "lorawan/LoRaWANStack.h"
#if defined(FEATURE_COMMON_PAL)
#include "mbed_trace.h"
#define TRACE_GROUP "LSTK"
#else
#define tr_debug(...) (void(0)) //dummies if feature common pal is not added
#define tr_info(...) (void(0)) //dummies if feature common pal is not added
#define tr_error(...) (void(0)) //dummies if feature common pal is not added
#define tr_warn(...) (void(0)) //dummies if feature common pal is not added
#endif //defined(FEATURE_COMMON_PAL)
#define INVALID_PORT 0xFF
#define MAX_CONFIRMED_MSG_RETRIES 255
using namespace mbed;
[IOTCELL-279] Using Application provided EventQueue The EventQueue thread in LoRaMac.cpp is disbanded and the LoRaWAN protocol is redesigned to store a pointer for an application provided EventQueue. It means that now the stack runs in the same thread as application. Application provided EventQueue is used to defer ISRs from radio driver and timer callbacks as well as the application events are queued to the same event loop.
2017-12-11 10:20:11 +00:00
using namespace events;
Adding LoRaWANStack class to control MAC and PHY LoRaWANStack class is our controller layer on top of our current MAC and PHY layer. It provides services to an implementation of LoRaWANBase class. It is a singleton class owing to the fact that the mac layer underneath is not a class object. Instead, it uses the MAC via setting mib, mlme, mcps requests and getting responses back from the mac layer using confirmations and indications. In essense this class is a special handle for mac layer underneath which is predominantly reference design based. In future we may refactor the LoRaMac.cpp code to make it object oriented and cleaner. At one end, it binds the application selected radio driver with the PHY layer and at the other end it provides services to upper layers handling the mac via well defined APIs. For proper selection of a PHY layer, user must use Mbed config system. For this purpose an mbed_lib.json is provided which can be overriden by the user defined mbed_app.json. By default the EU868 band is selected as a PHY layer. User must set relevant keys for the selected connection mechanism.
2017-11-27 13:17:18 +00:00
Move all compliance test code inside compilation flag All compliance test related codes are now inside LORAWAN_COMPLIANCE_TEST build flag. This will reduce memory usage in when compliance test codes are not needed.
2018-01-05 10:13:48 +00:00
#if defined(LORAWAN_COMPLIANCE_TEST)
#if (MBED_CONF_LORA_PHY == 0 || MBED_CONF_LORA_PHY == 4 || MBED_CONF_LORA_PHY == 6 || MBED_CONF_LORA_PHY == 7)
#define LORAWAN_COMPLIANCE_TEST_DATA_SIZE 16
#elif (MBED_CONF_LORA_PHY == 1 || MBED_CONF_LORA_PHY == 2 || MBED_CONF_LORA_PHY == 8 || MBED_CONF_LORA_PHY == 9)
#define LORAWAN_COMPLIANCE_TEST_DATA_SIZE 11
#else
#error "Must set LoRa PHY layer parameters."
#endif
Adding LoRaWANStack class to control MAC and PHY LoRaWANStack class is our controller layer on top of our current MAC and PHY layer. It provides services to an implementation of LoRaWANBase class. It is a singleton class owing to the fact that the mac layer underneath is not a class object. Instead, it uses the MAC via setting mib, mlme, mcps requests and getting responses back from the mac layer using confirmations and indications. In essense this class is a special handle for mac layer underneath which is predominantly reference design based. In future we may refactor the LoRaMac.cpp code to make it object oriented and cleaner. At one end, it binds the application selected radio driver with the PHY layer and at the other end it provides services to upper layers handling the mac via well defined APIs. For proper selection of a PHY layer, user must use Mbed config system. For this purpose an mbed_lib.json is provided which can be overriden by the user defined mbed_app.json. By default the EU868 band is selected as a PHY layer. User must set relevant keys for the selected connection mechanism.
2017-11-27 13:17:18 +00:00
#endif
/*****************************************************************************
* Private Member Functions *
****************************************************************************/
bool LoRaWANStack::is_port_valid(uint8_t port)
{
//Application should not use reserved and illegal port numbers.
if (port >= 224 || port == 0) {
return false;
} else {
return true;
}
}
[IOTCELL-282] Code cleanup/simplification and rules Baseline is changed to use a single set of data structures that simplifies the code in the LoRaWANStack and Mac layer. We are now following certian rules for naming data structures. - All structures visible outside their domain are prefixed as 'lorawan_' - All mac structures are prefixed as 'loramac_' - All subsystem or module strucutures carry their name in prefix, like 'mcps_' PHY layer still have legacy camel case data structures which will be entertained later while we will be simplifying PHY layer. Test cases are also updated with the new data structure naming conventions. One major difference from the previous baseline is the removal of static buffer from mcps indication. And we do not copy data from stack buffer to rx_msg buffer. This saves at least 512 bytes. It may look like now that if we have received something but the user have not read from the buffer, then the buffer will be overwritten and we will lose previous frame. Yes, we will. But the same will happen even if we would have copied the buffer into rx_msg because then the rx_msg gets overwritten. So we decide to abandon copying the buffer at multiple locations. We inform the user about reception, if the user doesn't read and the data gets overwritten, then so be it.
2018-01-12 14:39:31 +00:00
lorawan_status_t LoRaWANStack::set_application_port(uint8_t port)
Adding LoRaWANStack class to control MAC and PHY LoRaWANStack class is our controller layer on top of our current MAC and PHY layer. It provides services to an implementation of LoRaWANBase class. It is a singleton class owing to the fact that the mac layer underneath is not a class object. Instead, it uses the MAC via setting mib, mlme, mcps requests and getting responses back from the mac layer using confirmations and indications. In essense this class is a special handle for mac layer underneath which is predominantly reference design based. In future we may refactor the LoRaMac.cpp code to make it object oriented and cleaner. At one end, it binds the application selected radio driver with the PHY layer and at the other end it provides services to upper layers handling the mac via well defined APIs. For proper selection of a PHY layer, user must use Mbed config system. For this purpose an mbed_lib.json is provided which can be overriden by the user defined mbed_app.json. By default the EU868 band is selected as a PHY layer. User must set relevant keys for the selected connection mechanism.
2017-11-27 13:17:18 +00:00
{
if (is_port_valid(port)) {
_app_port = port;
[IOTCELL-282] Code cleanup/simplification and rules Baseline is changed to use a single set of data structures that simplifies the code in the LoRaWANStack and Mac layer. We are now following certian rules for naming data structures. - All structures visible outside their domain are prefixed as 'lorawan_' - All mac structures are prefixed as 'loramac_' - All subsystem or module strucutures carry their name in prefix, like 'mcps_' PHY layer still have legacy camel case data structures which will be entertained later while we will be simplifying PHY layer. Test cases are also updated with the new data structure naming conventions. One major difference from the previous baseline is the removal of static buffer from mcps indication. And we do not copy data from stack buffer to rx_msg buffer. This saves at least 512 bytes. It may look like now that if we have received something but the user have not read from the buffer, then the buffer will be overwritten and we will lose previous frame. Yes, we will. But the same will happen even if we would have copied the buffer into rx_msg because then the rx_msg gets overwritten. So we decide to abandon copying the buffer at multiple locations. We inform the user about reception, if the user doesn't read and the data gets overwritten, then so be it.
2018-01-12 14:39:31 +00:00
return LORAWAN_STATUS_OK;
Adding LoRaWANStack class to control MAC and PHY LoRaWANStack class is our controller layer on top of our current MAC and PHY layer. It provides services to an implementation of LoRaWANBase class. It is a singleton class owing to the fact that the mac layer underneath is not a class object. Instead, it uses the MAC via setting mib, mlme, mcps requests and getting responses back from the mac layer using confirmations and indications. In essense this class is a special handle for mac layer underneath which is predominantly reference design based. In future we may refactor the LoRaMac.cpp code to make it object oriented and cleaner. At one end, it binds the application selected radio driver with the PHY layer and at the other end it provides services to upper layers handling the mac via well defined APIs. For proper selection of a PHY layer, user must use Mbed config system. For this purpose an mbed_lib.json is provided which can be overriden by the user defined mbed_app.json. By default the EU868 band is selected as a PHY layer. User must set relevant keys for the selected connection mechanism.
2017-11-27 13:17:18 +00:00
}
[IOTCELL-282] Code cleanup/simplification and rules Baseline is changed to use a single set of data structures that simplifies the code in the LoRaWANStack and Mac layer. We are now following certian rules for naming data structures. - All structures visible outside their domain are prefixed as 'lorawan_' - All mac structures are prefixed as 'loramac_' - All subsystem or module strucutures carry their name in prefix, like 'mcps_' PHY layer still have legacy camel case data structures which will be entertained later while we will be simplifying PHY layer. Test cases are also updated with the new data structure naming conventions. One major difference from the previous baseline is the removal of static buffer from mcps indication. And we do not copy data from stack buffer to rx_msg buffer. This saves at least 512 bytes. It may look like now that if we have received something but the user have not read from the buffer, then the buffer will be overwritten and we will lose previous frame. Yes, we will. But the same will happen even if we would have copied the buffer into rx_msg because then the rx_msg gets overwritten. So we decide to abandon copying the buffer at multiple locations. We inform the user about reception, if the user doesn't read and the data gets overwritten, then so be it.
2018-01-12 14:39:31 +00:00
return LORAWAN_STATUS_PORT_INVALID;
Adding LoRaWANStack class to control MAC and PHY LoRaWANStack class is our controller layer on top of our current MAC and PHY layer. It provides services to an implementation of LoRaWANBase class. It is a singleton class owing to the fact that the mac layer underneath is not a class object. Instead, it uses the MAC via setting mib, mlme, mcps requests and getting responses back from the mac layer using confirmations and indications. In essense this class is a special handle for mac layer underneath which is predominantly reference design based. In future we may refactor the LoRaMac.cpp code to make it object oriented and cleaner. At one end, it binds the application selected radio driver with the PHY layer and at the other end it provides services to upper layers handling the mac via well defined APIs. For proper selection of a PHY layer, user must use Mbed config system. For this purpose an mbed_lib.json is provided which can be overriden by the user defined mbed_app.json. By default the EU868 band is selected as a PHY layer. User must set relevant keys for the selected connection mechanism.
2017-11-27 13:17:18 +00:00
}
/*****************************************************************************
* Constructor and destructor *
****************************************************************************/
LoRaWANStack::LoRaWANStack()
LoRa: LoRaWANInterface refactored. - Only internal changes, no functionality changes - Some minor improvements to LoRaWanStack
2018-03-12 11:30:00 +00:00
: _loramac(),
_device_current_state(DEVICE_STATE_NOT_INITIALIZED), _num_retry(1),
_app_port(INVALID_PORT), _link_check_requested(false), _queue(NULL)
Adding LoRaWANStack class to control MAC and PHY LoRaWANStack class is our controller layer on top of our current MAC and PHY layer. It provides services to an implementation of LoRaWANBase class. It is a singleton class owing to the fact that the mac layer underneath is not a class object. Instead, it uses the MAC via setting mib, mlme, mcps requests and getting responses back from the mac layer using confirmations and indications. In essense this class is a special handle for mac layer underneath which is predominantly reference design based. In future we may refactor the LoRaMac.cpp code to make it object oriented and cleaner. At one end, it binds the application selected radio driver with the PHY layer and at the other end it provides services to upper layers handling the mac via well defined APIs. For proper selection of a PHY layer, user must use Mbed config system. For this purpose an mbed_lib.json is provided which can be overriden by the user defined mbed_app.json. By default the EU868 band is selected as a PHY layer. User must set relevant keys for the selected connection mechanism.
2017-11-27 13:17:18 +00:00
{
#ifdef MBED_CONF_LORA_APP_PORT
if (is_port_valid(MBED_CONF_LORA_APP_PORT)) {
_app_port = MBED_CONF_LORA_APP_PORT;
} else {
tr_error("User defined port in .json is illegal.");
}
#endif
memset(&_lw_session, 0, sizeof(_lw_session));
memset(&_rx_msg, 0, sizeof(_rx_msg));
Improve error handling & robustness This commit also introduces API change for disconnect(). disconnect() will now return LORAWAN_STATUS_DEVICE_OFF for successfull disconnect. * LoRaWANStack::handle_tx() can be called with NULL buffer when length is 0. This commit fixes the case where user has provided NULL buffer and length is > max_possible_size. handle_tx() now always returns LORAWAN_STATUS_PARAMETER_INVALID if given buffer is NULL pointer and length > 0. General error checking is added and some asserts are added for events.
2018-02-09 07:59:15 +00:00
LoRaMacPrimitives.mcps_confirm = callback(this, &LoRaWANStack::mcps_confirm_handler);
LoRaMacPrimitives.mcps_indication = callback(this, &LoRaWANStack::mcps_indication_handler);
LoRaMacPrimitives.mlme_confirm = callback(this, &LoRaWANStack::mlme_confirm_handler);
LoRaMacPrimitives.mlme_indication = callback(this, &LoRaWANStack::mlme_indication_handler);
Adding LoRaWANStack class to control MAC and PHY LoRaWANStack class is our controller layer on top of our current MAC and PHY layer. It provides services to an implementation of LoRaWANBase class. It is a singleton class owing to the fact that the mac layer underneath is not a class object. Instead, it uses the MAC via setting mib, mlme, mcps requests and getting responses back from the mac layer using confirmations and indications. In essense this class is a special handle for mac layer underneath which is predominantly reference design based. In future we may refactor the LoRaMac.cpp code to make it object oriented and cleaner. At one end, it binds the application selected radio driver with the PHY layer and at the other end it provides services to upper layers handling the mac via well defined APIs. For proper selection of a PHY layer, user must use Mbed config system. For this purpose an mbed_lib.json is provided which can be overriden by the user defined mbed_app.json. By default the EU868 band is selected as a PHY layer. User must set relevant keys for the selected connection mechanism.
2017-11-27 13:17:18 +00:00
}
LoRaWANStack::~LoRaWANStack()
{
}
/*****************************************************************************
* Public member functions *
****************************************************************************/
LoRaWANStack& LoRaWANStack::get_lorawan_stack()
{
static LoRaWANStack _lw_stack;
return _lw_stack;
}
LoRa: LoRaWANInterface refactored. - Only internal changes, no functionality changes - Some minor improvements to LoRaWanStack
2018-03-12 11:30:00 +00:00
void LoRaWANStack::bind_radio_driver(LoRaRadio& radio)
Adding LoRaWANStack class to control MAC and PHY LoRaWANStack class is our controller layer on top of our current MAC and PHY layer. It provides services to an implementation of LoRaWANBase class. It is a singleton class owing to the fact that the mac layer underneath is not a class object. Instead, it uses the MAC via setting mib, mlme, mcps requests and getting responses back from the mac layer using confirmations and indications. In essense this class is a special handle for mac layer underneath which is predominantly reference design based. In future we may refactor the LoRaMac.cpp code to make it object oriented and cleaner. At one end, it binds the application selected radio driver with the PHY layer and at the other end it provides services to upper layers handling the mac via well defined APIs. For proper selection of a PHY layer, user must use Mbed config system. For this purpose an mbed_lib.json is provided which can be overriden by the user defined mbed_app.json. By default the EU868 band is selected as a PHY layer. User must set relevant keys for the selected connection mechanism.
2017-11-27 13:17:18 +00:00
{
LoRa: LoRaPHY dependency removed from LoRaMacStack - 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
2018-03-15 08:43:31 +00:00
_loramac.bind_radio_driver(radio);
LoRa: LoRaWANInterface refactored. - Only internal changes, no functionality changes - Some minor improvements to LoRaWanStack
2018-03-12 11:30:00 +00:00
}
lorawan_status_t LoRaWANStack::connect()
{
// connection attempt without parameters.
// System tries to look for configuration in mbed_lib.json that can be
// overridden by mbed_app.json. However, if none of the json files are
// available (highly unlikely), we still fallback to some default parameters.
// Check lorawan_data_structure for fallback defaults.
lorawan_connect_t connection_params;
LoRaWANStack is made independent of MAC sublayers - Only internal changes, no API has been broke. - Tested by manually running Green tea tests
2018-03-16 11:12:50 +00:00
//TODO: LoRaWANStack don't need to know these values, move to LoRaMac (or below)
#if (1 == MBED_CONF_LORA_OVER_THE_AIR_ACTIVATION)
static uint8_t dev_eui[] = MBED_CONF_LORA_DEVICE_EUI;
static uint8_t app_eui[] = MBED_CONF_LORA_APPLICATION_EUI;
static uint8_t app_key[] = MBED_CONF_LORA_APPLICATION_KEY;
connection_params.connect_type = LORAWAN_CONNECTION_OTAA;
connection_params.connection_u.otaa.app_eui = app_eui;
connection_params.connection_u.otaa.dev_eui = dev_eui;
connection_params.connection_u.otaa.app_key = app_key;
connection_params.connection_u.otaa.nb_trials = MBED_CONF_LORA_NB_TRIALS;
return join_request_by_otaa(connection_params);
#else
static uint8_t nwk_skey[] = MBED_CONF_LORA_NWKSKEY;
static uint8_t app_skey[] = MBED_CONF_LORA_APPSKEY;
static uint32_t dev_addr = MBED_CONF_LORA_DEVICE_ADDRESS;
static uint32_t nwk_id = (MBED_CONF_LORA_DEVICE_ADDRESS & LORAWAN_NETWORK_ID_MASK);
connection_params.connect_type = LORAWAN_CONNECTION_ABP;
connection_params.connection_u.abp.nwk_id = nwk_id;
connection_params.connection_u.abp.dev_addr = dev_addr;
connection_params.connection_u.abp.nwk_skey = nwk_skey;
connection_params.connection_u.abp.app_skey = app_skey;
return activation_by_personalization(connection_params);
#endif
LoRa: LoRaWANInterface refactored. - Only internal changes, no functionality changes - Some minor improvements to LoRaWanStack
2018-03-12 11:30:00 +00:00
}
lorawan_status_t LoRaWANStack::connect(const lorawan_connect_t &connect)
{
lorawan_status_t mac_status;
if (connect.connect_type == LORAWAN_CONNECTION_OTAA) {
mac_status = join_request_by_otaa(connect);
} else if (connect.connect_type == LORAWAN_CONNECTION_ABP) {
mac_status = activation_by_personalization(connect);
} else {
return LORAWAN_STATUS_PARAMETER_INVALID;
}
return mac_status;
Adding LoRaWANStack class to control MAC and PHY LoRaWANStack class is our controller layer on top of our current MAC and PHY layer. It provides services to an implementation of LoRaWANBase class. It is a singleton class owing to the fact that the mac layer underneath is not a class object. Instead, it uses the MAC via setting mib, mlme, mcps requests and getting responses back from the mac layer using confirmations and indications. In essense this class is a special handle for mac layer underneath which is predominantly reference design based. In future we may refactor the LoRaMac.cpp code to make it object oriented and cleaner. At one end, it binds the application selected radio driver with the PHY layer and at the other end it provides services to upper layers handling the mac via well defined APIs. For proper selection of a PHY layer, user must use Mbed config system. For this purpose an mbed_lib.json is provided which can be overriden by the user defined mbed_app.json. By default the EU868 band is selected as a PHY layer. User must set relevant keys for the selected connection mechanism.
2017-11-27 13:17:18 +00:00
}
Improve error handling & robustness This commit also introduces API change for disconnect(). disconnect() will now return LORAWAN_STATUS_DEVICE_OFF for successfull disconnect. * LoRaWANStack::handle_tx() can be called with NULL buffer when length is 0. This commit fixes the case where user has provided NULL buffer and length is > max_possible_size. handle_tx() now always returns LORAWAN_STATUS_PARAMETER_INVALID if given buffer is NULL pointer and length > 0. General error checking is added and some asserts are added for events.
2018-02-09 07:59:15 +00:00
[IOTCELL-282] Code cleanup/simplification and rules Baseline is changed to use a single set of data structures that simplifies the code in the LoRaWANStack and Mac layer. We are now following certian rules for naming data structures. - All structures visible outside their domain are prefixed as 'lorawan_' - All mac structures are prefixed as 'loramac_' - All subsystem or module strucutures carry their name in prefix, like 'mcps_' PHY layer still have legacy camel case data structures which will be entertained later while we will be simplifying PHY layer. Test cases are also updated with the new data structure naming conventions. One major difference from the previous baseline is the removal of static buffer from mcps indication. And we do not copy data from stack buffer to rx_msg buffer. This saves at least 512 bytes. It may look like now that if we have received something but the user have not read from the buffer, then the buffer will be overwritten and we will lose previous frame. Yes, we will. But the same will happen even if we would have copied the buffer into rx_msg because then the rx_msg gets overwritten. So we decide to abandon copying the buffer at multiple locations. We inform the user about reception, if the user doesn't read and the data gets overwritten, then so be it.
2018-01-12 14:39:31 +00:00
lorawan_status_t LoRaWANStack::initialize_mac_layer(EventQueue *queue)
Adding LoRaWANStack class to control MAC and PHY LoRaWANStack class is our controller layer on top of our current MAC and PHY layer. It provides services to an implementation of LoRaWANBase class. It is a singleton class owing to the fact that the mac layer underneath is not a class object. Instead, it uses the MAC via setting mib, mlme, mcps requests and getting responses back from the mac layer using confirmations and indications. In essense this class is a special handle for mac layer underneath which is predominantly reference design based. In future we may refactor the LoRaMac.cpp code to make it object oriented and cleaner. At one end, it binds the application selected radio driver with the PHY layer and at the other end it provides services to upper layers handling the mac via well defined APIs. For proper selection of a PHY layer, user must use Mbed config system. For this purpose an mbed_lib.json is provided which can be overriden by the user defined mbed_app.json. By default the EU868 band is selected as a PHY layer. User must set relevant keys for the selected connection mechanism.
2017-11-27 13:17:18 +00:00
{
LoRa: LoRaWANInterface refactored. - Only internal changes, no functionality changes - Some minor improvements to LoRaWanStack
2018-03-12 11:30:00 +00:00
if(!queue) {
return LORAWAN_STATUS_PARAMETER_INVALID;
}
Adding LoRaWANStack class to control MAC and PHY LoRaWANStack class is our controller layer on top of our current MAC and PHY layer. It provides services to an implementation of LoRaWANBase class. It is a singleton class owing to the fact that the mac layer underneath is not a class object. Instead, it uses the MAC via setting mib, mlme, mcps requests and getting responses back from the mac layer using confirmations and indications. In essense this class is a special handle for mac layer underneath which is predominantly reference design based. In future we may refactor the LoRaMac.cpp code to make it object oriented and cleaner. At one end, it binds the application selected radio driver with the PHY layer and at the other end it provides services to upper layers handling the mac via well defined APIs. For proper selection of a PHY layer, user must use Mbed config system. For this purpose an mbed_lib.json is provided which can be overriden by the user defined mbed_app.json. By default the EU868 band is selected as a PHY layer. User must set relevant keys for the selected connection mechanism.
2017-11-27 13:17:18 +00:00
if (DEVICE_STATE_NOT_INITIALIZED != _device_current_state)
{
tr_debug("Initialized already");
[IOTCELL-282] Code cleanup/simplification and rules Baseline is changed to use a single set of data structures that simplifies the code in the LoRaWANStack and Mac layer. We are now following certian rules for naming data structures. - All structures visible outside their domain are prefixed as 'lorawan_' - All mac structures are prefixed as 'loramac_' - All subsystem or module strucutures carry their name in prefix, like 'mcps_' PHY layer still have legacy camel case data structures which will be entertained later while we will be simplifying PHY layer. Test cases are also updated with the new data structure naming conventions. One major difference from the previous baseline is the removal of static buffer from mcps indication. And we do not copy data from stack buffer to rx_msg buffer. This saves at least 512 bytes. It may look like now that if we have received something but the user have not read from the buffer, then the buffer will be overwritten and we will lose previous frame. Yes, we will. But the same will happen even if we would have copied the buffer into rx_msg because then the rx_msg gets overwritten. So we decide to abandon copying the buffer at multiple locations. We inform the user about reception, if the user doesn't read and the data gets overwritten, then so be it.
2018-01-12 14:39:31 +00:00
return LORAWAN_STATUS_OK;
Adding LoRaWANStack class to control MAC and PHY LoRaWANStack class is our controller layer on top of our current MAC and PHY layer. It provides services to an implementation of LoRaWANBase class. It is a singleton class owing to the fact that the mac layer underneath is not a class object. Instead, it uses the MAC via setting mib, mlme, mcps requests and getting responses back from the mac layer using confirmations and indications. In essense this class is a special handle for mac layer underneath which is predominantly reference design based. In future we may refactor the LoRaMac.cpp code to make it object oriented and cleaner. At one end, it binds the application selected radio driver with the PHY layer and at the other end it provides services to upper layers handling the mac via well defined APIs. For proper selection of a PHY layer, user must use Mbed config system. For this purpose an mbed_lib.json is provided which can be overriden by the user defined mbed_app.json. By default the EU868 band is selected as a PHY layer. User must set relevant keys for the selected connection mechanism.
2017-11-27 13:17:18 +00:00
}
tr_debug("Initializing MAC layer");
[IOTCELL-279] Using Application provided EventQueue The EventQueue thread in LoRaMac.cpp is disbanded and the LoRaWAN protocol is redesigned to store a pointer for an application provided EventQueue. It means that now the stack runs in the same thread as application. Application provided EventQueue is used to defer ISRs from radio driver and timer callbacks as well as the application events are queued to the same event loop.
2017-12-11 10:20:11 +00:00
_queue = queue;
Move all compliance test code inside compilation flag All compliance test related codes are now inside LORAWAN_COMPLIANCE_TEST build flag. This will reduce memory usage in when compliance test codes are not needed.
2018-01-05 10:13:48 +00:00
#if defined(LORAWAN_COMPLIANCE_TEST)
Adding LoRaWANStack class to control MAC and PHY LoRaWANStack class is our controller layer on top of our current MAC and PHY layer. It provides services to an implementation of LoRaWANBase class. It is a singleton class owing to the fact that the mac layer underneath is not a class object. Instead, it uses the MAC via setting mib, mlme, mcps requests and getting responses back from the mac layer using confirmations and indications. In essense this class is a special handle for mac layer underneath which is predominantly reference design based. In future we may refactor the LoRaMac.cpp code to make it object oriented and cleaner. At one end, it binds the application selected radio driver with the PHY layer and at the other end it provides services to upper layers handling the mac via well defined APIs. For proper selection of a PHY layer, user must use Mbed config system. For this purpose an mbed_lib.json is provided which can be overriden by the user defined mbed_app.json. By default the EU868 band is selected as a PHY layer. User must set relevant keys for the selected connection mechanism.
2017-11-27 13:17:18 +00:00
_compliance_test.app_data_buffer = compliance_test_buffer;
Move all compliance test code inside compilation flag All compliance test related codes are now inside LORAWAN_COMPLIANCE_TEST build flag. This will reduce memory usage in when compliance test codes are not needed.
2018-01-05 10:13:48 +00:00
#endif
Adding LoRaWANStack class to control MAC and PHY LoRaWANStack class is our controller layer on top of our current MAC and PHY layer. It provides services to an implementation of LoRaWANBase class. It is a singleton class owing to the fact that the mac layer underneath is not a class object. Instead, it uses the MAC via setting mib, mlme, mcps requests and getting responses back from the mac layer using confirmations and indications. In essense this class is a special handle for mac layer underneath which is predominantly reference design based. In future we may refactor the LoRaMac.cpp code to make it object oriented and cleaner. At one end, it binds the application selected radio driver with the PHY layer and at the other end it provides services to upper layers handling the mac via well defined APIs. For proper selection of a PHY layer, user must use Mbed config system. For this purpose an mbed_lib.json is provided which can be overriden by the user defined mbed_app.json. By default the EU868 band is selected as a PHY layer. User must set relevant keys for the selected connection mechanism.
2017-11-27 13:17:18 +00:00
LoRa: LoRaPHY dependency removed from LoRaMacStack - 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
2018-03-15 08:43:31 +00:00
_loramac.initialize(&LoRaMacPrimitives, queue);
Adding LoRaWANStack class to control MAC and PHY LoRaWANStack class is our controller layer on top of our current MAC and PHY layer. It provides services to an implementation of LoRaWANBase class. It is a singleton class owing to the fact that the mac layer underneath is not a class object. Instead, it uses the MAC via setting mib, mlme, mcps requests and getting responses back from the mac layer using confirmations and indications. In essense this class is a special handle for mac layer underneath which is predominantly reference design based. In future we may refactor the LoRaMac.cpp code to make it object oriented and cleaner. At one end, it binds the application selected radio driver with the PHY layer and at the other end it provides services to upper layers handling the mac via well defined APIs. For proper selection of a PHY layer, user must use Mbed config system. For this purpose an mbed_lib.json is provided which can be overriden by the user defined mbed_app.json. By default the EU868 band is selected as a PHY layer. User must set relevant keys for the selected connection mechanism.
2017-11-27 13:17:18 +00:00
// Reset counters to zero. Will change in future with 1.1 support.
_lw_session.downlink_counter = 0;
_lw_session.uplink_counter = 0;
LoRa: LoRaWANInterface refactored. - Only internal changes, no functionality changes - Some minor improvements to LoRaWanStack
2018-03-12 11:30:00 +00:00
return lora_state_machine(DEVICE_STATE_INIT);
Adding LoRaWANStack class to control MAC and PHY LoRaWANStack class is our controller layer on top of our current MAC and PHY layer. It provides services to an implementation of LoRaWANBase class. It is a singleton class owing to the fact that the mac layer underneath is not a class object. Instead, it uses the MAC via setting mib, mlme, mcps requests and getting responses back from the mac layer using confirmations and indications. In essense this class is a special handle for mac layer underneath which is predominantly reference design based. In future we may refactor the LoRaMac.cpp code to make it object oriented and cleaner. At one end, it binds the application selected radio driver with the PHY layer and at the other end it provides services to upper layers handling the mac via well defined APIs. For proper selection of a PHY layer, user must use Mbed config system. For this purpose an mbed_lib.json is provided which can be overriden by the user defined mbed_app.json. By default the EU868 band is selected as a PHY layer. User must set relevant keys for the selected connection mechanism.
2017-11-27 13:17:18 +00:00
}
[IOTCELL-282] Code cleanup/simplification and rules Baseline is changed to use a single set of data structures that simplifies the code in the LoRaWANStack and Mac layer. We are now following certian rules for naming data structures. - All structures visible outside their domain are prefixed as 'lorawan_' - All mac structures are prefixed as 'loramac_' - All subsystem or module strucutures carry their name in prefix, like 'mcps_' PHY layer still have legacy camel case data structures which will be entertained later while we will be simplifying PHY layer. Test cases are also updated with the new data structure naming conventions. One major difference from the previous baseline is the removal of static buffer from mcps indication. And we do not copy data from stack buffer to rx_msg buffer. This saves at least 512 bytes. It may look like now that if we have received something but the user have not read from the buffer, then the buffer will be overwritten and we will lose previous frame. Yes, we will. But the same will happen even if we would have copied the buffer into rx_msg because then the rx_msg gets overwritten. So we decide to abandon copying the buffer at multiple locations. We inform the user about reception, if the user doesn't read and the data gets overwritten, then so be it.
2018-01-12 14:39:31 +00:00
lorawan_status_t LoRaWANStack::set_confirmed_msg_retry(uint8_t count)
Adding LoRaWANStack class to control MAC and PHY LoRaWANStack class is our controller layer on top of our current MAC and PHY layer. It provides services to an implementation of LoRaWANBase class. It is a singleton class owing to the fact that the mac layer underneath is not a class object. Instead, it uses the MAC via setting mib, mlme, mcps requests and getting responses back from the mac layer using confirmations and indications. In essense this class is a special handle for mac layer underneath which is predominantly reference design based. In future we may refactor the LoRaMac.cpp code to make it object oriented and cleaner. At one end, it binds the application selected radio driver with the PHY layer and at the other end it provides services to upper layers handling the mac via well defined APIs. For proper selection of a PHY layer, user must use Mbed config system. For this purpose an mbed_lib.json is provided which can be overriden by the user defined mbed_app.json. By default the EU868 band is selected as a PHY layer. User must set relevant keys for the selected connection mechanism.
2017-11-27 13:17:18 +00:00
{
[IOTCELL-279] Using Application provided EventQueue The EventQueue thread in LoRaMac.cpp is disbanded and the LoRaWAN protocol is redesigned to store a pointer for an application provided EventQueue. It means that now the stack runs in the same thread as application. Application provided EventQueue is used to defer ISRs from radio driver and timer callbacks as well as the application events are queued to the same event loop.
2017-12-11 10:20:11 +00:00
if (count >= MAX_CONFIRMED_MSG_RETRIES) {
[IOTCELL-282] Code cleanup/simplification and rules Baseline is changed to use a single set of data structures that simplifies the code in the LoRaWANStack and Mac layer. We are now following certian rules for naming data structures. - All structures visible outside their domain are prefixed as 'lorawan_' - All mac structures are prefixed as 'loramac_' - All subsystem or module strucutures carry their name in prefix, like 'mcps_' PHY layer still have legacy camel case data structures which will be entertained later while we will be simplifying PHY layer. Test cases are also updated with the new data structure naming conventions. One major difference from the previous baseline is the removal of static buffer from mcps indication. And we do not copy data from stack buffer to rx_msg buffer. This saves at least 512 bytes. It may look like now that if we have received something but the user have not read from the buffer, then the buffer will be overwritten and we will lose previous frame. Yes, we will. But the same will happen even if we would have copied the buffer into rx_msg because then the rx_msg gets overwritten. So we decide to abandon copying the buffer at multiple locations. We inform the user about reception, if the user doesn't read and the data gets overwritten, then so be it.
2018-01-12 14:39:31 +00:00
return LORAWAN_STATUS_PARAMETER_INVALID;
Adding LoRaWANStack class to control MAC and PHY LoRaWANStack class is our controller layer on top of our current MAC and PHY layer. It provides services to an implementation of LoRaWANBase class. It is a singleton class owing to the fact that the mac layer underneath is not a class object. Instead, it uses the MAC via setting mib, mlme, mcps requests and getting responses back from the mac layer using confirmations and indications. In essense this class is a special handle for mac layer underneath which is predominantly reference design based. In future we may refactor the LoRaMac.cpp code to make it object oriented and cleaner. At one end, it binds the application selected radio driver with the PHY layer and at the other end it provides services to upper layers handling the mac via well defined APIs. For proper selection of a PHY layer, user must use Mbed config system. For this purpose an mbed_lib.json is provided which can be overriden by the user defined mbed_app.json. By default the EU868 band is selected as a PHY layer. User must set relevant keys for the selected connection mechanism.
2017-11-27 13:17:18 +00:00
}
_num_retry = count;
[IOTCELL-282] Code cleanup/simplification and rules Baseline is changed to use a single set of data structures that simplifies the code in the LoRaWANStack and Mac layer. We are now following certian rules for naming data structures. - All structures visible outside their domain are prefixed as 'lorawan_' - All mac structures are prefixed as 'loramac_' - All subsystem or module strucutures carry their name in prefix, like 'mcps_' PHY layer still have legacy camel case data structures which will be entertained later while we will be simplifying PHY layer. Test cases are also updated with the new data structure naming conventions. One major difference from the previous baseline is the removal of static buffer from mcps indication. And we do not copy data from stack buffer to rx_msg buffer. This saves at least 512 bytes. It may look like now that if we have received something but the user have not read from the buffer, then the buffer will be overwritten and we will lose previous frame. Yes, we will. But the same will happen even if we would have copied the buffer into rx_msg because then the rx_msg gets overwritten. So we decide to abandon copying the buffer at multiple locations. We inform the user about reception, if the user doesn't read and the data gets overwritten, then so be it.
2018-01-12 14:39:31 +00:00
return LORAWAN_STATUS_OK;
Adding LoRaWANStack class to control MAC and PHY LoRaWANStack class is our controller layer on top of our current MAC and PHY layer. It provides services to an implementation of LoRaWANBase class. It is a singleton class owing to the fact that the mac layer underneath is not a class object. Instead, it uses the MAC via setting mib, mlme, mcps requests and getting responses back from the mac layer using confirmations and indications. In essense this class is a special handle for mac layer underneath which is predominantly reference design based. In future we may refactor the LoRaMac.cpp code to make it object oriented and cleaner. At one end, it binds the application selected radio driver with the PHY layer and at the other end it provides services to upper layers handling the mac via well defined APIs. For proper selection of a PHY layer, user must use Mbed config system. For this purpose an mbed_lib.json is provided which can be overriden by the user defined mbed_app.json. By default the EU868 band is selected as a PHY layer. User must set relevant keys for the selected connection mechanism.
2017-11-27 13:17:18 +00:00
}
Architecture rework, bug fixing & missing features MAC layer is now a class rather than being a blob. In addition to that Mac commands are now being handled in a seperate subsystem (a class of its own). In future we will do the same with othe sublayers of MAC like MLME, MCPS etc. The drive behind this exercise is to make MAC and supporting layers into an object oriented system. Major bug fixes include: - last join time inclusion in band parameters - disabling rx2 window if we missed the slot already - MLME uplink schdule hook - nbRep according to spec - maintaining datarate after successful joining - suppressing MLME requests if MAC is in TX_DELAYED state - Uplink dwell time verification Some missing features are implemented. Details are as follows. Support for LinkCheckRequet: An application API is added, add_link_check_request() to delegate a request for Link Check Request MAC command. * Application provides a callback function that needs to be called on reception of link check response. * Mac command is piggybacked with data frames. This API makes the sticky MAC command stick with the application payloads until/unless the application un-sticks the said mac command using remove_link_check_request() API. Handling fPending bit: If in the Downlink, we get the fPending bit set in fctrl octet, we attempt to send an empty message back to Network Server to open additional Receive windows. This operation is independent of the application. An RX_DONE event is queued bedore generating the said empty message. Specification does not mention what can be the type of that empty message. We have decided it to be of CONFIRMED type as it gives us an added benefit of retries if the corresponding RX slots are missed. Radio event callbacks as Mbed callbacks: radio_events_t structure has been carrying C-style callbacks which was inherited from the legacy code. These callbacks has now been changed to Mbed Callbacks that makes sure that we can be object oriented from now on.
2017-12-15 10:30:40 +00:00
/*!
* \brief MLME-Indication event function
*
* \param [IN] mlmeIndication - Pointer to the indication structure.
*/
[IOTCELL-282] Code cleanup/simplification and rules Baseline is changed to use a single set of data structures that simplifies the code in the LoRaWANStack and Mac layer. We are now following certian rules for naming data structures. - All structures visible outside their domain are prefixed as 'lorawan_' - All mac structures are prefixed as 'loramac_' - All subsystem or module strucutures carry their name in prefix, like 'mcps_' PHY layer still have legacy camel case data structures which will be entertained later while we will be simplifying PHY layer. Test cases are also updated with the new data structure naming conventions. One major difference from the previous baseline is the removal of static buffer from mcps indication. And we do not copy data from stack buffer to rx_msg buffer. This saves at least 512 bytes. It may look like now that if we have received something but the user have not read from the buffer, then the buffer will be overwritten and we will lose previous frame. Yes, we will. But the same will happen even if we would have copied the buffer into rx_msg because then the rx_msg gets overwritten. So we decide to abandon copying the buffer at multiple locations. We inform the user about reception, if the user doesn't read and the data gets overwritten, then so be it.
2018-01-12 14:39:31 +00:00
void LoRaWANStack::mlme_indication_handler(loramac_mlme_indication_t *mlmeIndication)
Adding LoRaWANStack class to control MAC and PHY LoRaWANStack class is our controller layer on top of our current MAC and PHY layer. It provides services to an implementation of LoRaWANBase class. It is a singleton class owing to the fact that the mac layer underneath is not a class object. Instead, it uses the MAC via setting mib, mlme, mcps requests and getting responses back from the mac layer using confirmations and indications. In essense this class is a special handle for mac layer underneath which is predominantly reference design based. In future we may refactor the LoRaMac.cpp code to make it object oriented and cleaner. At one end, it binds the application selected radio driver with the PHY layer and at the other end it provides services to upper layers handling the mac via well defined APIs. For proper selection of a PHY layer, user must use Mbed config system. For this purpose an mbed_lib.json is provided which can be overriden by the user defined mbed_app.json. By default the EU868 band is selected as a PHY layer. User must set relevant keys for the selected connection mechanism.
2017-11-27 13:17:18 +00:00
{
[IOTCELL-282] Code cleanup/simplification and rules Baseline is changed to use a single set of data structures that simplifies the code in the LoRaWANStack and Mac layer. We are now following certian rules for naming data structures. - All structures visible outside their domain are prefixed as 'lorawan_' - All mac structures are prefixed as 'loramac_' - All subsystem or module strucutures carry their name in prefix, like 'mcps_' PHY layer still have legacy camel case data structures which will be entertained later while we will be simplifying PHY layer. Test cases are also updated with the new data structure naming conventions. One major difference from the previous baseline is the removal of static buffer from mcps indication. And we do not copy data from stack buffer to rx_msg buffer. This saves at least 512 bytes. It may look like now that if we have received something but the user have not read from the buffer, then the buffer will be overwritten and we will lose previous frame. Yes, we will. But the same will happen even if we would have copied the buffer into rx_msg because then the rx_msg gets overwritten. So we decide to abandon copying the buffer at multiple locations. We inform the user about reception, if the user doesn't read and the data gets overwritten, then so be it.
2018-01-12 14:39:31 +00:00
switch( mlmeIndication->indication_type )
Architecture rework, bug fixing & missing features MAC layer is now a class rather than being a blob. In addition to that Mac commands are now being handled in a seperate subsystem (a class of its own). In future we will do the same with othe sublayers of MAC like MLME, MCPS etc. The drive behind this exercise is to make MAC and supporting layers into an object oriented system. Major bug fixes include: - last join time inclusion in band parameters - disabling rx2 window if we missed the slot already - MLME uplink schdule hook - nbRep according to spec - maintaining datarate after successful joining - suppressing MLME requests if MAC is in TX_DELAYED state - Uplink dwell time verification Some missing features are implemented. Details are as follows. Support for LinkCheckRequet: An application API is added, add_link_check_request() to delegate a request for Link Check Request MAC command. * Application provides a callback function that needs to be called on reception of link check response. * Mac command is piggybacked with data frames. This API makes the sticky MAC command stick with the application payloads until/unless the application un-sticks the said mac command using remove_link_check_request() API. Handling fPending bit: If in the Downlink, we get the fPending bit set in fctrl octet, we attempt to send an empty message back to Network Server to open additional Receive windows. This operation is independent of the application. An RX_DONE event is queued bedore generating the said empty message. Specification does not mention what can be the type of that empty message. We have decided it to be of CONFIRMED type as it gives us an added benefit of retries if the corresponding RX slots are missed. Radio event callbacks as Mbed callbacks: radio_events_t structure has been carrying C-style callbacks which was inherited from the legacy code. These callbacks has now been changed to Mbed Callbacks that makes sure that we can be object oriented from now on.
2017-12-15 10:30:40 +00:00
{
case MLME_SCHEDULE_UPLINK:
{// The MAC signals that we shall provide an uplink as soon as possible
// TODO: Sending implementation missing and will be implemented using
// another task.
//OnTxNextPacketTimerEvent( );
break;
}
default:
break;
}
}
LoRa: LoRaWANInterface refactored. - Only internal changes, no functionality changes - Some minor improvements to LoRaWanStack
2018-03-12 11:30:00 +00:00
lorawan_status_t LoRaWANStack::set_lora_callbacks(lorawan_app_callbacks_t *cbs)
Architecture rework, bug fixing & missing features MAC layer is now a class rather than being a blob. In addition to that Mac commands are now being handled in a seperate subsystem (a class of its own). In future we will do the same with othe sublayers of MAC like MLME, MCPS etc. The drive behind this exercise is to make MAC and supporting layers into an object oriented system. Major bug fixes include: - last join time inclusion in band parameters - disabling rx2 window if we missed the slot already - MLME uplink schdule hook - nbRep according to spec - maintaining datarate after successful joining - suppressing MLME requests if MAC is in TX_DELAYED state - Uplink dwell time verification Some missing features are implemented. Details are as follows. Support for LinkCheckRequet: An application API is added, add_link_check_request() to delegate a request for Link Check Request MAC command. * Application provides a callback function that needs to be called on reception of link check response. * Mac command is piggybacked with data frames. This API makes the sticky MAC command stick with the application payloads until/unless the application un-sticks the said mac command using remove_link_check_request() API. Handling fPending bit: If in the Downlink, we get the fPending bit set in fctrl octet, we attempt to send an empty message back to Network Server to open additional Receive windows. This operation is independent of the application. An RX_DONE event is queued bedore generating the said empty message. Specification does not mention what can be the type of that empty message. We have decided it to be of CONFIRMED type as it gives us an added benefit of retries if the corresponding RX slots are missed. Radio event callbacks as Mbed callbacks: radio_events_t structure has been carrying C-style callbacks which was inherited from the legacy code. These callbacks has now been changed to Mbed Callbacks that makes sure that we can be object oriented from now on.
2017-12-15 10:30:40 +00:00
{
LoRa: LoRaWANInterface refactored. - Only internal changes, no functionality changes - Some minor improvements to LoRaWanStack
2018-03-12 11:30:00 +00:00
if (!cbs || !cbs->events) {
return LORAWAN_STATUS_PARAMETER_INVALID;
}
Reworking callback API Application should be able to add some optional callbacks if it needs to. Ofcourse there is a penalty of 8-12 bytes per callback, but there can be certain needs of the application that needs to be met for example setting up a link check request etc. We have introduced a structure that contains callbacks for the application use. - 'events' callback is mandatory, user must assign it. Because this callback brings state changes for the application. We cannot segregate this into individual handlers because of RAM penalty. - Other calbacks (none of them are implemented yet are optional). Example of using the API is provided with doxygen
2017-12-21 11:37:38 +00:00
LoRa: LoRaWANInterface refactored. - Only internal changes, no functionality changes - Some minor improvements to LoRaWanStack
2018-03-12 11:30:00 +00:00
_callbacks.events = cbs->events;
[IOTCELL-282] Code cleanup/simplification and rules Baseline is changed to use a single set of data structures that simplifies the code in the LoRaWANStack and Mac layer. We are now following certian rules for naming data structures. - All structures visible outside their domain are prefixed as 'lorawan_' - All mac structures are prefixed as 'loramac_' - All subsystem or module strucutures carry their name in prefix, like 'mcps_' PHY layer still have legacy camel case data structures which will be entertained later while we will be simplifying PHY layer. Test cases are also updated with the new data structure naming conventions. One major difference from the previous baseline is the removal of static buffer from mcps indication. And we do not copy data from stack buffer to rx_msg buffer. This saves at least 512 bytes. It may look like now that if we have received something but the user have not read from the buffer, then the buffer will be overwritten and we will lose previous frame. Yes, we will. But the same will happen even if we would have copied the buffer into rx_msg because then the rx_msg gets overwritten. So we decide to abandon copying the buffer at multiple locations. We inform the user about reception, if the user doesn't read and the data gets overwritten, then so be it.
2018-01-12 14:39:31 +00:00
LoRa: LoRaWANInterface refactored. - Only internal changes, no functionality changes - Some minor improvements to LoRaWanStack
2018-03-12 11:30:00 +00:00
if (cbs->link_check_resp) {
_callbacks.link_check_resp = cbs->link_check_resp;
}
if (cbs->battery_level) {
_callbacks.battery_level = cbs->battery_level;
Reworking callback API Application should be able to add some optional callbacks if it needs to. Ofcourse there is a penalty of 8-12 bytes per callback, but there can be certain needs of the application that needs to be met for example setting up a link check request etc. We have introduced a structure that contains callbacks for the application use. - 'events' callback is mandatory, user must assign it. Because this callback brings state changes for the application. We cannot segregate this into individual handlers because of RAM penalty. - Other calbacks (none of them are implemented yet are optional). Example of using the API is provided with doxygen
2017-12-21 11:37:38 +00:00
}
LoRa: LoRaWANInterface refactored. - Only internal changes, no functionality changes - Some minor improvements to LoRaWanStack
2018-03-12 11:30:00 +00:00
return LORAWAN_STATUS_OK;
Adding LoRaWANStack class to control MAC and PHY LoRaWANStack class is our controller layer on top of our current MAC and PHY layer. It provides services to an implementation of LoRaWANBase class. It is a singleton class owing to the fact that the mac layer underneath is not a class object. Instead, it uses the MAC via setting mib, mlme, mcps requests and getting responses back from the mac layer using confirmations and indications. In essense this class is a special handle for mac layer underneath which is predominantly reference design based. In future we may refactor the LoRaMac.cpp code to make it object oriented and cleaner. At one end, it binds the application selected radio driver with the PHY layer and at the other end it provides services to upper layers handling the mac via well defined APIs. For proper selection of a PHY layer, user must use Mbed config system. For this purpose an mbed_lib.json is provided which can be overriden by the user defined mbed_app.json. By default the EU868 band is selected as a PHY layer. User must set relevant keys for the selected connection mechanism.
2017-11-27 13:17:18 +00:00
}
[IOTCELL-282] Code cleanup/simplification and rules Baseline is changed to use a single set of data structures that simplifies the code in the LoRaWANStack and Mac layer. We are now following certian rules for naming data structures. - All structures visible outside their domain are prefixed as 'lorawan_' - All mac structures are prefixed as 'loramac_' - All subsystem or module strucutures carry their name in prefix, like 'mcps_' PHY layer still have legacy camel case data structures which will be entertained later while we will be simplifying PHY layer. Test cases are also updated with the new data structure naming conventions. One major difference from the previous baseline is the removal of static buffer from mcps indication. And we do not copy data from stack buffer to rx_msg buffer. This saves at least 512 bytes. It may look like now that if we have received something but the user have not read from the buffer, then the buffer will be overwritten and we will lose previous frame. Yes, we will. But the same will happen even if we would have copied the buffer into rx_msg because then the rx_msg gets overwritten. So we decide to abandon copying the buffer at multiple locations. We inform the user about reception, if the user doesn't read and the data gets overwritten, then so be it.
2018-01-12 14:39:31 +00:00
lorawan_status_t LoRaWANStack::add_channels(const lorawan_channelplan_t &channel_plan)
Adding LoRaWANStack class to control MAC and PHY LoRaWANStack class is our controller layer on top of our current MAC and PHY layer. It provides services to an implementation of LoRaWANBase class. It is a singleton class owing to the fact that the mac layer underneath is not a class object. Instead, it uses the MAC via setting mib, mlme, mcps requests and getting responses back from the mac layer using confirmations and indications. In essense this class is a special handle for mac layer underneath which is predominantly reference design based. In future we may refactor the LoRaMac.cpp code to make it object oriented and cleaner. At one end, it binds the application selected radio driver with the PHY layer and at the other end it provides services to upper layers handling the mac via well defined APIs. For proper selection of a PHY layer, user must use Mbed config system. For this purpose an mbed_lib.json is provided which can be overriden by the user defined mbed_app.json. By default the EU868 band is selected as a PHY layer. User must set relevant keys for the selected connection mechanism.
2017-11-27 13:17:18 +00:00
{
if (_device_current_state == DEVICE_STATE_NOT_INITIALIZED) {
tr_error("Stack not initialized!");
[IOTCELL-282] Code cleanup/simplification and rules Baseline is changed to use a single set of data structures that simplifies the code in the LoRaWANStack and Mac layer. We are now following certian rules for naming data structures. - All structures visible outside their domain are prefixed as 'lorawan_' - All mac structures are prefixed as 'loramac_' - All subsystem or module strucutures carry their name in prefix, like 'mcps_' PHY layer still have legacy camel case data structures which will be entertained later while we will be simplifying PHY layer. Test cases are also updated with the new data structure naming conventions. One major difference from the previous baseline is the removal of static buffer from mcps indication. And we do not copy data from stack buffer to rx_msg buffer. This saves at least 512 bytes. It may look like now that if we have received something but the user have not read from the buffer, then the buffer will be overwritten and we will lose previous frame. Yes, we will. But the same will happen even if we would have copied the buffer into rx_msg because then the rx_msg gets overwritten. So we decide to abandon copying the buffer at multiple locations. We inform the user about reception, if the user doesn't read and the data gets overwritten, then so be it.
2018-01-12 14:39:31 +00:00
return LORAWAN_STATUS_NOT_INITIALIZED;
Adding LoRaWANStack class to control MAC and PHY LoRaWANStack class is our controller layer on top of our current MAC and PHY layer. It provides services to an implementation of LoRaWANBase class. It is a singleton class owing to the fact that the mac layer underneath is not a class object. Instead, it uses the MAC via setting mib, mlme, mcps requests and getting responses back from the mac layer using confirmations and indications. In essense this class is a special handle for mac layer underneath which is predominantly reference design based. In future we may refactor the LoRaMac.cpp code to make it object oriented and cleaner. At one end, it binds the application selected radio driver with the PHY layer and at the other end it provides services to upper layers handling the mac via well defined APIs. For proper selection of a PHY layer, user must use Mbed config system. For this purpose an mbed_lib.json is provided which can be overriden by the user defined mbed_app.json. By default the EU868 band is selected as a PHY layer. User must set relevant keys for the selected connection mechanism.
2017-11-27 13:17:18 +00:00
}
Style Changes in MAC layer Style changed according to Mbed-OS guidelines.
2018-02-09 14:23:33 +00:00
return _loramac.add_channel_plan(channel_plan);
Adding LoRaWANStack class to control MAC and PHY LoRaWANStack class is our controller layer on top of our current MAC and PHY layer. It provides services to an implementation of LoRaWANBase class. It is a singleton class owing to the fact that the mac layer underneath is not a class object. Instead, it uses the MAC via setting mib, mlme, mcps requests and getting responses back from the mac layer using confirmations and indications. In essense this class is a special handle for mac layer underneath which is predominantly reference design based. In future we may refactor the LoRaMac.cpp code to make it object oriented and cleaner. At one end, it binds the application selected radio driver with the PHY layer and at the other end it provides services to upper layers handling the mac via well defined APIs. For proper selection of a PHY layer, user must use Mbed config system. For this purpose an mbed_lib.json is provided which can be overriden by the user defined mbed_app.json. By default the EU868 band is selected as a PHY layer. User must set relevant keys for the selected connection mechanism.
2017-11-27 13:17:18 +00:00
}
[IOTCELL-282] Code cleanup/simplification and rules Baseline is changed to use a single set of data structures that simplifies the code in the LoRaWANStack and Mac layer. We are now following certian rules for naming data structures. - All structures visible outside their domain are prefixed as 'lorawan_' - All mac structures are prefixed as 'loramac_' - All subsystem or module strucutures carry their name in prefix, like 'mcps_' PHY layer still have legacy camel case data structures which will be entertained later while we will be simplifying PHY layer. Test cases are also updated with the new data structure naming conventions. One major difference from the previous baseline is the removal of static buffer from mcps indication. And we do not copy data from stack buffer to rx_msg buffer. This saves at least 512 bytes. It may look like now that if we have received something but the user have not read from the buffer, then the buffer will be overwritten and we will lose previous frame. Yes, we will. But the same will happen even if we would have copied the buffer into rx_msg because then the rx_msg gets overwritten. So we decide to abandon copying the buffer at multiple locations. We inform the user about reception, if the user doesn't read and the data gets overwritten, then so be it.
2018-01-12 14:39:31 +00:00
lorawan_status_t LoRaWANStack::drop_channel_list()
Adding LoRaWANStack class to control MAC and PHY LoRaWANStack class is our controller layer on top of our current MAC and PHY layer. It provides services to an implementation of LoRaWANBase class. It is a singleton class owing to the fact that the mac layer underneath is not a class object. Instead, it uses the MAC via setting mib, mlme, mcps requests and getting responses back from the mac layer using confirmations and indications. In essense this class is a special handle for mac layer underneath which is predominantly reference design based. In future we may refactor the LoRaMac.cpp code to make it object oriented and cleaner. At one end, it binds the application selected radio driver with the PHY layer and at the other end it provides services to upper layers handling the mac via well defined APIs. For proper selection of a PHY layer, user must use Mbed config system. For this purpose an mbed_lib.json is provided which can be overriden by the user defined mbed_app.json. By default the EU868 band is selected as a PHY layer. User must set relevant keys for the selected connection mechanism.
2017-11-27 13:17:18 +00:00
{
[IOTCELL-286] Adding Channel Plan subsystem Channel planning was distributed over LoRaWANStack and LoRaMac previously. We now centralize it by allocating the service to its own class. Thus making the workflow consistent, i.e., Request for channel plan = Application->Interface->stack->Mac->ChannelPlan Major change apart from adding the channel plan subsystem are the API changes in LoRaMac class.
2018-01-11 11:55:08 +00:00
if (_device_current_state == DEVICE_STATE_NOT_INITIALIZED) {
Adding LoRaWANStack class to control MAC and PHY LoRaWANStack class is our controller layer on top of our current MAC and PHY layer. It provides services to an implementation of LoRaWANBase class. It is a singleton class owing to the fact that the mac layer underneath is not a class object. Instead, it uses the MAC via setting mib, mlme, mcps requests and getting responses back from the mac layer using confirmations and indications. In essense this class is a special handle for mac layer underneath which is predominantly reference design based. In future we may refactor the LoRaMac.cpp code to make it object oriented and cleaner. At one end, it binds the application selected radio driver with the PHY layer and at the other end it provides services to upper layers handling the mac via well defined APIs. For proper selection of a PHY layer, user must use Mbed config system. For this purpose an mbed_lib.json is provided which can be overriden by the user defined mbed_app.json. By default the EU868 band is selected as a PHY layer. User must set relevant keys for the selected connection mechanism.
2017-11-27 13:17:18 +00:00
tr_error("Stack not initialized!");
[IOTCELL-282] Code cleanup/simplification and rules Baseline is changed to use a single set of data structures that simplifies the code in the LoRaWANStack and Mac layer. We are now following certian rules for naming data structures. - All structures visible outside their domain are prefixed as 'lorawan_' - All mac structures are prefixed as 'loramac_' - All subsystem or module strucutures carry their name in prefix, like 'mcps_' PHY layer still have legacy camel case data structures which will be entertained later while we will be simplifying PHY layer. Test cases are also updated with the new data structure naming conventions. One major difference from the previous baseline is the removal of static buffer from mcps indication. And we do not copy data from stack buffer to rx_msg buffer. This saves at least 512 bytes. It may look like now that if we have received something but the user have not read from the buffer, then the buffer will be overwritten and we will lose previous frame. Yes, we will. But the same will happen even if we would have copied the buffer into rx_msg because then the rx_msg gets overwritten. So we decide to abandon copying the buffer at multiple locations. We inform the user about reception, if the user doesn't read and the data gets overwritten, then so be it.
2018-01-12 14:39:31 +00:00
return LORAWAN_STATUS_NOT_INITIALIZED;
Adding LoRaWANStack class to control MAC and PHY LoRaWANStack class is our controller layer on top of our current MAC and PHY layer. It provides services to an implementation of LoRaWANBase class. It is a singleton class owing to the fact that the mac layer underneath is not a class object. Instead, it uses the MAC via setting mib, mlme, mcps requests and getting responses back from the mac layer using confirmations and indications. In essense this class is a special handle for mac layer underneath which is predominantly reference design based. In future we may refactor the LoRaMac.cpp code to make it object oriented and cleaner. At one end, it binds the application selected radio driver with the PHY layer and at the other end it provides services to upper layers handling the mac via well defined APIs. For proper selection of a PHY layer, user must use Mbed config system. For this purpose an mbed_lib.json is provided which can be overriden by the user defined mbed_app.json. By default the EU868 band is selected as a PHY layer. User must set relevant keys for the selected connection mechanism.
2017-11-27 13:17:18 +00:00
}
Style Changes in MAC layer Style changed according to Mbed-OS guidelines.
2018-02-09 14:23:33 +00:00
return _loramac.remove_channel_plan();
Adding LoRaWANStack class to control MAC and PHY LoRaWANStack class is our controller layer on top of our current MAC and PHY layer. It provides services to an implementation of LoRaWANBase class. It is a singleton class owing to the fact that the mac layer underneath is not a class object. Instead, it uses the MAC via setting mib, mlme, mcps requests and getting responses back from the mac layer using confirmations and indications. In essense this class is a special handle for mac layer underneath which is predominantly reference design based. In future we may refactor the LoRaMac.cpp code to make it object oriented and cleaner. At one end, it binds the application selected radio driver with the PHY layer and at the other end it provides services to upper layers handling the mac via well defined APIs. For proper selection of a PHY layer, user must use Mbed config system. For this purpose an mbed_lib.json is provided which can be overriden by the user defined mbed_app.json. By default the EU868 band is selected as a PHY layer. User must set relevant keys for the selected connection mechanism.
2017-11-27 13:17:18 +00:00
}
[IOTCELL-282] Code cleanup/simplification and rules Baseline is changed to use a single set of data structures that simplifies the code in the LoRaWANStack and Mac layer. We are now following certian rules for naming data structures. - All structures visible outside their domain are prefixed as 'lorawan_' - All mac structures are prefixed as 'loramac_' - All subsystem or module strucutures carry their name in prefix, like 'mcps_' PHY layer still have legacy camel case data structures which will be entertained later while we will be simplifying PHY layer. Test cases are also updated with the new data structure naming conventions. One major difference from the previous baseline is the removal of static buffer from mcps indication. And we do not copy data from stack buffer to rx_msg buffer. This saves at least 512 bytes. It may look like now that if we have received something but the user have not read from the buffer, then the buffer will be overwritten and we will lose previous frame. Yes, we will. But the same will happen even if we would have copied the buffer into rx_msg because then the rx_msg gets overwritten. So we decide to abandon copying the buffer at multiple locations. We inform the user about reception, if the user doesn't read and the data gets overwritten, then so be it.
2018-01-12 14:39:31 +00:00
lorawan_status_t LoRaWANStack::remove_a_channel(uint8_t channel_id)
Adding LoRaWANStack class to control MAC and PHY LoRaWANStack class is our controller layer on top of our current MAC and PHY layer. It provides services to an implementation of LoRaWANBase class. It is a singleton class owing to the fact that the mac layer underneath is not a class object. Instead, it uses the MAC via setting mib, mlme, mcps requests and getting responses back from the mac layer using confirmations and indications. In essense this class is a special handle for mac layer underneath which is predominantly reference design based. In future we may refactor the LoRaMac.cpp code to make it object oriented and cleaner. At one end, it binds the application selected radio driver with the PHY layer and at the other end it provides services to upper layers handling the mac via well defined APIs. For proper selection of a PHY layer, user must use Mbed config system. For this purpose an mbed_lib.json is provided which can be overriden by the user defined mbed_app.json. By default the EU868 band is selected as a PHY layer. User must set relevant keys for the selected connection mechanism.
2017-11-27 13:17:18 +00:00
{
if (_device_current_state == DEVICE_STATE_NOT_INITIALIZED )
{
tr_error("Stack not initialized!");
[IOTCELL-282] Code cleanup/simplification and rules Baseline is changed to use a single set of data structures that simplifies the code in the LoRaWANStack and Mac layer. We are now following certian rules for naming data structures. - All structures visible outside their domain are prefixed as 'lorawan_' - All mac structures are prefixed as 'loramac_' - All subsystem or module strucutures carry their name in prefix, like 'mcps_' PHY layer still have legacy camel case data structures which will be entertained later while we will be simplifying PHY layer. Test cases are also updated with the new data structure naming conventions. One major difference from the previous baseline is the removal of static buffer from mcps indication. And we do not copy data from stack buffer to rx_msg buffer. This saves at least 512 bytes. It may look like now that if we have received something but the user have not read from the buffer, then the buffer will be overwritten and we will lose previous frame. Yes, we will. But the same will happen even if we would have copied the buffer into rx_msg because then the rx_msg gets overwritten. So we decide to abandon copying the buffer at multiple locations. We inform the user about reception, if the user doesn't read and the data gets overwritten, then so be it.
2018-01-12 14:39:31 +00:00
return LORAWAN_STATUS_NOT_INITIALIZED;
Adding LoRaWANStack class to control MAC and PHY LoRaWANStack class is our controller layer on top of our current MAC and PHY layer. It provides services to an implementation of LoRaWANBase class. It is a singleton class owing to the fact that the mac layer underneath is not a class object. Instead, it uses the MAC via setting mib, mlme, mcps requests and getting responses back from the mac layer using confirmations and indications. In essense this class is a special handle for mac layer underneath which is predominantly reference design based. In future we may refactor the LoRaMac.cpp code to make it object oriented and cleaner. At one end, it binds the application selected radio driver with the PHY layer and at the other end it provides services to upper layers handling the mac via well defined APIs. For proper selection of a PHY layer, user must use Mbed config system. For this purpose an mbed_lib.json is provided which can be overriden by the user defined mbed_app.json. By default the EU868 band is selected as a PHY layer. User must set relevant keys for the selected connection mechanism.
2017-11-27 13:17:18 +00:00
}
Style Changes in MAC layer Style changed according to Mbed-OS guidelines.
2018-02-09 14:23:33 +00:00
return _loramac.remove_single_channel(channel_id);
Adding LoRaWANStack class to control MAC and PHY LoRaWANStack class is our controller layer on top of our current MAC and PHY layer. It provides services to an implementation of LoRaWANBase class. It is a singleton class owing to the fact that the mac layer underneath is not a class object. Instead, it uses the MAC via setting mib, mlme, mcps requests and getting responses back from the mac layer using confirmations and indications. In essense this class is a special handle for mac layer underneath which is predominantly reference design based. In future we may refactor the LoRaMac.cpp code to make it object oriented and cleaner. At one end, it binds the application selected radio driver with the PHY layer and at the other end it provides services to upper layers handling the mac via well defined APIs. For proper selection of a PHY layer, user must use Mbed config system. For this purpose an mbed_lib.json is provided which can be overriden by the user defined mbed_app.json. By default the EU868 band is selected as a PHY layer. User must set relevant keys for the selected connection mechanism.
2017-11-27 13:17:18 +00:00
}
[IOTCELL-282] Code cleanup/simplification and rules Baseline is changed to use a single set of data structures that simplifies the code in the LoRaWANStack and Mac layer. We are now following certian rules for naming data structures. - All structures visible outside their domain are prefixed as 'lorawan_' - All mac structures are prefixed as 'loramac_' - All subsystem or module strucutures carry their name in prefix, like 'mcps_' PHY layer still have legacy camel case data structures which will be entertained later while we will be simplifying PHY layer. Test cases are also updated with the new data structure naming conventions. One major difference from the previous baseline is the removal of static buffer from mcps indication. And we do not copy data from stack buffer to rx_msg buffer. This saves at least 512 bytes. It may look like now that if we have received something but the user have not read from the buffer, then the buffer will be overwritten and we will lose previous frame. Yes, we will. But the same will happen even if we would have copied the buffer into rx_msg because then the rx_msg gets overwritten. So we decide to abandon copying the buffer at multiple locations. We inform the user about reception, if the user doesn't read and the data gets overwritten, then so be it.
2018-01-12 14:39:31 +00:00
lorawan_status_t LoRaWANStack::get_enabled_channels(lorawan_channelplan_t& channel_plan)
Adding LoRaWANStack class to control MAC and PHY LoRaWANStack class is our controller layer on top of our current MAC and PHY layer. It provides services to an implementation of LoRaWANBase class. It is a singleton class owing to the fact that the mac layer underneath is not a class object. Instead, it uses the MAC via setting mib, mlme, mcps requests and getting responses back from the mac layer using confirmations and indications. In essense this class is a special handle for mac layer underneath which is predominantly reference design based. In future we may refactor the LoRaMac.cpp code to make it object oriented and cleaner. At one end, it binds the application selected radio driver with the PHY layer and at the other end it provides services to upper layers handling the mac via well defined APIs. For proper selection of a PHY layer, user must use Mbed config system. For this purpose an mbed_lib.json is provided which can be overriden by the user defined mbed_app.json. By default the EU868 band is selected as a PHY layer. User must set relevant keys for the selected connection mechanism.
2017-11-27 13:17:18 +00:00
{
if (_device_current_state == DEVICE_STATE_JOINING
|| _device_current_state == DEVICE_STATE_NOT_INITIALIZED
|| _device_current_state == DEVICE_STATE_INIT)
{
tr_error("Cannot get channel plan until Joined!");
[IOTCELL-282] Code cleanup/simplification and rules Baseline is changed to use a single set of data structures that simplifies the code in the LoRaWANStack and Mac layer. We are now following certian rules for naming data structures. - All structures visible outside their domain are prefixed as 'lorawan_' - All mac structures are prefixed as 'loramac_' - All subsystem or module strucutures carry their name in prefix, like 'mcps_' PHY layer still have legacy camel case data structures which will be entertained later while we will be simplifying PHY layer. Test cases are also updated with the new data structure naming conventions. One major difference from the previous baseline is the removal of static buffer from mcps indication. And we do not copy data from stack buffer to rx_msg buffer. This saves at least 512 bytes. It may look like now that if we have received something but the user have not read from the buffer, then the buffer will be overwritten and we will lose previous frame. Yes, we will. But the same will happen even if we would have copied the buffer into rx_msg because then the rx_msg gets overwritten. So we decide to abandon copying the buffer at multiple locations. We inform the user about reception, if the user doesn't read and the data gets overwritten, then so be it.
2018-01-12 14:39:31 +00:00
return LORAWAN_STATUS_BUSY;
Adding LoRaWANStack class to control MAC and PHY LoRaWANStack class is our controller layer on top of our current MAC and PHY layer. It provides services to an implementation of LoRaWANBase class. It is a singleton class owing to the fact that the mac layer underneath is not a class object. Instead, it uses the MAC via setting mib, mlme, mcps requests and getting responses back from the mac layer using confirmations and indications. In essense this class is a special handle for mac layer underneath which is predominantly reference design based. In future we may refactor the LoRaMac.cpp code to make it object oriented and cleaner. At one end, it binds the application selected radio driver with the PHY layer and at the other end it provides services to upper layers handling the mac via well defined APIs. For proper selection of a PHY layer, user must use Mbed config system. For this purpose an mbed_lib.json is provided which can be overriden by the user defined mbed_app.json. By default the EU868 band is selected as a PHY layer. User must set relevant keys for the selected connection mechanism.
2017-11-27 13:17:18 +00:00
}
Style Changes in MAC layer Style changed according to Mbed-OS guidelines.
2018-02-09 14:23:33 +00:00
return _loramac.get_channel_plan(channel_plan);
Adding LoRaWANStack class to control MAC and PHY LoRaWANStack class is our controller layer on top of our current MAC and PHY layer. It provides services to an implementation of LoRaWANBase class. It is a singleton class owing to the fact that the mac layer underneath is not a class object. Instead, it uses the MAC via setting mib, mlme, mcps requests and getting responses back from the mac layer using confirmations and indications. In essense this class is a special handle for mac layer underneath which is predominantly reference design based. In future we may refactor the LoRaMac.cpp code to make it object oriented and cleaner. At one end, it binds the application selected radio driver with the PHY layer and at the other end it provides services to upper layers handling the mac via well defined APIs. For proper selection of a PHY layer, user must use Mbed config system. For this purpose an mbed_lib.json is provided which can be overriden by the user defined mbed_app.json. By default the EU868 band is selected as a PHY layer. User must set relevant keys for the selected connection mechanism.
2017-11-27 13:17:18 +00:00
}
[IOTCELL-282] Code cleanup/simplification and rules Baseline is changed to use a single set of data structures that simplifies the code in the LoRaWANStack and Mac layer. We are now following certian rules for naming data structures. - All structures visible outside their domain are prefixed as 'lorawan_' - All mac structures are prefixed as 'loramac_' - All subsystem or module strucutures carry their name in prefix, like 'mcps_' PHY layer still have legacy camel case data structures which will be entertained later while we will be simplifying PHY layer. Test cases are also updated with the new data structure naming conventions. One major difference from the previous baseline is the removal of static buffer from mcps indication. And we do not copy data from stack buffer to rx_msg buffer. This saves at least 512 bytes. It may look like now that if we have received something but the user have not read from the buffer, then the buffer will be overwritten and we will lose previous frame. Yes, we will. But the same will happen even if we would have copied the buffer into rx_msg because then the rx_msg gets overwritten. So we decide to abandon copying the buffer at multiple locations. We inform the user about reception, if the user doesn't read and the data gets overwritten, then so be it.
2018-01-12 14:39:31 +00:00
lorawan_status_t LoRaWANStack::enable_adaptive_datarate(bool adr_enabled)
Adding LoRaWANStack class to control MAC and PHY LoRaWANStack class is our controller layer on top of our current MAC and PHY layer. It provides services to an implementation of LoRaWANBase class. It is a singleton class owing to the fact that the mac layer underneath is not a class object. Instead, it uses the MAC via setting mib, mlme, mcps requests and getting responses back from the mac layer using confirmations and indications. In essense this class is a special handle for mac layer underneath which is predominantly reference design based. In future we may refactor the LoRaMac.cpp code to make it object oriented and cleaner. At one end, it binds the application selected radio driver with the PHY layer and at the other end it provides services to upper layers handling the mac via well defined APIs. For proper selection of a PHY layer, user must use Mbed config system. For this purpose an mbed_lib.json is provided which can be overriden by the user defined mbed_app.json. By default the EU868 band is selected as a PHY layer. User must set relevant keys for the selected connection mechanism.
2017-11-27 13:17:18 +00:00
{
if (DEVICE_STATE_NOT_INITIALIZED == _device_current_state)
{
tr_error("Stack not initialized!");
[IOTCELL-282] Code cleanup/simplification and rules Baseline is changed to use a single set of data structures that simplifies the code in the LoRaWANStack and Mac layer. We are now following certian rules for naming data structures. - All structures visible outside their domain are prefixed as 'lorawan_' - All mac structures are prefixed as 'loramac_' - All subsystem or module strucutures carry their name in prefix, like 'mcps_' PHY layer still have legacy camel case data structures which will be entertained later while we will be simplifying PHY layer. Test cases are also updated with the new data structure naming conventions. One major difference from the previous baseline is the removal of static buffer from mcps indication. And we do not copy data from stack buffer to rx_msg buffer. This saves at least 512 bytes. It may look like now that if we have received something but the user have not read from the buffer, then the buffer will be overwritten and we will lose previous frame. Yes, we will. But the same will happen even if we would have copied the buffer into rx_msg because then the rx_msg gets overwritten. So we decide to abandon copying the buffer at multiple locations. We inform the user about reception, if the user doesn't read and the data gets overwritten, then so be it.
2018-01-12 14:39:31 +00:00
return LORAWAN_STATUS_NOT_INITIALIZED;
Adding LoRaWANStack class to control MAC and PHY LoRaWANStack class is our controller layer on top of our current MAC and PHY layer. It provides services to an implementation of LoRaWANBase class. It is a singleton class owing to the fact that the mac layer underneath is not a class object. Instead, it uses the MAC via setting mib, mlme, mcps requests and getting responses back from the mac layer using confirmations and indications. In essense this class is a special handle for mac layer underneath which is predominantly reference design based. In future we may refactor the LoRaMac.cpp code to make it object oriented and cleaner. At one end, it binds the application selected radio driver with the PHY layer and at the other end it provides services to upper layers handling the mac via well defined APIs. For proper selection of a PHY layer, user must use Mbed config system. For this purpose an mbed_lib.json is provided which can be overriden by the user defined mbed_app.json. By default the EU868 band is selected as a PHY layer. User must set relevant keys for the selected connection mechanism.
2017-11-27 13:17:18 +00:00
}
LoRaWANStack is made independent of MAC sublayers - Only internal changes, no API has been broke. - Tested by manually running Green tea tests
2018-03-16 11:12:50 +00:00
return _loramac.enable_adaptive_datarate(adr_enabled);
Adding LoRaWANStack class to control MAC and PHY LoRaWANStack class is our controller layer on top of our current MAC and PHY layer. It provides services to an implementation of LoRaWANBase class. It is a singleton class owing to the fact that the mac layer underneath is not a class object. Instead, it uses the MAC via setting mib, mlme, mcps requests and getting responses back from the mac layer using confirmations and indications. In essense this class is a special handle for mac layer underneath which is predominantly reference design based. In future we may refactor the LoRaMac.cpp code to make it object oriented and cleaner. At one end, it binds the application selected radio driver with the PHY layer and at the other end it provides services to upper layers handling the mac via well defined APIs. For proper selection of a PHY layer, user must use Mbed config system. For this purpose an mbed_lib.json is provided which can be overriden by the user defined mbed_app.json. By default the EU868 band is selected as a PHY layer. User must set relevant keys for the selected connection mechanism.
2017-11-27 13:17:18 +00:00
}
[IOTCELL-282] Code cleanup/simplification and rules Baseline is changed to use a single set of data structures that simplifies the code in the LoRaWANStack and Mac layer. We are now following certian rules for naming data structures. - All structures visible outside their domain are prefixed as 'lorawan_' - All mac structures are prefixed as 'loramac_' - All subsystem or module strucutures carry their name in prefix, like 'mcps_' PHY layer still have legacy camel case data structures which will be entertained later while we will be simplifying PHY layer. Test cases are also updated with the new data structure naming conventions. One major difference from the previous baseline is the removal of static buffer from mcps indication. And we do not copy data from stack buffer to rx_msg buffer. This saves at least 512 bytes. It may look like now that if we have received something but the user have not read from the buffer, then the buffer will be overwritten and we will lose previous frame. Yes, we will. But the same will happen even if we would have copied the buffer into rx_msg because then the rx_msg gets overwritten. So we decide to abandon copying the buffer at multiple locations. We inform the user about reception, if the user doesn't read and the data gets overwritten, then so be it.
2018-01-12 14:39:31 +00:00
lorawan_status_t LoRaWANStack::set_channel_data_rate(uint8_t data_rate)
Adding LoRaWANStack class to control MAC and PHY LoRaWANStack class is our controller layer on top of our current MAC and PHY layer. It provides services to an implementation of LoRaWANBase class. It is a singleton class owing to the fact that the mac layer underneath is not a class object. Instead, it uses the MAC via setting mib, mlme, mcps requests and getting responses back from the mac layer using confirmations and indications. In essense this class is a special handle for mac layer underneath which is predominantly reference design based. In future we may refactor the LoRaMac.cpp code to make it object oriented and cleaner. At one end, it binds the application selected radio driver with the PHY layer and at the other end it provides services to upper layers handling the mac via well defined APIs. For proper selection of a PHY layer, user must use Mbed config system. For this purpose an mbed_lib.json is provided which can be overriden by the user defined mbed_app.json. By default the EU868 band is selected as a PHY layer. User must set relevant keys for the selected connection mechanism.
2017-11-27 13:17:18 +00:00
{
if (DEVICE_STATE_NOT_INITIALIZED == _device_current_state)
{
tr_error("Stack not initialized!");
[IOTCELL-282] Code cleanup/simplification and rules Baseline is changed to use a single set of data structures that simplifies the code in the LoRaWANStack and Mac layer. We are now following certian rules for naming data structures. - All structures visible outside their domain are prefixed as 'lorawan_' - All mac structures are prefixed as 'loramac_' - All subsystem or module strucutures carry their name in prefix, like 'mcps_' PHY layer still have legacy camel case data structures which will be entertained later while we will be simplifying PHY layer. Test cases are also updated with the new data structure naming conventions. One major difference from the previous baseline is the removal of static buffer from mcps indication. And we do not copy data from stack buffer to rx_msg buffer. This saves at least 512 bytes. It may look like now that if we have received something but the user have not read from the buffer, then the buffer will be overwritten and we will lose previous frame. Yes, we will. But the same will happen even if we would have copied the buffer into rx_msg because then the rx_msg gets overwritten. So we decide to abandon copying the buffer at multiple locations. We inform the user about reception, if the user doesn't read and the data gets overwritten, then so be it.
2018-01-12 14:39:31 +00:00
return LORAWAN_STATUS_NOT_INITIALIZED;
Adding LoRaWANStack class to control MAC and PHY LoRaWANStack class is our controller layer on top of our current MAC and PHY layer. It provides services to an implementation of LoRaWANBase class. It is a singleton class owing to the fact that the mac layer underneath is not a class object. Instead, it uses the MAC via setting mib, mlme, mcps requests and getting responses back from the mac layer using confirmations and indications. In essense this class is a special handle for mac layer underneath which is predominantly reference design based. In future we may refactor the LoRaMac.cpp code to make it object oriented and cleaner. At one end, it binds the application selected radio driver with the PHY layer and at the other end it provides services to upper layers handling the mac via well defined APIs. For proper selection of a PHY layer, user must use Mbed config system. For this purpose an mbed_lib.json is provided which can be overriden by the user defined mbed_app.json. By default the EU868 band is selected as a PHY layer. User must set relevant keys for the selected connection mechanism.
2017-11-27 13:17:18 +00:00
}
LoRaWANStack is made independent of MAC sublayers - Only internal changes, no API has been broke. - Tested by manually running Green tea tests
2018-03-16 11:12:50 +00:00
return _loramac.set_channel_data_rate(data_rate);
Adding LoRaWANStack class to control MAC and PHY LoRaWANStack class is our controller layer on top of our current MAC and PHY layer. It provides services to an implementation of LoRaWANBase class. It is a singleton class owing to the fact that the mac layer underneath is not a class object. Instead, it uses the MAC via setting mib, mlme, mcps requests and getting responses back from the mac layer using confirmations and indications. In essense this class is a special handle for mac layer underneath which is predominantly reference design based. In future we may refactor the LoRaMac.cpp code to make it object oriented and cleaner. At one end, it binds the application selected radio driver with the PHY layer and at the other end it provides services to upper layers handling the mac via well defined APIs. For proper selection of a PHY layer, user must use Mbed config system. For this purpose an mbed_lib.json is provided which can be overriden by the user defined mbed_app.json. By default the EU868 band is selected as a PHY layer. User must set relevant keys for the selected connection mechanism.
2017-11-27 13:17:18 +00:00
}
[IOTCELL-282] Code cleanup/simplification and rules Baseline is changed to use a single set of data structures that simplifies the code in the LoRaWANStack and Mac layer. We are now following certian rules for naming data structures. - All structures visible outside their domain are prefixed as 'lorawan_' - All mac structures are prefixed as 'loramac_' - All subsystem or module strucutures carry their name in prefix, like 'mcps_' PHY layer still have legacy camel case data structures which will be entertained later while we will be simplifying PHY layer. Test cases are also updated with the new data structure naming conventions. One major difference from the previous baseline is the removal of static buffer from mcps indication. And we do not copy data from stack buffer to rx_msg buffer. This saves at least 512 bytes. It may look like now that if we have received something but the user have not read from the buffer, then the buffer will be overwritten and we will lose previous frame. Yes, we will. But the same will happen even if we would have copied the buffer into rx_msg because then the rx_msg gets overwritten. So we decide to abandon copying the buffer at multiple locations. We inform the user about reception, if the user doesn't read and the data gets overwritten, then so be it.
2018-01-12 14:39:31 +00:00
lorawan_status_t LoRaWANStack::join_request_by_otaa(const lorawan_connect_t &params)
Adding LoRaWANStack class to control MAC and PHY LoRaWANStack class is our controller layer on top of our current MAC and PHY layer. It provides services to an implementation of LoRaWANBase class. It is a singleton class owing to the fact that the mac layer underneath is not a class object. Instead, it uses the MAC via setting mib, mlme, mcps requests and getting responses back from the mac layer using confirmations and indications. In essense this class is a special handle for mac layer underneath which is predominantly reference design based. In future we may refactor the LoRaMac.cpp code to make it object oriented and cleaner. At one end, it binds the application selected radio driver with the PHY layer and at the other end it provides services to upper layers handling the mac via well defined APIs. For proper selection of a PHY layer, user must use Mbed config system. For this purpose an mbed_lib.json is provided which can be overriden by the user defined mbed_app.json. By default the EU868 band is selected as a PHY layer. User must set relevant keys for the selected connection mechanism.
2017-11-27 13:17:18 +00:00
{
if (DEVICE_STATE_NOT_INITIALIZED == _device_current_state)
{
tr_error("Stack not initialized!");
[IOTCELL-282] Code cleanup/simplification and rules Baseline is changed to use a single set of data structures that simplifies the code in the LoRaWANStack and Mac layer. We are now following certian rules for naming data structures. - All structures visible outside their domain are prefixed as 'lorawan_' - All mac structures are prefixed as 'loramac_' - All subsystem or module strucutures carry their name in prefix, like 'mcps_' PHY layer still have legacy camel case data structures which will be entertained later while we will be simplifying PHY layer. Test cases are also updated with the new data structure naming conventions. One major difference from the previous baseline is the removal of static buffer from mcps indication. And we do not copy data from stack buffer to rx_msg buffer. This saves at least 512 bytes. It may look like now that if we have received something but the user have not read from the buffer, then the buffer will be overwritten and we will lose previous frame. Yes, we will. But the same will happen even if we would have copied the buffer into rx_msg because then the rx_msg gets overwritten. So we decide to abandon copying the buffer at multiple locations. We inform the user about reception, if the user doesn't read and the data gets overwritten, then so be it.
2018-01-12 14:39:31 +00:00
return LORAWAN_STATUS_NOT_INITIALIZED;
Adding LoRaWANStack class to control MAC and PHY LoRaWANStack class is our controller layer on top of our current MAC and PHY layer. It provides services to an implementation of LoRaWANBase class. It is a singleton class owing to the fact that the mac layer underneath is not a class object. Instead, it uses the MAC via setting mib, mlme, mcps requests and getting responses back from the mac layer using confirmations and indications. In essense this class is a special handle for mac layer underneath which is predominantly reference design based. In future we may refactor the LoRaMac.cpp code to make it object oriented and cleaner. At one end, it binds the application selected radio driver with the PHY layer and at the other end it provides services to upper layers handling the mac via well defined APIs. For proper selection of a PHY layer, user must use Mbed config system. For this purpose an mbed_lib.json is provided which can be overriden by the user defined mbed_app.json. By default the EU868 band is selected as a PHY layer. User must set relevant keys for the selected connection mechanism.
2017-11-27 13:17:18 +00:00
}
tr_debug("Initiating OTAA");
// As mentioned in the comment above, in 1.0.2 spec, counters are always set
// to zero for new connection. This section is common for both normal and
// connection restore at this moment. Will change in future with 1.1 support.
LoRa: LoRaWANInterface refactored. - Only internal changes, no functionality changes - Some minor improvements to LoRaWanStack
2018-03-12 11:30:00 +00:00
_lw_session.downlink_counter = 0;
_lw_session.uplink_counter = 0;
_lw_session.connection.connect_type = LORAWAN_CONNECTION_OTAA;
Adding LoRaWANStack class to control MAC and PHY LoRaWANStack class is our controller layer on top of our current MAC and PHY layer. It provides services to an implementation of LoRaWANBase class. It is a singleton class owing to the fact that the mac layer underneath is not a class object. Instead, it uses the MAC via setting mib, mlme, mcps requests and getting responses back from the mac layer using confirmations and indications. In essense this class is a special handle for mac layer underneath which is predominantly reference design based. In future we may refactor the LoRaMac.cpp code to make it object oriented and cleaner. At one end, it binds the application selected radio driver with the PHY layer and at the other end it provides services to upper layers handling the mac via well defined APIs. For proper selection of a PHY layer, user must use Mbed config system. For this purpose an mbed_lib.json is provided which can be overriden by the user defined mbed_app.json. By default the EU868 band is selected as a PHY layer. User must set relevant keys for the selected connection mechanism.
2017-11-27 13:17:18 +00:00
LoRa: LoRaWANInterface refactored. - Only internal changes, no functionality changes - Some minor improvements to LoRaWanStack
2018-03-12 11:30:00 +00:00
_lw_session.connection.connection_u.otaa.dev_eui = params.connection_u.otaa.dev_eui;
_lw_session.connection.connection_u.otaa.app_eui = params.connection_u.otaa.app_eui;
_lw_session.connection.connection_u.otaa.app_key = params.connection_u.otaa.app_key;
_lw_session.connection.connection_u.otaa.nb_trials = params.connection_u.otaa.nb_trials;
return lora_state_machine(DEVICE_STATE_JOINING);
Adding LoRaWANStack class to control MAC and PHY LoRaWANStack class is our controller layer on top of our current MAC and PHY layer. It provides services to an implementation of LoRaWANBase class. It is a singleton class owing to the fact that the mac layer underneath is not a class object. Instead, it uses the MAC via setting mib, mlme, mcps requests and getting responses back from the mac layer using confirmations and indications. In essense this class is a special handle for mac layer underneath which is predominantly reference design based. In future we may refactor the LoRaMac.cpp code to make it object oriented and cleaner. At one end, it binds the application selected radio driver with the PHY layer and at the other end it provides services to upper layers handling the mac via well defined APIs. For proper selection of a PHY layer, user must use Mbed config system. For this purpose an mbed_lib.json is provided which can be overriden by the user defined mbed_app.json. By default the EU868 band is selected as a PHY layer. User must set relevant keys for the selected connection mechanism.
2017-11-27 13:17:18 +00:00
}
[IOTCELL-282] Code cleanup/simplification and rules Baseline is changed to use a single set of data structures that simplifies the code in the LoRaWANStack and Mac layer. We are now following certian rules for naming data structures. - All structures visible outside their domain are prefixed as 'lorawan_' - All mac structures are prefixed as 'loramac_' - All subsystem or module strucutures carry their name in prefix, like 'mcps_' PHY layer still have legacy camel case data structures which will be entertained later while we will be simplifying PHY layer. Test cases are also updated with the new data structure naming conventions. One major difference from the previous baseline is the removal of static buffer from mcps indication. And we do not copy data from stack buffer to rx_msg buffer. This saves at least 512 bytes. It may look like now that if we have received something but the user have not read from the buffer, then the buffer will be overwritten and we will lose previous frame. Yes, we will. But the same will happen even if we would have copied the buffer into rx_msg because then the rx_msg gets overwritten. So we decide to abandon copying the buffer at multiple locations. We inform the user about reception, if the user doesn't read and the data gets overwritten, then so be it.
2018-01-12 14:39:31 +00:00
lorawan_status_t LoRaWANStack::activation_by_personalization(const lorawan_connect_t &params)
Adding LoRaWANStack class to control MAC and PHY LoRaWANStack class is our controller layer on top of our current MAC and PHY layer. It provides services to an implementation of LoRaWANBase class. It is a singleton class owing to the fact that the mac layer underneath is not a class object. Instead, it uses the MAC via setting mib, mlme, mcps requests and getting responses back from the mac layer using confirmations and indications. In essense this class is a special handle for mac layer underneath which is predominantly reference design based. In future we may refactor the LoRaMac.cpp code to make it object oriented and cleaner. At one end, it binds the application selected radio driver with the PHY layer and at the other end it provides services to upper layers handling the mac via well defined APIs. For proper selection of a PHY layer, user must use Mbed config system. For this purpose an mbed_lib.json is provided which can be overriden by the user defined mbed_app.json. By default the EU868 band is selected as a PHY layer. User must set relevant keys for the selected connection mechanism.
2017-11-27 13:17:18 +00:00
{
if (DEVICE_STATE_NOT_INITIALIZED == _device_current_state) {
tr_error("Stack not initialized!");
[IOTCELL-282] Code cleanup/simplification and rules Baseline is changed to use a single set of data structures that simplifies the code in the LoRaWANStack and Mac layer. We are now following certian rules for naming data structures. - All structures visible outside their domain are prefixed as 'lorawan_' - All mac structures are prefixed as 'loramac_' - All subsystem or module strucutures carry their name in prefix, like 'mcps_' PHY layer still have legacy camel case data structures which will be entertained later while we will be simplifying PHY layer. Test cases are also updated with the new data structure naming conventions. One major difference from the previous baseline is the removal of static buffer from mcps indication. And we do not copy data from stack buffer to rx_msg buffer. This saves at least 512 bytes. It may look like now that if we have received something but the user have not read from the buffer, then the buffer will be overwritten and we will lose previous frame. Yes, we will. But the same will happen even if we would have copied the buffer into rx_msg because then the rx_msg gets overwritten. So we decide to abandon copying the buffer at multiple locations. We inform the user about reception, if the user doesn't read and the data gets overwritten, then so be it.
2018-01-12 14:39:31 +00:00
return LORAWAN_STATUS_NOT_INITIALIZED;
Adding LoRaWANStack class to control MAC and PHY LoRaWANStack class is our controller layer on top of our current MAC and PHY layer. It provides services to an implementation of LoRaWANBase class. It is a singleton class owing to the fact that the mac layer underneath is not a class object. Instead, it uses the MAC via setting mib, mlme, mcps requests and getting responses back from the mac layer using confirmations and indications. In essense this class is a special handle for mac layer underneath which is predominantly reference design based. In future we may refactor the LoRaMac.cpp code to make it object oriented and cleaner. At one end, it binds the application selected radio driver with the PHY layer and at the other end it provides services to upper layers handling the mac via well defined APIs. For proper selection of a PHY layer, user must use Mbed config system. For this purpose an mbed_lib.json is provided which can be overriden by the user defined mbed_app.json. By default the EU868 band is selected as a PHY layer. User must set relevant keys for the selected connection mechanism.
2017-11-27 13:17:18 +00:00
}
tr_debug("Initiating ABP");
LoRa: LoRaWANInterface refactored. - Only internal changes, no functionality changes - Some minor improvements to LoRaWanStack
2018-03-12 11:30:00 +00:00
_lw_session.connection.connect_type = LORAWAN_CONNECTION_ABP;
_lw_session.connection.connection_u.abp.dev_addr = params.connection_u.abp.dev_addr;
_lw_session.connection.connection_u.abp.nwk_skey = params.connection_u.abp.nwk_skey;
_lw_session.connection.connection_u.abp.app_skey = params.connection_u.abp.app_skey;
Adding LoRaWANStack class to control MAC and PHY LoRaWANStack class is our controller layer on top of our current MAC and PHY layer. It provides services to an implementation of LoRaWANBase class. It is a singleton class owing to the fact that the mac layer underneath is not a class object. Instead, it uses the MAC via setting mib, mlme, mcps requests and getting responses back from the mac layer using confirmations and indications. In essense this class is a special handle for mac layer underneath which is predominantly reference design based. In future we may refactor the LoRaMac.cpp code to make it object oriented and cleaner. At one end, it binds the application selected radio driver with the PHY layer and at the other end it provides services to upper layers handling the mac via well defined APIs. For proper selection of a PHY layer, user must use Mbed config system. For this purpose an mbed_lib.json is provided which can be overriden by the user defined mbed_app.json. By default the EU868 band is selected as a PHY layer. User must set relevant keys for the selected connection mechanism.
2017-11-27 13:17:18 +00:00
// If current state is SHUTDOWN, device may be trying to re-establish
// communication. In case of ABP specification is meddled about frame counters.
// It says to reset counters to zero but there is no mechanism to tell the
// network server that the device was disconnected or restarted.
// At the moment, this implementation does not support a non-volatile
LoRa: LoRaWANInterface refactored. - Only internal changes, no functionality changes - Some minor improvements to LoRaWanStack
2018-03-12 11:30:00 +00:00
// memory storage.
//_lw_session.downlink_counter; //Get from NVM
//_lw_session.uplink_counter; //Get from NVM
Adding LoRaWANStack class to control MAC and PHY LoRaWANStack class is our controller layer on top of our current MAC and PHY layer. It provides services to an implementation of LoRaWANBase class. It is a singleton class owing to the fact that the mac layer underneath is not a class object. Instead, it uses the MAC via setting mib, mlme, mcps requests and getting responses back from the mac layer using confirmations and indications. In essense this class is a special handle for mac layer underneath which is predominantly reference design based. In future we may refactor the LoRaMac.cpp code to make it object oriented and cleaner. At one end, it binds the application selected radio driver with the PHY layer and at the other end it provides services to upper layers handling the mac via well defined APIs. For proper selection of a PHY layer, user must use Mbed config system. For this purpose an mbed_lib.json is provided which can be overriden by the user defined mbed_app.json. By default the EU868 band is selected as a PHY layer. User must set relevant keys for the selected connection mechanism.
2017-11-27 13:17:18 +00:00
tr_debug("Frame Counters. UpCnt=%lu, DownCnt=%lu",
LoRa: LoRaWANInterface refactored. - Only internal changes, no functionality changes - Some minor improvements to LoRaWanStack
2018-03-12 11:30:00 +00:00
_lw_session.uplink_counter, _lw_session.downlink_counter);
Adding LoRaWANStack class to control MAC and PHY LoRaWANStack class is our controller layer on top of our current MAC and PHY layer. It provides services to an implementation of LoRaWANBase class. It is a singleton class owing to the fact that the mac layer underneath is not a class object. Instead, it uses the MAC via setting mib, mlme, mcps requests and getting responses back from the mac layer using confirmations and indications. In essense this class is a special handle for mac layer underneath which is predominantly reference design based. In future we may refactor the LoRaMac.cpp code to make it object oriented and cleaner. At one end, it binds the application selected radio driver with the PHY layer and at the other end it provides services to upper layers handling the mac via well defined APIs. For proper selection of a PHY layer, user must use Mbed config system. For this purpose an mbed_lib.json is provided which can be overriden by the user defined mbed_app.json. By default the EU868 band is selected as a PHY layer. User must set relevant keys for the selected connection mechanism.
2017-11-27 13:17:18 +00:00
LoRa: LoRaWANInterface refactored. - Only internal changes, no functionality changes - Some minor improvements to LoRaWanStack
2018-03-12 11:30:00 +00:00
return lora_state_machine(DEVICE_STATE_ABP_CONNECTING);
Adding LoRaWANStack class to control MAC and PHY LoRaWANStack class is our controller layer on top of our current MAC and PHY layer. It provides services to an implementation of LoRaWANBase class. It is a singleton class owing to the fact that the mac layer underneath is not a class object. Instead, it uses the MAC via setting mib, mlme, mcps requests and getting responses back from the mac layer using confirmations and indications. In essense this class is a special handle for mac layer underneath which is predominantly reference design based. In future we may refactor the LoRaMac.cpp code to make it object oriented and cleaner. At one end, it binds the application selected radio driver with the PHY layer and at the other end it provides services to upper layers handling the mac via well defined APIs. For proper selection of a PHY layer, user must use Mbed config system. For this purpose an mbed_lib.json is provided which can be overriden by the user defined mbed_app.json. By default the EU868 band is selected as a PHY layer. User must set relevant keys for the selected connection mechanism.
2017-11-27 13:17:18 +00:00
}
int16_t LoRaWANStack::handle_tx(uint8_t port, const uint8_t* data,
LoRa: LoRaPHY dependency removed from LoRaMacStack - 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
2018-03-15 08:43:31 +00:00
uint16_t length, uint8_t flags, bool null_allowed)
Adding LoRaWANStack class to control MAC and PHY LoRaWANStack class is our controller layer on top of our current MAC and PHY layer. It provides services to an implementation of LoRaWANBase class. It is a singleton class owing to the fact that the mac layer underneath is not a class object. Instead, it uses the MAC via setting mib, mlme, mcps requests and getting responses back from the mac layer using confirmations and indications. In essense this class is a special handle for mac layer underneath which is predominantly reference design based. In future we may refactor the LoRaMac.cpp code to make it object oriented and cleaner. At one end, it binds the application selected radio driver with the PHY layer and at the other end it provides services to upper layers handling the mac via well defined APIs. For proper selection of a PHY layer, user must use Mbed config system. For this purpose an mbed_lib.json is provided which can be overriden by the user defined mbed_app.json. By default the EU868 band is selected as a PHY layer. User must set relevant keys for the selected connection mechanism.
2017-11-27 13:17:18 +00:00
{
LoRa: LoRaPHY dependency removed from LoRaMacStack - 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
2018-03-15 08:43:31 +00:00
if (!null_allowed && !data) {
return LORAWAN_STATUS_PARAMETER_INVALID;
}
// add a link check request with normal data, until the application
// explicitly removes it.
LoRa: LoRaWANInterface refactored. - Only internal changes, no functionality changes - Some minor improvements to LoRaWanStack
2018-03-12 11:30:00 +00:00
if (_link_check_requested) {
set_link_check_request();
}
Adding LoRaWANStack class to control MAC and PHY LoRaWANStack class is our controller layer on top of our current MAC and PHY layer. It provides services to an implementation of LoRaWANBase class. It is a singleton class owing to the fact that the mac layer underneath is not a class object. Instead, it uses the MAC via setting mib, mlme, mcps requests and getting responses back from the mac layer using confirmations and indications. In essense this class is a special handle for mac layer underneath which is predominantly reference design based. In future we may refactor the LoRaMac.cpp code to make it object oriented and cleaner. At one end, it binds the application selected radio driver with the PHY layer and at the other end it provides services to upper layers handling the mac via well defined APIs. For proper selection of a PHY layer, user must use Mbed config system. For this purpose an mbed_lib.json is provided which can be overriden by the user defined mbed_app.json. By default the EU868 band is selected as a PHY layer. User must set relevant keys for the selected connection mechanism.
2017-11-27 13:17:18 +00:00
if (!_lw_session.active) {
[IOTCELL-282] Code cleanup/simplification and rules Baseline is changed to use a single set of data structures that simplifies the code in the LoRaWANStack and Mac layer. We are now following certian rules for naming data structures. - All structures visible outside their domain are prefixed as 'lorawan_' - All mac structures are prefixed as 'loramac_' - All subsystem or module strucutures carry their name in prefix, like 'mcps_' PHY layer still have legacy camel case data structures which will be entertained later while we will be simplifying PHY layer. Test cases are also updated with the new data structure naming conventions. One major difference from the previous baseline is the removal of static buffer from mcps indication. And we do not copy data from stack buffer to rx_msg buffer. This saves at least 512 bytes. It may look like now that if we have received something but the user have not read from the buffer, then the buffer will be overwritten and we will lose previous frame. Yes, we will. But the same will happen even if we would have copied the buffer into rx_msg because then the rx_msg gets overwritten. So we decide to abandon copying the buffer at multiple locations. We inform the user about reception, if the user doesn't read and the data gets overwritten, then so be it.
2018-01-12 14:39:31 +00:00
return LORAWAN_STATUS_NO_ACTIVE_SESSIONS;
Adding LoRaWANStack class to control MAC and PHY LoRaWANStack class is our controller layer on top of our current MAC and PHY layer. It provides services to an implementation of LoRaWANBase class. It is a singleton class owing to the fact that the mac layer underneath is not a class object. Instead, it uses the MAC via setting mib, mlme, mcps requests and getting responses back from the mac layer using confirmations and indications. In essense this class is a special handle for mac layer underneath which is predominantly reference design based. In future we may refactor the LoRaMac.cpp code to make it object oriented and cleaner. At one end, it binds the application selected radio driver with the PHY layer and at the other end it provides services to upper layers handling the mac via well defined APIs. For proper selection of a PHY layer, user must use Mbed config system. For this purpose an mbed_lib.json is provided which can be overriden by the user defined mbed_app.json. By default the EU868 band is selected as a PHY layer. User must set relevant keys for the selected connection mechanism.
2017-11-27 13:17:18 +00:00
}
LoRa: LoRaPHY dependency removed from LoRaMacStack - 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
2018-03-15 08:43:31 +00:00
if(_loramac.tx_ongoing()) {
[IOTCELL-282] Code cleanup/simplification and rules Baseline is changed to use a single set of data structures that simplifies the code in the LoRaWANStack and Mac layer. We are now following certian rules for naming data structures. - All structures visible outside their domain are prefixed as 'lorawan_' - All mac structures are prefixed as 'loramac_' - All subsystem or module strucutures carry their name in prefix, like 'mcps_' PHY layer still have legacy camel case data structures which will be entertained later while we will be simplifying PHY layer. Test cases are also updated with the new data structure naming conventions. One major difference from the previous baseline is the removal of static buffer from mcps indication. And we do not copy data from stack buffer to rx_msg buffer. This saves at least 512 bytes. It may look like now that if we have received something but the user have not read from the buffer, then the buffer will be overwritten and we will lose previous frame. Yes, we will. But the same will happen even if we would have copied the buffer into rx_msg because then the rx_msg gets overwritten. So we decide to abandon copying the buffer at multiple locations. We inform the user about reception, if the user doesn't read and the data gets overwritten, then so be it.
2018-01-12 14:39:31 +00:00
return LORAWAN_STATUS_WOULD_BLOCK;
Adding LoRaWANStack class to control MAC and PHY LoRaWANStack class is our controller layer on top of our current MAC and PHY layer. It provides services to an implementation of LoRaWANBase class. It is a singleton class owing to the fact that the mac layer underneath is not a class object. Instead, it uses the MAC via setting mib, mlme, mcps requests and getting responses back from the mac layer using confirmations and indications. In essense this class is a special handle for mac layer underneath which is predominantly reference design based. In future we may refactor the LoRaMac.cpp code to make it object oriented and cleaner. At one end, it binds the application selected radio driver with the PHY layer and at the other end it provides services to upper layers handling the mac via well defined APIs. For proper selection of a PHY layer, user must use Mbed config system. For this purpose an mbed_lib.json is provided which can be overriden by the user defined mbed_app.json. By default the EU868 band is selected as a PHY layer. User must set relevant keys for the selected connection mechanism.
2017-11-27 13:17:18 +00:00
}
Move all compliance test code inside compilation flag All compliance test related codes are now inside LORAWAN_COMPLIANCE_TEST build flag. This will reduce memory usage in when compliance test codes are not needed.
2018-01-05 10:13:48 +00:00
#if defined(LORAWAN_COMPLIANCE_TEST)
Adding LoRaWANStack class to control MAC and PHY LoRaWANStack class is our controller layer on top of our current MAC and PHY layer. It provides services to an implementation of LoRaWANBase class. It is a singleton class owing to the fact that the mac layer underneath is not a class object. Instead, it uses the MAC via setting mib, mlme, mcps requests and getting responses back from the mac layer using confirmations and indications. In essense this class is a special handle for mac layer underneath which is predominantly reference design based. In future we may refactor the LoRaMac.cpp code to make it object oriented and cleaner. At one end, it binds the application selected radio driver with the PHY layer and at the other end it provides services to upper layers handling the mac via well defined APIs. For proper selection of a PHY layer, user must use Mbed config system. For this purpose an mbed_lib.json is provided which can be overriden by the user defined mbed_app.json. By default the EU868 band is selected as a PHY layer. User must set relevant keys for the selected connection mechanism.
2017-11-27 13:17:18 +00:00
if (_compliance_test.running) {
[IOTCELL-282] Code cleanup/simplification and rules Baseline is changed to use a single set of data structures that simplifies the code in the LoRaWANStack and Mac layer. We are now following certian rules for naming data structures. - All structures visible outside their domain are prefixed as 'lorawan_' - All mac structures are prefixed as 'loramac_' - All subsystem or module strucutures carry their name in prefix, like 'mcps_' PHY layer still have legacy camel case data structures which will be entertained later while we will be simplifying PHY layer. Test cases are also updated with the new data structure naming conventions. One major difference from the previous baseline is the removal of static buffer from mcps indication. And we do not copy data from stack buffer to rx_msg buffer. This saves at least 512 bytes. It may look like now that if we have received something but the user have not read from the buffer, then the buffer will be overwritten and we will lose previous frame. Yes, we will. But the same will happen even if we would have copied the buffer into rx_msg because then the rx_msg gets overwritten. So we decide to abandon copying the buffer at multiple locations. We inform the user about reception, if the user doesn't read and the data gets overwritten, then so be it.
2018-01-12 14:39:31 +00:00
return LORAWAN_STATUS_COMPLIANCE_TEST_ON;
Adding LoRaWANStack class to control MAC and PHY LoRaWANStack class is our controller layer on top of our current MAC and PHY layer. It provides services to an implementation of LoRaWANBase class. It is a singleton class owing to the fact that the mac layer underneath is not a class object. Instead, it uses the MAC via setting mib, mlme, mcps requests and getting responses back from the mac layer using confirmations and indications. In essense this class is a special handle for mac layer underneath which is predominantly reference design based. In future we may refactor the LoRaMac.cpp code to make it object oriented and cleaner. At one end, it binds the application selected radio driver with the PHY layer and at the other end it provides services to upper layers handling the mac via well defined APIs. For proper selection of a PHY layer, user must use Mbed config system. For this purpose an mbed_lib.json is provided which can be overriden by the user defined mbed_app.json. By default the EU868 band is selected as a PHY layer. User must set relevant keys for the selected connection mechanism.
2017-11-27 13:17:18 +00:00
}
Move all compliance test code inside compilation flag All compliance test related codes are now inside LORAWAN_COMPLIANCE_TEST build flag. This will reduce memory usage in when compliance test codes are not needed.
2018-01-05 10:13:48 +00:00
#endif
Adding LoRaWANStack class to control MAC and PHY LoRaWANStack class is our controller layer on top of our current MAC and PHY layer. It provides services to an implementation of LoRaWANBase class. It is a singleton class owing to the fact that the mac layer underneath is not a class object. Instead, it uses the MAC via setting mib, mlme, mcps requests and getting responses back from the mac layer using confirmations and indications. In essense this class is a special handle for mac layer underneath which is predominantly reference design based. In future we may refactor the LoRaMac.cpp code to make it object oriented and cleaner. At one end, it binds the application selected radio driver with the PHY layer and at the other end it provides services to upper layers handling the mac via well defined APIs. For proper selection of a PHY layer, user must use Mbed config system. For this purpose an mbed_lib.json is provided which can be overriden by the user defined mbed_app.json. By default the EU868 band is selected as a PHY layer. User must set relevant keys for the selected connection mechanism.
2017-11-27 13:17:18 +00:00
[IOTCELL-282] Code cleanup/simplification and rules Baseline is changed to use a single set of data structures that simplifies the code in the LoRaWANStack and Mac layer. We are now following certian rules for naming data structures. - All structures visible outside their domain are prefixed as 'lorawan_' - All mac structures are prefixed as 'loramac_' - All subsystem or module strucutures carry their name in prefix, like 'mcps_' PHY layer still have legacy camel case data structures which will be entertained later while we will be simplifying PHY layer. Test cases are also updated with the new data structure naming conventions. One major difference from the previous baseline is the removal of static buffer from mcps indication. And we do not copy data from stack buffer to rx_msg buffer. This saves at least 512 bytes. It may look like now that if we have received something but the user have not read from the buffer, then the buffer will be overwritten and we will lose previous frame. Yes, we will. But the same will happen even if we would have copied the buffer into rx_msg because then the rx_msg gets overwritten. So we decide to abandon copying the buffer at multiple locations. We inform the user about reception, if the user doesn't read and the data gets overwritten, then so be it.
2018-01-12 14:39:31 +00:00
lorawan_status_t status;
Adding LoRaWANStack class to control MAC and PHY LoRaWANStack class is our controller layer on top of our current MAC and PHY layer. It provides services to an implementation of LoRaWANBase class. It is a singleton class owing to the fact that the mac layer underneath is not a class object. Instead, it uses the MAC via setting mib, mlme, mcps requests and getting responses back from the mac layer using confirmations and indications. In essense this class is a special handle for mac layer underneath which is predominantly reference design based. In future we may refactor the LoRaMac.cpp code to make it object oriented and cleaner. At one end, it binds the application selected radio driver with the PHY layer and at the other end it provides services to upper layers handling the mac via well defined APIs. For proper selection of a PHY layer, user must use Mbed config system. For this purpose an mbed_lib.json is provided which can be overriden by the user defined mbed_app.json. By default the EU868 band is selected as a PHY layer. User must set relevant keys for the selected connection mechanism.
2017-11-27 13:17:18 +00:00
LoRaWANStack is made independent of MAC sublayers - Only internal changes, no API has been broke. - Tested by manually running Green tea tests
2018-03-16 11:12:50 +00:00
if (_loramac.nwk_joined() == false) {
return LORAWAN_STATUS_NO_NETWORK_JOINED;
Adding LoRaWANStack class to control MAC and PHY LoRaWANStack class is our controller layer on top of our current MAC and PHY layer. It provides services to an implementation of LoRaWANBase class. It is a singleton class owing to the fact that the mac layer underneath is not a class object. Instead, it uses the MAC via setting mib, mlme, mcps requests and getting responses back from the mac layer using confirmations and indications. In essense this class is a special handle for mac layer underneath which is predominantly reference design based. In future we may refactor the LoRaMac.cpp code to make it object oriented and cleaner. At one end, it binds the application selected radio driver with the PHY layer and at the other end it provides services to upper layers handling the mac via well defined APIs. For proper selection of a PHY layer, user must use Mbed config system. For this purpose an mbed_lib.json is provided which can be overriden by the user defined mbed_app.json. By default the EU868 band is selected as a PHY layer. User must set relevant keys for the selected connection mechanism.
2017-11-27 13:17:18 +00:00
}
status = set_application_port(port);
[IOTCELL-282] Code cleanup/simplification and rules Baseline is changed to use a single set of data structures that simplifies the code in the LoRaWANStack and Mac layer. We are now following certian rules for naming data structures. - All structures visible outside their domain are prefixed as 'lorawan_' - All mac structures are prefixed as 'loramac_' - All subsystem or module strucutures carry their name in prefix, like 'mcps_' PHY layer still have legacy camel case data structures which will be entertained later while we will be simplifying PHY layer. Test cases are also updated with the new data structure naming conventions. One major difference from the previous baseline is the removal of static buffer from mcps indication. And we do not copy data from stack buffer to rx_msg buffer. This saves at least 512 bytes. It may look like now that if we have received something but the user have not read from the buffer, then the buffer will be overwritten and we will lose previous frame. Yes, we will. But the same will happen even if we would have copied the buffer into rx_msg because then the rx_msg gets overwritten. So we decide to abandon copying the buffer at multiple locations. We inform the user about reception, if the user doesn't read and the data gets overwritten, then so be it.
2018-01-12 14:39:31 +00:00
if (status != LORAWAN_STATUS_OK) {
Adding LoRaWANStack class to control MAC and PHY LoRaWANStack class is our controller layer on top of our current MAC and PHY layer. It provides services to an implementation of LoRaWANBase class. It is a singleton class owing to the fact that the mac layer underneath is not a class object. Instead, it uses the MAC via setting mib, mlme, mcps requests and getting responses back from the mac layer using confirmations and indications. In essense this class is a special handle for mac layer underneath which is predominantly reference design based. In future we may refactor the LoRaMac.cpp code to make it object oriented and cleaner. At one end, it binds the application selected radio driver with the PHY layer and at the other end it provides services to upper layers handling the mac via well defined APIs. For proper selection of a PHY layer, user must use Mbed config system. For this purpose an mbed_lib.json is provided which can be overriden by the user defined mbed_app.json. By default the EU868 band is selected as a PHY layer. User must set relevant keys for the selected connection mechanism.
2017-11-27 13:17:18 +00:00
tr_error("Illegal application port definition.");
return status;
}
LoRaWANStack is made independent of MAC sublayers - Only internal changes, no API has been broke. - Tested by manually running Green tea tests
2018-03-16 11:12:50 +00:00
if (flags == 0 ||
(flags & MSG_FLAG_MASK) == (MSG_CONFIRMED_FLAG|MSG_UNCONFIRMED_FLAG)) {
Adding LoRaWANStack class to control MAC and PHY LoRaWANStack class is our controller layer on top of our current MAC and PHY layer. It provides services to an implementation of LoRaWANBase class. It is a singleton class owing to the fact that the mac layer underneath is not a class object. Instead, it uses the MAC via setting mib, mlme, mcps requests and getting responses back from the mac layer using confirmations and indications. In essense this class is a special handle for mac layer underneath which is predominantly reference design based. In future we may refactor the LoRaMac.cpp code to make it object oriented and cleaner. At one end, it binds the application selected radio driver with the PHY layer and at the other end it provides services to upper layers handling the mac via well defined APIs. For proper selection of a PHY layer, user must use Mbed config system. For this purpose an mbed_lib.json is provided which can be overriden by the user defined mbed_app.json. By default the EU868 band is selected as a PHY layer. User must set relevant keys for the selected connection mechanism.
2017-11-27 13:17:18 +00:00
tr_error("CONFIRMED and UNCONFIRMED are mutually exclusive for send()");
[IOTCELL-282] Code cleanup/simplification and rules Baseline is changed to use a single set of data structures that simplifies the code in the LoRaWANStack and Mac layer. We are now following certian rules for naming data structures. - All structures visible outside their domain are prefixed as 'lorawan_' - All mac structures are prefixed as 'loramac_' - All subsystem or module strucutures carry their name in prefix, like 'mcps_' PHY layer still have legacy camel case data structures which will be entertained later while we will be simplifying PHY layer. Test cases are also updated with the new data structure naming conventions. One major difference from the previous baseline is the removal of static buffer from mcps indication. And we do not copy data from stack buffer to rx_msg buffer. This saves at least 512 bytes. It may look like now that if we have received something but the user have not read from the buffer, then the buffer will be overwritten and we will lose previous frame. Yes, we will. But the same will happen even if we would have copied the buffer into rx_msg because then the rx_msg gets overwritten. So we decide to abandon copying the buffer at multiple locations. We inform the user about reception, if the user doesn't read and the data gets overwritten, then so be it.
2018-01-12 14:39:31 +00:00
return LORAWAN_STATUS_PARAMETER_INVALID;
Adding LoRaWANStack class to control MAC and PHY LoRaWANStack class is our controller layer on top of our current MAC and PHY layer. It provides services to an implementation of LoRaWANBase class. It is a singleton class owing to the fact that the mac layer underneath is not a class object. Instead, it uses the MAC via setting mib, mlme, mcps requests and getting responses back from the mac layer using confirmations and indications. In essense this class is a special handle for mac layer underneath which is predominantly reference design based. In future we may refactor the LoRaMac.cpp code to make it object oriented and cleaner. At one end, it binds the application selected radio driver with the PHY layer and at the other end it provides services to upper layers handling the mac via well defined APIs. For proper selection of a PHY layer, user must use Mbed config system. For this purpose an mbed_lib.json is provided which can be overriden by the user defined mbed_app.json. By default the EU868 band is selected as a PHY layer. User must set relevant keys for the selected connection mechanism.
2017-11-27 13:17:18 +00:00
}
LoRa: LoRaPHY dependency removed from LoRaMacStack - 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
2018-03-15 08:43:31 +00:00
int16_t len = _loramac.prepare_ongoing_tx(port, data, length, flags, _num_retry);
Adding LoRaWANStack class to control MAC and PHY LoRaWANStack class is our controller layer on top of our current MAC and PHY layer. It provides services to an implementation of LoRaWANBase class. It is a singleton class owing to the fact that the mac layer underneath is not a class object. Instead, it uses the MAC via setting mib, mlme, mcps requests and getting responses back from the mac layer using confirmations and indications. In essense this class is a special handle for mac layer underneath which is predominantly reference design based. In future we may refactor the LoRaMac.cpp code to make it object oriented and cleaner. At one end, it binds the application selected radio driver with the PHY layer and at the other end it provides services to upper layers handling the mac via well defined APIs. For proper selection of a PHY layer, user must use Mbed config system. For this purpose an mbed_lib.json is provided which can be overriden by the user defined mbed_app.json. By default the EU868 band is selected as a PHY layer. User must set relevant keys for the selected connection mechanism.
2017-11-27 13:17:18 +00:00
LoRa: LoRaWANInterface refactored. - Only internal changes, no functionality changes - Some minor improvements to LoRaWanStack
2018-03-12 11:30:00 +00:00
status = lora_state_machine(DEVICE_STATE_SEND);
Adding LoRaWANStack class to control MAC and PHY LoRaWANStack class is our controller layer on top of our current MAC and PHY layer. It provides services to an implementation of LoRaWANBase class. It is a singleton class owing to the fact that the mac layer underneath is not a class object. Instead, it uses the MAC via setting mib, mlme, mcps requests and getting responses back from the mac layer using confirmations and indications. In essense this class is a special handle for mac layer underneath which is predominantly reference design based. In future we may refactor the LoRaMac.cpp code to make it object oriented and cleaner. At one end, it binds the application selected radio driver with the PHY layer and at the other end it provides services to upper layers handling the mac via well defined APIs. For proper selection of a PHY layer, user must use Mbed config system. For this purpose an mbed_lib.json is provided which can be overriden by the user defined mbed_app.json. By default the EU868 band is selected as a PHY layer. User must set relevant keys for the selected connection mechanism.
2017-11-27 13:17:18 +00:00
// send user the length of data which is scheduled now.
// user should take care of the pending data.
LoRa: LoRaPHY dependency removed from LoRaMacStack - 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
2018-03-15 08:43:31 +00:00
return (status == LORAWAN_STATUS_OK) ? len : (int16_t) status;
Adding LoRaWANStack class to control MAC and PHY LoRaWANStack class is our controller layer on top of our current MAC and PHY layer. It provides services to an implementation of LoRaWANBase class. It is a singleton class owing to the fact that the mac layer underneath is not a class object. Instead, it uses the MAC via setting mib, mlme, mcps requests and getting responses back from the mac layer using confirmations and indications. In essense this class is a special handle for mac layer underneath which is predominantly reference design based. In future we may refactor the LoRaMac.cpp code to make it object oriented and cleaner. At one end, it binds the application selected radio driver with the PHY layer and at the other end it provides services to upper layers handling the mac via well defined APIs. For proper selection of a PHY layer, user must use Mbed config system. For this purpose an mbed_lib.json is provided which can be overriden by the user defined mbed_app.json. By default the EU868 band is selected as a PHY layer. User must set relevant keys for the selected connection mechanism.
2017-11-27 13:17:18 +00:00
}
int16_t LoRaWANStack::handle_rx(const uint8_t port, uint8_t* data,
uint16_t length, uint8_t flags)
{
if (!_lw_session.active) {
[IOTCELL-282] Code cleanup/simplification and rules Baseline is changed to use a single set of data structures that simplifies the code in the LoRaWANStack and Mac layer. We are now following certian rules for naming data structures. - All structures visible outside their domain are prefixed as 'lorawan_' - All mac structures are prefixed as 'loramac_' - All subsystem or module strucutures carry their name in prefix, like 'mcps_' PHY layer still have legacy camel case data structures which will be entertained later while we will be simplifying PHY layer. Test cases are also updated with the new data structure naming conventions. One major difference from the previous baseline is the removal of static buffer from mcps indication. And we do not copy data from stack buffer to rx_msg buffer. This saves at least 512 bytes. It may look like now that if we have received something but the user have not read from the buffer, then the buffer will be overwritten and we will lose previous frame. Yes, we will. But the same will happen even if we would have copied the buffer into rx_msg because then the rx_msg gets overwritten. So we decide to abandon copying the buffer at multiple locations. We inform the user about reception, if the user doesn't read and the data gets overwritten, then so be it.
2018-01-12 14:39:31 +00:00
return LORAWAN_STATUS_NO_ACTIVE_SESSIONS;
Adding LoRaWANStack class to control MAC and PHY LoRaWANStack class is our controller layer on top of our current MAC and PHY layer. It provides services to an implementation of LoRaWANBase class. It is a singleton class owing to the fact that the mac layer underneath is not a class object. Instead, it uses the MAC via setting mib, mlme, mcps requests and getting responses back from the mac layer using confirmations and indications. In essense this class is a special handle for mac layer underneath which is predominantly reference design based. In future we may refactor the LoRaMac.cpp code to make it object oriented and cleaner. At one end, it binds the application selected radio driver with the PHY layer and at the other end it provides services to upper layers handling the mac via well defined APIs. For proper selection of a PHY layer, user must use Mbed config system. For this purpose an mbed_lib.json is provided which can be overriden by the user defined mbed_app.json. By default the EU868 band is selected as a PHY layer. User must set relevant keys for the selected connection mechanism.
2017-11-27 13:17:18 +00:00
}
// No messages to read.
if (!_rx_msg.receive_ready) {
[IOTCELL-282] Code cleanup/simplification and rules Baseline is changed to use a single set of data structures that simplifies the code in the LoRaWANStack and Mac layer. We are now following certian rules for naming data structures. - All structures visible outside their domain are prefixed as 'lorawan_' - All mac structures are prefixed as 'loramac_' - All subsystem or module strucutures carry their name in prefix, like 'mcps_' PHY layer still have legacy camel case data structures which will be entertained later while we will be simplifying PHY layer. Test cases are also updated with the new data structure naming conventions. One major difference from the previous baseline is the removal of static buffer from mcps indication. And we do not copy data from stack buffer to rx_msg buffer. This saves at least 512 bytes. It may look like now that if we have received something but the user have not read from the buffer, then the buffer will be overwritten and we will lose previous frame. Yes, we will. But the same will happen even if we would have copied the buffer into rx_msg because then the rx_msg gets overwritten. So we decide to abandon copying the buffer at multiple locations. We inform the user about reception, if the user doesn't read and the data gets overwritten, then so be it.
2018-01-12 14:39:31 +00:00
return LORAWAN_STATUS_WOULD_BLOCK;
Adding LoRaWANStack class to control MAC and PHY LoRaWANStack class is our controller layer on top of our current MAC and PHY layer. It provides services to an implementation of LoRaWANBase class. It is a singleton class owing to the fact that the mac layer underneath is not a class object. Instead, it uses the MAC via setting mib, mlme, mcps requests and getting responses back from the mac layer using confirmations and indications. In essense this class is a special handle for mac layer underneath which is predominantly reference design based. In future we may refactor the LoRaMac.cpp code to make it object oriented and cleaner. At one end, it binds the application selected radio driver with the PHY layer and at the other end it provides services to upper layers handling the mac via well defined APIs. For proper selection of a PHY layer, user must use Mbed config system. For this purpose an mbed_lib.json is provided which can be overriden by the user defined mbed_app.json. By default the EU868 band is selected as a PHY layer. User must set relevant keys for the selected connection mechanism.
2017-11-27 13:17:18 +00:00
}
Move all compliance test code inside compilation flag All compliance test related codes are now inside LORAWAN_COMPLIANCE_TEST build flag. This will reduce memory usage in when compliance test codes are not needed.
2018-01-05 10:13:48 +00:00
#if defined(LORAWAN_COMPLIANCE_TEST)
Adding LoRaWANStack class to control MAC and PHY LoRaWANStack class is our controller layer on top of our current MAC and PHY layer. It provides services to an implementation of LoRaWANBase class. It is a singleton class owing to the fact that the mac layer underneath is not a class object. Instead, it uses the MAC via setting mib, mlme, mcps requests and getting responses back from the mac layer using confirmations and indications. In essense this class is a special handle for mac layer underneath which is predominantly reference design based. In future we may refactor the LoRaMac.cpp code to make it object oriented and cleaner. At one end, it binds the application selected radio driver with the PHY layer and at the other end it provides services to upper layers handling the mac via well defined APIs. For proper selection of a PHY layer, user must use Mbed config system. For this purpose an mbed_lib.json is provided which can be overriden by the user defined mbed_app.json. By default the EU868 band is selected as a PHY layer. User must set relevant keys for the selected connection mechanism.
2017-11-27 13:17:18 +00:00
if (_compliance_test.running) {
[IOTCELL-282] Code cleanup/simplification and rules Baseline is changed to use a single set of data structures that simplifies the code in the LoRaWANStack and Mac layer. We are now following certian rules for naming data structures. - All structures visible outside their domain are prefixed as 'lorawan_' - All mac structures are prefixed as 'loramac_' - All subsystem or module strucutures carry their name in prefix, like 'mcps_' PHY layer still have legacy camel case data structures which will be entertained later while we will be simplifying PHY layer. Test cases are also updated with the new data structure naming conventions. One major difference from the previous baseline is the removal of static buffer from mcps indication. And we do not copy data from stack buffer to rx_msg buffer. This saves at least 512 bytes. It may look like now that if we have received something but the user have not read from the buffer, then the buffer will be overwritten and we will lose previous frame. Yes, we will. But the same will happen even if we would have copied the buffer into rx_msg because then the rx_msg gets overwritten. So we decide to abandon copying the buffer at multiple locations. We inform the user about reception, if the user doesn't read and the data gets overwritten, then so be it.
2018-01-12 14:39:31 +00:00
return LORAWAN_STATUS_COMPLIANCE_TEST_ON;
Adding LoRaWANStack class to control MAC and PHY LoRaWANStack class is our controller layer on top of our current MAC and PHY layer. It provides services to an implementation of LoRaWANBase class. It is a singleton class owing to the fact that the mac layer underneath is not a class object. Instead, it uses the MAC via setting mib, mlme, mcps requests and getting responses back from the mac layer using confirmations and indications. In essense this class is a special handle for mac layer underneath which is predominantly reference design based. In future we may refactor the LoRaMac.cpp code to make it object oriented and cleaner. At one end, it binds the application selected radio driver with the PHY layer and at the other end it provides services to upper layers handling the mac via well defined APIs. For proper selection of a PHY layer, user must use Mbed config system. For this purpose an mbed_lib.json is provided which can be overriden by the user defined mbed_app.json. By default the EU868 band is selected as a PHY layer. User must set relevant keys for the selected connection mechanism.
2017-11-27 13:17:18 +00:00
}
Move all compliance test code inside compilation flag All compliance test related codes are now inside LORAWAN_COMPLIANCE_TEST build flag. This will reduce memory usage in when compliance test codes are not needed.
2018-01-05 10:13:48 +00:00
#endif
Adding LoRaWANStack class to control MAC and PHY LoRaWANStack class is our controller layer on top of our current MAC and PHY layer. It provides services to an implementation of LoRaWANBase class. It is a singleton class owing to the fact that the mac layer underneath is not a class object. Instead, it uses the MAC via setting mib, mlme, mcps requests and getting responses back from the mac layer using confirmations and indications. In essense this class is a special handle for mac layer underneath which is predominantly reference design based. In future we may refactor the LoRaMac.cpp code to make it object oriented and cleaner. At one end, it binds the application selected radio driver with the PHY layer and at the other end it provides services to upper layers handling the mac via well defined APIs. For proper selection of a PHY layer, user must use Mbed config system. For this purpose an mbed_lib.json is provided which can be overriden by the user defined mbed_app.json. By default the EU868 band is selected as a PHY layer. User must set relevant keys for the selected connection mechanism.
2017-11-27 13:17:18 +00:00
LoRa: LoRaWANInterface refactored. - Only internal changes, no functionality changes - Some minor improvements to LoRaWanStack
2018-03-12 11:30:00 +00:00
if (data == NULL || length == 0) {
[IOTCELL-282] Code cleanup/simplification and rules Baseline is changed to use a single set of data structures that simplifies the code in the LoRaWANStack and Mac layer. We are now following certian rules for naming data structures. - All structures visible outside their domain are prefixed as 'lorawan_' - All mac structures are prefixed as 'loramac_' - All subsystem or module strucutures carry their name in prefix, like 'mcps_' PHY layer still have legacy camel case data structures which will be entertained later while we will be simplifying PHY layer. Test cases are also updated with the new data structure naming conventions. One major difference from the previous baseline is the removal of static buffer from mcps indication. And we do not copy data from stack buffer to rx_msg buffer. This saves at least 512 bytes. It may look like now that if we have received something but the user have not read from the buffer, then the buffer will be overwritten and we will lose previous frame. Yes, we will. But the same will happen even if we would have copied the buffer into rx_msg because then the rx_msg gets overwritten. So we decide to abandon copying the buffer at multiple locations. We inform the user about reception, if the user doesn't read and the data gets overwritten, then so be it.
2018-01-12 14:39:31 +00:00
return LORAWAN_STATUS_PARAMETER_INVALID;
Adding LoRaWANStack class to control MAC and PHY LoRaWANStack class is our controller layer on top of our current MAC and PHY layer. It provides services to an implementation of LoRaWANBase class. It is a singleton class owing to the fact that the mac layer underneath is not a class object. Instead, it uses the MAC via setting mib, mlme, mcps requests and getting responses back from the mac layer using confirmations and indications. In essense this class is a special handle for mac layer underneath which is predominantly reference design based. In future we may refactor the LoRaMac.cpp code to make it object oriented and cleaner. At one end, it binds the application selected radio driver with the PHY layer and at the other end it provides services to upper layers handling the mac via well defined APIs. For proper selection of a PHY layer, user must use Mbed config system. For this purpose an mbed_lib.json is provided which can be overriden by the user defined mbed_app.json. By default the EU868 band is selected as a PHY layer. User must set relevant keys for the selected connection mechanism.
2017-11-27 13:17:18 +00:00
}
[IOTCELL-282] Code cleanup/simplification and rules Baseline is changed to use a single set of data structures that simplifies the code in the LoRaWANStack and Mac layer. We are now following certian rules for naming data structures. - All structures visible outside their domain are prefixed as 'lorawan_' - All mac structures are prefixed as 'loramac_' - All subsystem or module strucutures carry their name in prefix, like 'mcps_' PHY layer still have legacy camel case data structures which will be entertained later while we will be simplifying PHY layer. Test cases are also updated with the new data structure naming conventions. One major difference from the previous baseline is the removal of static buffer from mcps indication. And we do not copy data from stack buffer to rx_msg buffer. This saves at least 512 bytes. It may look like now that if we have received something but the user have not read from the buffer, then the buffer will be overwritten and we will lose previous frame. Yes, we will. But the same will happen even if we would have copied the buffer into rx_msg because then the rx_msg gets overwritten. So we decide to abandon copying the buffer at multiple locations. We inform the user about reception, if the user doesn't read and the data gets overwritten, then so be it.
2018-01-12 14:39:31 +00:00
uint8_t *base_ptr = _rx_msg.msg.mcps_indication.buffer;
uint16_t base_size = _rx_msg.msg.mcps_indication.buffer_size;
Adding LoRaWANStack class to control MAC and PHY LoRaWANStack class is our controller layer on top of our current MAC and PHY layer. It provides services to an implementation of LoRaWANBase class. It is a singleton class owing to the fact that the mac layer underneath is not a class object. Instead, it uses the MAC via setting mib, mlme, mcps requests and getting responses back from the mac layer using confirmations and indications. In essense this class is a special handle for mac layer underneath which is predominantly reference design based. In future we may refactor the LoRaMac.cpp code to make it object oriented and cleaner. At one end, it binds the application selected radio driver with the PHY layer and at the other end it provides services to upper layers handling the mac via well defined APIs. For proper selection of a PHY layer, user must use Mbed config system. For this purpose an mbed_lib.json is provided which can be overriden by the user defined mbed_app.json. By default the EU868 band is selected as a PHY layer. User must set relevant keys for the selected connection mechanism.
2017-11-27 13:17:18 +00:00
bool read_complete = false;
[IOTCELL-282] Code cleanup/simplification and rules Baseline is changed to use a single set of data structures that simplifies the code in the LoRaWANStack and Mac layer. We are now following certian rules for naming data structures. - All structures visible outside their domain are prefixed as 'lorawan_' - All mac structures are prefixed as 'loramac_' - All subsystem or module strucutures carry their name in prefix, like 'mcps_' PHY layer still have legacy camel case data structures which will be entertained later while we will be simplifying PHY layer. Test cases are also updated with the new data structure naming conventions. One major difference from the previous baseline is the removal of static buffer from mcps indication. And we do not copy data from stack buffer to rx_msg buffer. This saves at least 512 bytes. It may look like now that if we have received something but the user have not read from the buffer, then the buffer will be overwritten and we will lose previous frame. Yes, we will. But the same will happen even if we would have copied the buffer into rx_msg because then the rx_msg gets overwritten. So we decide to abandon copying the buffer at multiple locations. We inform the user about reception, if the user doesn't read and the data gets overwritten, then so be it.
2018-01-12 14:39:31 +00:00
if (_rx_msg.msg.mcps_indication.port != port) {
Adding LoRaWANStack class to control MAC and PHY LoRaWANStack class is our controller layer on top of our current MAC and PHY layer. It provides services to an implementation of LoRaWANBase class. It is a singleton class owing to the fact that the mac layer underneath is not a class object. Instead, it uses the MAC via setting mib, mlme, mcps requests and getting responses back from the mac layer using confirmations and indications. In essense this class is a special handle for mac layer underneath which is predominantly reference design based. In future we may refactor the LoRaMac.cpp code to make it object oriented and cleaner. At one end, it binds the application selected radio driver with the PHY layer and at the other end it provides services to upper layers handling the mac via well defined APIs. For proper selection of a PHY layer, user must use Mbed config system. For this purpose an mbed_lib.json is provided which can be overriden by the user defined mbed_app.json. By default the EU868 band is selected as a PHY layer. User must set relevant keys for the selected connection mechanism.
2017-11-27 13:17:18 +00:00
// Nothing yet received for this particular port
[IOTCELL-282] Code cleanup/simplification and rules Baseline is changed to use a single set of data structures that simplifies the code in the LoRaWANStack and Mac layer. We are now following certian rules for naming data structures. - All structures visible outside their domain are prefixed as 'lorawan_' - All mac structures are prefixed as 'loramac_' - All subsystem or module strucutures carry their name in prefix, like 'mcps_' PHY layer still have legacy camel case data structures which will be entertained later while we will be simplifying PHY layer. Test cases are also updated with the new data structure naming conventions. One major difference from the previous baseline is the removal of static buffer from mcps indication. And we do not copy data from stack buffer to rx_msg buffer. This saves at least 512 bytes. It may look like now that if we have received something but the user have not read from the buffer, then the buffer will be overwritten and we will lose previous frame. Yes, we will. But the same will happen even if we would have copied the buffer into rx_msg because then the rx_msg gets overwritten. So we decide to abandon copying the buffer at multiple locations. We inform the user about reception, if the user doesn't read and the data gets overwritten, then so be it.
2018-01-12 14:39:31 +00:00
return LORAWAN_STATUS_WOULD_BLOCK;
Adding LoRaWANStack class to control MAC and PHY LoRaWANStack class is our controller layer on top of our current MAC and PHY layer. It provides services to an implementation of LoRaWANBase class. It is a singleton class owing to the fact that the mac layer underneath is not a class object. Instead, it uses the MAC via setting mib, mlme, mcps requests and getting responses back from the mac layer using confirmations and indications. In essense this class is a special handle for mac layer underneath which is predominantly reference design based. In future we may refactor the LoRaMac.cpp code to make it object oriented and cleaner. At one end, it binds the application selected radio driver with the PHY layer and at the other end it provides services to upper layers handling the mac via well defined APIs. For proper selection of a PHY layer, user must use Mbed config system. For this purpose an mbed_lib.json is provided which can be overriden by the user defined mbed_app.json. By default the EU868 band is selected as a PHY layer. User must set relevant keys for the selected connection mechanism.
2017-11-27 13:17:18 +00:00
}
// check if message received is a Confirmed message and user subscribed to it or not
[IOTCELL-282] Code cleanup/simplification and rules Baseline is changed to use a single set of data structures that simplifies the code in the LoRaWANStack and Mac layer. We are now following certian rules for naming data structures. - All structures visible outside their domain are prefixed as 'lorawan_' - All mac structures are prefixed as 'loramac_' - All subsystem or module strucutures carry their name in prefix, like 'mcps_' PHY layer still have legacy camel case data structures which will be entertained later while we will be simplifying PHY layer. Test cases are also updated with the new data structure naming conventions. One major difference from the previous baseline is the removal of static buffer from mcps indication. And we do not copy data from stack buffer to rx_msg buffer. This saves at least 512 bytes. It may look like now that if we have received something but the user have not read from the buffer, then the buffer will be overwritten and we will lose previous frame. Yes, we will. But the same will happen even if we would have copied the buffer into rx_msg because then the rx_msg gets overwritten. So we decide to abandon copying the buffer at multiple locations. We inform the user about reception, if the user doesn't read and the data gets overwritten, then so be it.
2018-01-12 14:39:31 +00:00
if (_rx_msg.msg.mcps_indication.type == MCPS_CONFIRMED
Adding LoRaWANStack class to control MAC and PHY LoRaWANStack class is our controller layer on top of our current MAC and PHY layer. It provides services to an implementation of LoRaWANBase class. It is a singleton class owing to the fact that the mac layer underneath is not a class object. Instead, it uses the MAC via setting mib, mlme, mcps requests and getting responses back from the mac layer using confirmations and indications. In essense this class is a special handle for mac layer underneath which is predominantly reference design based. In future we may refactor the LoRaMac.cpp code to make it object oriented and cleaner. At one end, it binds the application selected radio driver with the PHY layer and at the other end it provides services to upper layers handling the mac via well defined APIs. For proper selection of a PHY layer, user must use Mbed config system. For this purpose an mbed_lib.json is provided which can be overriden by the user defined mbed_app.json. By default the EU868 band is selected as a PHY layer. User must set relevant keys for the selected connection mechanism.
2017-11-27 13:17:18 +00:00
&& ((flags & MSG_FLAG_MASK) == MSG_CONFIRMED_FLAG
|| (flags & MSG_FLAG_MASK) == MSG_CONFIRMED_MULTICAST
|| (flags & MSG_FLAG_MASK) == MSG_CONFIRMED_PROPRIETARY)) {
tr_debug("RX - Confirmed Message, flags=%d", flags);
}
// check if message received is a Unconfirmed message and user subscribed to it or not
[IOTCELL-282] Code cleanup/simplification and rules Baseline is changed to use a single set of data structures that simplifies the code in the LoRaWANStack and Mac layer. We are now following certian rules for naming data structures. - All structures visible outside their domain are prefixed as 'lorawan_' - All mac structures are prefixed as 'loramac_' - All subsystem or module strucutures carry their name in prefix, like 'mcps_' PHY layer still have legacy camel case data structures which will be entertained later while we will be simplifying PHY layer. Test cases are also updated with the new data structure naming conventions. One major difference from the previous baseline is the removal of static buffer from mcps indication. And we do not copy data from stack buffer to rx_msg buffer. This saves at least 512 bytes. It may look like now that if we have received something but the user have not read from the buffer, then the buffer will be overwritten and we will lose previous frame. Yes, we will. But the same will happen even if we would have copied the buffer into rx_msg because then the rx_msg gets overwritten. So we decide to abandon copying the buffer at multiple locations. We inform the user about reception, if the user doesn't read and the data gets overwritten, then so be it.
2018-01-12 14:39:31 +00:00
if (_rx_msg.msg.mcps_indication.type == MCPS_UNCONFIRMED
Adding LoRaWANStack class to control MAC and PHY LoRaWANStack class is our controller layer on top of our current MAC and PHY layer. It provides services to an implementation of LoRaWANBase class. It is a singleton class owing to the fact that the mac layer underneath is not a class object. Instead, it uses the MAC via setting mib, mlme, mcps requests and getting responses back from the mac layer using confirmations and indications. In essense this class is a special handle for mac layer underneath which is predominantly reference design based. In future we may refactor the LoRaMac.cpp code to make it object oriented and cleaner. At one end, it binds the application selected radio driver with the PHY layer and at the other end it provides services to upper layers handling the mac via well defined APIs. For proper selection of a PHY layer, user must use Mbed config system. For this purpose an mbed_lib.json is provided which can be overriden by the user defined mbed_app.json. By default the EU868 band is selected as a PHY layer. User must set relevant keys for the selected connection mechanism.
2017-11-27 13:17:18 +00:00
&& ((flags & MSG_FLAG_MASK) == MSG_UNCONFIRMED_FLAG
|| (flags & MSG_FLAG_MASK) == MSG_UNCONFIRMED_MULTICAST
|| (flags & MSG_FLAG_MASK) == MSG_UNCONFIRMED_PROPRIETARY)) {
tr_debug("RX - Unconfirmed Message - flags=%d", flags);
}
// check the length of received message whether we can fit into user
// buffer completely or not
[IOTCELL-282] Code cleanup/simplification and rules Baseline is changed to use a single set of data structures that simplifies the code in the LoRaWANStack and Mac layer. We are now following certian rules for naming data structures. - All structures visible outside their domain are prefixed as 'lorawan_' - All mac structures are prefixed as 'loramac_' - All subsystem or module strucutures carry their name in prefix, like 'mcps_' PHY layer still have legacy camel case data structures which will be entertained later while we will be simplifying PHY layer. Test cases are also updated with the new data structure naming conventions. One major difference from the previous baseline is the removal of static buffer from mcps indication. And we do not copy data from stack buffer to rx_msg buffer. This saves at least 512 bytes. It may look like now that if we have received something but the user have not read from the buffer, then the buffer will be overwritten and we will lose previous frame. Yes, we will. But the same will happen even if we would have copied the buffer into rx_msg because then the rx_msg gets overwritten. So we decide to abandon copying the buffer at multiple locations. We inform the user about reception, if the user doesn't read and the data gets overwritten, then so be it.
2018-01-12 14:39:31 +00:00
if (_rx_msg.msg.mcps_indication.buffer_size > length &&
Adding LoRaWANStack class to control MAC and PHY LoRaWANStack class is our controller layer on top of our current MAC and PHY layer. It provides services to an implementation of LoRaWANBase class. It is a singleton class owing to the fact that the mac layer underneath is not a class object. Instead, it uses the MAC via setting mib, mlme, mcps requests and getting responses back from the mac layer using confirmations and indications. In essense this class is a special handle for mac layer underneath which is predominantly reference design based. In future we may refactor the LoRaMac.cpp code to make it object oriented and cleaner. At one end, it binds the application selected radio driver with the PHY layer and at the other end it provides services to upper layers handling the mac via well defined APIs. For proper selection of a PHY layer, user must use Mbed config system. For this purpose an mbed_lib.json is provided which can be overriden by the user defined mbed_app.json. By default the EU868 band is selected as a PHY layer. User must set relevant keys for the selected connection mechanism.
2017-11-27 13:17:18 +00:00
_rx_msg.prev_read_size == 0) {
// we can't fit into user buffer. Invoke counter measures
[IOTCELL-282] Code cleanup/simplification and rules Baseline is changed to use a single set of data structures that simplifies the code in the LoRaWANStack and Mac layer. We are now following certian rules for naming data structures. - All structures visible outside their domain are prefixed as 'lorawan_' - All mac structures are prefixed as 'loramac_' - All subsystem or module strucutures carry their name in prefix, like 'mcps_' PHY layer still have legacy camel case data structures which will be entertained later while we will be simplifying PHY layer. Test cases are also updated with the new data structure naming conventions. One major difference from the previous baseline is the removal of static buffer from mcps indication. And we do not copy data from stack buffer to rx_msg buffer. This saves at least 512 bytes. It may look like now that if we have received something but the user have not read from the buffer, then the buffer will be overwritten and we will lose previous frame. Yes, we will. But the same will happen even if we would have copied the buffer into rx_msg because then the rx_msg gets overwritten. So we decide to abandon copying the buffer at multiple locations. We inform the user about reception, if the user doesn't read and the data gets overwritten, then so be it.
2018-01-12 14:39:31 +00:00
_rx_msg.pending_size = _rx_msg.msg.mcps_indication.buffer_size - length;
Adding LoRaWANStack class to control MAC and PHY LoRaWANStack class is our controller layer on top of our current MAC and PHY layer. It provides services to an implementation of LoRaWANBase class. It is a singleton class owing to the fact that the mac layer underneath is not a class object. Instead, it uses the MAC via setting mib, mlme, mcps requests and getting responses back from the mac layer using confirmations and indications. In essense this class is a special handle for mac layer underneath which is predominantly reference design based. In future we may refactor the LoRaMac.cpp code to make it object oriented and cleaner. At one end, it binds the application selected radio driver with the PHY layer and at the other end it provides services to upper layers handling the mac via well defined APIs. For proper selection of a PHY layer, user must use Mbed config system. For this purpose an mbed_lib.json is provided which can be overriden by the user defined mbed_app.json. By default the EU868 band is selected as a PHY layer. User must set relevant keys for the selected connection mechanism.
2017-11-27 13:17:18 +00:00
base_size = length;
_rx_msg.prev_read_size = base_size;
memcpy(data, base_ptr, base_size);
} else if (_rx_msg.prev_read_size == 0) {
_rx_msg.pending_size = 0;
_rx_msg.prev_read_size = 0;
memcpy(data, base_ptr, base_size);
read_complete = true;
}
// If its the pending read then we should copy only the remaining part of
// the buffer. Due to checks above, in case of a pending read, this block
// will be the only one to get invoked
if (_rx_msg.pending_size > 0 && _rx_msg.prev_read_size > 0) {
memcpy(data, base_ptr+_rx_msg.prev_read_size, base_size);
}
// we are done handing over received buffer to user. check if there is
// anything pending. If not, memset the buffer to zero and indicate
// that no read is in progress
if (read_complete) {
[IOTCELL-282] Code cleanup/simplification and rules Baseline is changed to use a single set of data structures that simplifies the code in the LoRaWANStack and Mac layer. We are now following certian rules for naming data structures. - All structures visible outside their domain are prefixed as 'lorawan_' - All mac structures are prefixed as 'loramac_' - All subsystem or module strucutures carry their name in prefix, like 'mcps_' PHY layer still have legacy camel case data structures which will be entertained later while we will be simplifying PHY layer. Test cases are also updated with the new data structure naming conventions. One major difference from the previous baseline is the removal of static buffer from mcps indication. And we do not copy data from stack buffer to rx_msg buffer. This saves at least 512 bytes. It may look like now that if we have received something but the user have not read from the buffer, then the buffer will be overwritten and we will lose previous frame. Yes, we will. But the same will happen even if we would have copied the buffer into rx_msg because then the rx_msg gets overwritten. So we decide to abandon copying the buffer at multiple locations. We inform the user about reception, if the user doesn't read and the data gets overwritten, then so be it.
2018-01-12 14:39:31 +00:00
memset(_rx_msg.msg.mcps_indication.buffer, 0, LORAMAC_PHY_MAXPAYLOAD);
Adding LoRaWANStack class to control MAC and PHY LoRaWANStack class is our controller layer on top of our current MAC and PHY layer. It provides services to an implementation of LoRaWANBase class. It is a singleton class owing to the fact that the mac layer underneath is not a class object. Instead, it uses the MAC via setting mib, mlme, mcps requests and getting responses back from the mac layer using confirmations and indications. In essense this class is a special handle for mac layer underneath which is predominantly reference design based. In future we may refactor the LoRaMac.cpp code to make it object oriented and cleaner. At one end, it binds the application selected radio driver with the PHY layer and at the other end it provides services to upper layers handling the mac via well defined APIs. For proper selection of a PHY layer, user must use Mbed config system. For this purpose an mbed_lib.json is provided which can be overriden by the user defined mbed_app.json. By default the EU868 band is selected as a PHY layer. User must set relevant keys for the selected connection mechanism.
2017-11-27 13:17:18 +00:00
_rx_msg.receive_ready = false;
}
Receive API typo fix Receive API should return the length of data written to the user buffer as the Posix APIs suggest rather than sending the pending length of data back. That has actually been a typo mistake which actually wnt in even with doicumentation :)
2017-12-14 13:20:27 +00:00
return base_size;
Adding LoRaWANStack class to control MAC and PHY LoRaWANStack class is our controller layer on top of our current MAC and PHY layer. It provides services to an implementation of LoRaWANBase class. It is a singleton class owing to the fact that the mac layer underneath is not a class object. Instead, it uses the MAC via setting mib, mlme, mcps requests and getting responses back from the mac layer using confirmations and indications. In essense this class is a special handle for mac layer underneath which is predominantly reference design based. In future we may refactor the LoRaMac.cpp code to make it object oriented and cleaner. At one end, it binds the application selected radio driver with the PHY layer and at the other end it provides services to upper layers handling the mac via well defined APIs. For proper selection of a PHY layer, user must use Mbed config system. For this purpose an mbed_lib.json is provided which can be overriden by the user defined mbed_app.json. By default the EU868 band is selected as a PHY layer. User must set relevant keys for the selected connection mechanism.
2017-11-27 13:17:18 +00:00
}
[IOTCELL-282] Code cleanup/simplification and rules Baseline is changed to use a single set of data structures that simplifies the code in the LoRaWANStack and Mac layer. We are now following certian rules for naming data structures. - All structures visible outside their domain are prefixed as 'lorawan_' - All mac structures are prefixed as 'loramac_' - All subsystem or module strucutures carry their name in prefix, like 'mcps_' PHY layer still have legacy camel case data structures which will be entertained later while we will be simplifying PHY layer. Test cases are also updated with the new data structure naming conventions. One major difference from the previous baseline is the removal of static buffer from mcps indication. And we do not copy data from stack buffer to rx_msg buffer. This saves at least 512 bytes. It may look like now that if we have received something but the user have not read from the buffer, then the buffer will be overwritten and we will lose previous frame. Yes, we will. But the same will happen even if we would have copied the buffer into rx_msg because then the rx_msg gets overwritten. So we decide to abandon copying the buffer at multiple locations. We inform the user about reception, if the user doesn't read and the data gets overwritten, then so be it.
2018-01-12 14:39:31 +00:00
void LoRaWANStack::mlme_confirm_handler(loramac_mlme_confirm_t *mlme_confirm)
Adding LoRaWANStack class to control MAC and PHY LoRaWANStack class is our controller layer on top of our current MAC and PHY layer. It provides services to an implementation of LoRaWANBase class. It is a singleton class owing to the fact that the mac layer underneath is not a class object. Instead, it uses the MAC via setting mib, mlme, mcps requests and getting responses back from the mac layer using confirmations and indications. In essense this class is a special handle for mac layer underneath which is predominantly reference design based. In future we may refactor the LoRaMac.cpp code to make it object oriented and cleaner. At one end, it binds the application selected radio driver with the PHY layer and at the other end it provides services to upper layers handling the mac via well defined APIs. For proper selection of a PHY layer, user must use Mbed config system. For this purpose an mbed_lib.json is provided which can be overriden by the user defined mbed_app.json. By default the EU868 band is selected as a PHY layer. User must set relevant keys for the selected connection mechanism.
2017-11-27 13:17:18 +00:00
{
[IOTCELL-282] Code cleanup/simplification and rules Baseline is changed to use a single set of data structures that simplifies the code in the LoRaWANStack and Mac layer. We are now following certian rules for naming data structures. - All structures visible outside their domain are prefixed as 'lorawan_' - All mac structures are prefixed as 'loramac_' - All subsystem or module strucutures carry their name in prefix, like 'mcps_' PHY layer still have legacy camel case data structures which will be entertained later while we will be simplifying PHY layer. Test cases are also updated with the new data structure naming conventions. One major difference from the previous baseline is the removal of static buffer from mcps indication. And we do not copy data from stack buffer to rx_msg buffer. This saves at least 512 bytes. It may look like now that if we have received something but the user have not read from the buffer, then the buffer will be overwritten and we will lose previous frame. Yes, we will. But the same will happen even if we would have copied the buffer into rx_msg because then the rx_msg gets overwritten. So we decide to abandon copying the buffer at multiple locations. We inform the user about reception, if the user doesn't read and the data gets overwritten, then so be it.
2018-01-12 14:39:31 +00:00
switch (mlme_confirm->req_type) {
case MLME_JOIN:
if (mlme_confirm->status == LORAMAC_EVENT_INFO_STATUS_OK) {
Adding LoRaWANStack class to control MAC and PHY LoRaWANStack class is our controller layer on top of our current MAC and PHY layer. It provides services to an implementation of LoRaWANBase class. It is a singleton class owing to the fact that the mac layer underneath is not a class object. Instead, it uses the MAC via setting mib, mlme, mcps requests and getting responses back from the mac layer using confirmations and indications. In essense this class is a special handle for mac layer underneath which is predominantly reference design based. In future we may refactor the LoRaMac.cpp code to make it object oriented and cleaner. At one end, it binds the application selected radio driver with the PHY layer and at the other end it provides services to upper layers handling the mac via well defined APIs. For proper selection of a PHY layer, user must use Mbed config system. For this purpose an mbed_lib.json is provided which can be overriden by the user defined mbed_app.json. By default the EU868 band is selected as a PHY layer. User must set relevant keys for the selected connection mechanism.
2017-11-27 13:17:18 +00:00
// Status is OK, node has joined the network
LoRa: LoRaWANInterface refactored. - Only internal changes, no functionality changes - Some minor improvements to LoRaWanStack
2018-03-12 11:30:00 +00:00
if (lora_state_machine(DEVICE_STATE_JOINED) != LORAWAN_STATUS_OK) {
Improve error handling & robustness This commit also introduces API change for disconnect(). disconnect() will now return LORAWAN_STATUS_DEVICE_OFF for successfull disconnect. * LoRaWANStack::handle_tx() can be called with NULL buffer when length is 0. This commit fixes the case where user has provided NULL buffer and length is > max_possible_size. handle_tx() now always returns LORAWAN_STATUS_PARAMETER_INVALID if given buffer is NULL pointer and length > 0. General error checking is added and some asserts are added for events.
2018-02-09 07:59:15 +00:00
tr_error("Lora state machine did not return LORAWAN_STATUS_OK");
}
Adding LoRaWANStack class to control MAC and PHY LoRaWANStack class is our controller layer on top of our current MAC and PHY layer. It provides services to an implementation of LoRaWANBase class. It is a singleton class owing to the fact that the mac layer underneath is not a class object. Instead, it uses the MAC via setting mib, mlme, mcps requests and getting responses back from the mac layer using confirmations and indications. In essense this class is a special handle for mac layer underneath which is predominantly reference design based. In future we may refactor the LoRaMac.cpp code to make it object oriented and cleaner. At one end, it binds the application selected radio driver with the PHY layer and at the other end it provides services to upper layers handling the mac via well defined APIs. For proper selection of a PHY layer, user must use Mbed config system. For this purpose an mbed_lib.json is provided which can be overriden by the user defined mbed_app.json. By default the EU868 band is selected as a PHY layer. User must set relevant keys for the selected connection mechanism.
2017-11-27 13:17:18 +00:00
} else {
// Join attempt failed.
LoRa: LoRaWANInterface refactored. - Only internal changes, no functionality changes - Some minor improvements to LoRaWanStack
2018-03-12 11:30:00 +00:00
if (lora_state_machine(DEVICE_STATE_IDLE) != LORAWAN_STATUS_IDLE) {
Improve error handling & robustness This commit also introduces API change for disconnect(). disconnect() will now return LORAWAN_STATUS_DEVICE_OFF for successfull disconnect. * LoRaWANStack::handle_tx() can be called with NULL buffer when length is 0. This commit fixes the case where user has provided NULL buffer and length is > max_possible_size. handle_tx() now always returns LORAWAN_STATUS_PARAMETER_INVALID if given buffer is NULL pointer and length > 0. General error checking is added and some asserts are added for events.
2018-02-09 07:59:15 +00:00
tr_error("Lora state machine did not return DEVICE_STATE_IDLE !");
}
Reworking callback API Application should be able to add some optional callbacks if it needs to. Ofcourse there is a penalty of 8-12 bytes per callback, but there can be certain needs of the application that needs to be met for example setting up a link check request etc. We have introduced a structure that contains callbacks for the application use. - 'events' callback is mandatory, user must assign it. Because this callback brings state changes for the application. We cannot segregate this into individual handlers because of RAM penalty. - Other calbacks (none of them are implemented yet are optional). Example of using the API is provided with doxygen
2017-12-21 11:37:38 +00:00
if (_callbacks.events) {
Improve error handling & robustness This commit also introduces API change for disconnect(). disconnect() will now return LORAWAN_STATUS_DEVICE_OFF for successfull disconnect. * LoRaWANStack::handle_tx() can be called with NULL buffer when length is 0. This commit fixes the case where user has provided NULL buffer and length is > max_possible_size. handle_tx() now always returns LORAWAN_STATUS_PARAMETER_INVALID if given buffer is NULL pointer and length > 0. General error checking is added and some asserts are added for events.
2018-02-09 07:59:15 +00:00
const int ret = _queue->call(_callbacks.events, JOIN_FAILURE);
MBED_ASSERT(ret != 0);
(void)ret;
Reworking callback API Application should be able to add some optional callbacks if it needs to. Ofcourse there is a penalty of 8-12 bytes per callback, but there can be certain needs of the application that needs to be met for example setting up a link check request etc. We have introduced a structure that contains callbacks for the application use. - 'events' callback is mandatory, user must assign it. Because this callback brings state changes for the application. We cannot segregate this into individual handlers because of RAM penalty. - Other calbacks (none of them are implemented yet are optional). Example of using the API is provided with doxygen
2017-12-21 11:37:38 +00:00
}
Adding LoRaWANStack class to control MAC and PHY LoRaWANStack class is our controller layer on top of our current MAC and PHY layer. It provides services to an implementation of LoRaWANBase class. It is a singleton class owing to the fact that the mac layer underneath is not a class object. Instead, it uses the MAC via setting mib, mlme, mcps requests and getting responses back from the mac layer using confirmations and indications. In essense this class is a special handle for mac layer underneath which is predominantly reference design based. In future we may refactor the LoRaMac.cpp code to make it object oriented and cleaner. At one end, it binds the application selected radio driver with the PHY layer and at the other end it provides services to upper layers handling the mac via well defined APIs. For proper selection of a PHY layer, user must use Mbed config system. For this purpose an mbed_lib.json is provided which can be overriden by the user defined mbed_app.json. By default the EU868 band is selected as a PHY layer. User must set relevant keys for the selected connection mechanism.
2017-11-27 13:17:18 +00:00
}
break;
[IOTCELL-282] Code cleanup/simplification and rules Baseline is changed to use a single set of data structures that simplifies the code in the LoRaWANStack and Mac layer. We are now following certian rules for naming data structures. - All structures visible outside their domain are prefixed as 'lorawan_' - All mac structures are prefixed as 'loramac_' - All subsystem or module strucutures carry their name in prefix, like 'mcps_' PHY layer still have legacy camel case data structures which will be entertained later while we will be simplifying PHY layer. Test cases are also updated with the new data structure naming conventions. One major difference from the previous baseline is the removal of static buffer from mcps indication. And we do not copy data from stack buffer to rx_msg buffer. This saves at least 512 bytes. It may look like now that if we have received something but the user have not read from the buffer, then the buffer will be overwritten and we will lose previous frame. Yes, we will. But the same will happen even if we would have copied the buffer into rx_msg because then the rx_msg gets overwritten. So we decide to abandon copying the buffer at multiple locations. We inform the user about reception, if the user doesn't read and the data gets overwritten, then so be it.
2018-01-12 14:39:31 +00:00
case MLME_LINK_CHECK:
if (mlme_confirm->status == LORAMAC_EVENT_INFO_STATUS_OK) {
Adding LoRaWANStack class to control MAC and PHY LoRaWANStack class is our controller layer on top of our current MAC and PHY layer. It provides services to an implementation of LoRaWANBase class. It is a singleton class owing to the fact that the mac layer underneath is not a class object. Instead, it uses the MAC via setting mib, mlme, mcps requests and getting responses back from the mac layer using confirmations and indications. In essense this class is a special handle for mac layer underneath which is predominantly reference design based. In future we may refactor the LoRaMac.cpp code to make it object oriented and cleaner. At one end, it binds the application selected radio driver with the PHY layer and at the other end it provides services to upper layers handling the mac via well defined APIs. For proper selection of a PHY layer, user must use Mbed config system. For this purpose an mbed_lib.json is provided which can be overriden by the user defined mbed_app.json. By default the EU868 band is selected as a PHY layer. User must set relevant keys for the selected connection mechanism.
2017-11-27 13:17:18 +00:00
// Check DemodMargin
// Check NbGateways
Move all compliance test code inside compilation flag All compliance test related codes are now inside LORAWAN_COMPLIANCE_TEST build flag. This will reduce memory usage in when compliance test codes are not needed.
2018-01-05 10:13:48 +00:00
#if defined(LORAWAN_COMPLIANCE_TEST)
Adding LoRaWANStack class to control MAC and PHY LoRaWANStack class is our controller layer on top of our current MAC and PHY layer. It provides services to an implementation of LoRaWANBase class. It is a singleton class owing to the fact that the mac layer underneath is not a class object. Instead, it uses the MAC via setting mib, mlme, mcps requests and getting responses back from the mac layer using confirmations and indications. In essense this class is a special handle for mac layer underneath which is predominantly reference design based. In future we may refactor the LoRaMac.cpp code to make it object oriented and cleaner. At one end, it binds the application selected radio driver with the PHY layer and at the other end it provides services to upper layers handling the mac via well defined APIs. For proper selection of a PHY layer, user must use Mbed config system. For this purpose an mbed_lib.json is provided which can be overriden by the user defined mbed_app.json. By default the EU868 band is selected as a PHY layer. User must set relevant keys for the selected connection mechanism.
2017-11-27 13:17:18 +00:00
if (_compliance_test.running == true) {
_compliance_test.link_check = true;
_compliance_test.demod_margin = mlme_confirm->demod_margin;
_compliance_test.nb_gateways = mlme_confirm->nb_gateways;
Architecture rework, bug fixing & missing features MAC layer is now a class rather than being a blob. In addition to that Mac commands are now being handled in a seperate subsystem (a class of its own). In future we will do the same with othe sublayers of MAC like MLME, MCPS etc. The drive behind this exercise is to make MAC and supporting layers into an object oriented system. Major bug fixes include: - last join time inclusion in band parameters - disabling rx2 window if we missed the slot already - MLME uplink schdule hook - nbRep according to spec - maintaining datarate after successful joining - suppressing MLME requests if MAC is in TX_DELAYED state - Uplink dwell time verification Some missing features are implemented. Details are as follows. Support for LinkCheckRequet: An application API is added, add_link_check_request() to delegate a request for Link Check Request MAC command. * Application provides a callback function that needs to be called on reception of link check response. * Mac command is piggybacked with data frames. This API makes the sticky MAC command stick with the application payloads until/unless the application un-sticks the said mac command using remove_link_check_request() API. Handling fPending bit: If in the Downlink, we get the fPending bit set in fctrl octet, we attempt to send an empty message back to Network Server to open additional Receive windows. This operation is independent of the application. An RX_DONE event is queued bedore generating the said empty message. Specification does not mention what can be the type of that empty message. We have decided it to be of CONFIRMED type as it gives us an added benefit of retries if the corresponding RX slots are missed. Radio event callbacks as Mbed callbacks: radio_events_t structure has been carrying C-style callbacks which was inherited from the legacy code. These callbacks has now been changed to Mbed Callbacks that makes sure that we can be object oriented from now on.
2017-12-15 10:30:40 +00:00
} else
Move all compliance test code inside compilation flag All compliance test related codes are now inside LORAWAN_COMPLIANCE_TEST build flag. This will reduce memory usage in when compliance test codes are not needed.
2018-01-05 10:13:48 +00:00
#endif
Architecture rework, bug fixing & missing features MAC layer is now a class rather than being a blob. In addition to that Mac commands are now being handled in a seperate subsystem (a class of its own). In future we will do the same with othe sublayers of MAC like MLME, MCPS etc. The drive behind this exercise is to make MAC and supporting layers into an object oriented system. Major bug fixes include: - last join time inclusion in band parameters - disabling rx2 window if we missed the slot already - MLME uplink schdule hook - nbRep according to spec - maintaining datarate after successful joining - suppressing MLME requests if MAC is in TX_DELAYED state - Uplink dwell time verification Some missing features are implemented. Details are as follows. Support for LinkCheckRequet: An application API is added, add_link_check_request() to delegate a request for Link Check Request MAC command. * Application provides a callback function that needs to be called on reception of link check response. * Mac command is piggybacked with data frames. This API makes the sticky MAC command stick with the application payloads until/unless the application un-sticks the said mac command using remove_link_check_request() API. Handling fPending bit: If in the Downlink, we get the fPending bit set in fctrl octet, we attempt to send an empty message back to Network Server to open additional Receive windows. This operation is independent of the application. An RX_DONE event is queued bedore generating the said empty message. Specification does not mention what can be the type of that empty message. We have decided it to be of CONFIRMED type as it gives us an added benefit of retries if the corresponding RX slots are missed. Radio event callbacks as Mbed callbacks: radio_events_t structure has been carrying C-style callbacks which was inherited from the legacy code. These callbacks has now been changed to Mbed Callbacks that makes sure that we can be object oriented from now on.
2017-12-15 10:30:40 +00:00
{
// normal operation as oppose to compliance testing
if (_callbacks.link_check_resp) {
Improve error handling & robustness This commit also introduces API change for disconnect(). disconnect() will now return LORAWAN_STATUS_DEVICE_OFF for successfull disconnect. * LoRaWANStack::handle_tx() can be called with NULL buffer when length is 0. This commit fixes the case where user has provided NULL buffer and length is > max_possible_size. handle_tx() now always returns LORAWAN_STATUS_PARAMETER_INVALID if given buffer is NULL pointer and length > 0. General error checking is added and some asserts are added for events.
2018-02-09 07:59:15 +00:00
const int ret = _queue->call(_callbacks.link_check_resp,
mlme_confirm->demod_margin,
mlme_confirm->nb_gateways);
MBED_ASSERT(ret != 0);
(void)ret;
Architecture rework, bug fixing & missing features MAC layer is now a class rather than being a blob. In addition to that Mac commands are now being handled in a seperate subsystem (a class of its own). In future we will do the same with othe sublayers of MAC like MLME, MCPS etc. The drive behind this exercise is to make MAC and supporting layers into an object oriented system. Major bug fixes include: - last join time inclusion in band parameters - disabling rx2 window if we missed the slot already - MLME uplink schdule hook - nbRep according to spec - maintaining datarate after successful joining - suppressing MLME requests if MAC is in TX_DELAYED state - Uplink dwell time verification Some missing features are implemented. Details are as follows. Support for LinkCheckRequet: An application API is added, add_link_check_request() to delegate a request for Link Check Request MAC command. * Application provides a callback function that needs to be called on reception of link check response. * Mac command is piggybacked with data frames. This API makes the sticky MAC command stick with the application payloads until/unless the application un-sticks the said mac command using remove_link_check_request() API. Handling fPending bit: If in the Downlink, we get the fPending bit set in fctrl octet, we attempt to send an empty message back to Network Server to open additional Receive windows. This operation is independent of the application. An RX_DONE event is queued bedore generating the said empty message. Specification does not mention what can be the type of that empty message. We have decided it to be of CONFIRMED type as it gives us an added benefit of retries if the corresponding RX slots are missed. Radio event callbacks as Mbed callbacks: radio_events_t structure has been carrying C-style callbacks which was inherited from the legacy code. These callbacks has now been changed to Mbed Callbacks that makes sure that we can be object oriented from now on.
2017-12-15 10:30:40 +00:00
}
}
Adding LoRaWANStack class to control MAC and PHY LoRaWANStack class is our controller layer on top of our current MAC and PHY layer. It provides services to an implementation of LoRaWANBase class. It is a singleton class owing to the fact that the mac layer underneath is not a class object. Instead, it uses the MAC via setting mib, mlme, mcps requests and getting responses back from the mac layer using confirmations and indications. In essense this class is a special handle for mac layer underneath which is predominantly reference design based. In future we may refactor the LoRaMac.cpp code to make it object oriented and cleaner. At one end, it binds the application selected radio driver with the PHY layer and at the other end it provides services to upper layers handling the mac via well defined APIs. For proper selection of a PHY layer, user must use Mbed config system. For this purpose an mbed_lib.json is provided which can be overriden by the user defined mbed_app.json. By default the EU868 band is selected as a PHY layer. User must set relevant keys for the selected connection mechanism.
2017-11-27 13:17:18 +00:00
}
break;
default:
break;
}
}
[IOTCELL-282] Code cleanup/simplification and rules Baseline is changed to use a single set of data structures that simplifies the code in the LoRaWANStack and Mac layer. We are now following certian rules for naming data structures. - All structures visible outside their domain are prefixed as 'lorawan_' - All mac structures are prefixed as 'loramac_' - All subsystem or module strucutures carry their name in prefix, like 'mcps_' PHY layer still have legacy camel case data structures which will be entertained later while we will be simplifying PHY layer. Test cases are also updated with the new data structure naming conventions. One major difference from the previous baseline is the removal of static buffer from mcps indication. And we do not copy data from stack buffer to rx_msg buffer. This saves at least 512 bytes. It may look like now that if we have received something but the user have not read from the buffer, then the buffer will be overwritten and we will lose previous frame. Yes, we will. But the same will happen even if we would have copied the buffer into rx_msg because then the rx_msg gets overwritten. So we decide to abandon copying the buffer at multiple locations. We inform the user about reception, if the user doesn't read and the data gets overwritten, then so be it.
2018-01-12 14:39:31 +00:00
void LoRaWANStack::mcps_confirm_handler(loramac_mcps_confirm_t *mcps_confirm)
Adding LoRaWANStack class to control MAC and PHY LoRaWANStack class is our controller layer on top of our current MAC and PHY layer. It provides services to an implementation of LoRaWANBase class. It is a singleton class owing to the fact that the mac layer underneath is not a class object. Instead, it uses the MAC via setting mib, mlme, mcps requests and getting responses back from the mac layer using confirmations and indications. In essense this class is a special handle for mac layer underneath which is predominantly reference design based. In future we may refactor the LoRaMac.cpp code to make it object oriented and cleaner. At one end, it binds the application selected radio driver with the PHY layer and at the other end it provides services to upper layers handling the mac via well defined APIs. For proper selection of a PHY layer, user must use Mbed config system. For this purpose an mbed_lib.json is provided which can be overriden by the user defined mbed_app.json. By default the EU868 band is selected as a PHY layer. User must set relevant keys for the selected connection mechanism.
2017-11-27 13:17:18 +00:00
{
[IOTCELL-282] Code cleanup/simplification and rules Baseline is changed to use a single set of data structures that simplifies the code in the LoRaWANStack and Mac layer. We are now following certian rules for naming data structures. - All structures visible outside their domain are prefixed as 'lorawan_' - All mac structures are prefixed as 'loramac_' - All subsystem or module strucutures carry their name in prefix, like 'mcps_' PHY layer still have legacy camel case data structures which will be entertained later while we will be simplifying PHY layer. Test cases are also updated with the new data structure naming conventions. One major difference from the previous baseline is the removal of static buffer from mcps indication. And we do not copy data from stack buffer to rx_msg buffer. This saves at least 512 bytes. It may look like now that if we have received something but the user have not read from the buffer, then the buffer will be overwritten and we will lose previous frame. Yes, we will. But the same will happen even if we would have copied the buffer into rx_msg because then the rx_msg gets overwritten. So we decide to abandon copying the buffer at multiple locations. We inform the user about reception, if the user doesn't read and the data gets overwritten, then so be it.
2018-01-12 14:39:31 +00:00
if (mcps_confirm->status != LORAMAC_EVENT_INFO_STATUS_OK) {
LoRa: LoRaPHY dependency removed from LoRaMacStack - 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
2018-03-15 08:43:31 +00:00
_loramac.reset_ongoing_tx();
Adding LoRaWANStack class to control MAC and PHY LoRaWANStack class is our controller layer on top of our current MAC and PHY layer. It provides services to an implementation of LoRaWANBase class. It is a singleton class owing to the fact that the mac layer underneath is not a class object. Instead, it uses the MAC via setting mib, mlme, mcps requests and getting responses back from the mac layer using confirmations and indications. In essense this class is a special handle for mac layer underneath which is predominantly reference design based. In future we may refactor the LoRaMac.cpp code to make it object oriented and cleaner. At one end, it binds the application selected radio driver with the PHY layer and at the other end it provides services to upper layers handling the mac via well defined APIs. For proper selection of a PHY layer, user must use Mbed config system. For this purpose an mbed_lib.json is provided which can be overriden by the user defined mbed_app.json. By default the EU868 band is selected as a PHY layer. User must set relevant keys for the selected connection mechanism.
2017-11-27 13:17:18 +00:00
tr_error("mcps_confirm_handler: Error code = %d", mcps_confirm->status);
[IOTCELL-282] Code cleanup/simplification and rules Baseline is changed to use a single set of data structures that simplifies the code in the LoRaWANStack and Mac layer. We are now following certian rules for naming data structures. - All structures visible outside their domain are prefixed as 'lorawan_' - All mac structures are prefixed as 'loramac_' - All subsystem or module strucutures carry their name in prefix, like 'mcps_' PHY layer still have legacy camel case data structures which will be entertained later while we will be simplifying PHY layer. Test cases are also updated with the new data structure naming conventions. One major difference from the previous baseline is the removal of static buffer from mcps indication. And we do not copy data from stack buffer to rx_msg buffer. This saves at least 512 bytes. It may look like now that if we have received something but the user have not read from the buffer, then the buffer will be overwritten and we will lose previous frame. Yes, we will. But the same will happen even if we would have copied the buffer into rx_msg because then the rx_msg gets overwritten. So we decide to abandon copying the buffer at multiple locations. We inform the user about reception, if the user doesn't read and the data gets overwritten, then so be it.
2018-01-12 14:39:31 +00:00
if (mcps_confirm->status == LORAMAC_EVENT_INFO_STATUS_TX_TIMEOUT) {
Reworking callback API Application should be able to add some optional callbacks if it needs to. Ofcourse there is a penalty of 8-12 bytes per callback, but there can be certain needs of the application that needs to be met for example setting up a link check request etc. We have introduced a structure that contains callbacks for the application use. - 'events' callback is mandatory, user must assign it. Because this callback brings state changes for the application. We cannot segregate this into individual handlers because of RAM penalty. - Other calbacks (none of them are implemented yet are optional). Example of using the API is provided with doxygen
2017-12-21 11:37:38 +00:00
if (_callbacks.events) {
Improve error handling & robustness This commit also introduces API change for disconnect(). disconnect() will now return LORAWAN_STATUS_DEVICE_OFF for successfull disconnect. * LoRaWANStack::handle_tx() can be called with NULL buffer when length is 0. This commit fixes the case where user has provided NULL buffer and length is > max_possible_size. handle_tx() now always returns LORAWAN_STATUS_PARAMETER_INVALID if given buffer is NULL pointer and length > 0. General error checking is added and some asserts are added for events.
2018-02-09 07:59:15 +00:00
const int ret = _queue->call(_callbacks.events, TX_TIMEOUT);
MBED_ASSERT(ret != 0);
(void)ret;
Reworking callback API Application should be able to add some optional callbacks if it needs to. Ofcourse there is a penalty of 8-12 bytes per callback, but there can be certain needs of the application that needs to be met for example setting up a link check request etc. We have introduced a structure that contains callbacks for the application use. - 'events' callback is mandatory, user must assign it. Because this callback brings state changes for the application. We cannot segregate this into individual handlers because of RAM penalty. - Other calbacks (none of them are implemented yet are optional). Example of using the API is provided with doxygen
2017-12-21 11:37:38 +00:00
}
Adding LoRaWANStack class to control MAC and PHY LoRaWANStack class is our controller layer on top of our current MAC and PHY layer. It provides services to an implementation of LoRaWANBase class. It is a singleton class owing to the fact that the mac layer underneath is not a class object. Instead, it uses the MAC via setting mib, mlme, mcps requests and getting responses back from the mac layer using confirmations and indications. In essense this class is a special handle for mac layer underneath which is predominantly reference design based. In future we may refactor the LoRaMac.cpp code to make it object oriented and cleaner. At one end, it binds the application selected radio driver with the PHY layer and at the other end it provides services to upper layers handling the mac via well defined APIs. For proper selection of a PHY layer, user must use Mbed config system. For this purpose an mbed_lib.json is provided which can be overriden by the user defined mbed_app.json. By default the EU868 band is selected as a PHY layer. User must set relevant keys for the selected connection mechanism.
2017-11-27 13:17:18 +00:00
return;
LoRaWANStack is made independent of MAC sublayers - Only internal changes, no API has been broke. - Tested by manually running Green tea tests
2018-03-16 11:12:50 +00:00
} else if (mcps_confirm->status == LORAMAC_EVENT_INFO_STATUS_RX2_TIMEOUT) {
Adding LoRaWANStack class to control MAC and PHY LoRaWANStack class is our controller layer on top of our current MAC and PHY layer. It provides services to an implementation of LoRaWANBase class. It is a singleton class owing to the fact that the mac layer underneath is not a class object. Instead, it uses the MAC via setting mib, mlme, mcps requests and getting responses back from the mac layer using confirmations and indications. In essense this class is a special handle for mac layer underneath which is predominantly reference design based. In future we may refactor the LoRaMac.cpp code to make it object oriented and cleaner. At one end, it binds the application selected radio driver with the PHY layer and at the other end it provides services to upper layers handling the mac via well defined APIs. For proper selection of a PHY layer, user must use Mbed config system. For this purpose an mbed_lib.json is provided which can be overriden by the user defined mbed_app.json. By default the EU868 band is selected as a PHY layer. User must set relevant keys for the selected connection mechanism.
2017-11-27 13:17:18 +00:00
tr_debug("Did not receive Ack");
}
Reworking callback API Application should be able to add some optional callbacks if it needs to. Ofcourse there is a penalty of 8-12 bytes per callback, but there can be certain needs of the application that needs to be met for example setting up a link check request etc. We have introduced a structure that contains callbacks for the application use. - 'events' callback is mandatory, user must assign it. Because this callback brings state changes for the application. We cannot segregate this into individual handlers because of RAM penalty. - Other calbacks (none of them are implemented yet are optional). Example of using the API is provided with doxygen
2017-12-21 11:37:38 +00:00
if (_callbacks.events) {
Improve error handling & robustness This commit also introduces API change for disconnect(). disconnect() will now return LORAWAN_STATUS_DEVICE_OFF for successfull disconnect. * LoRaWANStack::handle_tx() can be called with NULL buffer when length is 0. This commit fixes the case where user has provided NULL buffer and length is > max_possible_size. handle_tx() now always returns LORAWAN_STATUS_PARAMETER_INVALID if given buffer is NULL pointer and length > 0. General error checking is added and some asserts are added for events.
2018-02-09 07:59:15 +00:00
const int ret = _queue->call(_callbacks.events, TX_ERROR);
MBED_ASSERT(ret != 0);
(void)ret;
Reworking callback API Application should be able to add some optional callbacks if it needs to. Ofcourse there is a penalty of 8-12 bytes per callback, but there can be certain needs of the application that needs to be met for example setting up a link check request etc. We have introduced a structure that contains callbacks for the application use. - 'events' callback is mandatory, user must assign it. Because this callback brings state changes for the application. We cannot segregate this into individual handlers because of RAM penalty. - Other calbacks (none of them are implemented yet are optional). Example of using the API is provided with doxygen
2017-12-21 11:37:38 +00:00
}
Adding LoRaWANStack class to control MAC and PHY LoRaWANStack class is our controller layer on top of our current MAC and PHY layer. It provides services to an implementation of LoRaWANBase class. It is a singleton class owing to the fact that the mac layer underneath is not a class object. Instead, it uses the MAC via setting mib, mlme, mcps requests and getting responses back from the mac layer using confirmations and indications. In essense this class is a special handle for mac layer underneath which is predominantly reference design based. In future we may refactor the LoRaMac.cpp code to make it object oriented and cleaner. At one end, it binds the application selected radio driver with the PHY layer and at the other end it provides services to upper layers handling the mac via well defined APIs. For proper selection of a PHY layer, user must use Mbed config system. For this purpose an mbed_lib.json is provided which can be overriden by the user defined mbed_app.json. By default the EU868 band is selected as a PHY layer. User must set relevant keys for the selected connection mechanism.
2017-11-27 13:17:18 +00:00
return;
}
LoRaWANStack is made independent of MAC sublayers - Only internal changes, no API has been broke. - Tested by manually running Green tea tests
2018-03-16 11:12:50 +00:00
if (mcps_confirm->req_type == MCPS_CONFIRMED &&
mcps_confirm->ack_received) {
Adding LoRaWANStack class to control MAC and PHY LoRaWANStack class is our controller layer on top of our current MAC and PHY layer. It provides services to an implementation of LoRaWANBase class. It is a singleton class owing to the fact that the mac layer underneath is not a class object. Instead, it uses the MAC via setting mib, mlme, mcps requests and getting responses back from the mac layer using confirmations and indications. In essense this class is a special handle for mac layer underneath which is predominantly reference design based. In future we may refactor the LoRaMac.cpp code to make it object oriented and cleaner. At one end, it binds the application selected radio driver with the PHY layer and at the other end it provides services to upper layers handling the mac via well defined APIs. For proper selection of a PHY layer, user must use Mbed config system. For this purpose an mbed_lib.json is provided which can be overriden by the user defined mbed_app.json. By default the EU868 band is selected as a PHY layer. User must set relevant keys for the selected connection mechanism.
2017-11-27 13:17:18 +00:00
tr_debug("Ack received.");
}
[IOTCELL-282] Code cleanup/simplification and rules Baseline is changed to use a single set of data structures that simplifies the code in the LoRaWANStack and Mac layer. We are now following certian rules for naming data structures. - All structures visible outside their domain are prefixed as 'lorawan_' - All mac structures are prefixed as 'loramac_' - All subsystem or module strucutures carry their name in prefix, like 'mcps_' PHY layer still have legacy camel case data structures which will be entertained later while we will be simplifying PHY layer. Test cases are also updated with the new data structure naming conventions. One major difference from the previous baseline is the removal of static buffer from mcps indication. And we do not copy data from stack buffer to rx_msg buffer. This saves at least 512 bytes. It may look like now that if we have received something but the user have not read from the buffer, then the buffer will be overwritten and we will lose previous frame. Yes, we will. But the same will happen even if we would have copied the buffer into rx_msg because then the rx_msg gets overwritten. So we decide to abandon copying the buffer at multiple locations. We inform the user about reception, if the user doesn't read and the data gets overwritten, then so be it.
2018-01-12 14:39:31 +00:00
_lw_session.uplink_counter = mcps_confirm->ul_frame_counter;
LoRa: LoRaPHY dependency removed from LoRaMacStack - 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
2018-03-15 08:43:31 +00:00
_loramac.set_tx_ongoing(false);
Reworking callback API Application should be able to add some optional callbacks if it needs to. Ofcourse there is a penalty of 8-12 bytes per callback, but there can be certain needs of the application that needs to be met for example setting up a link check request etc. We have introduced a structure that contains callbacks for the application use. - 'events' callback is mandatory, user must assign it. Because this callback brings state changes for the application. We cannot segregate this into individual handlers because of RAM penalty. - Other calbacks (none of them are implemented yet are optional). Example of using the API is provided with doxygen
2017-12-21 11:37:38 +00:00
if (_callbacks.events) {
Improve error handling & robustness This commit also introduces API change for disconnect(). disconnect() will now return LORAWAN_STATUS_DEVICE_OFF for successfull disconnect. * LoRaWANStack::handle_tx() can be called with NULL buffer when length is 0. This commit fixes the case where user has provided NULL buffer and length is > max_possible_size. handle_tx() now always returns LORAWAN_STATUS_PARAMETER_INVALID if given buffer is NULL pointer and length > 0. General error checking is added and some asserts are added for events.
2018-02-09 07:59:15 +00:00
const int ret = _queue->call(_callbacks.events, TX_DONE);
MBED_ASSERT(ret != 0);
(void)ret;
Reworking callback API Application should be able to add some optional callbacks if it needs to. Ofcourse there is a penalty of 8-12 bytes per callback, but there can be certain needs of the application that needs to be met for example setting up a link check request etc. We have introduced a structure that contains callbacks for the application use. - 'events' callback is mandatory, user must assign it. Because this callback brings state changes for the application. We cannot segregate this into individual handlers because of RAM penalty. - Other calbacks (none of them are implemented yet are optional). Example of using the API is provided with doxygen
2017-12-21 11:37:38 +00:00
}
Adding LoRaWANStack class to control MAC and PHY LoRaWANStack class is our controller layer on top of our current MAC and PHY layer. It provides services to an implementation of LoRaWANBase class. It is a singleton class owing to the fact that the mac layer underneath is not a class object. Instead, it uses the MAC via setting mib, mlme, mcps requests and getting responses back from the mac layer using confirmations and indications. In essense this class is a special handle for mac layer underneath which is predominantly reference design based. In future we may refactor the LoRaMac.cpp code to make it object oriented and cleaner. At one end, it binds the application selected radio driver with the PHY layer and at the other end it provides services to upper layers handling the mac via well defined APIs. For proper selection of a PHY layer, user must use Mbed config system. For this purpose an mbed_lib.json is provided which can be overriden by the user defined mbed_app.json. By default the EU868 band is selected as a PHY layer. User must set relevant keys for the selected connection mechanism.
2017-11-27 13:17:18 +00:00
}
[IOTCELL-282] Code cleanup/simplification and rules Baseline is changed to use a single set of data structures that simplifies the code in the LoRaWANStack and Mac layer. We are now following certian rules for naming data structures. - All structures visible outside their domain are prefixed as 'lorawan_' - All mac structures are prefixed as 'loramac_' - All subsystem or module strucutures carry their name in prefix, like 'mcps_' PHY layer still have legacy camel case data structures which will be entertained later while we will be simplifying PHY layer. Test cases are also updated with the new data structure naming conventions. One major difference from the previous baseline is the removal of static buffer from mcps indication. And we do not copy data from stack buffer to rx_msg buffer. This saves at least 512 bytes. It may look like now that if we have received something but the user have not read from the buffer, then the buffer will be overwritten and we will lose previous frame. Yes, we will. But the same will happen even if we would have copied the buffer into rx_msg because then the rx_msg gets overwritten. So we decide to abandon copying the buffer at multiple locations. We inform the user about reception, if the user doesn't read and the data gets overwritten, then so be it.
2018-01-12 14:39:31 +00:00
void LoRaWANStack::mcps_indication_handler(loramac_mcps_indication_t *mcps_indication)
Adding LoRaWANStack class to control MAC and PHY LoRaWANStack class is our controller layer on top of our current MAC and PHY layer. It provides services to an implementation of LoRaWANBase class. It is a singleton class owing to the fact that the mac layer underneath is not a class object. Instead, it uses the MAC via setting mib, mlme, mcps requests and getting responses back from the mac layer using confirmations and indications. In essense this class is a special handle for mac layer underneath which is predominantly reference design based. In future we may refactor the LoRaMac.cpp code to make it object oriented and cleaner. At one end, it binds the application selected radio driver with the PHY layer and at the other end it provides services to upper layers handling the mac via well defined APIs. For proper selection of a PHY layer, user must use Mbed config system. For this purpose an mbed_lib.json is provided which can be overriden by the user defined mbed_app.json. By default the EU868 band is selected as a PHY layer. User must set relevant keys for the selected connection mechanism.
2017-11-27 13:17:18 +00:00
{
[IOTCELL-282] Code cleanup/simplification and rules Baseline is changed to use a single set of data structures that simplifies the code in the LoRaWANStack and Mac layer. We are now following certian rules for naming data structures. - All structures visible outside their domain are prefixed as 'lorawan_' - All mac structures are prefixed as 'loramac_' - All subsystem or module strucutures carry their name in prefix, like 'mcps_' PHY layer still have legacy camel case data structures which will be entertained later while we will be simplifying PHY layer. Test cases are also updated with the new data structure naming conventions. One major difference from the previous baseline is the removal of static buffer from mcps indication. And we do not copy data from stack buffer to rx_msg buffer. This saves at least 512 bytes. It may look like now that if we have received something but the user have not read from the buffer, then the buffer will be overwritten and we will lose previous frame. Yes, we will. But the same will happen even if we would have copied the buffer into rx_msg because then the rx_msg gets overwritten. So we decide to abandon copying the buffer at multiple locations. We inform the user about reception, if the user doesn't read and the data gets overwritten, then so be it.
2018-01-12 14:39:31 +00:00
if (mcps_indication->status != LORAMAC_EVENT_INFO_STATUS_OK) {
Reworking callback API Application should be able to add some optional callbacks if it needs to. Ofcourse there is a penalty of 8-12 bytes per callback, but there can be certain needs of the application that needs to be met for example setting up a link check request etc. We have introduced a structure that contains callbacks for the application use. - 'events' callback is mandatory, user must assign it. Because this callback brings state changes for the application. We cannot segregate this into individual handlers because of RAM penalty. - Other calbacks (none of them are implemented yet are optional). Example of using the API is provided with doxygen
2017-12-21 11:37:38 +00:00
if (_callbacks.events) {
Improve error handling & robustness This commit also introduces API change for disconnect(). disconnect() will now return LORAWAN_STATUS_DEVICE_OFF for successfull disconnect. * LoRaWANStack::handle_tx() can be called with NULL buffer when length is 0. This commit fixes the case where user has provided NULL buffer and length is > max_possible_size. handle_tx() now always returns LORAWAN_STATUS_PARAMETER_INVALID if given buffer is NULL pointer and length > 0. General error checking is added and some asserts are added for events.
2018-02-09 07:59:15 +00:00
const int ret = _queue->call(_callbacks.events, RX_ERROR);
MBED_ASSERT(ret != 0);
(void)ret;
Reworking callback API Application should be able to add some optional callbacks if it needs to. Ofcourse there is a penalty of 8-12 bytes per callback, but there can be certain needs of the application that needs to be met for example setting up a link check request etc. We have introduced a structure that contains callbacks for the application use. - 'events' callback is mandatory, user must assign it. Because this callback brings state changes for the application. We cannot segregate this into individual handlers because of RAM penalty. - Other calbacks (none of them are implemented yet are optional). Example of using the API is provided with doxygen
2017-12-21 11:37:38 +00:00
}
Adding LoRaWANStack class to control MAC and PHY LoRaWANStack class is our controller layer on top of our current MAC and PHY layer. It provides services to an implementation of LoRaWANBase class. It is a singleton class owing to the fact that the mac layer underneath is not a class object. Instead, it uses the MAC via setting mib, mlme, mcps requests and getting responses back from the mac layer using confirmations and indications. In essense this class is a special handle for mac layer underneath which is predominantly reference design based. In future we may refactor the LoRaMac.cpp code to make it object oriented and cleaner. At one end, it binds the application selected radio driver with the PHY layer and at the other end it provides services to upper layers handling the mac via well defined APIs. For proper selection of a PHY layer, user must use Mbed config system. For this purpose an mbed_lib.json is provided which can be overriden by the user defined mbed_app.json. By default the EU868 band is selected as a PHY layer. User must set relevant keys for the selected connection mechanism.
2017-11-27 13:17:18 +00:00
return;
}
[IOTCELL-282] Code cleanup/simplification and rules Baseline is changed to use a single set of data structures that simplifies the code in the LoRaWANStack and Mac layer. We are now following certian rules for naming data structures. - All structures visible outside their domain are prefixed as 'lorawan_' - All mac structures are prefixed as 'loramac_' - All subsystem or module strucutures carry their name in prefix, like 'mcps_' PHY layer still have legacy camel case data structures which will be entertained later while we will be simplifying PHY layer. Test cases are also updated with the new data structure naming conventions. One major difference from the previous baseline is the removal of static buffer from mcps indication. And we do not copy data from stack buffer to rx_msg buffer. This saves at least 512 bytes. It may look like now that if we have received something but the user have not read from the buffer, then the buffer will be overwritten and we will lose previous frame. Yes, we will. But the same will happen even if we would have copied the buffer into rx_msg because then the rx_msg gets overwritten. So we decide to abandon copying the buffer at multiple locations. We inform the user about reception, if the user doesn't read and the data gets overwritten, then so be it.
2018-01-12 14:39:31 +00:00
switch (mcps_indication->type) {
case MCPS_UNCONFIRMED:
Adding LoRaWANStack class to control MAC and PHY LoRaWANStack class is our controller layer on top of our current MAC and PHY layer. It provides services to an implementation of LoRaWANBase class. It is a singleton class owing to the fact that the mac layer underneath is not a class object. Instead, it uses the MAC via setting mib, mlme, mcps requests and getting responses back from the mac layer using confirmations and indications. In essense this class is a special handle for mac layer underneath which is predominantly reference design based. In future we may refactor the LoRaMac.cpp code to make it object oriented and cleaner. At one end, it binds the application selected radio driver with the PHY layer and at the other end it provides services to upper layers handling the mac via well defined APIs. For proper selection of a PHY layer, user must use Mbed config system. For this purpose an mbed_lib.json is provided which can be overriden by the user defined mbed_app.json. By default the EU868 band is selected as a PHY layer. User must set relevant keys for the selected connection mechanism.
2017-11-27 13:17:18 +00:00
break;
[IOTCELL-282] Code cleanup/simplification and rules Baseline is changed to use a single set of data structures that simplifies the code in the LoRaWANStack and Mac layer. We are now following certian rules for naming data structures. - All structures visible outside their domain are prefixed as 'lorawan_' - All mac structures are prefixed as 'loramac_' - All subsystem or module strucutures carry their name in prefix, like 'mcps_' PHY layer still have legacy camel case data structures which will be entertained later while we will be simplifying PHY layer. Test cases are also updated with the new data structure naming conventions. One major difference from the previous baseline is the removal of static buffer from mcps indication. And we do not copy data from stack buffer to rx_msg buffer. This saves at least 512 bytes. It may look like now that if we have received something but the user have not read from the buffer, then the buffer will be overwritten and we will lose previous frame. Yes, we will. But the same will happen even if we would have copied the buffer into rx_msg because then the rx_msg gets overwritten. So we decide to abandon copying the buffer at multiple locations. We inform the user about reception, if the user doesn't read and the data gets overwritten, then so be it.
2018-01-12 14:39:31 +00:00
case MCPS_CONFIRMED:
Adding LoRaWANStack class to control MAC and PHY LoRaWANStack class is our controller layer on top of our current MAC and PHY layer. It provides services to an implementation of LoRaWANBase class. It is a singleton class owing to the fact that the mac layer underneath is not a class object. Instead, it uses the MAC via setting mib, mlme, mcps requests and getting responses back from the mac layer using confirmations and indications. In essense this class is a special handle for mac layer underneath which is predominantly reference design based. In future we may refactor the LoRaMac.cpp code to make it object oriented and cleaner. At one end, it binds the application selected radio driver with the PHY layer and at the other end it provides services to upper layers handling the mac via well defined APIs. For proper selection of a PHY layer, user must use Mbed config system. For this purpose an mbed_lib.json is provided which can be overriden by the user defined mbed_app.json. By default the EU868 band is selected as a PHY layer. User must set relevant keys for the selected connection mechanism.
2017-11-27 13:17:18 +00:00
break;
[IOTCELL-282] Code cleanup/simplification and rules Baseline is changed to use a single set of data structures that simplifies the code in the LoRaWANStack and Mac layer. We are now following certian rules for naming data structures. - All structures visible outside their domain are prefixed as 'lorawan_' - All mac structures are prefixed as 'loramac_' - All subsystem or module strucutures carry their name in prefix, like 'mcps_' PHY layer still have legacy camel case data structures which will be entertained later while we will be simplifying PHY layer. Test cases are also updated with the new data structure naming conventions. One major difference from the previous baseline is the removal of static buffer from mcps indication. And we do not copy data from stack buffer to rx_msg buffer. This saves at least 512 bytes. It may look like now that if we have received something but the user have not read from the buffer, then the buffer will be overwritten and we will lose previous frame. Yes, we will. But the same will happen even if we would have copied the buffer into rx_msg because then the rx_msg gets overwritten. So we decide to abandon copying the buffer at multiple locations. We inform the user about reception, if the user doesn't read and the data gets overwritten, then so be it.
2018-01-12 14:39:31 +00:00
case MCPS_PROPRIETARY:
Adding LoRaWANStack class to control MAC and PHY LoRaWANStack class is our controller layer on top of our current MAC and PHY layer. It provides services to an implementation of LoRaWANBase class. It is a singleton class owing to the fact that the mac layer underneath is not a class object. Instead, it uses the MAC via setting mib, mlme, mcps requests and getting responses back from the mac layer using confirmations and indications. In essense this class is a special handle for mac layer underneath which is predominantly reference design based. In future we may refactor the LoRaMac.cpp code to make it object oriented and cleaner. At one end, it binds the application selected radio driver with the PHY layer and at the other end it provides services to upper layers handling the mac via well defined APIs. For proper selection of a PHY layer, user must use Mbed config system. For this purpose an mbed_lib.json is provided which can be overriden by the user defined mbed_app.json. By default the EU868 band is selected as a PHY layer. User must set relevant keys for the selected connection mechanism.
2017-11-27 13:17:18 +00:00
break;
[IOTCELL-282] Code cleanup/simplification and rules Baseline is changed to use a single set of data structures that simplifies the code in the LoRaWANStack and Mac layer. We are now following certian rules for naming data structures. - All structures visible outside their domain are prefixed as 'lorawan_' - All mac structures are prefixed as 'loramac_' - All subsystem or module strucutures carry their name in prefix, like 'mcps_' PHY layer still have legacy camel case data structures which will be entertained later while we will be simplifying PHY layer. Test cases are also updated with the new data structure naming conventions. One major difference from the previous baseline is the removal of static buffer from mcps indication. And we do not copy data from stack buffer to rx_msg buffer. This saves at least 512 bytes. It may look like now that if we have received something but the user have not read from the buffer, then the buffer will be overwritten and we will lose previous frame. Yes, we will. But the same will happen even if we would have copied the buffer into rx_msg because then the rx_msg gets overwritten. So we decide to abandon copying the buffer at multiple locations. We inform the user about reception, if the user doesn't read and the data gets overwritten, then so be it.
2018-01-12 14:39:31 +00:00
case MCPS_MULTICAST:
Adding LoRaWANStack class to control MAC and PHY LoRaWANStack class is our controller layer on top of our current MAC and PHY layer. It provides services to an implementation of LoRaWANBase class. It is a singleton class owing to the fact that the mac layer underneath is not a class object. Instead, it uses the MAC via setting mib, mlme, mcps requests and getting responses back from the mac layer using confirmations and indications. In essense this class is a special handle for mac layer underneath which is predominantly reference design based. In future we may refactor the LoRaMac.cpp code to make it object oriented and cleaner. At one end, it binds the application selected radio driver with the PHY layer and at the other end it provides services to upper layers handling the mac via well defined APIs. For proper selection of a PHY layer, user must use Mbed config system. For this purpose an mbed_lib.json is provided which can be overriden by the user defined mbed_app.json. By default the EU868 band is selected as a PHY layer. User must set relevant keys for the selected connection mechanism.
2017-11-27 13:17:18 +00:00
break;
default:
break;
}
LoRaWANStack is made independent of MAC sublayers - Only internal changes, no API has been broke. - Tested by manually running Green tea tests
2018-03-16 11:12:50 +00:00
//TODO:
Adding LoRaWANStack class to control MAC and PHY LoRaWANStack class is our controller layer on top of our current MAC and PHY layer. It provides services to an implementation of LoRaWANBase class. It is a singleton class owing to the fact that the mac layer underneath is not a class object. Instead, it uses the MAC via setting mib, mlme, mcps requests and getting responses back from the mac layer using confirmations and indications. In essense this class is a special handle for mac layer underneath which is predominantly reference design based. In future we may refactor the LoRaMac.cpp code to make it object oriented and cleaner. At one end, it binds the application selected radio driver with the PHY layer and at the other end it provides services to upper layers handling the mac via well defined APIs. For proper selection of a PHY layer, user must use Mbed config system. For this purpose an mbed_lib.json is provided which can be overriden by the user defined mbed_app.json. By default the EU868 band is selected as a PHY layer. User must set relevant keys for the selected connection mechanism.
2017-11-27 13:17:18 +00:00
// Check Multicast
// Check Port
// Check Datarate
// Check FramePending
// Check Buffer
// Check BufferSize
// Check Rssi
// Check Snr
// Check RxSlot
_lw_session.downlink_counter++;
Move all compliance test code inside compilation flag All compliance test related codes are now inside LORAWAN_COMPLIANCE_TEST build flag. This will reduce memory usage in when compliance test codes are not needed.
2018-01-05 10:13:48 +00:00
#if defined(LORAWAN_COMPLIANCE_TEST)
Adding LoRaWANStack class to control MAC and PHY LoRaWANStack class is our controller layer on top of our current MAC and PHY layer. It provides services to an implementation of LoRaWANBase class. It is a singleton class owing to the fact that the mac layer underneath is not a class object. Instead, it uses the MAC via setting mib, mlme, mcps requests and getting responses back from the mac layer using confirmations and indications. In essense this class is a special handle for mac layer underneath which is predominantly reference design based. In future we may refactor the LoRaMac.cpp code to make it object oriented and cleaner. At one end, it binds the application selected radio driver with the PHY layer and at the other end it provides services to upper layers handling the mac via well defined APIs. For proper selection of a PHY layer, user must use Mbed config system. For this purpose an mbed_lib.json is provided which can be overriden by the user defined mbed_app.json. By default the EU868 band is selected as a PHY layer. User must set relevant keys for the selected connection mechanism.
2017-11-27 13:17:18 +00:00
if (_compliance_test.running == true) {
_compliance_test.downlink_counter++;
}
Move all compliance test code inside compilation flag All compliance test related codes are now inside LORAWAN_COMPLIANCE_TEST build flag. This will reduce memory usage in when compliance test codes are not needed.
2018-01-05 10:13:48 +00:00
#endif
Adding LoRaWANStack class to control MAC and PHY LoRaWANStack class is our controller layer on top of our current MAC and PHY layer. It provides services to an implementation of LoRaWANBase class. It is a singleton class owing to the fact that the mac layer underneath is not a class object. Instead, it uses the MAC via setting mib, mlme, mcps requests and getting responses back from the mac layer using confirmations and indications. In essense this class is a special handle for mac layer underneath which is predominantly reference design based. In future we may refactor the LoRaMac.cpp code to make it object oriented and cleaner. At one end, it binds the application selected radio driver with the PHY layer and at the other end it provides services to upper layers handling the mac via well defined APIs. For proper selection of a PHY layer, user must use Mbed config system. For this purpose an mbed_lib.json is provided which can be overriden by the user defined mbed_app.json. By default the EU868 band is selected as a PHY layer. User must set relevant keys for the selected connection mechanism.
2017-11-27 13:17:18 +00:00
[IOTCELL-282] Code cleanup/simplification and rules Baseline is changed to use a single set of data structures that simplifies the code in the LoRaWANStack and Mac layer. We are now following certian rules for naming data structures. - All structures visible outside their domain are prefixed as 'lorawan_' - All mac structures are prefixed as 'loramac_' - All subsystem or module strucutures carry their name in prefix, like 'mcps_' PHY layer still have legacy camel case data structures which will be entertained later while we will be simplifying PHY layer. Test cases are also updated with the new data structure naming conventions. One major difference from the previous baseline is the removal of static buffer from mcps indication. And we do not copy data from stack buffer to rx_msg buffer. This saves at least 512 bytes. It may look like now that if we have received something but the user have not read from the buffer, then the buffer will be overwritten and we will lose previous frame. Yes, we will. But the same will happen even if we would have copied the buffer into rx_msg because then the rx_msg gets overwritten. So we decide to abandon copying the buffer at multiple locations. We inform the user about reception, if the user doesn't read and the data gets overwritten, then so be it.
2018-01-12 14:39:31 +00:00
if (mcps_indication->is_data_recvd == true) {
Adding LoRaWANStack class to control MAC and PHY LoRaWANStack class is our controller layer on top of our current MAC and PHY layer. It provides services to an implementation of LoRaWANBase class. It is a singleton class owing to the fact that the mac layer underneath is not a class object. Instead, it uses the MAC via setting mib, mlme, mcps requests and getting responses back from the mac layer using confirmations and indications. In essense this class is a special handle for mac layer underneath which is predominantly reference design based. In future we may refactor the LoRaMac.cpp code to make it object oriented and cleaner. At one end, it binds the application selected radio driver with the PHY layer and at the other end it provides services to upper layers handling the mac via well defined APIs. For proper selection of a PHY layer, user must use Mbed config system. For this purpose an mbed_lib.json is provided which can be overriden by the user defined mbed_app.json. By default the EU868 band is selected as a PHY layer. User must set relevant keys for the selected connection mechanism.
2017-11-27 13:17:18 +00:00
switch (mcps_indication->port) {
LoRaWANStack is made independent of MAC sublayers - Only internal changes, no API has been broke. - Tested by manually running Green tea tests
2018-03-16 11:12:50 +00:00
case 224: {
Move all compliance test code inside compilation flag All compliance test related codes are now inside LORAWAN_COMPLIANCE_TEST build flag. This will reduce memory usage in when compliance test codes are not needed.
2018-01-05 10:13:48 +00:00
#if defined(LORAWAN_COMPLIANCE_TEST)
LoRaWANStack is made independent of MAC sublayers - Only internal changes, no API has been broke. - Tested by manually running Green tea tests
2018-03-16 11:12:50 +00:00
tr_debug("Compliance test command received.");
compliance_test_handler(mcps_indication);
Move all compliance test code inside compilation flag All compliance test related codes are now inside LORAWAN_COMPLIANCE_TEST build flag. This will reduce memory usage in when compliance test codes are not needed.
2018-01-05 10:13:48 +00:00
#else
LoRaWANStack is made independent of MAC sublayers - Only internal changes, no API has been broke. - Tested by manually running Green tea tests
2018-03-16 11:12:50 +00:00
tr_info("Compliance test disabled.");
Move all compliance test code inside compilation flag All compliance test related codes are now inside LORAWAN_COMPLIANCE_TEST build flag. This will reduce memory usage in when compliance test codes are not needed.
2018-01-05 10:13:48 +00:00
#endif
LoRaWANStack is made independent of MAC sublayers - Only internal changes, no API has been broke. - Tested by manually running Green tea tests
2018-03-16 11:12:50 +00:00
break;
}
default: {
if (is_port_valid(mcps_indication->port) == true ||
mcps_indication->type == MCPS_PROPRIETARY) {
// Valid message arrived.
_rx_msg.type = LORAMAC_RX_MCPS_INDICATION;
_rx_msg.msg.mcps_indication.buffer_size = mcps_indication->buffer_size;
_rx_msg.msg.mcps_indication.port = mcps_indication->port;
_rx_msg.msg.mcps_indication.buffer = mcps_indication->buffer;
// Notify application about received frame..
tr_debug("Received %d bytes", _rx_msg.msg.mcps_indication.buffer_size);
_rx_msg.receive_ready = true;
if (_callbacks.events) {
const int ret = _queue->call(_callbacks.events, RX_DONE);
MBED_ASSERT(ret != 0);
(void)ret;
}
Architecture rework, bug fixing & missing features MAC layer is now a class rather than being a blob. In addition to that Mac commands are now being handled in a seperate subsystem (a class of its own). In future we will do the same with othe sublayers of MAC like MLME, MCPS etc. The drive behind this exercise is to make MAC and supporting layers into an object oriented system. Major bug fixes include: - last join time inclusion in band parameters - disabling rx2 window if we missed the slot already - MLME uplink schdule hook - nbRep according to spec - maintaining datarate after successful joining - suppressing MLME requests if MAC is in TX_DELAYED state - Uplink dwell time verification Some missing features are implemented. Details are as follows. Support for LinkCheckRequet: An application API is added, add_link_check_request() to delegate a request for Link Check Request MAC command. * Application provides a callback function that needs to be called on reception of link check response. * Mac command is piggybacked with data frames. This API makes the sticky MAC command stick with the application payloads until/unless the application un-sticks the said mac command using remove_link_check_request() API. Handling fPending bit: If in the Downlink, we get the fPending bit set in fctrl octet, we attempt to send an empty message back to Network Server to open additional Receive windows. This operation is independent of the application. An RX_DONE event is queued bedore generating the said empty message. Specification does not mention what can be the type of that empty message. We have decided it to be of CONFIRMED type as it gives us an added benefit of retries if the corresponding RX slots are missed. Radio event callbacks as Mbed callbacks: radio_events_t structure has been carrying C-style callbacks which was inherited from the legacy code. These callbacks has now been changed to Mbed Callbacks that makes sure that we can be object oriented from now on.
2017-12-15 10:30:40 +00:00
LoRaWANStack is made independent of MAC sublayers - Only internal changes, no API has been broke. - Tested by manually running Green tea tests
2018-03-16 11:12:50 +00:00
//TODO: below if clauses can be combined,
// because those are calling same function with same parameters
Fix reception of class C messages - Do not put radio into sleep when message is received in class c mode - Experimental feature for acknowledging confirmed downlink messages
2018-02-22 13:24:44 +00:00
LoRaWANStack is made independent of MAC sublayers - Only internal changes, no API has been broke. - Tested by manually running Green tea tests
2018-03-16 11:12:50 +00:00
// If fPending bit is set we try to generate an empty packet
// with CONFIRMED flag set. We always set a CONFIRMED flag so
// that we could retry a certain number of times if the uplink
// failed for some reason
if (_loramac.get_device_class() != CLASS_C && mcps_indication->fpending_status) {
handle_tx(mcps_indication->port, NULL, 0, MSG_CONFIRMED_FLAG, true);
}
Fix reception of class C messages - Do not put radio into sleep when message is received in class c mode - Experimental feature for acknowledging confirmed downlink messages
2018-02-22 13:24:44 +00:00
LoRaWANStack is made independent of MAC sublayers - Only internal changes, no API has been broke. - Tested by manually running Green tea tests
2018-03-16 11:12:50 +00:00
// Class C and node received a confirmed message so we need to
// send an empty packet to acknowledge the message.
// This scenario is unspecified by LoRaWAN 1.0.2 specification,
// but version 1.1.0 says that network SHALL not send any new
// confirmed messages until ack has been sent
if (_loramac.get_device_class() == CLASS_C && mcps_indication->type == MCPS_CONFIRMED) {
handle_tx(mcps_indication->port, NULL, 0, MSG_CONFIRMED_FLAG, true);
}
} else {
// Invalid port, ports 0, 224 and 225-255 are reserved.
Architecture rework, bug fixing & missing features MAC layer is now a class rather than being a blob. In addition to that Mac commands are now being handled in a seperate subsystem (a class of its own). In future we will do the same with othe sublayers of MAC like MLME, MCPS etc. The drive behind this exercise is to make MAC and supporting layers into an object oriented system. Major bug fixes include: - last join time inclusion in band parameters - disabling rx2 window if we missed the slot already - MLME uplink schdule hook - nbRep according to spec - maintaining datarate after successful joining - suppressing MLME requests if MAC is in TX_DELAYED state - Uplink dwell time verification Some missing features are implemented. Details are as follows. Support for LinkCheckRequet: An application API is added, add_link_check_request() to delegate a request for Link Check Request MAC command. * Application provides a callback function that needs to be called on reception of link check response. * Mac command is piggybacked with data frames. This API makes the sticky MAC command stick with the application payloads until/unless the application un-sticks the said mac command using remove_link_check_request() API. Handling fPending bit: If in the Downlink, we get the fPending bit set in fctrl octet, we attempt to send an empty message back to Network Server to open additional Receive windows. This operation is independent of the application. An RX_DONE event is queued bedore generating the said empty message. Specification does not mention what can be the type of that empty message. We have decided it to be of CONFIRMED type as it gives us an added benefit of retries if the corresponding RX slots are missed. Radio event callbacks as Mbed callbacks: radio_events_t structure has been carrying C-style callbacks which was inherited from the legacy code. These callbacks has now been changed to Mbed Callbacks that makes sure that we can be object oriented from now on.
2017-12-15 10:30:40 +00:00
}
LoRaWANStack is made independent of MAC sublayers - Only internal changes, no API has been broke. - Tested by manually running Green tea tests
2018-03-16 11:12:50 +00:00
break;
Adding LoRaWANStack class to control MAC and PHY LoRaWANStack class is our controller layer on top of our current MAC and PHY layer. It provides services to an implementation of LoRaWANBase class. It is a singleton class owing to the fact that the mac layer underneath is not a class object. Instead, it uses the MAC via setting mib, mlme, mcps requests and getting responses back from the mac layer using confirmations and indications. In essense this class is a special handle for mac layer underneath which is predominantly reference design based. In future we may refactor the LoRaMac.cpp code to make it object oriented and cleaner. At one end, it binds the application selected radio driver with the PHY layer and at the other end it provides services to upper layers handling the mac via well defined APIs. For proper selection of a PHY layer, user must use Mbed config system. For this purpose an mbed_lib.json is provided which can be overriden by the user defined mbed_app.json. By default the EU868 band is selected as a PHY layer. User must set relevant keys for the selected connection mechanism.
2017-11-27 13:17:18 +00:00
}
}
}
}
[IOTCELL-282] Code cleanup/simplification and rules Baseline is changed to use a single set of data structures that simplifies the code in the LoRaWANStack and Mac layer. We are now following certian rules for naming data structures. - All structures visible outside their domain are prefixed as 'lorawan_' - All mac structures are prefixed as 'loramac_' - All subsystem or module strucutures carry their name in prefix, like 'mcps_' PHY layer still have legacy camel case data structures which will be entertained later while we will be simplifying PHY layer. Test cases are also updated with the new data structure naming conventions. One major difference from the previous baseline is the removal of static buffer from mcps indication. And we do not copy data from stack buffer to rx_msg buffer. This saves at least 512 bytes. It may look like now that if we have received something but the user have not read from the buffer, then the buffer will be overwritten and we will lose previous frame. Yes, we will. But the same will happen even if we would have copied the buffer into rx_msg because then the rx_msg gets overwritten. So we decide to abandon copying the buffer at multiple locations. We inform the user about reception, if the user doesn't read and the data gets overwritten, then so be it.
2018-01-12 14:39:31 +00:00
lorawan_status_t LoRaWANStack::set_link_check_request()
Architecture rework, bug fixing & missing features MAC layer is now a class rather than being a blob. In addition to that Mac commands are now being handled in a seperate subsystem (a class of its own). In future we will do the same with othe sublayers of MAC like MLME, MCPS etc. The drive behind this exercise is to make MAC and supporting layers into an object oriented system. Major bug fixes include: - last join time inclusion in band parameters - disabling rx2 window if we missed the slot already - MLME uplink schdule hook - nbRep according to spec - maintaining datarate after successful joining - suppressing MLME requests if MAC is in TX_DELAYED state - Uplink dwell time verification Some missing features are implemented. Details are as follows. Support for LinkCheckRequet: An application API is added, add_link_check_request() to delegate a request for Link Check Request MAC command. * Application provides a callback function that needs to be called on reception of link check response. * Mac command is piggybacked with data frames. This API makes the sticky MAC command stick with the application payloads until/unless the application un-sticks the said mac command using remove_link_check_request() API. Handling fPending bit: If in the Downlink, we get the fPending bit set in fctrl octet, we attempt to send an empty message back to Network Server to open additional Receive windows. This operation is independent of the application. An RX_DONE event is queued bedore generating the said empty message. Specification does not mention what can be the type of that empty message. We have decided it to be of CONFIRMED type as it gives us an added benefit of retries if the corresponding RX slots are missed. Radio event callbacks as Mbed callbacks: radio_events_t structure has been carrying C-style callbacks which was inherited from the legacy code. These callbacks has now been changed to Mbed Callbacks that makes sure that we can be object oriented from now on.
2017-12-15 10:30:40 +00:00
{
LoRa: LoRaWANInterface refactored. - Only internal changes, no functionality changes - Some minor improvements to LoRaWanStack
2018-03-12 11:30:00 +00:00
_link_check_requested = true;
Architecture rework, bug fixing & missing features MAC layer is now a class rather than being a blob. In addition to that Mac commands are now being handled in a seperate subsystem (a class of its own). In future we will do the same with othe sublayers of MAC like MLME, MCPS etc. The drive behind this exercise is to make MAC and supporting layers into an object oriented system. Major bug fixes include: - last join time inclusion in band parameters - disabling rx2 window if we missed the slot already - MLME uplink schdule hook - nbRep according to spec - maintaining datarate after successful joining - suppressing MLME requests if MAC is in TX_DELAYED state - Uplink dwell time verification Some missing features are implemented. Details are as follows. Support for LinkCheckRequet: An application API is added, add_link_check_request() to delegate a request for Link Check Request MAC command. * Application provides a callback function that needs to be called on reception of link check response. * Mac command is piggybacked with data frames. This API makes the sticky MAC command stick with the application payloads until/unless the application un-sticks the said mac command using remove_link_check_request() API. Handling fPending bit: If in the Downlink, we get the fPending bit set in fctrl octet, we attempt to send an empty message back to Network Server to open additional Receive windows. This operation is independent of the application. An RX_DONE event is queued bedore generating the said empty message. Specification does not mention what can be the type of that empty message. We have decided it to be of CONFIRMED type as it gives us an added benefit of retries if the corresponding RX slots are missed. Radio event callbacks as Mbed callbacks: radio_events_t structure has been carrying C-style callbacks which was inherited from the legacy code. These callbacks has now been changed to Mbed Callbacks that makes sure that we can be object oriented from now on.
2017-12-15 10:30:40 +00:00
if (!_callbacks.link_check_resp) {
tr_error("Must assign a callback function for link check request. ");
[IOTCELL-282] Code cleanup/simplification and rules Baseline is changed to use a single set of data structures that simplifies the code in the LoRaWANStack and Mac layer. We are now following certian rules for naming data structures. - All structures visible outside their domain are prefixed as 'lorawan_' - All mac structures are prefixed as 'loramac_' - All subsystem or module strucutures carry their name in prefix, like 'mcps_' PHY layer still have legacy camel case data structures which will be entertained later while we will be simplifying PHY layer. Test cases are also updated with the new data structure naming conventions. One major difference from the previous baseline is the removal of static buffer from mcps indication. And we do not copy data from stack buffer to rx_msg buffer. This saves at least 512 bytes. It may look like now that if we have received something but the user have not read from the buffer, then the buffer will be overwritten and we will lose previous frame. Yes, we will. But the same will happen even if we would have copied the buffer into rx_msg because then the rx_msg gets overwritten. So we decide to abandon copying the buffer at multiple locations. We inform the user about reception, if the user doesn't read and the data gets overwritten, then so be it.
2018-01-12 14:39:31 +00:00
return LORAWAN_STATUS_PARAMETER_INVALID;
Architecture rework, bug fixing & missing features MAC layer is now a class rather than being a blob. In addition to that Mac commands are now being handled in a seperate subsystem (a class of its own). In future we will do the same with othe sublayers of MAC like MLME, MCPS etc. The drive behind this exercise is to make MAC and supporting layers into an object oriented system. Major bug fixes include: - last join time inclusion in band parameters - disabling rx2 window if we missed the slot already - MLME uplink schdule hook - nbRep according to spec - maintaining datarate after successful joining - suppressing MLME requests if MAC is in TX_DELAYED state - Uplink dwell time verification Some missing features are implemented. Details are as follows. Support for LinkCheckRequet: An application API is added, add_link_check_request() to delegate a request for Link Check Request MAC command. * Application provides a callback function that needs to be called on reception of link check response. * Mac command is piggybacked with data frames. This API makes the sticky MAC command stick with the application payloads until/unless the application un-sticks the said mac command using remove_link_check_request() API. Handling fPending bit: If in the Downlink, we get the fPending bit set in fctrl octet, we attempt to send an empty message back to Network Server to open additional Receive windows. This operation is independent of the application. An RX_DONE event is queued bedore generating the said empty message. Specification does not mention what can be the type of that empty message. We have decided it to be of CONFIRMED type as it gives us an added benefit of retries if the corresponding RX slots are missed. Radio event callbacks as Mbed callbacks: radio_events_t structure has been carrying C-style callbacks which was inherited from the legacy code. These callbacks has now been changed to Mbed Callbacks that makes sure that we can be object oriented from now on.
2017-12-15 10:30:40 +00:00
}
LoRaWANStack is made independent of MAC sublayers - Only internal changes, no API has been broke. - Tested by manually running Green tea tests
2018-03-16 11:12:50 +00:00
_loramac.setup_link_check_request();
return LORAWAN_STATUS_OK;
LoRa: LoRaWANInterface refactored. - Only internal changes, no functionality changes - Some minor improvements to LoRaWanStack
2018-03-12 11:30:00 +00:00
}
void LoRaWANStack::remove_link_check_request()
{
_link_check_requested = false;
Architecture rework, bug fixing & missing features MAC layer is now a class rather than being a blob. In addition to that Mac commands are now being handled in a seperate subsystem (a class of its own). In future we will do the same with othe sublayers of MAC like MLME, MCPS etc. The drive behind this exercise is to make MAC and supporting layers into an object oriented system. Major bug fixes include: - last join time inclusion in band parameters - disabling rx2 window if we missed the slot already - MLME uplink schdule hook - nbRep according to spec - maintaining datarate after successful joining - suppressing MLME requests if MAC is in TX_DELAYED state - Uplink dwell time verification Some missing features are implemented. Details are as follows. Support for LinkCheckRequet: An application API is added, add_link_check_request() to delegate a request for Link Check Request MAC command. * Application provides a callback function that needs to be called on reception of link check response. * Mac command is piggybacked with data frames. This API makes the sticky MAC command stick with the application payloads until/unless the application un-sticks the said mac command using remove_link_check_request() API. Handling fPending bit: If in the Downlink, we get the fPending bit set in fctrl octet, we attempt to send an empty message back to Network Server to open additional Receive windows. This operation is independent of the application. An RX_DONE event is queued bedore generating the said empty message. Specification does not mention what can be the type of that empty message. We have decided it to be of CONFIRMED type as it gives us an added benefit of retries if the corresponding RX slots are missed. Radio event callbacks as Mbed callbacks: radio_events_t structure has been carrying C-style callbacks which was inherited from the legacy code. These callbacks has now been changed to Mbed Callbacks that makes sure that we can be object oriented from now on.
2017-12-15 10:30:40 +00:00
}
Improve error handling & robustness This commit also introduces API change for disconnect(). disconnect() will now return LORAWAN_STATUS_DEVICE_OFF for successfull disconnect. * LoRaWANStack::handle_tx() can be called with NULL buffer when length is 0. This commit fixes the case where user has provided NULL buffer and length is > max_possible_size. handle_tx() now always returns LORAWAN_STATUS_PARAMETER_INVALID if given buffer is NULL pointer and length > 0. General error checking is added and some asserts are added for events.
2018-02-09 07:59:15 +00:00
lorawan_status_t LoRaWANStack::shutdown()
Adding LoRaWANStack class to control MAC and PHY LoRaWANStack class is our controller layer on top of our current MAC and PHY layer. It provides services to an implementation of LoRaWANBase class. It is a singleton class owing to the fact that the mac layer underneath is not a class object. Instead, it uses the MAC via setting mib, mlme, mcps requests and getting responses back from the mac layer using confirmations and indications. In essense this class is a special handle for mac layer underneath which is predominantly reference design based. In future we may refactor the LoRaMac.cpp code to make it object oriented and cleaner. At one end, it binds the application selected radio driver with the PHY layer and at the other end it provides services to upper layers handling the mac via well defined APIs. For proper selection of a PHY layer, user must use Mbed config system. For this purpose an mbed_lib.json is provided which can be overriden by the user defined mbed_app.json. By default the EU868 band is selected as a PHY layer. User must set relevant keys for the selected connection mechanism.
2017-11-27 13:17:18 +00:00
{
LoRa: LoRaWANInterface refactored. - Only internal changes, no functionality changes - Some minor improvements to LoRaWanStack
2018-03-12 11:30:00 +00:00
return lora_state_machine(DEVICE_STATE_SHUTDOWN);
Adding LoRaWANStack class to control MAC and PHY LoRaWANStack class is our controller layer on top of our current MAC and PHY layer. It provides services to an implementation of LoRaWANBase class. It is a singleton class owing to the fact that the mac layer underneath is not a class object. Instead, it uses the MAC via setting mib, mlme, mcps requests and getting responses back from the mac layer using confirmations and indications. In essense this class is a special handle for mac layer underneath which is predominantly reference design based. In future we may refactor the LoRaMac.cpp code to make it object oriented and cleaner. At one end, it binds the application selected radio driver with the PHY layer and at the other end it provides services to upper layers handling the mac via well defined APIs. For proper selection of a PHY layer, user must use Mbed config system. For this purpose an mbed_lib.json is provided which can be overriden by the user defined mbed_app.json. By default the EU868 band is selected as a PHY layer. User must set relevant keys for the selected connection mechanism.
2017-11-27 13:17:18 +00:00
}
LoRaWANStack is made independent of MAC sublayers - Only internal changes, no API has been broke. - Tested by manually running Green tea tests
2018-03-16 11:12:50 +00:00
lorawan_status_t LoRaWANStack::set_device_class(const device_class_t& device_class)
Add set_device_class API to change active device class 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
2018-02-20 13:48:08 +00:00
{
LoRaWANStack is made independent of MAC sublayers - Only internal changes, no API has been broke. - Tested by manually running Green tea tests
2018-03-16 11:12:50 +00:00
if (device_class == CLASS_B) {
return LORAWAN_STATUS_UNSUPPORTED;
}
_loramac.set_device_class(device_class);
return LORAWAN_STATUS_OK;
Add set_device_class API to change active device class 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
2018-02-20 13:48:08 +00:00
}
LoRa: LoRaWANInterface refactored. - Only internal changes, no functionality changes - Some minor improvements to LoRaWanStack
2018-03-12 11:30:00 +00:00
lorawan_status_t LoRaWANStack::lora_state_machine(device_states_t new_state)
Adding LoRaWANStack class to control MAC and PHY LoRaWANStack class is our controller layer on top of our current MAC and PHY layer. It provides services to an implementation of LoRaWANBase class. It is a singleton class owing to the fact that the mac layer underneath is not a class object. Instead, it uses the MAC via setting mib, mlme, mcps requests and getting responses back from the mac layer using confirmations and indications. In essense this class is a special handle for mac layer underneath which is predominantly reference design based. In future we may refactor the LoRaMac.cpp code to make it object oriented and cleaner. At one end, it binds the application selected radio driver with the PHY layer and at the other end it provides services to upper layers handling the mac via well defined APIs. For proper selection of a PHY layer, user must use Mbed config system. For this purpose an mbed_lib.json is provided which can be overriden by the user defined mbed_app.json. By default the EU868 band is selected as a PHY layer. User must set relevant keys for the selected connection mechanism.
2017-11-27 13:17:18 +00:00
{
[IOTCELL-282] Code cleanup/simplification and rules Baseline is changed to use a single set of data structures that simplifies the code in the LoRaWANStack and Mac layer. We are now following certian rules for naming data structures. - All structures visible outside their domain are prefixed as 'lorawan_' - All mac structures are prefixed as 'loramac_' - All subsystem or module strucutures carry their name in prefix, like 'mcps_' PHY layer still have legacy camel case data structures which will be entertained later while we will be simplifying PHY layer. Test cases are also updated with the new data structure naming conventions. One major difference from the previous baseline is the removal of static buffer from mcps indication. And we do not copy data from stack buffer to rx_msg buffer. This saves at least 512 bytes. It may look like now that if we have received something but the user have not read from the buffer, then the buffer will be overwritten and we will lose previous frame. Yes, we will. But the same will happen even if we would have copied the buffer into rx_msg because then the rx_msg gets overwritten. So we decide to abandon copying the buffer at multiple locations. We inform the user about reception, if the user doesn't read and the data gets overwritten, then so be it.
2018-01-12 14:39:31 +00:00
lorawan_status_t status = LORAWAN_STATUS_DEVICE_OFF;
Adding LoRaWANStack class to control MAC and PHY LoRaWANStack class is our controller layer on top of our current MAC and PHY layer. It provides services to an implementation of LoRaWANBase class. It is a singleton class owing to the fact that the mac layer underneath is not a class object. Instead, it uses the MAC via setting mib, mlme, mcps requests and getting responses back from the mac layer using confirmations and indications. In essense this class is a special handle for mac layer underneath which is predominantly reference design based. In future we may refactor the LoRaMac.cpp code to make it object oriented and cleaner. At one end, it binds the application selected radio driver with the PHY layer and at the other end it provides services to upper layers handling the mac via well defined APIs. For proper selection of a PHY layer, user must use Mbed config system. For this purpose an mbed_lib.json is provided which can be overriden by the user defined mbed_app.json. By default the EU868 band is selected as a PHY layer. User must set relevant keys for the selected connection mechanism.
2017-11-27 13:17:18 +00:00
LoRa: LoRaWANInterface refactored. - Only internal changes, no functionality changes - Some minor improvements to LoRaWanStack
2018-03-12 11:30:00 +00:00
_device_current_state = new_state;
Adding LoRaWANStack class to control MAC and PHY LoRaWANStack class is our controller layer on top of our current MAC and PHY layer. It provides services to an implementation of LoRaWANBase class. It is a singleton class owing to the fact that the mac layer underneath is not a class object. Instead, it uses the MAC via setting mib, mlme, mcps requests and getting responses back from the mac layer using confirmations and indications. In essense this class is a special handle for mac layer underneath which is predominantly reference design based. In future we may refactor the LoRaMac.cpp code to make it object oriented and cleaner. At one end, it binds the application selected radio driver with the PHY layer and at the other end it provides services to upper layers handling the mac via well defined APIs. For proper selection of a PHY layer, user must use Mbed config system. For this purpose an mbed_lib.json is provided which can be overriden by the user defined mbed_app.json. By default the EU868 band is selected as a PHY layer. User must set relevant keys for the selected connection mechanism.
2017-11-27 13:17:18 +00:00
switch (_device_current_state) {
case DEVICE_STATE_SHUTDOWN:
/*
* Remove channels
* Radio will be put to sleep by the APIs underneath
*/
drop_channel_list();
Implement LoRaMac::disconnect In order to reset LoRaMac's state in disconnect, we need to implement an API which can be used to cancel all outstanding requests and reset LoRaMac's internal state to idle. This commit introduces LoRaMac::disconnect() which can be used for this purpose.
2018-01-26 12:33:26 +00:00
_loramac.disconnect();
Move all compliance test code inside compilation flag All compliance test related codes are now inside LORAWAN_COMPLIANCE_TEST build flag. This will reduce memory usage in when compliance test codes are not needed.
2018-01-05 10:13:48 +00:00
#if defined(LORAWAN_COMPLIANCE_TEST)
_loramac.LoRaMacStopTxTimer();
#endif
LoRaWANStack is made independent of MAC sublayers - Only internal changes, no API has been broke. - Tested by manually running Green tea tests
2018-03-16 11:12:50 +00:00
_loramac.set_nwk_joined(false);
Adding LoRaWANStack class to control MAC and PHY LoRaWANStack class is our controller layer on top of our current MAC and PHY layer. It provides services to an implementation of LoRaWANBase class. It is a singleton class owing to the fact that the mac layer underneath is not a class object. Instead, it uses the MAC via setting mib, mlme, mcps requests and getting responses back from the mac layer using confirmations and indications. In essense this class is a special handle for mac layer underneath which is predominantly reference design based. In future we may refactor the LoRaMac.cpp code to make it object oriented and cleaner. At one end, it binds the application selected radio driver with the PHY layer and at the other end it provides services to upper layers handling the mac via well defined APIs. For proper selection of a PHY layer, user must use Mbed config system. For this purpose an mbed_lib.json is provided which can be overriden by the user defined mbed_app.json. By default the EU868 band is selected as a PHY layer. User must set relevant keys for the selected connection mechanism.
2017-11-27 13:17:18 +00:00
LoRa: LoRaPHY dependency removed from LoRaMacStack - 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
2018-03-15 08:43:31 +00:00
_loramac.reset_ongoing_tx(true);
[IOTCELL-282] Code cleanup/simplification and rules Baseline is changed to use a single set of data structures that simplifies the code in the LoRaWANStack and Mac layer. We are now following certian rules for naming data structures. - All structures visible outside their domain are prefixed as 'lorawan_' - All mac structures are prefixed as 'loramac_' - All subsystem or module strucutures carry their name in prefix, like 'mcps_' PHY layer still have legacy camel case data structures which will be entertained later while we will be simplifying PHY layer. Test cases are also updated with the new data structure naming conventions. One major difference from the previous baseline is the removal of static buffer from mcps indication. And we do not copy data from stack buffer to rx_msg buffer. This saves at least 512 bytes. It may look like now that if we have received something but the user have not read from the buffer, then the buffer will be overwritten and we will lose previous frame. Yes, we will. But the same will happen even if we would have copied the buffer into rx_msg because then the rx_msg gets overwritten. So we decide to abandon copying the buffer at multiple locations. We inform the user about reception, if the user doesn't read and the data gets overwritten, then so be it.
2018-01-12 14:39:31 +00:00
_rx_msg.msg.mcps_indication.buffer = NULL;
Adding LoRaWANStack class to control MAC and PHY LoRaWANStack class is our controller layer on top of our current MAC and PHY layer. It provides services to an implementation of LoRaWANBase class. It is a singleton class owing to the fact that the mac layer underneath is not a class object. Instead, it uses the MAC via setting mib, mlme, mcps requests and getting responses back from the mac layer using confirmations and indications. In essense this class is a special handle for mac layer underneath which is predominantly reference design based. In future we may refactor the LoRaMac.cpp code to make it object oriented and cleaner. At one end, it binds the application selected radio driver with the PHY layer and at the other end it provides services to upper layers handling the mac via well defined APIs. For proper selection of a PHY layer, user must use Mbed config system. For this purpose an mbed_lib.json is provided which can be overriden by the user defined mbed_app.json. By default the EU868 band is selected as a PHY layer. User must set relevant keys for the selected connection mechanism.
2017-11-27 13:17:18 +00:00
_rx_msg.receive_ready = false;
_rx_msg.prev_read_size = 0;
[IOTCELL-282] Code cleanup/simplification and rules Baseline is changed to use a single set of data structures that simplifies the code in the LoRaWANStack and Mac layer. We are now following certian rules for naming data structures. - All structures visible outside their domain are prefixed as 'lorawan_' - All mac structures are prefixed as 'loramac_' - All subsystem or module strucutures carry their name in prefix, like 'mcps_' PHY layer still have legacy camel case data structures which will be entertained later while we will be simplifying PHY layer. Test cases are also updated with the new data structure naming conventions. One major difference from the previous baseline is the removal of static buffer from mcps indication. And we do not copy data from stack buffer to rx_msg buffer. This saves at least 512 bytes. It may look like now that if we have received something but the user have not read from the buffer, then the buffer will be overwritten and we will lose previous frame. Yes, we will. But the same will happen even if we would have copied the buffer into rx_msg because then the rx_msg gets overwritten. So we decide to abandon copying the buffer at multiple locations. We inform the user about reception, if the user doesn't read and the data gets overwritten, then so be it.
2018-01-12 14:39:31 +00:00
_rx_msg.msg.mcps_indication.buffer_size = 0;
Adding LoRaWANStack class to control MAC and PHY LoRaWANStack class is our controller layer on top of our current MAC and PHY layer. It provides services to an implementation of LoRaWANBase class. It is a singleton class owing to the fact that the mac layer underneath is not a class object. Instead, it uses the MAC via setting mib, mlme, mcps requests and getting responses back from the mac layer using confirmations and indications. In essense this class is a special handle for mac layer underneath which is predominantly reference design based. In future we may refactor the LoRaMac.cpp code to make it object oriented and cleaner. At one end, it binds the application selected radio driver with the PHY layer and at the other end it provides services to upper layers handling the mac via well defined APIs. For proper selection of a PHY layer, user must use Mbed config system. For this purpose an mbed_lib.json is provided which can be overriden by the user defined mbed_app.json. By default the EU868 band is selected as a PHY layer. User must set relevant keys for the selected connection mechanism.
2017-11-27 13:17:18 +00:00
_lw_session.active = false;
tr_debug("LoRaWAN protocol has been shut down.");
Reworking callback API Application should be able to add some optional callbacks if it needs to. Ofcourse there is a penalty of 8-12 bytes per callback, but there can be certain needs of the application that needs to be met for example setting up a link check request etc. We have introduced a structure that contains callbacks for the application use. - 'events' callback is mandatory, user must assign it. Because this callback brings state changes for the application. We cannot segregate this into individual handlers because of RAM penalty. - Other calbacks (none of them are implemented yet are optional). Example of using the API is provided with doxygen
2017-12-21 11:37:38 +00:00
if (_callbacks.events) {
Improve error handling & robustness This commit also introduces API change for disconnect(). disconnect() will now return LORAWAN_STATUS_DEVICE_OFF for successfull disconnect. * LoRaWANStack::handle_tx() can be called with NULL buffer when length is 0. This commit fixes the case where user has provided NULL buffer and length is > max_possible_size. handle_tx() now always returns LORAWAN_STATUS_PARAMETER_INVALID if given buffer is NULL pointer and length > 0. General error checking is added and some asserts are added for events.
2018-02-09 07:59:15 +00:00
const int ret = _queue->call(_callbacks.events, DISCONNECTED);
MBED_ASSERT(ret != 0);
(void)ret;
Reworking callback API Application should be able to add some optional callbacks if it needs to. Ofcourse there is a penalty of 8-12 bytes per callback, but there can be certain needs of the application that needs to be met for example setting up a link check request etc. We have introduced a structure that contains callbacks for the application use. - 'events' callback is mandatory, user must assign it. Because this callback brings state changes for the application. We cannot segregate this into individual handlers because of RAM penalty. - Other calbacks (none of them are implemented yet are optional). Example of using the API is provided with doxygen
2017-12-21 11:37:38 +00:00
}
[IOTCELL-282] Code cleanup/simplification and rules Baseline is changed to use a single set of data structures that simplifies the code in the LoRaWANStack and Mac layer. We are now following certian rules for naming data structures. - All structures visible outside their domain are prefixed as 'lorawan_' - All mac structures are prefixed as 'loramac_' - All subsystem or module strucutures carry their name in prefix, like 'mcps_' PHY layer still have legacy camel case data structures which will be entertained later while we will be simplifying PHY layer. Test cases are also updated with the new data structure naming conventions. One major difference from the previous baseline is the removal of static buffer from mcps indication. And we do not copy data from stack buffer to rx_msg buffer. This saves at least 512 bytes. It may look like now that if we have received something but the user have not read from the buffer, then the buffer will be overwritten and we will lose previous frame. Yes, we will. But the same will happen even if we would have copied the buffer into rx_msg because then the rx_msg gets overwritten. So we decide to abandon copying the buffer at multiple locations. We inform the user about reception, if the user doesn't read and the data gets overwritten, then so be it.
2018-01-12 14:39:31 +00:00
status = LORAWAN_STATUS_DEVICE_OFF;
Adding LoRaWANStack class to control MAC and PHY LoRaWANStack class is our controller layer on top of our current MAC and PHY layer. It provides services to an implementation of LoRaWANBase class. It is a singleton class owing to the fact that the mac layer underneath is not a class object. Instead, it uses the MAC via setting mib, mlme, mcps requests and getting responses back from the mac layer using confirmations and indications. In essense this class is a special handle for mac layer underneath which is predominantly reference design based. In future we may refactor the LoRaMac.cpp code to make it object oriented and cleaner. At one end, it binds the application selected radio driver with the PHY layer and at the other end it provides services to upper layers handling the mac via well defined APIs. For proper selection of a PHY layer, user must use Mbed config system. For this purpose an mbed_lib.json is provided which can be overriden by the user defined mbed_app.json. By default the EU868 band is selected as a PHY layer. User must set relevant keys for the selected connection mechanism.
2017-11-27 13:17:18 +00:00
break;
case DEVICE_STATE_NOT_INITIALIZED:
[IOTCELL-282] Code cleanup/simplification and rules Baseline is changed to use a single set of data structures that simplifies the code in the LoRaWANStack and Mac layer. We are now following certian rules for naming data structures. - All structures visible outside their domain are prefixed as 'lorawan_' - All mac structures are prefixed as 'loramac_' - All subsystem or module strucutures carry their name in prefix, like 'mcps_' PHY layer still have legacy camel case data structures which will be entertained later while we will be simplifying PHY layer. Test cases are also updated with the new data structure naming conventions. One major difference from the previous baseline is the removal of static buffer from mcps indication. And we do not copy data from stack buffer to rx_msg buffer. This saves at least 512 bytes. It may look like now that if we have received something but the user have not read from the buffer, then the buffer will be overwritten and we will lose previous frame. Yes, we will. But the same will happen even if we would have copied the buffer into rx_msg because then the rx_msg gets overwritten. So we decide to abandon copying the buffer at multiple locations. We inform the user about reception, if the user doesn't read and the data gets overwritten, then so be it.
2018-01-12 14:39:31 +00:00
status = LORAWAN_STATUS_DEVICE_OFF;
Adding LoRaWANStack class to control MAC and PHY LoRaWANStack class is our controller layer on top of our current MAC and PHY layer. It provides services to an implementation of LoRaWANBase class. It is a singleton class owing to the fact that the mac layer underneath is not a class object. Instead, it uses the MAC via setting mib, mlme, mcps requests and getting responses back from the mac layer using confirmations and indications. In essense this class is a special handle for mac layer underneath which is predominantly reference design based. In future we may refactor the LoRaMac.cpp code to make it object oriented and cleaner. At one end, it binds the application selected radio driver with the PHY layer and at the other end it provides services to upper layers handling the mac via well defined APIs. For proper selection of a PHY layer, user must use Mbed config system. For this purpose an mbed_lib.json is provided which can be overriden by the user defined mbed_app.json. By default the EU868 band is selected as a PHY layer. User must set relevant keys for the selected connection mechanism.
2017-11-27 13:17:18 +00:00
break;
case DEVICE_STATE_INIT:
[IOTCELL-282] Code cleanup/simplification and rules Baseline is changed to use a single set of data structures that simplifies the code in the LoRaWANStack and Mac layer. We are now following certian rules for naming data structures. - All structures visible outside their domain are prefixed as 'lorawan_' - All mac structures are prefixed as 'loramac_' - All subsystem or module strucutures carry their name in prefix, like 'mcps_' PHY layer still have legacy camel case data structures which will be entertained later while we will be simplifying PHY layer. Test cases are also updated with the new data structure naming conventions. One major difference from the previous baseline is the removal of static buffer from mcps indication. And we do not copy data from stack buffer to rx_msg buffer. This saves at least 512 bytes. It may look like now that if we have received something but the user have not read from the buffer, then the buffer will be overwritten and we will lose previous frame. Yes, we will. But the same will happen even if we would have copied the buffer into rx_msg because then the rx_msg gets overwritten. So we decide to abandon copying the buffer at multiple locations. We inform the user about reception, if the user doesn't read and the data gets overwritten, then so be it.
2018-01-12 14:39:31 +00:00
status = LORAWAN_STATUS_OK;
Adding LoRaWANStack class to control MAC and PHY LoRaWANStack class is our controller layer on top of our current MAC and PHY layer. It provides services to an implementation of LoRaWANBase class. It is a singleton class owing to the fact that the mac layer underneath is not a class object. Instead, it uses the MAC via setting mib, mlme, mcps requests and getting responses back from the mac layer using confirmations and indications. In essense this class is a special handle for mac layer underneath which is predominantly reference design based. In future we may refactor the LoRaMac.cpp code to make it object oriented and cleaner. At one end, it binds the application selected radio driver with the PHY layer and at the other end it provides services to upper layers handling the mac via well defined APIs. For proper selection of a PHY layer, user must use Mbed config system. For this purpose an mbed_lib.json is provided which can be overriden by the user defined mbed_app.json. By default the EU868 band is selected as a PHY layer. User must set relevant keys for the selected connection mechanism.
2017-11-27 13:17:18 +00:00
break;
case DEVICE_STATE_JOINING:
if (_lw_session.connection.connect_type == LORAWAN_CONNECTION_OTAA) {
tr_debug("Send Join-request..");
LoRaWANStack is made independent of MAC sublayers - Only internal changes, no API has been broke. - Tested by manually running Green tea tests
2018-03-16 11:12:50 +00:00
status = _loramac.join_by_otaa(_lw_session.connection.connection_u.otaa);
[IOTCELL-282] Code cleanup/simplification and rules Baseline is changed to use a single set of data structures that simplifies the code in the LoRaWANStack and Mac layer. We are now following certian rules for naming data structures. - All structures visible outside their domain are prefixed as 'lorawan_' - All mac structures are prefixed as 'loramac_' - All subsystem or module strucutures carry their name in prefix, like 'mcps_' PHY layer still have legacy camel case data structures which will be entertained later while we will be simplifying PHY layer. Test cases are also updated with the new data structure naming conventions. One major difference from the previous baseline is the removal of static buffer from mcps indication. And we do not copy data from stack buffer to rx_msg buffer. This saves at least 512 bytes. It may look like now that if we have received something but the user have not read from the buffer, then the buffer will be overwritten and we will lose previous frame. Yes, we will. But the same will happen even if we would have copied the buffer into rx_msg because then the rx_msg gets overwritten. So we decide to abandon copying the buffer at multiple locations. We inform the user about reception, if the user doesn't read and the data gets overwritten, then so be it.
2018-01-12 14:39:31 +00:00
if (status != LORAWAN_STATUS_OK) {
Adding LoRaWANStack class to control MAC and PHY LoRaWANStack class is our controller layer on top of our current MAC and PHY layer. It provides services to an implementation of LoRaWANBase class. It is a singleton class owing to the fact that the mac layer underneath is not a class object. Instead, it uses the MAC via setting mib, mlme, mcps requests and getting responses back from the mac layer using confirmations and indications. In essense this class is a special handle for mac layer underneath which is predominantly reference design based. In future we may refactor the LoRaMac.cpp code to make it object oriented and cleaner. At one end, it binds the application selected radio driver with the PHY layer and at the other end it provides services to upper layers handling the mac via well defined APIs. For proper selection of a PHY layer, user must use Mbed config system. For this purpose an mbed_lib.json is provided which can be overriden by the user defined mbed_app.json. By default the EU868 band is selected as a PHY layer. User must set relevant keys for the selected connection mechanism.
2017-11-27 13:17:18 +00:00
return status;
}
LoRaWANStack is made independent of MAC sublayers - Only internal changes, no API has been broke. - Tested by manually running Green tea tests
2018-03-16 11:12:50 +00:00
[IOTCELL-282] Code cleanup/simplification and rules Baseline is changed to use a single set of data structures that simplifies the code in the LoRaWANStack and Mac layer. We are now following certian rules for naming data structures. - All structures visible outside their domain are prefixed as 'lorawan_' - All mac structures are prefixed as 'loramac_' - All subsystem or module strucutures carry their name in prefix, like 'mcps_' PHY layer still have legacy camel case data structures which will be entertained later while we will be simplifying PHY layer. Test cases are also updated with the new data structure naming conventions. One major difference from the previous baseline is the removal of static buffer from mcps indication. And we do not copy data from stack buffer to rx_msg buffer. This saves at least 512 bytes. It may look like now that if we have received something but the user have not read from the buffer, then the buffer will be overwritten and we will lose previous frame. Yes, we will. But the same will happen even if we would have copied the buffer into rx_msg because then the rx_msg gets overwritten. So we decide to abandon copying the buffer at multiple locations. We inform the user about reception, if the user doesn't read and the data gets overwritten, then so be it.
2018-01-12 14:39:31 +00:00
return LORAWAN_STATUS_CONNECT_IN_PROGRESS;
Adding LoRaWANStack class to control MAC and PHY LoRaWANStack class is our controller layer on top of our current MAC and PHY layer. It provides services to an implementation of LoRaWANBase class. It is a singleton class owing to the fact that the mac layer underneath is not a class object. Instead, it uses the MAC via setting mib, mlme, mcps requests and getting responses back from the mac layer using confirmations and indications. In essense this class is a special handle for mac layer underneath which is predominantly reference design based. In future we may refactor the LoRaMac.cpp code to make it object oriented and cleaner. At one end, it binds the application selected radio driver with the PHY layer and at the other end it provides services to upper layers handling the mac via well defined APIs. For proper selection of a PHY layer, user must use Mbed config system. For this purpose an mbed_lib.json is provided which can be overriden by the user defined mbed_app.json. By default the EU868 band is selected as a PHY layer. User must set relevant keys for the selected connection mechanism.
2017-11-27 13:17:18 +00:00
} else {
[IOTCELL-282] Code cleanup/simplification and rules Baseline is changed to use a single set of data structures that simplifies the code in the LoRaWANStack and Mac layer. We are now following certian rules for naming data structures. - All structures visible outside their domain are prefixed as 'lorawan_' - All mac structures are prefixed as 'loramac_' - All subsystem or module strucutures carry their name in prefix, like 'mcps_' PHY layer still have legacy camel case data structures which will be entertained later while we will be simplifying PHY layer. Test cases are also updated with the new data structure naming conventions. One major difference from the previous baseline is the removal of static buffer from mcps indication. And we do not copy data from stack buffer to rx_msg buffer. This saves at least 512 bytes. It may look like now that if we have received something but the user have not read from the buffer, then the buffer will be overwritten and we will lose previous frame. Yes, we will. But the same will happen even if we would have copied the buffer into rx_msg because then the rx_msg gets overwritten. So we decide to abandon copying the buffer at multiple locations. We inform the user about reception, if the user doesn't read and the data gets overwritten, then so be it.
2018-01-12 14:39:31 +00:00
status = LORAWAN_STATUS_PARAMETER_INVALID;
Adding LoRaWANStack class to control MAC and PHY LoRaWANStack class is our controller layer on top of our current MAC and PHY layer. It provides services to an implementation of LoRaWANBase class. It is a singleton class owing to the fact that the mac layer underneath is not a class object. Instead, it uses the MAC via setting mib, mlme, mcps requests and getting responses back from the mac layer using confirmations and indications. In essense this class is a special handle for mac layer underneath which is predominantly reference design based. In future we may refactor the LoRaMac.cpp code to make it object oriented and cleaner. At one end, it binds the application selected radio driver with the PHY layer and at the other end it provides services to upper layers handling the mac via well defined APIs. For proper selection of a PHY layer, user must use Mbed config system. For this purpose an mbed_lib.json is provided which can be overriden by the user defined mbed_app.json. By default the EU868 band is selected as a PHY layer. User must set relevant keys for the selected connection mechanism.
2017-11-27 13:17:18 +00:00
}
break;
case DEVICE_STATE_JOINED:
tr_debug("Join OK!");
LoRaWANStack is made independent of MAC sublayers - Only internal changes, no API has been broke. - Tested by manually running Green tea tests
2018-03-16 11:12:50 +00:00
Adding LoRaWANStack class to control MAC and PHY LoRaWANStack class is our controller layer on top of our current MAC and PHY layer. It provides services to an implementation of LoRaWANBase class. It is a singleton class owing to the fact that the mac layer underneath is not a class object. Instead, it uses the MAC via setting mib, mlme, mcps requests and getting responses back from the mac layer using confirmations and indications. In essense this class is a special handle for mac layer underneath which is predominantly reference design based. In future we may refactor the LoRaMac.cpp code to make it object oriented and cleaner. At one end, it binds the application selected radio driver with the PHY layer and at the other end it provides services to upper layers handling the mac via well defined APIs. For proper selection of a PHY layer, user must use Mbed config system. For this purpose an mbed_lib.json is provided which can be overriden by the user defined mbed_app.json. By default the EU868 band is selected as a PHY layer. User must set relevant keys for the selected connection mechanism.
2017-11-27 13:17:18 +00:00
_lw_session.active = true;
LoRaWANStack is made independent of MAC sublayers - Only internal changes, no API has been broke. - Tested by manually running Green tea tests
2018-03-16 11:12:50 +00:00
Reworking callback API Application should be able to add some optional callbacks if it needs to. Ofcourse there is a penalty of 8-12 bytes per callback, but there can be certain needs of the application that needs to be met for example setting up a link check request etc. We have introduced a structure that contains callbacks for the application use. - 'events' callback is mandatory, user must assign it. Because this callback brings state changes for the application. We cannot segregate this into individual handlers because of RAM penalty. - Other calbacks (none of them are implemented yet are optional). Example of using the API is provided with doxygen
2017-12-21 11:37:38 +00:00
if (_callbacks.events) {
Improve error handling & robustness This commit also introduces API change for disconnect(). disconnect() will now return LORAWAN_STATUS_DEVICE_OFF for successfull disconnect. * LoRaWANStack::handle_tx() can be called with NULL buffer when length is 0. This commit fixes the case where user has provided NULL buffer and length is > max_possible_size. handle_tx() now always returns LORAWAN_STATUS_PARAMETER_INVALID if given buffer is NULL pointer and length > 0. General error checking is added and some asserts are added for events.
2018-02-09 07:59:15 +00:00
const int ret = _queue->call(_callbacks.events, CONNECTED);
MBED_ASSERT(ret != 0);
(void)ret;
Reworking callback API Application should be able to add some optional callbacks if it needs to. Ofcourse there is a penalty of 8-12 bytes per callback, but there can be certain needs of the application that needs to be met for example setting up a link check request etc. We have introduced a structure that contains callbacks for the application use. - 'events' callback is mandatory, user must assign it. Because this callback brings state changes for the application. We cannot segregate this into individual handlers because of RAM penalty. - Other calbacks (none of them are implemented yet are optional). Example of using the API is provided with doxygen
2017-12-21 11:37:38 +00:00
}
Improve error handling & robustness This commit also introduces API change for disconnect(). disconnect() will now return LORAWAN_STATUS_DEVICE_OFF for successfull disconnect. * LoRaWANStack::handle_tx() can be called with NULL buffer when length is 0. This commit fixes the case where user has provided NULL buffer and length is > max_possible_size. handle_tx() now always returns LORAWAN_STATUS_PARAMETER_INVALID if given buffer is NULL pointer and length > 0. General error checking is added and some asserts are added for events.
2018-02-09 07:59:15 +00:00
status = LORAWAN_STATUS_OK;
Adding LoRaWANStack class to control MAC and PHY LoRaWANStack class is our controller layer on top of our current MAC and PHY layer. It provides services to an implementation of LoRaWANBase class. It is a singleton class owing to the fact that the mac layer underneath is not a class object. Instead, it uses the MAC via setting mib, mlme, mcps requests and getting responses back from the mac layer using confirmations and indications. In essense this class is a special handle for mac layer underneath which is predominantly reference design based. In future we may refactor the LoRaMac.cpp code to make it object oriented and cleaner. At one end, it binds the application selected radio driver with the PHY layer and at the other end it provides services to upper layers handling the mac via well defined APIs. For proper selection of a PHY layer, user must use Mbed config system. For this purpose an mbed_lib.json is provided which can be overriden by the user defined mbed_app.json. By default the EU868 band is selected as a PHY layer. User must set relevant keys for the selected connection mechanism.
2017-11-27 13:17:18 +00:00
break;
case DEVICE_STATE_ABP_CONNECTING:
LoRaWANStack is made independent of MAC sublayers - Only internal changes, no API has been broke. - Tested by manually running Green tea tests
2018-03-16 11:12:50 +00:00
_loramac.join_by_abp(_lw_session.connection.connection_u.abp);
Adding LoRaWANStack class to control MAC and PHY LoRaWANStack class is our controller layer on top of our current MAC and PHY layer. It provides services to an implementation of LoRaWANBase class. It is a singleton class owing to the fact that the mac layer underneath is not a class object. Instead, it uses the MAC via setting mib, mlme, mcps requests and getting responses back from the mac layer using confirmations and indications. In essense this class is a special handle for mac layer underneath which is predominantly reference design based. In future we may refactor the LoRaMac.cpp code to make it object oriented and cleaner. At one end, it binds the application selected radio driver with the PHY layer and at the other end it provides services to upper layers handling the mac via well defined APIs. For proper selection of a PHY layer, user must use Mbed config system. For this purpose an mbed_lib.json is provided which can be overriden by the user defined mbed_app.json. By default the EU868 band is selected as a PHY layer. User must set relevant keys for the selected connection mechanism.
2017-11-27 13:17:18 +00:00
tr_debug("ABP Connection OK!");
LoRaWANStack is made independent of MAC sublayers - Only internal changes, no API has been broke. - Tested by manually running Green tea tests
2018-03-16 11:12:50 +00:00
[IOTCELL-282] Code cleanup/simplification and rules Baseline is changed to use a single set of data structures that simplifies the code in the LoRaWANStack and Mac layer. We are now following certian rules for naming data structures. - All structures visible outside their domain are prefixed as 'lorawan_' - All mac structures are prefixed as 'loramac_' - All subsystem or module strucutures carry their name in prefix, like 'mcps_' PHY layer still have legacy camel case data structures which will be entertained later while we will be simplifying PHY layer. Test cases are also updated with the new data structure naming conventions. One major difference from the previous baseline is the removal of static buffer from mcps indication. And we do not copy data from stack buffer to rx_msg buffer. This saves at least 512 bytes. It may look like now that if we have received something but the user have not read from the buffer, then the buffer will be overwritten and we will lose previous frame. Yes, we will. But the same will happen even if we would have copied the buffer into rx_msg because then the rx_msg gets overwritten. So we decide to abandon copying the buffer at multiple locations. We inform the user about reception, if the user doesn't read and the data gets overwritten, then so be it.
2018-01-12 14:39:31 +00:00
status = LORAWAN_STATUS_OK;
LoRaWANStack is made independent of MAC sublayers - Only internal changes, no API has been broke. - Tested by manually running Green tea tests
2018-03-16 11:12:50 +00:00
Adding LoRaWANStack class to control MAC and PHY LoRaWANStack class is our controller layer on top of our current MAC and PHY layer. It provides services to an implementation of LoRaWANBase class. It is a singleton class owing to the fact that the mac layer underneath is not a class object. Instead, it uses the MAC via setting mib, mlme, mcps requests and getting responses back from the mac layer using confirmations and indications. In essense this class is a special handle for mac layer underneath which is predominantly reference design based. In future we may refactor the LoRaMac.cpp code to make it object oriented and cleaner. At one end, it binds the application selected radio driver with the PHY layer and at the other end it provides services to upper layers handling the mac via well defined APIs. For proper selection of a PHY layer, user must use Mbed config system. For this purpose an mbed_lib.json is provided which can be overriden by the user defined mbed_app.json. By default the EU868 band is selected as a PHY layer. User must set relevant keys for the selected connection mechanism.
2017-11-27 13:17:18 +00:00
_lw_session.active = true;
Reworking callback API Application should be able to add some optional callbacks if it needs to. Ofcourse there is a penalty of 8-12 bytes per callback, but there can be certain needs of the application that needs to be met for example setting up a link check request etc. We have introduced a structure that contains callbacks for the application use. - 'events' callback is mandatory, user must assign it. Because this callback brings state changes for the application. We cannot segregate this into individual handlers because of RAM penalty. - Other calbacks (none of them are implemented yet are optional). Example of using the API is provided with doxygen
2017-12-21 11:37:38 +00:00
if (_callbacks.events) {
Improve error handling & robustness This commit also introduces API change for disconnect(). disconnect() will now return LORAWAN_STATUS_DEVICE_OFF for successfull disconnect. * LoRaWANStack::handle_tx() can be called with NULL buffer when length is 0. This commit fixes the case where user has provided NULL buffer and length is > max_possible_size. handle_tx() now always returns LORAWAN_STATUS_PARAMETER_INVALID if given buffer is NULL pointer and length > 0. General error checking is added and some asserts are added for events.
2018-02-09 07:59:15 +00:00
const int ret = _queue->call(_callbacks.events, CONNECTED);
MBED_ASSERT(ret != 0);
(void)ret;
Reworking callback API Application should be able to add some optional callbacks if it needs to. Ofcourse there is a penalty of 8-12 bytes per callback, but there can be certain needs of the application that needs to be met for example setting up a link check request etc. We have introduced a structure that contains callbacks for the application use. - 'events' callback is mandatory, user must assign it. Because this callback brings state changes for the application. We cannot segregate this into individual handlers because of RAM penalty. - Other calbacks (none of them are implemented yet are optional). Example of using the API is provided with doxygen
2017-12-21 11:37:38 +00:00
}
Adding LoRaWANStack class to control MAC and PHY LoRaWANStack class is our controller layer on top of our current MAC and PHY layer. It provides services to an implementation of LoRaWANBase class. It is a singleton class owing to the fact that the mac layer underneath is not a class object. Instead, it uses the MAC via setting mib, mlme, mcps requests and getting responses back from the mac layer using confirmations and indications. In essense this class is a special handle for mac layer underneath which is predominantly reference design based. In future we may refactor the LoRaMac.cpp code to make it object oriented and cleaner. At one end, it binds the application selected radio driver with the PHY layer and at the other end it provides services to upper layers handling the mac via well defined APIs. For proper selection of a PHY layer, user must use Mbed config system. For this purpose an mbed_lib.json is provided which can be overriden by the user defined mbed_app.json. By default the EU868 band is selected as a PHY layer. User must set relevant keys for the selected connection mechanism.
2017-11-27 13:17:18 +00:00
break;
case DEVICE_STATE_SEND:
LoRa: LoRaPHY dependency removed from LoRaMacStack - 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
2018-03-15 08:43:31 +00:00
if (_loramac.tx_ongoing()) {
[IOTCELL-282] Code cleanup/simplification and rules Baseline is changed to use a single set of data structures that simplifies the code in the LoRaWANStack and Mac layer. We are now following certian rules for naming data structures. - All structures visible outside their domain are prefixed as 'lorawan_' - All mac structures are prefixed as 'loramac_' - All subsystem or module strucutures carry their name in prefix, like 'mcps_' PHY layer still have legacy camel case data structures which will be entertained later while we will be simplifying PHY layer. Test cases are also updated with the new data structure naming conventions. One major difference from the previous baseline is the removal of static buffer from mcps indication. And we do not copy data from stack buffer to rx_msg buffer. This saves at least 512 bytes. It may look like now that if we have received something but the user have not read from the buffer, then the buffer will be overwritten and we will lose previous frame. Yes, we will. But the same will happen even if we would have copied the buffer into rx_msg because then the rx_msg gets overwritten. So we decide to abandon copying the buffer at multiple locations. We inform the user about reception, if the user doesn't read and the data gets overwritten, then so be it.
2018-01-12 14:39:31 +00:00
status = LORAWAN_STATUS_OK;
Adding LoRaWANStack class to control MAC and PHY LoRaWANStack class is our controller layer on top of our current MAC and PHY layer. It provides services to an implementation of LoRaWANBase class. It is a singleton class owing to the fact that the mac layer underneath is not a class object. Instead, it uses the MAC via setting mib, mlme, mcps requests and getting responses back from the mac layer using confirmations and indications. In essense this class is a special handle for mac layer underneath which is predominantly reference design based. In future we may refactor the LoRaMac.cpp code to make it object oriented and cleaner. At one end, it binds the application selected radio driver with the PHY layer and at the other end it provides services to upper layers handling the mac via well defined APIs. For proper selection of a PHY layer, user must use Mbed config system. For this purpose an mbed_lib.json is provided which can be overriden by the user defined mbed_app.json. By default the EU868 band is selected as a PHY layer. User must set relevant keys for the selected connection mechanism.
2017-11-27 13:17:18 +00:00
} else {
LoRa: LoRaPHY dependency removed from LoRaMacStack - 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
2018-03-15 08:43:31 +00:00
_loramac.set_tx_ongoing(true);
status = _loramac.send_ongoing_tx();
Adding LoRaWANStack class to control MAC and PHY LoRaWANStack class is our controller layer on top of our current MAC and PHY layer. It provides services to an implementation of LoRaWANBase class. It is a singleton class owing to the fact that the mac layer underneath is not a class object. Instead, it uses the MAC via setting mib, mlme, mcps requests and getting responses back from the mac layer using confirmations and indications. In essense this class is a special handle for mac layer underneath which is predominantly reference design based. In future we may refactor the LoRaMac.cpp code to make it object oriented and cleaner. At one end, it binds the application selected radio driver with the PHY layer and at the other end it provides services to upper layers handling the mac via well defined APIs. For proper selection of a PHY layer, user must use Mbed config system. For this purpose an mbed_lib.json is provided which can be overriden by the user defined mbed_app.json. By default the EU868 band is selected as a PHY layer. User must set relevant keys for the selected connection mechanism.
2017-11-27 13:17:18 +00:00
switch (status) {
[IOTCELL-282] Code cleanup/simplification and rules Baseline is changed to use a single set of data structures that simplifies the code in the LoRaWANStack and Mac layer. We are now following certian rules for naming data structures. - All structures visible outside their domain are prefixed as 'lorawan_' - All mac structures are prefixed as 'loramac_' - All subsystem or module strucutures carry their name in prefix, like 'mcps_' PHY layer still have legacy camel case data structures which will be entertained later while we will be simplifying PHY layer. Test cases are also updated with the new data structure naming conventions. One major difference from the previous baseline is the removal of static buffer from mcps indication. And we do not copy data from stack buffer to rx_msg buffer. This saves at least 512 bytes. It may look like now that if we have received something but the user have not read from the buffer, then the buffer will be overwritten and we will lose previous frame. Yes, we will. But the same will happen even if we would have copied the buffer into rx_msg because then the rx_msg gets overwritten. So we decide to abandon copying the buffer at multiple locations. We inform the user about reception, if the user doesn't read and the data gets overwritten, then so be it.
2018-01-12 14:39:31 +00:00
case LORAWAN_STATUS_OK:
Adding LoRaWANStack class to control MAC and PHY LoRaWANStack class is our controller layer on top of our current MAC and PHY layer. It provides services to an implementation of LoRaWANBase class. It is a singleton class owing to the fact that the mac layer underneath is not a class object. Instead, it uses the MAC via setting mib, mlme, mcps requests and getting responses back from the mac layer using confirmations and indications. In essense this class is a special handle for mac layer underneath which is predominantly reference design based. In future we may refactor the LoRaMac.cpp code to make it object oriented and cleaner. At one end, it binds the application selected radio driver with the PHY layer and at the other end it provides services to upper layers handling the mac via well defined APIs. For proper selection of a PHY layer, user must use Mbed config system. For this purpose an mbed_lib.json is provided which can be overriden by the user defined mbed_app.json. By default the EU868 band is selected as a PHY layer. User must set relevant keys for the selected connection mechanism.
2017-11-27 13:17:18 +00:00
tr_debug("Frame scheduled to TX..");
break;
[IOTCELL-282] Code cleanup/simplification and rules Baseline is changed to use a single set of data structures that simplifies the code in the LoRaWANStack and Mac layer. We are now following certian rules for naming data structures. - All structures visible outside their domain are prefixed as 'lorawan_' - All mac structures are prefixed as 'loramac_' - All subsystem or module strucutures carry their name in prefix, like 'mcps_' PHY layer still have legacy camel case data structures which will be entertained later while we will be simplifying PHY layer. Test cases are also updated with the new data structure naming conventions. One major difference from the previous baseline is the removal of static buffer from mcps indication. And we do not copy data from stack buffer to rx_msg buffer. This saves at least 512 bytes. It may look like now that if we have received something but the user have not read from the buffer, then the buffer will be overwritten and we will lose previous frame. Yes, we will. But the same will happen even if we would have copied the buffer into rx_msg because then the rx_msg gets overwritten. So we decide to abandon copying the buffer at multiple locations. We inform the user about reception, if the user doesn't read and the data gets overwritten, then so be it.
2018-01-12 14:39:31 +00:00
case LORAWAN_STATUS_CRYPTO_FAIL:
Adding LoRaWANStack class to control MAC and PHY LoRaWANStack class is our controller layer on top of our current MAC and PHY layer. It provides services to an implementation of LoRaWANBase class. It is a singleton class owing to the fact that the mac layer underneath is not a class object. Instead, it uses the MAC via setting mib, mlme, mcps requests and getting responses back from the mac layer using confirmations and indications. In essense this class is a special handle for mac layer underneath which is predominantly reference design based. In future we may refactor the LoRaMac.cpp code to make it object oriented and cleaner. At one end, it binds the application selected radio driver with the PHY layer and at the other end it provides services to upper layers handling the mac via well defined APIs. For proper selection of a PHY layer, user must use Mbed config system. For this purpose an mbed_lib.json is provided which can be overriden by the user defined mbed_app.json. By default the EU868 band is selected as a PHY layer. User must set relevant keys for the selected connection mechanism.
2017-11-27 13:17:18 +00:00
tr_error("Crypto failed. Clearing TX buffers");
Reworking callback API Application should be able to add some optional callbacks if it needs to. Ofcourse there is a penalty of 8-12 bytes per callback, but there can be certain needs of the application that needs to be met for example setting up a link check request etc. We have introduced a structure that contains callbacks for the application use. - 'events' callback is mandatory, user must assign it. Because this callback brings state changes for the application. We cannot segregate this into individual handlers because of RAM penalty. - Other calbacks (none of them are implemented yet are optional). Example of using the API is provided with doxygen
2017-12-21 11:37:38 +00:00
if (_callbacks.events) {
Improve error handling & robustness This commit also introduces API change for disconnect(). disconnect() will now return LORAWAN_STATUS_DEVICE_OFF for successfull disconnect. * LoRaWANStack::handle_tx() can be called with NULL buffer when length is 0. This commit fixes the case where user has provided NULL buffer and length is > max_possible_size. handle_tx() now always returns LORAWAN_STATUS_PARAMETER_INVALID if given buffer is NULL pointer and length > 0. General error checking is added and some asserts are added for events.
2018-02-09 07:59:15 +00:00
const int ret = _queue->call(_callbacks.events, TX_CRYPTO_ERROR);
MBED_ASSERT(ret != 0);
(void)ret;
Reworking callback API Application should be able to add some optional callbacks if it needs to. Ofcourse there is a penalty of 8-12 bytes per callback, but there can be certain needs of the application that needs to be met for example setting up a link check request etc. We have introduced a structure that contains callbacks for the application use. - 'events' callback is mandatory, user must assign it. Because this callback brings state changes for the application. We cannot segregate this into individual handlers because of RAM penalty. - Other calbacks (none of them are implemented yet are optional). Example of using the API is provided with doxygen
2017-12-21 11:37:38 +00:00
}
Adding LoRaWANStack class to control MAC and PHY LoRaWANStack class is our controller layer on top of our current MAC and PHY layer. It provides services to an implementation of LoRaWANBase class. It is a singleton class owing to the fact that the mac layer underneath is not a class object. Instead, it uses the MAC via setting mib, mlme, mcps requests and getting responses back from the mac layer using confirmations and indications. In essense this class is a special handle for mac layer underneath which is predominantly reference design based. In future we may refactor the LoRaMac.cpp code to make it object oriented and cleaner. At one end, it binds the application selected radio driver with the PHY layer and at the other end it provides services to upper layers handling the mac via well defined APIs. For proper selection of a PHY layer, user must use Mbed config system. For this purpose an mbed_lib.json is provided which can be overriden by the user defined mbed_app.json. By default the EU868 band is selected as a PHY layer. User must set relevant keys for the selected connection mechanism.
2017-11-27 13:17:18 +00:00
break;
default:
tr_error("Failure to schedule TX!");
Reworking callback API Application should be able to add some optional callbacks if it needs to. Ofcourse there is a penalty of 8-12 bytes per callback, but there can be certain needs of the application that needs to be met for example setting up a link check request etc. We have introduced a structure that contains callbacks for the application use. - 'events' callback is mandatory, user must assign it. Because this callback brings state changes for the application. We cannot segregate this into individual handlers because of RAM penalty. - Other calbacks (none of them are implemented yet are optional). Example of using the API is provided with doxygen
2017-12-21 11:37:38 +00:00
if (_callbacks.events) {
Improve error handling & robustness This commit also introduces API change for disconnect(). disconnect() will now return LORAWAN_STATUS_DEVICE_OFF for successfull disconnect. * LoRaWANStack::handle_tx() can be called with NULL buffer when length is 0. This commit fixes the case where user has provided NULL buffer and length is > max_possible_size. handle_tx() now always returns LORAWAN_STATUS_PARAMETER_INVALID if given buffer is NULL pointer and length > 0. General error checking is added and some asserts are added for events.
2018-02-09 07:59:15 +00:00
const int ret = _queue->call(_callbacks.events, TX_SCHEDULING_ERROR);
MBED_ASSERT(ret != 0);
(void)ret;
Reworking callback API Application should be able to add some optional callbacks if it needs to. Ofcourse there is a penalty of 8-12 bytes per callback, but there can be certain needs of the application that needs to be met for example setting up a link check request etc. We have introduced a structure that contains callbacks for the application use. - 'events' callback is mandatory, user must assign it. Because this callback brings state changes for the application. We cannot segregate this into individual handlers because of RAM penalty. - Other calbacks (none of them are implemented yet are optional). Example of using the API is provided with doxygen
2017-12-21 11:37:38 +00:00
}
Adding LoRaWANStack class to control MAC and PHY LoRaWANStack class is our controller layer on top of our current MAC and PHY layer. It provides services to an implementation of LoRaWANBase class. It is a singleton class owing to the fact that the mac layer underneath is not a class object. Instead, it uses the MAC via setting mib, mlme, mcps requests and getting responses back from the mac layer using confirmations and indications. In essense this class is a special handle for mac layer underneath which is predominantly reference design based. In future we may refactor the LoRaMac.cpp code to make it object oriented and cleaner. At one end, it binds the application selected radio driver with the PHY layer and at the other end it provides services to upper layers handling the mac via well defined APIs. For proper selection of a PHY layer, user must use Mbed config system. For this purpose an mbed_lib.json is provided which can be overriden by the user defined mbed_app.json. By default the EU868 band is selected as a PHY layer. User must set relevant keys for the selected connection mechanism.
2017-11-27 13:17:18 +00:00
break;
}
}
LoRaWANStack is made independent of MAC sublayers - Only internal changes, no API has been broke. - Tested by manually running Green tea tests
2018-03-16 11:12:50 +00:00
LoRa: LoRaWANInterface refactored. - Only internal changes, no functionality changes - Some minor improvements to LoRaWanStack
2018-03-12 11:30:00 +00:00
_device_current_state = DEVICE_STATE_IDLE;
Adding LoRaWANStack class to control MAC and PHY LoRaWANStack class is our controller layer on top of our current MAC and PHY layer. It provides services to an implementation of LoRaWANBase class. It is a singleton class owing to the fact that the mac layer underneath is not a class object. Instead, it uses the MAC via setting mib, mlme, mcps requests and getting responses back from the mac layer using confirmations and indications. In essense this class is a special handle for mac layer underneath which is predominantly reference design based. In future we may refactor the LoRaMac.cpp code to make it object oriented and cleaner. At one end, it binds the application selected radio driver with the PHY layer and at the other end it provides services to upper layers handling the mac via well defined APIs. For proper selection of a PHY layer, user must use Mbed config system. For this purpose an mbed_lib.json is provided which can be overriden by the user defined mbed_app.json. By default the EU868 band is selected as a PHY layer. User must set relevant keys for the selected connection mechanism.
2017-11-27 13:17:18 +00:00
break;
case DEVICE_STATE_IDLE:
[IOTCELL-282] Code cleanup/simplification and rules Baseline is changed to use a single set of data structures that simplifies the code in the LoRaWANStack and Mac layer. We are now following certian rules for naming data structures. - All structures visible outside their domain are prefixed as 'lorawan_' - All mac structures are prefixed as 'loramac_' - All subsystem or module strucutures carry their name in prefix, like 'mcps_' PHY layer still have legacy camel case data structures which will be entertained later while we will be simplifying PHY layer. Test cases are also updated with the new data structure naming conventions. One major difference from the previous baseline is the removal of static buffer from mcps indication. And we do not copy data from stack buffer to rx_msg buffer. This saves at least 512 bytes. It may look like now that if we have received something but the user have not read from the buffer, then the buffer will be overwritten and we will lose previous frame. Yes, we will. But the same will happen even if we would have copied the buffer into rx_msg because then the rx_msg gets overwritten. So we decide to abandon copying the buffer at multiple locations. We inform the user about reception, if the user doesn't read and the data gets overwritten, then so be it.
2018-01-12 14:39:31 +00:00
status = LORAWAN_STATUS_IDLE;
Adding LoRaWANStack class to control MAC and PHY LoRaWANStack class is our controller layer on top of our current MAC and PHY layer. It provides services to an implementation of LoRaWANBase class. It is a singleton class owing to the fact that the mac layer underneath is not a class object. Instead, it uses the MAC via setting mib, mlme, mcps requests and getting responses back from the mac layer using confirmations and indications. In essense this class is a special handle for mac layer underneath which is predominantly reference design based. In future we may refactor the LoRaMac.cpp code to make it object oriented and cleaner. At one end, it binds the application selected radio driver with the PHY layer and at the other end it provides services to upper layers handling the mac via well defined APIs. For proper selection of a PHY layer, user must use Mbed config system. For this purpose an mbed_lib.json is provided which can be overriden by the user defined mbed_app.json. By default the EU868 band is selected as a PHY layer. User must set relevant keys for the selected connection mechanism.
2017-11-27 13:17:18 +00:00
break;
Move all compliance test code inside compilation flag All compliance test related codes are now inside LORAWAN_COMPLIANCE_TEST build flag. This will reduce memory usage in when compliance test codes are not needed.
2018-01-05 10:13:48 +00:00
#if defined(LORAWAN_COMPLIANCE_TEST)
Adding LoRaWANStack class to control MAC and PHY LoRaWANStack class is our controller layer on top of our current MAC and PHY layer. It provides services to an implementation of LoRaWANBase class. It is a singleton class owing to the fact that the mac layer underneath is not a class object. Instead, it uses the MAC via setting mib, mlme, mcps requests and getting responses back from the mac layer using confirmations and indications. In essense this class is a special handle for mac layer underneath which is predominantly reference design based. In future we may refactor the LoRaMac.cpp code to make it object oriented and cleaner. At one end, it binds the application selected radio driver with the PHY layer and at the other end it provides services to upper layers handling the mac via well defined APIs. For proper selection of a PHY layer, user must use Mbed config system. For this purpose an mbed_lib.json is provided which can be overriden by the user defined mbed_app.json. By default the EU868 band is selected as a PHY layer. User must set relevant keys for the selected connection mechanism.
2017-11-27 13:17:18 +00:00
case DEVICE_STATE_COMPLIANCE_TEST:
tr_debug("Device is in compliance test mode.");
LoRaWANStack is made independent of MAC sublayers - Only internal changes, no API has been broke. - Tested by manually running Green tea tests
2018-03-16 11:12:50 +00:00
_loramac.LoRaMacSetTxTimer(5000); //ms
Adding LoRaWANStack class to control MAC and PHY LoRaWANStack class is our controller layer on top of our current MAC and PHY layer. It provides services to an implementation of LoRaWANBase class. It is a singleton class owing to the fact that the mac layer underneath is not a class object. Instead, it uses the MAC via setting mib, mlme, mcps requests and getting responses back from the mac layer using confirmations and indications. In essense this class is a special handle for mac layer underneath which is predominantly reference design based. In future we may refactor the LoRaMac.cpp code to make it object oriented and cleaner. At one end, it binds the application selected radio driver with the PHY layer and at the other end it provides services to upper layers handling the mac via well defined APIs. For proper selection of a PHY layer, user must use Mbed config system. For this purpose an mbed_lib.json is provided which can be overriden by the user defined mbed_app.json. By default the EU868 band is selected as a PHY layer. User must set relevant keys for the selected connection mechanism.
2017-11-27 13:17:18 +00:00
if (_compliance_test.running == true) {
send_compliance_test_frame_to_mac();
}
[IOTCELL-282] Code cleanup/simplification and rules Baseline is changed to use a single set of data structures that simplifies the code in the LoRaWANStack and Mac layer. We are now following certian rules for naming data structures. - All structures visible outside their domain are prefixed as 'lorawan_' - All mac structures are prefixed as 'loramac_' - All subsystem or module strucutures carry their name in prefix, like 'mcps_' PHY layer still have legacy camel case data structures which will be entertained later while we will be simplifying PHY layer. Test cases are also updated with the new data structure naming conventions. One major difference from the previous baseline is the removal of static buffer from mcps indication. And we do not copy data from stack buffer to rx_msg buffer. This saves at least 512 bytes. It may look like now that if we have received something but the user have not read from the buffer, then the buffer will be overwritten and we will lose previous frame. Yes, we will. But the same will happen even if we would have copied the buffer into rx_msg because then the rx_msg gets overwritten. So we decide to abandon copying the buffer at multiple locations. We inform the user about reception, if the user doesn't read and the data gets overwritten, then so be it.
2018-01-12 14:39:31 +00:00
status = LORAWAN_STATUS_COMPLIANCE_TEST_ON;
Adding LoRaWANStack class to control MAC and PHY LoRaWANStack class is our controller layer on top of our current MAC and PHY layer. It provides services to an implementation of LoRaWANBase class. It is a singleton class owing to the fact that the mac layer underneath is not a class object. Instead, it uses the MAC via setting mib, mlme, mcps requests and getting responses back from the mac layer using confirmations and indications. In essense this class is a special handle for mac layer underneath which is predominantly reference design based. In future we may refactor the LoRaMac.cpp code to make it object oriented and cleaner. At one end, it binds the application selected radio driver with the PHY layer and at the other end it provides services to upper layers handling the mac via well defined APIs. For proper selection of a PHY layer, user must use Mbed config system. For this purpose an mbed_lib.json is provided which can be overriden by the user defined mbed_app.json. By default the EU868 band is selected as a PHY layer. User must set relevant keys for the selected connection mechanism.
2017-11-27 13:17:18 +00:00
break;
Move all compliance test code inside compilation flag All compliance test related codes are now inside LORAWAN_COMPLIANCE_TEST build flag. This will reduce memory usage in when compliance test codes are not needed.
2018-01-05 10:13:48 +00:00
#endif
Adding LoRaWANStack class to control MAC and PHY LoRaWANStack class is our controller layer on top of our current MAC and PHY layer. It provides services to an implementation of LoRaWANBase class. It is a singleton class owing to the fact that the mac layer underneath is not a class object. Instead, it uses the MAC via setting mib, mlme, mcps requests and getting responses back from the mac layer using confirmations and indications. In essense this class is a special handle for mac layer underneath which is predominantly reference design based. In future we may refactor the LoRaMac.cpp code to make it object oriented and cleaner. At one end, it binds the application selected radio driver with the PHY layer and at the other end it provides services to upper layers handling the mac via well defined APIs. For proper selection of a PHY layer, user must use Mbed config system. For this purpose an mbed_lib.json is provided which can be overriden by the user defined mbed_app.json. By default the EU868 band is selected as a PHY layer. User must set relevant keys for the selected connection mechanism.
2017-11-27 13:17:18 +00:00
default:
[IOTCELL-282] Code cleanup/simplification and rules Baseline is changed to use a single set of data structures that simplifies the code in the LoRaWANStack and Mac layer. We are now following certian rules for naming data structures. - All structures visible outside their domain are prefixed as 'lorawan_' - All mac structures are prefixed as 'loramac_' - All subsystem or module strucutures carry their name in prefix, like 'mcps_' PHY layer still have legacy camel case data structures which will be entertained later while we will be simplifying PHY layer. Test cases are also updated with the new data structure naming conventions. One major difference from the previous baseline is the removal of static buffer from mcps indication. And we do not copy data from stack buffer to rx_msg buffer. This saves at least 512 bytes. It may look like now that if we have received something but the user have not read from the buffer, then the buffer will be overwritten and we will lose previous frame. Yes, we will. But the same will happen even if we would have copied the buffer into rx_msg because then the rx_msg gets overwritten. So we decide to abandon copying the buffer at multiple locations. We inform the user about reception, if the user doesn't read and the data gets overwritten, then so be it.
2018-01-12 14:39:31 +00:00
status = LORAWAN_STATUS_SERVICE_UNKNOWN;
Adding LoRaWANStack class to control MAC and PHY LoRaWANStack class is our controller layer on top of our current MAC and PHY layer. It provides services to an implementation of LoRaWANBase class. It is a singleton class owing to the fact that the mac layer underneath is not a class object. Instead, it uses the MAC via setting mib, mlme, mcps requests and getting responses back from the mac layer using confirmations and indications. In essense this class is a special handle for mac layer underneath which is predominantly reference design based. In future we may refactor the LoRaMac.cpp code to make it object oriented and cleaner. At one end, it binds the application selected radio driver with the PHY layer and at the other end it provides services to upper layers handling the mac via well defined APIs. For proper selection of a PHY layer, user must use Mbed config system. For this purpose an mbed_lib.json is provided which can be overriden by the user defined mbed_app.json. By default the EU868 band is selected as a PHY layer. User must set relevant keys for the selected connection mechanism.
2017-11-27 13:17:18 +00:00
break;
}
return status;
}
LoRa: LoRaMacMcps refactored to remove dependency to LoRaMac. - 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
2018-03-05 13:16:08 +00:00
#if defined(LORAWAN_COMPLIANCE_TEST)
LoRa: LoRaPHY dependency removed from LoRaMacStack - 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
2018-03-15 08:43:31 +00:00
lorawan_status_t LoRaWANStack::send_compliance_test_frame_to_mac()
LoRa: LoRaMacMcps refactored to remove dependency to LoRaMac. - 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
2018-03-05 13:16:08 +00:00
{
LoRa: LoRaPHY dependency removed from LoRaMacStack - 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
2018-03-15 08:43:31 +00:00
loramac_mcps_req_t mcps_req;
// prepare_special_tx_frame(_compliance_test.app_port);
//TODO: What if the port is not 224 ???
if (_compliance_test.app_port == 224) {
LoRa: LoRaMacMcps refactored to remove dependency to LoRaMac. - 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
2018-03-05 13:16:08 +00:00
// Clear any normal message stuff before compliance test.
LoRa: LoRaPHY dependency removed from LoRaMacStack - 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
2018-03-15 08:43:31 +00:00
memset(&mcps_req, 0, sizeof(mcps_req));
LoRa: LoRaMacMcps refactored to remove dependency to LoRaMac. - 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
2018-03-05 13:16:08 +00:00
if (_compliance_test.link_check == true) {
_compliance_test.link_check = false;
_compliance_test.state = 1;
LoRa: LoRaPHY dependency removed from LoRaMacStack - 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
2018-03-15 08:43:31 +00:00
mcps_req.f_buffer_size = 3;
mcps_req.f_buffer[0] = 5;
mcps_req.f_buffer[1] = _compliance_test.demod_margin;
mcps_req.f_buffer[2] = _compliance_test.nb_gateways;
LoRa: LoRaMacMcps refactored to remove dependency to LoRaMac. - 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
2018-03-05 13:16:08 +00:00
} else {
switch (_compliance_test.state) {
case 4:
_compliance_test.state = 1;
LoRa: LoRaPHY dependency removed from LoRaMacStack - 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
2018-03-15 08:43:31 +00:00
mcps_req.f_buffer_size = _compliance_test.app_data_size;
LoRa: LoRaMacMcps refactored to remove dependency to LoRaMac. - 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
2018-03-05 13:16:08 +00:00
LoRa: LoRaPHY dependency removed from LoRaMacStack - 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
2018-03-15 08:43:31 +00:00
mcps_req.f_buffer[0] = _compliance_test.app_data_buffer[0];
LoRa: LoRaMacMcps refactored to remove dependency to LoRaMac. - 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
2018-03-05 13:16:08 +00:00
for(uint8_t i = 1; i < MIN(_compliance_test.app_data_size, MBED_CONF_LORA_TX_MAX_SIZE); ++i) {
LoRa: LoRaPHY dependency removed from LoRaMacStack - 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
2018-03-15 08:43:31 +00:00
mcps_req.f_buffer[i] = _compliance_test.app_data_buffer[i];
LoRa: LoRaMacMcps refactored to remove dependency to LoRaMac. - 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
2018-03-05 13:16:08 +00:00
}
break;
case 1:
LoRa: LoRaPHY dependency removed from LoRaMacStack - 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
2018-03-15 08:43:31 +00:00
mcps_req.f_buffer_size = 2;
mcps_req.f_buffer[0] = _compliance_test.downlink_counter >> 8;
mcps_req.f_buffer[1] = _compliance_test.downlink_counter;
LoRa: LoRaMacMcps refactored to remove dependency to LoRaMac. - 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
2018-03-05 13:16:08 +00:00
break;
}
}
}
LoRa: LoRaPHY dependency removed from LoRaMacStack - 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
2018-03-15 08:43:31 +00:00
//TODO: If port is not 224, this might not work!
//Is there a test case where same _tx_msg's buffer would be used, when port is not 224???
LoRa: LoRaMacMcps refactored to remove dependency to LoRaMac. - 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
2018-03-05 13:16:08 +00:00
if (!_compliance_test.is_tx_confirmed) {
mcps_req.type = MCPS_UNCONFIRMED;
LoRa: LoRaPHY dependency removed from LoRaMacStack - 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
2018-03-15 08:43:31 +00:00
// mcps_req.f_buffer = _tx_msg.f_buffer;
// mcps_req.f_buffer_size = _tx_msg.f_buffer_size;
LoRa: LoRaMacMcps refactored to remove dependency to LoRaMac. - 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
2018-03-05 13:16:08 +00:00
mcps_req.fport = _compliance_test.app_port;
mcps_req.nb_trials = 1;
LoRa: LoRaPHY dependency removed from LoRaMacStack - 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
2018-03-15 08:43:31 +00:00
mcps_req.data_rate = _loramac.get_default_tx_datarate();
LoRa: LoRaMacMcps refactored to remove dependency to LoRaMac. - 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
2018-03-05 13:16:08 +00:00
tr_info("Transmit unconfirmed compliance test frame %d bytes.", mcps_req.f_buffer_size);
for (uint8_t i = 0; i < mcps_req.f_buffer_size; ++i) {
tr_info("Byte %d, data is 0x%x", i+1, ((uint8_t*)mcps_req.f_buffer)[i]);
}
} else if (_compliance_test.is_tx_confirmed) {
mcps_req.type = MCPS_CONFIRMED;
LoRa: LoRaPHY dependency removed from LoRaMacStack - 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
2018-03-15 08:43:31 +00:00
// mcps_req.f_buffer = _tx_msg.f_buffer;
// mcps_req.f_buffer_size = _tx_msg.f_buffer_size;
LoRa: LoRaMacMcps refactored to remove dependency to LoRaMac. - 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
2018-03-05 13:16:08 +00:00
mcps_req.fport = _compliance_test.app_port;
mcps_req.nb_trials = _num_retry;
LoRa: LoRaPHY dependency removed from LoRaMacStack - 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
2018-03-15 08:43:31 +00:00
mcps_req.data_rate = _loramac.get_default_tx_datarate();
LoRa: LoRaMacMcps refactored to remove dependency to LoRaMac. - 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
2018-03-05 13:16:08 +00:00
tr_info("Transmit confirmed compliance test frame %d bytes.", mcps_req.f_buffer_size);
for (uint8_t i = 0; i < mcps_req.f_buffer_size; ++i) {
tr_info("Byte %d, data is 0x%x", i+1, ((uint8_t*)mcps_req.f_buffer)[i]);
}
} else {
return LORAWAN_STATUS_SERVICE_UNKNOWN;
}
return mcps_request_handler(&mcps_req);
}
LoRa: LoRaPHY dependency removed from LoRaMacStack - 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
2018-03-15 08:43:31 +00:00
LoRaWANStack is made independent of MAC sublayers - Only internal changes, no API has been broke. - Tested by manually running Green tea tests
2018-03-16 11:12:50 +00:00
lorawan_status_t LoRaWANStack::mcps_request_handler(loramac_mcps_req_t *mcps_request)
{
if (mcps_request == NULL) {
return LORAWAN_STATUS_PARAMETER_INVALID;
}
return _loramac.mcps_request(mcps_request);
}
LoRa: LoRaPHY dependency removed from LoRaMacStack - 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
2018-03-15 08:43:31 +00:00
void LoRaWANStack::compliance_test_handler(loramac_mcps_indication_t *mcps_indication)
{
if (_compliance_test.running == false) {
// Check compliance test enable command (i)
if ((mcps_indication->buffer_size == 4) &&
(mcps_indication->buffer[0] == 0x01) &&
(mcps_indication->buffer[1] == 0x01) &&
(mcps_indication->buffer[2] == 0x01) &&
(mcps_indication->buffer[3] == 0x01)) {
_compliance_test.is_tx_confirmed = false;
_compliance_test.app_port = 224;
_compliance_test.app_data_size = 2;
_compliance_test.downlink_counter = 0;
_compliance_test.link_check = false;
_compliance_test.demod_margin = 0;
_compliance_test.nb_gateways = 0;
_compliance_test.running = true;
_compliance_test.state = 1;
LoRaWANStack is made independent of MAC sublayers - Only internal changes, no API has been broke. - Tested by manually running Green tea tests
2018-03-16 11:12:50 +00:00
_loramac.enable_adaptive_datarate(true);
LoRa: LoRaPHY dependency removed from LoRaMacStack - 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
2018-03-15 08:43:31 +00:00
#if MBED_CONF_LORA_PHY == 0
_loramac.LoRaMacTestSetDutyCycleOn(false);
#endif
//5000ms
_loramac.LoRaMacSetTxTimer(5000);
//TODO: Should we call lora_state_machine here instead of just setting the state?
_device_current_state = DEVICE_STATE_COMPLIANCE_TEST;
// lora_state_machine(DEVICE_STATE_COMPLIANCE_TEST);
tr_debug("Compliance test activated.");
}
} else {
_compliance_test.state = mcps_indication->buffer[0];
switch (_compliance_test.state) {
case 0: // Check compliance test disable command (ii)
_compliance_test.is_tx_confirmed = true;
_compliance_test.app_port = MBED_CONF_LORA_APP_PORT;
_compliance_test.app_data_size = LORAWAN_COMPLIANCE_TEST_DATA_SIZE;
_compliance_test.downlink_counter = 0;
_compliance_test.running = false;
LoRaWANStack is made independent of MAC sublayers - Only internal changes, no API has been broke. - Tested by manually running Green tea tests
2018-03-16 11:12:50 +00:00
_loramac.enable_adaptive_datarate(MBED_CONF_LORA_ADR_ON);
LoRa: LoRaPHY dependency removed from LoRaMacStack - 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
2018-03-15 08:43:31 +00:00
#if MBED_CONF_LORA_PHY == 0
_loramac.LoRaMacTestSetDutyCycleOn(MBED_CONF_LORA_DUTY_CYCLE_ON);
#endif
// Go to idle state after compliance test mode.
tr_debug("Compliance test disabled.");
_loramac.LoRaMacStopTxTimer();
// Clear any compliance test message stuff before going back to normal operation.
_loramac.reset_ongoing_tx();
lora_state_machine(DEVICE_STATE_IDLE);
break;
case 1: // (iii, iv)
_compliance_test.app_data_size = 2;
break;
case 2: // Enable confirmed messages (v)
_compliance_test.is_tx_confirmed = true;
_compliance_test.state = 1;
break;
case 3: // Disable confirmed messages (vi)
_compliance_test.is_tx_confirmed = false;
_compliance_test.state = 1;
break;
case 4: // (vii)
_compliance_test.app_data_size = mcps_indication->buffer_size;
_compliance_test.app_data_buffer[0] = 4;
for(uint8_t i = 1; i < MIN(_compliance_test.app_data_size, LORAMAC_PHY_MAXPAYLOAD); ++i) {
_compliance_test.app_data_buffer[i] = mcps_indication->buffer[i] + 1;
}
send_compliance_test_frame_to_mac();
break;
case 5: // (viii)
LoRaWANStack is made independent of MAC sublayers - Only internal changes, no API has been broke. - Tested by manually running Green tea tests
2018-03-16 11:12:50 +00:00
_loramac.setup_link_check_request();
LoRa: LoRaPHY dependency removed from LoRaMacStack - 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
2018-03-15 08:43:31 +00:00
break;
case 6: // (ix)
LoRaWANStack is made independent of MAC sublayers - Only internal changes, no API has been broke. - Tested by manually running Green tea tests
2018-03-16 11:12:50 +00:00
loramac_mlme_req_t mlme_req;
LoRa: LoRaPHY dependency removed from LoRaMacStack - 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
2018-03-15 08:43:31 +00:00
// Disable TestMode and revert back to normal operation
_compliance_test.is_tx_confirmed = true;
_compliance_test.app_port = MBED_CONF_LORA_APP_PORT;
_compliance_test.app_data_size = LORAWAN_COMPLIANCE_TEST_DATA_SIZE;
_compliance_test.downlink_counter = 0;
_compliance_test.running = false;
LoRaWANStack is made independent of MAC sublayers - Only internal changes, no API has been broke. - Tested by manually running Green tea tests
2018-03-16 11:12:50 +00:00
_loramac.enable_adaptive_datarate(MBED_CONF_LORA_ADR_ON);
LoRa: LoRaPHY dependency removed from LoRaMacStack - 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
2018-03-15 08:43:31 +00:00
#if MBED_CONF_LORA_PHY == 0
_loramac.LoRaMacTestSetDutyCycleOn(MBED_CONF_LORA_DUTY_CYCLE_ON);
#endif
LoRaWANStack is made independent of MAC sublayers - Only internal changes, no API has been broke. - Tested by manually running Green tea tests
2018-03-16 11:12:50 +00:00
_loramac.join_by_otaa(_lw_session.connection.connection_u.otaa);
LoRa: LoRaPHY dependency removed from LoRaMacStack - 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
2018-03-15 08:43:31 +00:00
break;
case 7: // (x)
if (mcps_indication->buffer_size == 3) {
loramac_mlme_req_t mlme_req;
mlme_req.type = MLME_TXCW;
LoRaWANStack is made independent of MAC sublayers - Only internal changes, no API has been broke. - Tested by manually running Green tea tests
2018-03-16 11:12:50 +00:00
mlme_req.cw_tx_mode.timeout = (uint16_t)((mcps_indication->buffer[1] << 8) | mcps_indication->buffer[2]);
LoRa: LoRaPHY dependency removed from LoRaMacStack - 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
2018-03-15 08:43:31 +00:00
_loramac.mlme_request(&mlme_req);
} else if (mcps_indication->buffer_size == 7) {
loramac_mlme_req_t mlme_req;
mlme_req.type = MLME_TXCW_1;
LoRaWANStack is made independent of MAC sublayers - Only internal changes, no API has been broke. - Tested by manually running Green tea tests
2018-03-16 11:12:50 +00:00
mlme_req.cw_tx_mode.timeout = (uint16_t)((mcps_indication->buffer[1] << 8) | mcps_indication->buffer[2]);
mlme_req.cw_tx_mode.frequency = (uint32_t)((mcps_indication->buffer[3] << 16) | (mcps_indication->buffer[4] << 8)
LoRa: LoRaPHY dependency removed from LoRaMacStack - 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
2018-03-15 08:43:31 +00:00
| mcps_indication->buffer[5]) * 100;
LoRaWANStack is made independent of MAC sublayers - Only internal changes, no API has been broke. - Tested by manually running Green tea tests
2018-03-16 11:12:50 +00:00
mlme_req.cw_tx_mode.power = mcps_indication->buffer[6];
LoRa: LoRaPHY dependency removed from LoRaMacStack - 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
2018-03-15 08:43:31 +00:00
_loramac.mlme_request(&mlme_req);
}
_compliance_test.state = 1;
break;
}
}
}
LoRa: LoRaMacMcps refactored to remove dependency to LoRaMac. - 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
2018-03-05 13:16:08 +00:00
#endif