• State Verified Answer
  • Replies 5 replies
  • Subscribers 62 subscribers
  • Views 2074 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 222650
Options
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Bluetooth mesh setup

kunal07

Hey, I am trying to get a bluetooth mesh up and running with the nrf52832 dev boards (PCA10040) acting as nodes and a Raspberry Pi 3 (with bluez meshctl) as the provisioner. I am succesfully able to run the light_client_server example in the Mesh SDK. I have a couple of queries - 

1. I have a requirement of around 10k nodes. The nodes will need to transmit sensor data at periodic intervals to the provisioner. Is this feasible with a single provisioner? If not, what would be an ideal configuration for this scenario? 

2. How would I send periodic advertisement packets (for reading the RSSI value) to the provisioner across the mesh? And once received, how would I read the data on the raspberry pi?

Parents
  • +1

    Hello,

    The number of addresses in a bluetooth mesh network is 32 767, so it is in theory possible with more than 10k nodes in a single network. I want to check a couple of things about your network/application:

    1: How often and how much data do you intend to send from each node?

    2: How dense it your network? It is a bit hard to answer exact, but are all the nodes within range of one another, or are they spread out on a large area?

    To answer shortly to your questions:

    1: It is feasible with a single provisioner (a single network).

    2: You can either create a custom model and send dummy data (an empty packet) and measure the RSSI value of these packets, or measure the RSSI value from the sensor data packets. How you do it on the RPi side, I am not sure.

    Check this site.

    Best regards,

    Edvin

Reply
  • +1

    Hello,

    The number of addresses in a bluetooth mesh network is 32 767, so it is in theory possible with more than 10k nodes in a single network. I want to check a couple of things about your network/application:

    1: How often and how much data do you intend to send from each node?

    2: How dense it your network? It is a bit hard to answer exact, but are all the nodes within range of one another, or are they spread out on a large area?

    To answer shortly to your questions:

    1: It is feasible with a single provisioner (a single network).

    2: You can either create a custom model and send dummy data (an empty packet) and measure the RSSI value of these packets, or measure the RSSI value from the sensor data packets. How you do it on the RPi side, I am not sure.

    Check this site.

    Best regards,

    Edvin

Children
  • 0 in reply to Edvin

    Hey, Thanks for the reply.

    1. The data from sensor will be sent out once every 3 to 4 hours.

    2. Our application will run over a large area, but the nodes will be mostly be in range of one another.

    Are there any design considerations (both hardware and software wise) to be taken care of for implementing a mesh of this scale?

  • +1 in reply to kunal07

    Hello,

    I see.

    1: How much data are we talking every 3-4 hours. How large is the sensor packet you want to send? The reason that I ask is because the data rate of mesh networks is quite limited if you have a large amount of nodes. The reason for this is that Bluetooth Mesh is a flooding network. This means that every node receiving a mesh message will retransmit this packet regardless of the destination address. So if one node sends out a message and 3 nodes are in range, then all 3 nodes will (after a short random delay) retransmit this message. Now, if 10k nodes are in range of the node sending the initial message, this means that you all the sudden has a lot of messages travelling around in the network. This will as you can imagine cause a lot of traffic. This is fine. A message will be received by a node if only one of the retransmissions will be received correctly (correct CRC). 

    If you see that this becomes a problem, you may change the behavior of your network by only setting a certain amount of the nodes to be retransmitting nodes. This is set in nrf_mesh_config_core.h, in:

    #define MESH_FEATURE_RELAY_ENABLED (1)

    If this is set to 0, then the node will not relay/retransmit any messages. 

     

    kunal07 said:
    2. Our application will run over a large area, but the nodes will be mostly be in range of one another.

     This is a bit related to the first point, but does that mean that all nodes are in range of all other nodes, so that the required number of hops is 0? 

    If so, I would still recommend that you have a decent amount of relay nodes, just in case of collisions of messages. 

     

    kunal07 said:
    Are there any design considerations (both hardware and software wise) to be taken care of for implementing a mesh of this scale?

     I am no HW expert, but I don't think there is anything particular you need to consider for a Mesh node HW wise in comparison to a regular BLE device. You should be aware that Mesh applications draw more current than a BLE device, which is caused by the Mesh requirement of always having the radio in RX mode.

    Also, if you intend to do large scale testing, I recommend that you program your devices with a bootloader. Although this is an extra part that you need to get familiar with, it makes it a lot easier to update the FW on a large number of nodes. You can read our getting started guide here.

    Best regards,

    Edvin

  • 0 in reply to Edvin

    Hey,

    Thanks again for the response.

    1. The node will send out around 8-10 bytes of sensor data. All the data has to ultimately reach the provisioner (Raspberry Pi).

    2. The nodes will have to form a path to the provisioner (which will not be in direct range of the far end nodes, hence the mesh requirement)

    3. Will look into the bootloader part. Thank you!

    Regarding the power consumption, what would be the current draw of each node in relay mode? 

    The friend node and LPN architecture seems to be complex and hard to maintain for a mesh of this size. Any suggestions?

  • +1 in reply to kunal07

    I see. You would need at least as many relay nodes so that the path back to the RPi is covered with relay nodes. If possible more than the minimum requirement in case a node's battery runs out or similar. 

    kunal07 said:
    Regarding the power consumption, what would be the current draw of each node in relay mode? 

    As my colleague states in this post, the radio needs to be on in RX mode at all times, so the current consumption will be a minimum of 5mA.

    I think the restriction on how many friend nodes a single node can have is in the memory requirement for the friend node. The actual number depends on a few things, among others how many messages you are queuing up for the friend nodes. I don't know, but I suspect that you don't need any messages from the gateway (RPi) to the sensor nodes, so this number will not be large. However, I am still not sure exactly how many low power nodes, but you can test this out with the low power node example in the mesh SDK. You can find the testing documentation for this example here.

    BR,

    Edvin

Related