nRF5340 Mesh data transfer speed slow?

[JobMeulenbeld]

I am currently researching the capabilities of Bluetooth Mesh with the nRF5340 DK. I have two DK's which are communicating over Mesh where one sends data (20 bytes) to the other. I turned retransmissions off. I have read on this forum that the speed of Mesh should be around 3.4 kb/s. I can send these 20 bytes with an interval of 200 ms without issue, but when the other DK is receiving the data, there are gaps (missed packets).

On the right is the correct sequence of packets being sent. On the left there is a consistent gap of 6 packets. Which indicates that it takes around 1.2 seconds to handle a packet of 20 bytes (133 b/s)?

 

I tested this with a buffer of 100 bytes as well, this resulted in gaps of 17 packets. Thus indicating that it takes around 3.4 seconds to handle a packet of 100 bytes (235 b/s)?

Maybe I am doing something wrong since I am not getting near the indicated transfer speed. Any tips?

Kind regards,

Job

[Elfving]

Hello Job,

Are you saying this communication is just happening with one hop, from one 53DK to the other?

BLE Mesh relies on it being able to relay. One reason for this is to make sure that the messages spread around the network, but another is to make sure that the package is received, as one node can't be continuously scanning in order to get 100% of the packets around. I would recommend having a few nodes that relay as well, that should make the number of lost packets decrease. 

Though for the same reason (the need for additional nodes to relay) it is hard to estimate the throughput in a Mesh network. All of a sudden you might be dependent on a packet that took a strange route in the network. That is why throughput is seldom the focus in BLE Mesh, as you would most often use it for situations where there is relatively little traffic). Mesh can handle large files, but that would usually take a while (a mesh DFU typically takes a few hours). Though with the new BLOB transfer server and recent additions to Mesh v1.1 there is a bit more support for this available now.

I do not know any number for the throughput through a Mesh network. Though from node to another there is always the "100 packets per each sliding window of 10seconds" rule. 

Regards,

Elfving

[JobMeulenbeld]

Hello Elfving,

Indeed, in the setup I used 2 53dk's to send data to each other. I am currently using the same 53dk to send data to multiple nrf52 mcu's, but the same issue persists. I can't send a message of 20 bytes quicker than at an interval of about every second. This seems very slow to me.

Something interesting what I noticed:

The sender listens to its own messages (subscribed to the group it sends to). Whenever it receives its own message a self made callback is called (message sent). What I thought is that this was a smart way to know when the device is done sending and ready to send another message since it has fully received its own. This however is not the case. If I use that callback to immediately send a new message, the sender misses its own message. But if I send it with a 1 second delay beforehand, everything works fine.

My question now is:

1. How do I know when a message is fully received and the device is ready to receive another?

2. Is there a way to increase the "message handling" speed of the device? Because taking about 1 second for 20 bytes seems too slow for me.

[Elfving]

Sorry about the wait Job, I've been away for a while.

JobMeulenbeld said:

I can't send a message of 20 bytes quicker than at an interval of about every second.

There is something I am probably misunderstanding here. The impression I got from you previous querie was that there was issues getting all the packages to be recieved. 

I can send these 20 bytes with an interval of 200 ms without issue

I tested this with a buffer of 100 bytes as well, this resulted in gaps of 17 packets.

So you have no issue sending these packets (neither 20bytes or more), though at one point you are dropping packets? Or are you saying this is a new problem you've just noticed?

JobMeulenbeld said:

What I thought is that this was a smart way to know when the device is done sending and ready to send another message since it has fully received its own.

You wouldn't have to add this extra logic to the application side. The stack should fix this for you.

JobMeulenbeld said:

1. How do I know when a message is fully received and the device is ready to receive another?

You can use acknowledged messages if you want, though this will add to the network load.

JobMeulenbeld said:

2. Is there a way to increase the "message handling" speed of the device? Because taking about 1 second for 20 bytes seems too slow for me.

Could you explain again the issue you are seeing here?

Regards,

Elfving

