Previously, we weren't filling in RX1 frequecny in rx_window1_config
structure. However, everything worked as in LoRaPHY::rx_config() API
there was a check which filled in correct RX1 frequency.
Now we are filling in RX1 freq. properly while we are computing
parameters for RX1 window.
LinkADRReq mac command can be used by the network server to set a
certain level of QOS using NbTrans field which is applicable to
Unconfirmed traffic only for 1.0.2 spec.
This commit introduces mechanisms to facilitate this QOS. It means to
repeat an outgoing unconfirmed message NbTrans times without changing
its frame counter.
For class C, we have retired the ack_expiry_timer_for_class_c and have
replaced it with another timer which mimics the RX2 closure as in Class
A but doesn't actually close RX2 window. It's just a mechanism by which
the state machine is informed that the you can proceed forward, we have
not received anything in RX2 window either. This is needed as RX2
doesn't timeout in class C (i.e., the radio remains in continuous mode).
In addition to that we need to close any pending timers for Receive
windows after the MIC has passed and the Duplicate counter check has
also been passed.
set_next_channel() is the base function provided by LoRaPHY class and should be overridden
by the PHYs who behave differently as compared to EU868 like PHY layers.
CN470 PHY had been missing such an override.
In addition to that we have provided a parameter "fsb-mask-china" that can be used to
enforce a custom frequency sub-band of operation as most of the base stations in the market
may not support all 96 channels. Such a strategy will help in rapid network acquisition.
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.
- 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.
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.
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.
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.
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().
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.
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.
We went through an exercise of adding band information to
any new channel being added. Default channels were looked over.
This commits duly adds missing band information to default channels.
band_t structure in phy parameters was not being filled in properly
and we were spilling over the array boundary for bands.
In addition to that two utility functions are added to perform safety
checking taking in the frequency and filling out band information plus
boundry value checks.
In LoRa TX power value 0 means the maximum allowed TX power and values >0
are limiting the allowed TX power to lower.
tx_config was incorrectly checking the power level and causing the maximum
TX power to be always used. Lora gateway can request node to use lower TX
power with LinkAdrReq MAC command.
Bug was reported by @tpet93 and it was correctly diagnosed that channels
were not being set in the phy_params structure. This commit fixes the bug
and sets up channels correctly.
Removed the while loop checking the return value from set_next_channel
(GitHub Issue https://github.com/Lora-net/LoRaMac-node/issues/357)
The new return values are:
LORAWAN_STATUS_OK : A channel has been found.
LORAWAN_STATUS_NO_FREE_CHANNEL_FOUND : No free channel has been found (AS923 and KR920 regions)
LORAWAN_STATUS_DUTYCYCLE_RESTRICTED : No channel found due to the duty-cycle or JoinReq back-off restrictions. Trial must be delayed.
LORAWAN_STATUS_NO_CHANNEL_FOUND : No channel has been found. Re-enabled the default channels.
Cruz Monrreal II
Antti Kauppila
Hasnain Virk
Kimmo Vaisanen
Martin Kojtal
Kevin Bracey