It was pointed out in #7432 and #7232 that the stack was comparing frame payload size
with the allowed payload size in a wrong manner in shcedule_tx().
We must strip the overhead from the frame before comparison.
We did have a similar check in prepare_ongoing_tx() API which would correctly analyse
the situation but a check was needed in schedule_tx() as well. The reason is that the
schedule_tx() API can be called automatically by the stack if the user intiated requested
was not promptly entertained because of duty cycle restriction. Now, the datarate can change
here (for CONFIRMED messages if the ack was not received after retries max out). That's why
a test for validity was needed.
We now perform a comparison using _ongoing_tx_message structure which contains the actual
FRMPayload size.
For proprietary type of messages only MHDR and Port field is used so we shouldn't add MAC commands
and other overhead into them.
In order to have consistent frame overhead, we have opted to always include Port field in the
frame.
For ABP: First call to connect() or connect(params) will return LORAWAN_STATUS_OK
and a CONNECTED event will be sent. Any subsequent call will return
LORAWAN_STATUS_ALREADY_CONNECTED (posix EISCONN) and no event is generated.
FOR OTAA: First call to connect() or connect(params) will return LORAWAN_STATUS_CONNECT_IN_PROGRESS
and a CONNECTED event will be sent whenever the JoinAccept is received. If the application
calls connect again before receiving the CONNECTED event, LORAWAN_STATUS_BUSY will be returned.
After the CONNECTED event is dispatched, any subsequent call to connect() or connect(params) API
will be returned with LORWAN_STATUS_ALREADY_CONNECTED.
No new parameters are accepted after the first call. The application must disconnect before making
a connect() call with new parameters.
This is a remedy for the issue #7230.
While the device is joining, LORAWAN_STATUS_CONNECT_IN_PROGRESS is returned.
However, if the device is already joined, we will return LORAWAN_STATUS_ALREADY_CONNECTED.
Instead of giving LoRaWANTimeHandler object as parameter for constructor,
object is now given via own initialize() method.
This change is needed for future refactoring where application can give own
PHY object for LoRa stack.
In rx_config(params) API we shouldn't check for radio state as radio may never get
idle for a class C device. That check made sense only for class A. As the PHY layer
have no conecpt of receive windows which is a MAC layer construct, we should remove the
state check.
The API will be changed later to void rx_config(params).
In addition to that another bug is fixed in the open_rx2_windows() API. We should set the rx slot
first before instantiating a test based on its value.
This commit fixes the issue reported in #7285.
If the radio is unable to transmit, its a fatal error and can happen
both while joining or sending a normal packet. In the case of such
a catastrophy we ought to tell the application that this happened.
A fix for the radio driver will also be patched.
receive(uint32_t) API in the LoRaRadio class (base class for the radio drivers) should
not take any argument as we decided to take hardware timers for RX timeout interrupts
instead of software timers. It is being refactored to receive(void).
This is an API change, but as it is not an application interface, we will not put a
deprecation notice. Only user of this API is our stack (LoRaPHY layer) which has been updated
accordingly.
Actual driver comes out of the tree and a PR is open there to update the drivers:
https://github.com/ARMmbed/mbed-semtech-lora-rf-drivers/pull/22
In addition to this an internal API belonging to LoRaPHY class is refactored.
set_rx_window(parameters) is refactored to handle_receive(void) which is more consistent with
handle_send().
If the automatic uplink is sent directly the call-stack becomes larger than 1K
which may cause serious problems in debug builds. Just to have a respite between
RX and TX we queue an event for the automatic uplink rather than directly undergoing
an automatic uplink.
RX1 and 2 delays needed to be more precise and aggregate tx time was
drifiting because of timing difference between actual tx interrupt and
our processing of that interrupt ever so slightly.
We now take a timestamp of the tx interrupt and take a time diff while
instantiating delay timers. The timestamp is then used to update the aggregate
tx time.
Two new methods are introduced in the LoRaMac class which provide current
timing and current receive slot. These functions are used by LoRaWANStack
for its processing.
If the value is an integer, the 4th bit is used for sign, so you can store
values upto 7 only whereas the datarate values could go upto 15. That's why
we need to turn this to an unsigned integer so that the last bit can also be used.
Travis astyle check pointed out some of the style mismatches in the code.
Not all of them are worth changing as they make the code unreadable and
some of them are semantically wrong.
So in this commit, we have attempted to pick the most important style
mismatches and rectify.
General stability improvements are performed.
A flag is added if a Class C RX2 window is open.
We shouldn't open it again if its already opened.
TX_CRYPTO_ERROR is renamed to CRYPTO_ERROR.
Keeping TX_CRYPTO_ERROR for backwards compatibility.
In Class C, rx timeout does not take place for RX2 windows, so if we have
not received anything, we would be retrying but if the no. of retries are
maxed out, and we have not recieved anything yet, we need a mechanism to
tell the upper layer that this has happened.
rx_abort() was sort of dead code as it was doing essentially nothing.
It might have actually meddled with the state machine if it was hit by
invoking on_ack_timeout_timer_event().
State machine and corresponding processors now take care of the ack timeout,
retries and all other bits, so we don't need abort_rx().
MCPS confirmation should be filled with the current number of retries
if the ack is not recieved for a CONFIRMED message.
Ack retry number needs to be incremented after the retry is made not before
that.
A few traces are added at the crucial junctions of the code just to tally with
the conceptual flow for debug purposes.
Application can use cancel_sending() API to stop any outstanding, outgoing
transmission (a TX which is not already queued for transmission). This can
potentially enable use cases where the application could cancel a transmission
and go to sleep if the backoff period is long enough rather than waiting for
the transmission to happen.
This API enables the application to get hold of remaining time after which
the transmission will take place. User can query the backoff time whenever
there is a packet in the TX pipe. If the event for the backoff expiry is
already queued, the stack does not provide backoff metadata.
An API is added to fetch any meta-data available after a succesful
transmission. The stack will make the meta data available after the
TX interrupt is processed. User can get the tx meta data after receiving
TX_DONE event.
In the reception data path, we needed to check the MCPS CONFIRMATION type
not the MCPS INDICATION type. Indication message type is for downlink message type
which can be UNCONFIRMED even if we have sent a CONFIRMED one, e.g., an ACK.
Application can give battery_level callback method what Lora stack
uses to query battery level for DevStatusReq MAC command response.
The problem was that this callback was never called.
This commit fixes this problem and if application does not set
battery_level callback at all, value 255 (= The end-device was not able to
measure the battery level.) will be returned to lora gateway.
If the frame length is not what we are expecting, it is
found to be a good practise to actually continue with what we
have received rather than aborting. As we have already demodulated
the packet and RX slots are used up, ther is not so much benefit in
dropping that packet.
While configuring RX parameters for the radio, we need to feed in
rx windows 1 and 2 parameters which are computed when we do the transmission.
We are actually setting the physical value of the data rate rather than
data rate table index and the expectation was to set the data rate index.
The asia pacific region supports custom channel planning and
downlink channel request. By virtue of a mistake, this information
was missing and hence a custom channel support was not working.
Fixes issue #6783.
There had been essentially two state machines running in our stack
which was too cumbersome and was not alligned in any symmetry.
In this work we make sure that:
* There are no callbacks from the MAC layer to Stack controller layer.
* Primitives are made local to the mac layer and are presented as
read-only to the stack controller layer.
* Interrupt handling and processing is moved to the stack controller layer.
* Reception is divided into smaller units, seperating handling of Join Accept
and normal data frames. MIC gets its own unit.
* Extraction of data and MAC commands from the payload is also being done now in
its own method.
* To ensure integrity of the stack, and sanctity of the radio payload, we copy the
radio payload buffer immediately in the rx interrupt and hoist a flag that prevents
another interrupt from happening for a short while when we are processing the previous
packet.
* If an automatic uplink is on going, we do not send a TX_DONE event to application
anymore as that is logically incorrect.
* state_controller() is the central engine for the state machine. To save code space and
memory, we are not handling each and every state in the state_controller(). Some of the states
which have no processing to be done, are explicitely set.
* For all the states who need special processing, seperate methods are added.
* Class A always run to completion to IDLE and CLass C always runs to completion as RECEIVING.
Making our LoRaWAN stack thread safe. If RTOS is not present, locks
don't do anything. ScopedLock is used to automate the lock release on
context expiry.
Cruz Monrreal
Hasnain Virk
Kimmo Vaisanen
Martin Kojtal
Amanda Butler