• State Verified Answer
  • Replies 2 replies
  • Subscribers 75 subscribers
  • Views 168 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 344932
Options

Bluetooth Mesh Chat

Allen23122452121

Hello!

I’ve been learning about Bluetooth Mesh recently, and I’ve been testing the sample at nrf\samples\bluetooth\mesh\chat, but there are still some parts I don’t quite understand:

  1. How is message scanning configured in this sample? Is it running at a 100% duty cycle? If not, how can it ensure that no messages are missed?

  2. What is the message forwarding logic between nodes? Is it based on flooding? Does each node forward all received messages within the TTL?

  3. I noticed that the following configurations are enabled: CONFIG_BT_MESH_RELAY=y and CONFIG_BT_MESH_FRIEND=y. How does a node determine which role it is playing? Is it a RELAY node? A FRIEND node? Or just a regular node?

    Looking forward to your help.

Parents
  • +1

    Hi Allen23122452121,

    How is message scanning configured in this sample? Is it running at a 100% duty cycle? If not, how can it ensure that no messages are missed?

    Message sending and receiving in the Chat Client Model is done no differently than in other BT Mesh models.

    Scanning and sending are done over the same radio, so it is not always 100% duty cycle. The radio would stop scanning when it has to send. However, it would be receiving as much as possible when it doesn't have anything to send.

    There are several acknowledgement mechanisms in the Mesh stacks to help with reliability. However, none of them is done in the Chat sample.

    What is the message forwarding logic between nodes? Is it based on flooding? Does each node forward all received messages within the TTL?

    It is based on flooding, and each node forward messages based on TTL.

    I noticed that the following configurations are enabled: CONFIG_BT_MESH_RELAY=y and CONFIG_BT_MESH_FRIEND=y. How does a node determine which role it is playing? Is it a RELAY node? A FRIEND node? Or just a regular node?

    The roles are configured by a Configuration Client in the mesh network.

    As your questions seem basic, may I recommend looking at some resources for the basics of Bluetooth Mesh, such as:
    Introduction to Bluetooth Mesh - YouTube
    The BluetoothRegistered Mesh Primer | BluetoothRegistered Technology Website
    An Introduction to Bluetooth Mesh Software Development | BluetoothRegistered Technology Website

    Hieu

Reply
  • +1

    Hi Allen23122452121,

    How is message scanning configured in this sample? Is it running at a 100% duty cycle? If not, how can it ensure that no messages are missed?

    Message sending and receiving in the Chat Client Model is done no differently than in other BT Mesh models.

    Scanning and sending are done over the same radio, so it is not always 100% duty cycle. The radio would stop scanning when it has to send. However, it would be receiving as much as possible when it doesn't have anything to send.

    There are several acknowledgement mechanisms in the Mesh stacks to help with reliability. However, none of them is done in the Chat sample.

    What is the message forwarding logic between nodes? Is it based on flooding? Does each node forward all received messages within the TTL?

    It is based on flooding, and each node forward messages based on TTL.

    I noticed that the following configurations are enabled: CONFIG_BT_MESH_RELAY=y and CONFIG_BT_MESH_FRIEND=y. How does a node determine which role it is playing? Is it a RELAY node? A FRIEND node? Or just a regular node?

    The roles are configured by a Configuration Client in the mesh network.

    As your questions seem basic, may I recommend looking at some resources for the basics of Bluetooth Mesh, such as:
    Introduction to Bluetooth Mesh - YouTube
    The BluetoothRegistered Mesh Primer | BluetoothRegistered Technology Website
    An Introduction to Bluetooth Mesh Software Development | BluetoothRegistered Technology Website

    Hieu

Children
Related
Terms of service