This phy implementation was just to support a single sub-band in US region.
As we have decided to make FSBs configurable, we do not need this class anymore.
Just like US915 PHY, user can define a custom FSB mask for AU915 PHY.
This helps deployments where base stations do not portray full feature
channel sets and choose to stick with sub-bands.
Some LoRaMac methods were defined as public even though there were used only
internally.
Also removed definition of some methods which were not even implemented nor used.
- Duty cycle can be now only disabled with duty-cycle-on flag if region supports duty-cycle.
If region does not support duty-cycle, this flag has no effect and duty cycle is always
disabled.
- Also introduced a new flag (duty-cycle-on-join) to disable duty cycle for JOIN requests.
This flag can be used for testing only and is used to speed up JOIN request testing as
backoff times for JOIN request are really long (easily several minutes per attempt).
This flag works in conjunction with main duty cycle setting. Disabling duty-cycle-on-join
works only if duty-cycle-on is disabled (or region settings have duty cycle disabled).
In #b0b0261 we changed the RX2 data rate to start from the highest data rate
available for the PHY rather than standard defined DR.
This introduced a regression, i.e., even when somebody changed the default RX2 data
rate to something usable for their environment, it didn't take any effect. As in
reset_mac_params() we override the data rate with max value possible for that PHY.
This commit restores the original behaviour and we always use standard defined
values.
In release builds where MBED_ASSERT macro is syphoned off, we were hitting
an unused variable warning. To mitigate that we could direct the variable
used in MBED_ASSERT to void.
In order have a consistent return value for all methods in case of system is uninitialized
now also send and receive methods can return LORAWAN_STATUS_NOT_INITIALIZED.
Thix commit fixes a bug where stack was resending join-accept already
after RX1 if received join-response was invalid.
Stack should wait for RX2 before resending the join-accept.
LoRaMAC was not initialized properly if application called
connect(const lorawan_connect_t &connect);
This causes problems for example in case where application
first disconnects and then reconnects as counter values are not
initialized.
When node sends a CONFIRMED message and gateway sends ACK in RX1 window but the
message gets corrupted during the transmission (e.g. MIC fails), currently
our stack already checks for retransmission after RX1 and if retries attemps are
exhausted, TX_ERROR event is sent to application. This is wrong as MAC layer
will still attempt reception in RX2 window.
This commit fixes the behaviour so that TX_ERROR is not sent until RX2 window
has been closed.
It is quite possible that the user request for scheduling an uplink is deferred because of backoff or if it was a CONFIRMED message, a retry may take place on a different datarate and different channel.
We didn't have a hook for such deferred scheduling, telling the user whether the async rescheduling worked or not. This commit adds that capability and now we can tell the application if a scheduling failure took place after the original schedule request was accepted.
failed of its own accord) would prevent futher connect()'s due to the
CONN_IN_PROGRESS_FLAG remaining set. This change clears that flag in
the two cases described.
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).
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.
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.
Hasnain Virk
Martin Kojtal
Cruz Monrreal
Kimmo Vaisanen
Amanda Butler
Edd Inglis