This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Question about NRF MESH for a Sensor applications on differents NRF52 Device.

Hello,

I would like to create a mesh application with different nodes that are gyroscopic and pressure sensor in a 10+-  meters radius area and provide the data from the sensors node to a Raspberry collector at 1Hz.

Im using Several NRF52832 Devloppement Board, SDK 16.0 and  SDK Mesh 4.0

Here are different question :

1) Is it relevent to use the Mesh SDK ?

2) Are there any model that match sensor application to send "large" data ?

3) What is the comsuption in power of a basic node  that transmit data ? (And the standard consumption of a friend node using Low Power node ?)

4) IS it better to create mutliple server node and one client node OR Control model ( both server and client ) acordingly to mesh spec. ?

Parents
  • Hi,

    1) It may or may not be a good choice to use Bluetooth mesh for this, depending on the requirements. If you use Bluetooth mesh then our nRF5 SDK for Mesh is the correct SDK to use for developing an application on the nRF52 series devices.

    2) Bluetooth mesh is not particularly well suited for large amounts of data. What amount of data are we talking about, what is the throughput per node and what is the throughput in total?

    The Bluetooth mesh specification restricts the number of messages originating from a single node to max. 100 messages during a sliding 10 seconds window. Messages can be sent as multiple packets, up to 32 packets for a total message payload of 380 bytes.

    In practice there is a big difference in throughput between acknowledged and non-acknowledged messages, and depending on number of nodes in the network. How many nodes do you have, and is it required for the application on the sensor side to know if messages has been correctly received in the other end?

    3) Power consumption depends on usage. Most nodes need to be in RX mode all of the time not used for TX. This means power consumption is equal to being in constant RX mode, which can be read directly from the Product Specification of the nRF device used. Low Power Nodes have lower consumption, as they only needs to use the radio on set events (for receiving messages) or if they have themselves something to send. There are some numbers for LPN in this thread: Bluetooth Mesh Low Power Node.

    4) In Bluetooth mesh, the state (such as sensor readings) exist in a server model. The state can be set or read from a client model. That means if you have a mesh node who is also a sensor, that node would typically have a sensor server model. It can periodically publish status messages containing the current sensor value. The node receiving the sensor models will be a client. A control model, on the other hand, is a model that acts both as client (to some nodes) and server (to some nodes). Typically a control model performs complex calculations such as regulating heating in a room based on sensor readings from thermometers, occupancy senosors, time of day, etc. If you do not need any nodes that do that kind of decisions and control, then you do not need any control models. If all you need is to relay data, then you should address messages directly from the sensors to the device collecting the sensor data. (Messages will get resent through the network and arrive at the collecting device.)

    Regards,
    Terje

  • Thank you for your answer !

    If all you need is to relay data, then you should address messages directly from the sensors to the device collecting the sensor data. (Messages will get resent through the network and arrive at the collecting device.)

    About 4) If all the server are linked directly to one device won't there be any synchronisation problem ?

  • Hi,

    I am not sure if I 100% understand what you mean, but:

    • The network topology is not using direct links, rather messages are automatically resent through the network until they reach the destination. There is no active synchronization, but throughput is throttled to prevent congestion.
    • If multiple elements publish to the same group address, elements subscribed to that group address can see which element sent the message from the source address of the message.

    Regards,
    Terje

Reply
  • Hi,

    I am not sure if I 100% understand what you mean, but:

    • The network topology is not using direct links, rather messages are automatically resent through the network until they reach the destination. There is no active synchronization, but throughput is throttled to prevent congestion.
    • If multiple elements publish to the same group address, elements subscribed to that group address can see which element sent the message from the source address of the message.

    Regards,
    Terje

Children
No Data
Related