- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Dear All,,,
I'm testing cypress mesh solution the below environment.
-. KIT : CYBT-213043-MESH
-. IDE : ModusToolbox 1.1
-. BT SDK 1.4
-. Code Example : Download BT SDK 1.4 example from GIT
-. Test : mesh location client / server among snip folder in code example.
About Bluetooth mesh messaging, I can see the below.
=====================================================
Acknowledged vs. Unacknowledged
As the name suggests, acknowledged messages require a response from the node that it is addressed to. The response confirms that the message was received and it may also return data back to the sender (e.g. in response to a GET). If a sender does not receive the expected response from a message it may resend it. Messages must be idempotent so that a message received more than once is no different than if it had only been received once.
GET, SET, STATUS
All access messages are of the three broad types of GET, SET, and STATUS.
GET messages request a state value from one or more nodes. A GET message is always acknowledged.
SET messages are used to change the value of a state. A SET message can be either acknowledged or unacknowledged.
STATUS messages are sent in response to a GET, and acknowledged SET, or may also be sent by a node independently, for example, periodically using a timer. A STATUS message is always unacknowledged. Therefore, if a node sends a GET message but never receives a STATUS return message, it may resend the GET message.
===========================================================
Questions :
If then, In case of SET message, How do I distinguish between sending acknowledged and unacknowledged set messages?
Maybe, Is it related to the reply field of the wiced_bt_mesh_event_t structure?
For example, is it acknowledged set message if the reply field is true, or is it unacknowledged set message if the reply filed is false?
typedef struct wiced_bt_mesh_event__t
{
struct wiced_bt_mesh_event__t *p_next; /**< Pointer to the next event in the queue */
void *complete_callback; /**< pointer to the send complete callback */
uint16_t company_id; /**< Company ID for the Model ID */
uint16_t model_id; /**< Model ID */
uint16_t opcode; /**< Opcode of the message to be transmitted or that has been received */
uint16_t hci_opcode; /**< HCI Opcode received of the message from the MCU being processed */
uint8_t element_idx; /**< Element Index of the source or destination of the message */
uint8_t ttl; /**< Time to leave to be used when transmitting or as received from the peer */
uint16_t src; /**< Address of the source mesh node */
uint16_t dst; /**< Address of the destination mesh node */
uint16_t app_key_idx; /**< Application key index used to decrypt when message was received or which should be used to encrypt to send the message */
uint16_t num_in_group; /**< number of devices in the group list */
uint16_t *group_list; /**< If dst is a group address, this points to the array of with individual unicast addresses */
uint16_t data_len; /**< Length of data corresponding to the event */
uint8_t credential_flag;/**< Value of the Friendship Credential Flag */
uint8_t retrans_cnt; /**< Number of retransmissions for each message. Should be <= 0x7f. It is ignored using 0 value or if it is reply (reply == WICED_TRUE). */
#define RETRANSMIT_TIMER_TICK 50
uint8_t retrans_time; /**< Interval between retransmissions in 50-millisecond steps */
uint8_t reply; /**< If TRUE the reply is expected */
#define REPLY_TIMER_TICK 50
uint8_t reply_timeout; /**< Time to wait for the peer model layer acknowledgment in 50-millisecond steps */
#define TX_STATUS_COMPLETED 0
#define TX_STATUS_FAILED 1
#define TX_STATUS_ACK_RECEIVED 2
uint8_t tx_status; /**< Transmission failed or timeout occurred waiting for peer reply */
wiced_timer_t timer;
uint16_t friend_addr; /**< core sets it to friend address when calls complete_callback if segmented message has been sent and acked by the friend OnBehalfOf LPN. Otherwise it is 0 */
uint8_t send_segmented; /**< if non-0 then core uses segmentation to send that message even if it fits into unsegmented message. */
int8_t rssi; /**< RSSI of the received message */
} wiced_bt_mesh_event_t;
Thanks,
Solved! Go to Solution.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
HI PICH_4397076
You are right. If reply field is TRUE then acknowledgement is expected. And if it is false then it is un-acknowledgement message.
On client side you have to set the field properly and then send the message.
If you want to learn more about the usage, may be you can refer the source code MeshClient/MeshClientControl (available along with the SDK). If checkbox called 'reliable' is marked, then it is for ack messages and otherwise it is un-ack messages.
Thanks,
-Dheeraj
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
HI PICH_4397076
You are right. If reply field is TRUE then acknowledgement is expected. And if it is false then it is un-acknowledgement message.
On client side you have to set the field properly and then send the message.
If you want to learn more about the usage, may be you can refer the source code MeshClient/MeshClientControl (available along with the SDK). If checkbox called 'reliable' is marked, then it is for ack messages and otherwise it is un-ack messages.
Thanks,
-Dheeraj