With class B now being available the device class test moved to the LoRaMac class which then queries the Class B interface for support.
The Class B interface is not available here because the unit test stack class instantiates a LoRaMac stub class .
- 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.