ARMmbed
/
mbed-os
mirror of https://github.com/ARMmbed/mbed-os.git
1
0
Fork 0
Code Issues Projects Releases Wiki Activity

Copy edit LoraWANBase.h 

Copy edit file, mostly for consistent U.S. spelling and precise language.
pull/7719/head
Amanda Butler 2018-08-08 15:30:18 -05:00 committed by GitHub
parent 17d02d949f
commit 71341ec44e
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 42 additions and 42 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

74
features/lorawan/LoRaWANBase.h
View File

@ -37,35 +37,35 @@ public:
*/
virtual lorawan_status_t initialize(events::EventQueue *queue) = 0;
/** Connect OTAA or ABP using Mbed-OS config system
/** Connect OTAA or ABP using the Mbed OS config system
*
* Connect by Over The Air Activation or Activation By Personalization.
* You need to configure the connection properly via the Mbed OS configuration
* You need to configure the connection properly using the Mbed OS configuration
* system.
*
* When connecting via OTAA, the return code for success (LORAWAN_STATUS_CONNECT_IN_PROGRESS) is negative.
* However, this is not a real error. It tells you that the connection is in progress and you will
* be notified of the completion via an event. By default, after the Join Accept message
* When connecting through OTAA, the return code for success (LORAWAN_STATUS_CONNECT_IN_PROGRESS) is negative.
* However, this is not a real error. It tells you that the connection is in progress, and an event will
* notify you of the completion. By default, after the Join Accept message
* is received, base stations may provide the node with a CF-List that replaces
* all user-configured channels except the Join/Default channels. A CF-List can
* configure a maximum of five channels other than the default channels.
*
* To configure more channels, we recommend that you use the `set_channel_plan()` API after the connection.
* By default, the PHY layers configure only the mandatory Join channels. The retransmission back-off restrictions
* on these channels are severe and you may experience long delays or even failures in the confirmed traffic.
* on these channels are severe, and you may experience long delays or even failures in the confirmed traffic.
* If you add more channels, the aggregated duty cycle becomes much more relaxed as compared to the Join (default) channels only.
*
* **NOTES ON RECONNECTION:**
* Currently, the Mbed OS LoRaWAN implementation does not support non-volatile
* memory storage. Therefore, the state and frame counters cannot be restored after
* a power cycle. However, if you use the `disconnect()` API to shut down the LoRaWAN
* protocol, the state and frame counters are saved. Connecting again would try to
* restore the previous session. According to the LoRaWAN 1.0.2 specification, the frame counters are always reset
* to zero for OTAA and a new Join request lets the network server know
* that the counters need a reset. The same is said about the ABP but there
* protocol, the state and frame counters are saved. Connecting again
* restores the previous session. According to the LoRaWAN 1.0.2 specification, the frame counters are always reset
* to 0 for OTAA, and a new Join request lets the network server know
* that the counters need a reset. The same is said about the ABP, but there
* is no way to convey this information to the network server. For a network
* server, an ABP device is always connected. That's why storing the frame counters
* is important, at least for ABP. That's why we try to restore frame counters from
* is important for ABP. That's why we restore frame counters from
* session information after a disconnection.
*
* @return Common: LORAWAN_STATUS_NOT_INITIALIZED if system is not initialized with initialize(),
@ -87,17 +87,17 @@ public:
* All connection parameters are chosen by the user and provided in the
* data structure passed down.
*
* When connecting via OTAA, the return code for success (LORAWAN_STATUS_CONNECT_IN_PROGRESS) is negative.
* However, this is not a real error. It tells you that connection is in progress and you will
* be notified of completion via an event. By default, after Join Accept message
* is received, base stations may provide the node with a CF-List which replaces
* When connecting using OTAA, the return code for success (LORAWAN_STATUS_CONNECT_IN_PROGRESS) is negative.
* However, this is not a real error. It tells you that connection is in progress, and an event will
* notify you of completion. By default, after Join Accept message
* is received, base stations may provide the node with a CF-List that replaces
* all user-configured channels except the Join/Default channels. A CF-List can
* configure a maximum of five channels other than the default channels.
*
* To configure more channels, we recommend that you use the `set_channel_plan()` API after the connection.
* By default, the PHY layers configure only the mandatory Join
* channels. The retransmission back-off restrictions on these channels
* are severe and you may experience long delays or even
* are severe, and you may experience long delays or even
* failures in the confirmed traffic. If you add more channels, the aggregated duty
* cycle becomes much more relaxed as compared to the Join (default) channels only.
*
@ -105,13 +105,13 @@ public:
* Currently, the Mbed OS LoRaWAN implementation does not support non-volatile
* memory storage. Therefore, the state and frame counters cannot be restored after
* a power cycle. However, if you use the `disconnect()` API to shut down the LoRaWAN
* protocol, the state and frame counters are saved. Connecting again would try to
* restore the previous session. According to the LoRaWAN 1.0.2 specification, the frame counters are always reset
* to zero for OTAA and a new Join request lets the network server know
* that the counters need a reset. The same is said about the ABP but there
* protocol, the state and frame counters are saved. Connecting again
* restores the previous session. According to the LoRaWAN 1.0.2 specification, the frame counters are always reset
* to zero for OTAA, and a new Join request lets the network server know
* that the counters need a reset. The same is said about the ABP, but there
* is no way to convey this information to the network server. For a network
* server, an ABP device is always connected. That's why storing the frame counters
* is important, at least for ABP. That's why we try to restore frame counters from
* is important for ABP. That's why we restore frame counters from
* session information after a disconnection.
*
* @param connect Options for an end device connection to the gateway.
@ -146,15 +146,15 @@ public:
* from the Network Server, user provided method is called.
*
* One way to use this API may be the validation of connectivity after a long
* deep sleep. Mbed LoRaWANStack piggy-backs the MAC commands with data
* frame payload so the application needs to try sending something and the Network
* deep sleep. Mbed LoRaWANStack follows the MAC commands with data
* frame payload, so the application needs send something, and the Network
* Server may respond during the RX slots.
*
* This API is usable only when the 'link_check_resp' callback is set by
* the application. See add_lora_app_callbacks API. If the above mentioned
* callback is not set, a LORAWAN_STATUS_PARAMETER_INVALID error is thrown.
*
* First parameter to callback function is the demodulation margin and
* The first parameter to callback function is the demodulation margin, and
* the second parameter is the number of gateways that successfully received
* the last request.
*
@ -172,7 +172,7 @@ public:
/** Removes link check request sticky MAC command.
*
* Any already queued request may still get entertained. However, no new
* Any already queued request may still be completed. However, no new
* requests will be made.
*/
virtual void remove_link_check_request() = 0;
@ -192,7 +192,7 @@ public:
/** Enables adaptive data rate (ADR)
*
* The underlying LoRaPHY and LoRaMac layers handle the data rate automatically
* for the user, based upon the radio conditions (network congestion).
* for the user, based on the radio conditions (network congestion).
*
* @return LORAWAN_STATUS_OK on success, negative error code
* on failure:
@ -202,8 +202,8 @@ public:
/** Disables adaptive data rate
*
* When adaptive data rate (ADR) is disabled, you can either set a certain
* data rate or the MAC layer selects a default value.
* When adaptive data rate (ADR) is disabled, either you can set a certain
* data rate, or the MAC layer selects a default value.
*
* @return LORAWAN_STATUS_OK on success, negative error code on failure:
* LORAWAN_STATUS_NOT_INITIALIZED if system is not initialized with initialize()
@ -218,7 +218,7 @@ public:
* receive an acknowledgment. The MAC performs a data rate adaptation as in
* the LoRaWAN Specification V1.0.2, chapter 18.4, table on page 64.
*
* Note, that if number of retries is set to 1 or 2, MAC will not decrease
* Note that if the number of retries is set to 1 or 2, MAC does not decrease
* the data rate, if the LoRaMAC layer did not receive an acknowledgment.
*
* @param count The number of retries for confirmed messages.
@ -239,7 +239,7 @@ public:
* is already active, the request is silently ignored. A negative error
* code is returned if there is any problem with parameters.
*
* Please note that this API can also be used to add a single channel to the
* Please note that you can also use this API to add a single channel to the
* existing channel plan.
*
* There is no reverse mechanism in the 1.0.2 specification for a node to request
@ -247,7 +247,7 @@ public:
* You need to ensure that the corresponding base station supports the channel or channels being added.
*
* If your list includes a default channel (a channel where Join Requests
* are received) you cannot fully configure the channel parameters.
* are received), you cannot fully configure the channel parameters.
* Either leave the channel settings to default or check your
* corresponding PHY layer implementation. For example, LoRaPHYE868.
*
@ -362,8 +362,8 @@ public:
* one another depending on the intended use case or reception
* expectation.
*
* e.g., MSG_CONFIRMED_FLAG and MSG_UNCONFIRMED_FLAG are
* not mutually exclusive, i.e., the user can subscribe to
* For example, MSG_CONFIRMED_FLAG and MSG_UNCONFIRMED_FLAG are
* not mutually exclusive. In other words, the user can subscribe to
* receive both CONFIRMED AND UNCONFIRMED messages at
* the same time.
*
@ -385,7 +385,7 @@ public:
*
* @param length The size of data in bytes
*
* @param port Return the number of port to which message was received.
* @param port Return the number of port from which message was received.
*
* @param flags Return flags to determine what type of message was received.
* MSG_UNCONFIRMED_FLAG = 0x01
@ -518,13 +518,13 @@ public:
* This API is used to cancel any outstanding transmission in the TX pipe.
* If an event for transmission is not already queued at the end of backoff timer,
* the system can cancel the outstanding outgoing packet. Otherwise, the system is
* busy sending and can't be held back. The system will not try to re-send if the
* busy sending and can't be held back. The system will not try to resend if the
* outgoing message was a CONFIRMED message even if the ack is not received.
*
* @return LORAWAN_STATUS_OK if the sending is cancelled, otherwise
* @return LORAWAN_STATUS_OK if the sending is canceled, otherwise
* other negative error code if request failed:
* LORAWAN_STATUS_NOT_INITIALIZED if system is not initialized with initialize(),
* LORAWAN_STATUS_BUSY if the send cannot be cancelled
* LORAWAN_STATUS_BUSY if the send cannot be canceled
*/
virtual lorawan_status_t cancel_sending(void) = 0;
};