BLE mesh custom model message receive interval

[yogeshiggalore]

Hi, 

I am using two Nordic boards running custom client and server models.
The board running custom client model is sending 138bytes of data, which is being received by the board running the custom server model.

I calculated the time interval between reception of each 138byte packet on the server model, and found that it is 1.5 secs.

This is too much and I want to reduce this to be under 0.5 secs.

Kindly suggest how I can send and receive data packets via BLE-Mesh faster & in a more optimal way.

If you can suggest a sample program or example, it would be better.

Thanks

[AHaug]

Hi, 

Solely based on a couple of assumptions and computations it seems like 1.5seconds is a bit high for that time interval. Each pack has a payload of 11 bytes, meaning you will need 13 packs to send one message consisting of 138 bytes. Maximum frequency is 50 packs / second so it should result in something like 3-4 messages / second. So depending on other factors such as the number of jumps in the network it should be possible to reduce the time lower than 1.5 seconds.

I will have to confirm some details with the mesh team before I can come back with anything conclusive, but in the mean while could you give me some information about the following:

• Are you running NCS? If so, what version of the SDK are you running?
• Are you basing the custom models in your application on any existing nordic sample?
• Can you provide a minimal sample that we can use to recreate the issue (including configuration files)
  • Remember to not add any sensitive information in the provided sample if you end upp attaching the sample

Kind regards,
Andreas

[yogeshiggalore]

thanks, Andreas for a quick reply. 

I also did the same analysis as you did. 

currently, I am using 1.9.1 and planning to move it to 2.0.2 in the coming days.

yes based on nordic sample code I have developed custom models.

since it involves customer permission and I am not supposed to share any code related to that. 

need your help in changing adv interval in ble mesh prj.conf  

is any method to available improve throughput?

. 

[AHaug]

Hi,

yogeshiggalore said:

since it involves customer permission and I am not supposed to share any code related to that. 

That is understandable.

Can you share some more information about your network topology and configuration?

• How many nodes do you have in your network?
• How many jumps is it expected that your message will perform?
• How large is the physical range of your network, i.e how large does it stretch from one end to the other?

Under the section "Relay" on our documentation pages, you can see some reasons for why the transport time is so long. I don't necessarily think that the size of your network is what causes the long transport time, but it should be nice to clarify if that is whats causing your issues.

yogeshiggalore said:

is any method to available improve throughput?

One option to use in NCS v2.x is to use CONFIG_BT_MESH_ADV_EXT, albeit with some care. The extended advertisement is not experimental in NCS v2.x BLE but it is not yet verified verified to be stable for use with Bluetooth Mesh.

Kind regards,
Andreas

[yogeshiggalore]

thanks Andreas, 

Apology could not able replay back due to other priority work. 

AHaug said:

• How many nodes do you have in your network?
• How many jumps is it expected that your message will perform?
• How large is the physical range of your network, i.e how large does it stretch from one end to the other?

Currently, we are planning to have 100 nodes in a network, it may extend to 500 but not more than that. 

max1 or 2 hop is what I am planning as of now. (algo will decide first fit node to transfer firmware)

you can say 70 or 80 feet.

I am using 1.9.1 and planing to move to 2.0.2 in comming days. 

[AHaug]

Hi,

Apologies for the late response. I've been out of office on business travel for the past few days and will be for the two next weeks as well. I will do my best to find a colleague to handle your case for that duration. 

Kind regards,
Andreas