We had a bug especially in the reception path. Our recv window opening
delays were being calculated on the premise that the radio has to capture
5 preamble symbols out of 8 transmitted by the base station. However, in PHY
layer while setting radio rc settings, we were setting preamble length to be 8.
Preamble length register needs to be configured differently for Uplink and Downlink.
For uplink, we wish to transmit 8 preamble symbols whereas in the reception path we need
to receive 5 preamble symbols at least out of 8.
Alongwith that the maximum range of timing error may vary from platform to platform as it
is based upon the crystal in the chip. We have now made these parameters configurable and
have loaded them with the most optimal defaults.
The issue rose up when using ARMC6. A test case didn't initialize NetID
parameter for ABP while using connect(params) API. NetID is the first 7 bits
of the Device Address. It makes sense to actually remove the net-id parameter
from ABP settings as the stack can deduce it from device address. However, the ABP
structure is exposed in public APIs, so we can't really do that at the moment.
Simpler fix is to move the mask that helps us to extract first 7 bits of the device address
is exposed in lorawan_types.h and the user can use it to deduce correct net-id.
DR7 is used for FSK in AS932 region. As a default max DR, we should use a LoRa modulation
compatible data rate. Ofcourse if a device wishes to use FSK, it can set DR7 using set_data_rate() API
and turning off ADR, or an NS can configure a new channel for the device utilizing DR7.
The stack was trying to connect with default data rates which happened to be
the lowest data rates in a specific region. In the beginning device and NS do
not have agreed upon tx rx parameters and there can be synchronization issues.
When we use lower datarates, we may end up having a minute and a half long
transmissions that hnot only blocks the channel for a long time but also reduce
the chance of proper synch between device and NS. That's why we have decided to
begin with higher data rates and gradually decrease datarate if we do not hear
from the network server.
In the case when an automatic uplink was queued and the user do have something send,
we should give priority to user data instead od automatic uplink message.
This commit fixes some bugs from cancel_sending() method:
- System crashed if method was called before initialization.
Now LORAWAN_STATUS_NOT_INITIALIZED will be returned.
- Method returned LORAWAN_STATUS_BUSY error when no send request was pending.
LORAWAN_STATUS_OK should be returned in this case.
- LORAWAN_STATUS_BUSY is now returned if backoff timer is just about to be
dispatched (time_left returns 0).
I changed stack size because the deafult stack size may not be enough for
Ethernet of GR-PEACH(Cortex-A).
- Stack size is default size + 128 byte
In order to maximize the performance of Ethernet, I changed heap size to
below.
- Heap size is default size * 32 byte(send descriptor num is 16 and recv
descriptoer num is 16).
The integration is simply to define the macro MBEDTLS_HAVE_TIME_DATE
in the features/mbedtls/platform/inc/platform_mbed.h. The default
implementation of the mbedtls_time() function provided by mbed TLS is
sufficient to work with mbed OS because both use POSIX functions.
51f92b0efd introduced
handling for connection attempts while a connection was already underway or have been
completed. Unfortunately a similar check slipped through and the stack was not able to continue
sending join requests if an error happened.
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.
The TEST_SKIP and TEST_SKIP_UNLESS macros (w/ and w/o messages) allow the test
to skip the test case execution from the point the macro was called (without
failing the test).
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.
Setting ""nsapi.dns-cache-size": 0" still left some of the DNS
caching code in. Add crude #if to remove all of it.
This allows one to save 429 bytes of flash and 48 bytes of RAM on
ARMC5 builds.
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().
Fix error: IIOTCLT-2769 - mbed-coap: extra response received after registration
Added own flag to enable blockwise support, without setting default blockwise
payload size. This allows to receive blockwise messages while still sending
without blockwise.
Fix CoAP request blockwise response handling
When request is sent, response can have blockwise option set. All requests must
be stored to the linked list.
The existing test was expecting that the acknowledgement of the reset command would be the first and only event receive. This assumption is false.
As a consequence, the new code parse all incoming packets and raise a flag in the following circumstances:
* a reset packet has been successfully received.
* RX stream is not synchronized
* The status of the reset command is an error.
Another test has been added that send a serie of reset commands.
* Move IP Socket stuff to InternetSocket class which is inherited by TCP/UDP
* Implement sendto() and recvfrom() on TCP socket
* Implement connect() call on UDP
* Implement send() and recv() calls on UDP socket
Code was written using MBED_CONF_DEFAULT_* but the mbed_lib.json file
that created these values is prefixed with "nsapi" and therefore
final macros are MBED_CONF_NSAPI_DEFAULT_*
The first test focuse on the transport by testing that the reset sequence is
correctly sent to the controller and properly received.
The second test validates that the reset sequence fullfill the right state
of the stack and ensure that bluetooth initialization succeed.