[JobMeulenbeld]

Hello Elfving,

Elfving said:

The impression I got from you previous querie was that there was issues getting all the packages to be recieved

The packets that are not received is a result of my issue. What I am encountering is that when I send packets with a size of 20 bytes, it takes some time (1.2 seconds) to process the packet before it can receive a new packet. If a message is send to the same receiver during that period, the packet is lost.

Elfving said:

So you have no issue sending these packets (neither 20bytes or more), though at one point you are dropping packets?

If I have a large enough interval between the packets, there is no issue in sending/receiving the packets. The issue occurs when I want to send data more frequent, then the packet loss starts to occur.

Elfving said:

You can use acknowledged messages if you want, though this will add to the network load.

Hmmm, with the current issue that I am facing, that does not sound appealing.

Elfving said:

Could you explain again the issue you are seeing here?

So the problem for me is that I use Bluetooth Mesh to send data to other nodes. When the data size increases, the message handling time (time to process the message) increases as well. This is logical in my opinion, but it already occurs when I want to send 20 bytes. Receiving the 20 bytes and processing them takes around 1.2 seconds which seems very slow to me since it is just 20 bytes right? Or is this expected behavior. I thought that a Mesh message would send a 20 byte message in a couple of milliseconds, not seconds.

I hope this clears up my question. If you need more information, please let me know.

With kind regards,

Job

[Elfving]

I see. Well 1.2seconds is rather long for it to be processing.

I just realized that 20 bytes is high enough to be a segmented message. 3 packets in total acctually. Bluetooth Mesh packet sizes are 15 bytes for unsegmented messages. If you want to try this test a bit more bare-bones you can try to send something shorter than 15 bytes. So one thing to note is that you are acctually sending two messages. Though this doesn't really explain what you are seeing. Being a segmented message, the packets needs to be ACKed as well. 

My guess is that the message doesn't get sent because the previous one isn't finished or unACKed. 

Could you try sending <12bytes and see if you are seeing the same thing? And could you send me the code that you are trying to run? Maybe there is some error being returned that you are not checking.

JobMeulenbeld said:

So the problem for me is that I use Bluetooth Mesh to send data to other nodes. When the data size increases, the message handling time (time to process the message) increases as well. This is logical in my opinion, but it already occurs when I want to send 20 bytes. Receiving the 20 bytes and processing them takes around 1.2 seconds which seems very slow to me since it is just 20 bytes right? Or is this expected behavior. I thought that a Mesh message would send a 20 byte message in a couple of milliseconds, not seconds.

I don't really know what to say regarding throughput, as that would depend on a lot of factors. Though the "100 packets per each sliding window of 10seconds"-rule being a limitation should give you some idea about it. So processing a message for 1.2seconds doesn't sound right.

Regards,

Elfving

[JobMeulenbeld]

Hello Elfving,

Elfving said:

If you want to try this test a bit more bare-bones you can try to send something shorter than 15 bytes

I have tested it with different sizes, this time on an nRF 52840, but the problem persists:

- (4 bytes): Works perfectly with an interval of 200 ms

- (10 bytes):  receives 1 out of 4 messages with an interval of 200 ms ( 800 ms per message)

- (20 bytes): Just as before, 1 out of 6 messages with an interval of 200 ms (1200 ms per message)

I have attached the project that I am running. Perhaps you will see something that I am missing 

Nordic_Devzone.zip

The program can be used as listener and sender. Just comment out the looper thread, then it will just listen to the sender.

[Elfving]

JobMeulenbeld said:

- (4 bytes): Works perfectly with an interval of 200 ms

- (10 bytes):  receives 1 out of 4 messages with an interval of 200 ms ( 800 ms per message)

I find it particularly odd that you see a diffence here. No matter the issue, this should essentially be the same test.

Thanks for sending the project. What NCS version are you using for it?

Regards,

Elfving

[JobMeulenbeld]

Elfving said:

What NCS version are you using for it?

I am using the Connect SDK V2.5.2