CC2640R2F: YFV (WCSP): BLE throughput observations and questions

Hi,

I have asked a colleague to comment.

In the meantime, you may want to review BLUETOOTH CORE SPECIFICATION Version 5.3 | Vol 6, Part B, §4.1 for details on the frame space.

Best regards,

Hi Tony,

I apologize. Clement assigned this thread to me and it fell to the bottom of my list. It was recently flagged and brought back up, and I'll be more than happy to help you now. Let me know if you're still at this phase of development or if you've been able to progress since you've posted.

Tony Kobet said:

1) It's my understanding that, according to the BLE spec, within a connection interval, packets are to be separated by 150us.  The logs show a very consistent 230us gap between the central's empty PDU and the peripheral's response packet, and then a 430us gap between the peripheral's data packet and the next empty PDU from the central.  Is this to be expected?

The T_IFS you're referencing is in the BLUETOOTH CORE SPECIFICATION Version 5.3 | Vol 6, Part B, §4.1 as Clement says. Is it possible the timing you're experiencing is the time from start of a packet to the start of the next packet, not the end of the first packet to the start of the next packet as the T_IFS refers to?

Tony Kobet said:

The peripheral does not seem to respect the MAX_NUM_PDU value.  At the beginning of the transfer, it is common for 20+ packets to be sent in one connection interval.  Is this normal BLE stack behavior?

MAX_NUM_PDU refers to the maximum number of buffers allocated by the host to send the controller inside each BLE device. It does not have to do with how many packets are sent in a connection interval.

Tony Kobet said:

3) How much, and what kind of difference can it make if there are multiple wifi networks or other RF sources in the area when running BLE downloads?  When running in our development lab or the customer's lab, the download rate slows over time, but always completes.  When running at the board manufacturing facility, the download never completes.

This does not surprise me greatly. Manufacturing environments are notoriously noisy from an RF perspective. You can improve your device's performance by bringing the two BLE devices closer together, shielding them from noise with a Faraday cage or changing to the coded PHY.

Tony Kobet said:

4) When the download slows over time, the logs do not show errors, but fewer packets are sent per connection interval as the download progresses.  Toward the end of the download, only 5 or 6 packets might be included in a given interval.  In the last packet in the connection interval, the More Data field within the BLE Link Layer Data Header is set to false, indicating there is no more data to send, but the download might be only 80% complete.  Since the firmware is running the same loop reading from flash and calling GATT_Notification, I am not clear on why the application would only be able to get 5 or 6 records out during the connection interval when it was sending 20+ early in the download.  I have had issues in the past where the download would slow down due to a memory leak and heap exhaustion, but that issues was addressed, and this does not seem to be the case here since the download can be repeated immediately and the performance is the same (fast start, slow finish).  If there were a heap issue, I would expect subsequent downloads to start out slow and eventually fail.

I don't have an immediate answer for this now. Tell me if it is still a problem and I'll be happy to investigate further.

Thanks, Nathan.  Throughput performance is something we'd like to understand better, but the product is in the field and throughput as it stands is acceptable, though not great.

Nathan Block said:

Is it possible the timing you're experiencing is the time from start of a packet to the start of the next packet, not the end of the first packet to the start of the next packet as the T_IFS refers to?

Yes, that's entirely possible since I misunderstood the documentation.  Thanks for straightening me out on that.  Based on a 1 MB data rate and the number of bytes in the packets, the gap seems a little short, but it is consistent.

The slowing downloads over time is a problem, but not a showstopper.  It is worse in noisier environments and when signal strength is weaker.  I need to revisit the issue in light of my misunderstanding of the MAX_NUM_PDU setting.  There are some experiments I need to run involving retrieving each packet's content from external flash and queuing for transmission.  If there is no general issue that you're aware of that could be leading to the behavior, I would say you can stand down until we investigate further.

One other question, though - I have not looked at this for a couple months now, but I was looking into a way for the firmware to monitor the status of the BLE stack as it got packets off the device over the air, to see if packets were getting backed up so the firmware could perhaps throttle back on submitting packets for transmission.  I was not able to find any such status.  Do you know of a way to do this?

Hi Tony,

Have you seen the BLE throughput example? It's located in the github here, and it may have features that you can mimic to see if the problem is your device. You could also set a counter for every byte your device receives to make sure you're not receiving empty packets, but I think overall it would be smartest to use a packet sniffer if you have access to one. This can help us understand better if the problem is with the wireless portion or with your receiver's software. See if many packets are being resent over due to errors.

Nate

I looked at the throughput example, and our firmware is similar in how it gets packets off the board, but I have not actually run that example.

We use Wireshark as the sniffer software; this how we got the trace in the original post in this thread.  The trace does not show any packet retransmissions, but I have not looked into whether Wireshark can be configured to show more low-level detail.  I'll need to figure that out and rerun some tests.

Sounds good! Let me know when you have more details. Open a new thread and reference this one if you have a separate question. This helps us organize our site better for future users.

Best,

Nate