- Documented LoRaWANInterface beacon acquisition, and ping slot APIs
- Existing GPS time set/get documentation was only in LoRaWANStack.h, so I copied their docs to LoRaWANInterface and lightly modified them
to be a higher level description like the other documentation in this file.
- Updated set_utc_time to handle millisecond precision gps time.
Use close_rx_window callback to disable active class b window. This change protects against disabling the radio during class A transmit
Move class B resume notification to one location in LoRaMac::set_tx_ongoing()
- Added a bool return status to LoRaPHY::compute_*_win_params(...) methods. Currently, failed status returned if the rx slot type is invalid or rf frequency is invalid
- Updated Class B implementation to check return status
The Rx done/timeout event handler now checks if the radio is currently
transmitting before putting the radio to sleep. This test returns true in
class A rx window event handlers, so the radio is not not put to sleep.
Now to accurately test if transmitting, a mod ongoing flag is set true on send
and false on tx done/timeout.
Make class function names lower case. Previously, class b's public interface was part of the class and to avoid function name conflicts the static API was being distinguished from instance methods by upper-casing the first letter.
Fixed by moving the public interface to new LoRaMacClassBInterface
- Initialize Class B configuration
- Implement class B receiver configuration
- For regions such as US915 with derived rx_config(), changes to the base class implementation makes the derivation unnecessary , so these region specific versions have been removed
The existing gps time resolution is seconds, while class b beacon and ping slot scheduling requires millisecond resolution.
This set of changes switches gps time to millisecond resolution.
As per discussion with Nicolas Sornin, any device time synchronization
value must be handled as is (monotonically increasing GPS epoch time guaranteed to be monotonic with granularity 1 second).
Once we receive a response to DevTimeReq (i.e., DevTimeAns is received)
we immediately set our local gps time stamp and take a snapshot of our
local monotonic (ticker or equivalent) clock. This is achieved by
calling 'set_gps_time(...)' API in the LoRaWANTimer module.
After that an event is generated to let the application know that a
device time has been synched.
Provides hooks for the internal APIs handling GPS time base for device
synchronization.
In addition to that 'set_system_time_utc(...)' API is added which have no
roots in the stack. Its just a helper for the application developer to
acquire UTC time base given the difference between TAI and UTC time
bases.
LoRaWANTimer class is responsible for providing time base for the
LoRaWAN stack in Mbed OS. It derives its core monotonic clock from the
EventQueue which is essentially a millisecond ticker or equivalent (in
tickless mode). LoRaWAN network can assist the device for device level
time synchronization using ClockSynchronization protocol (for v1.0.2) or
by replying to DevTimeReq MAC command (for v1.0.3 and above). The time
base used for device synchronization using above methods is purely
based on GPS epoch and needs no conversion to UTC or TAI etc (no
adjustment for leap seconds either).
Therefore we have extended the LoRaWANTimer APIs to account for GPS time
base if assisted by the network.
get_gps_time() is the API to use to acquire GPS time base from the
stack. If the network never assisted the device with a time stamp, a
value of zero is returned which means GPS time base is not available.
set_gps_time(time) API is used to set a given GPS time-stamp when the
network sends it.
These APIs are hooked via LoRaMAC to LoRaWANInterface which exposes the
access to the application.
The application can use add_device_time_request() API to attach
DeviceTimeRequest mac command for the next outgoing packet.
It is a non-stick mac command, so if there is no response, the app can
retry. The API indicates if the mac command was queued successfully or
not. The actual indication of successful time and date update will come
through an event 'DEVICE_TIME_SYNCHED'.
DevTimeAns mac command will carry number of seconds since the GPS epoch
in the first four bytes and the fifth byte is the fractional part.
After extracting the time from the command fields, we need to adjust
this time according to the unix time, so we add the Unix to GPS time
diff to it. After that we account for leap seconds and set the time
using standard set_time() call.
We have removed the method time_received() fom LoRaPHY as it is not
important nor required. It doesn't fit into the LoRaPHY context.
Stubs are therefore updated to reflect the change.
mbed_lib.json now contains the configurable parameters for TAI to UTC
and GPS TAI to UTC differences in seconds needed for leap second
correction. They are loaded with values as of 2018.
While post processing a transmission in case of no reception, we already
take care of frame counters. We must not kick post processing step once
again.
* While starting timer for rejoin request type 0, we should multiply max
time with 1000 as the timer APIs take ms values as parameters.
* RJCountX are incremented every time a Rejoin request is sent. For MIC
calculation we need to take the previous RJCnt value in account.
* Rejoin process should start against an event otherwise it will meddle
with state machine and any ongoing traffic.
* If a Type 1 rejoin is ongoing, we should not trigger a Type 0 rejoin.
* Some bug fixes after Triage with Antti.
Double precision may introduce unwanted results and it's impact is
massive on microcontrollers. So we change the precision from double to
float.
This change doesn't seem to enhance performance yet.
In 1.1, NbTrans governs both unconfirmed and confirmed traffic.
We cannot set number of retries ourselves. Based upon NbTrans received
in linkADRReq command, we will retry. If NbTrans is 1, we will send only
one message and if ack is not received we will generate TX error event.
Its the NS now which controls how many retransmission a device can do
without incrementing Frame counter. When we fail with TX error after not
receiving an ack, we increment the frame counter. This is necessary as
the NS will drop anything with the previous counter and it can happen
that the NS may have sent an ack but we didn't receive it.
Rejoin requests and presence/absence of CFlist demand different
handling.
If a Rejoin request was sent we shall use RJCountX (0,1) instead of dev
nonce for key derivation.
If a Rejoin request is not of type 2, we reset mac, phy parameters
alongwith frame counters. However, if it is type 2, we reset frame
counters only.
If cflist i present, we shall always apply it as it is.
If it's not and rejoin type is not type 2, we restore default channels.
Otherwise the local channels do not change.
Unknown
Hasnain Virk
Antti Kauppila