• State Resolved
  • Locked Locked
  • Replies 11 replies
  • Subscribers 55 subscribers
  • Views 1939 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Original question:

RTOS/CC2640R2F: Example for continuous receiving data from a UART peripheral

RTOS/CC2640R2F: Simple Stream Server service Example uart RingBuffer size and packet loss

Jianlin Zhou
Expert 1230 points

Part Number: CC2640R2F
Other Parts Discussed in Thread: CC1310, CC2640

Tool/software: TI-RTOS

Hello,

I'm working on two CC2640 Launchpad and following the simple_serial_socket_server and simple_serial_socket_client code. I tested the demo mentioned in Git and could use a CC1310 to send data packet to the client through UART. The data packet is 204 bytes long with a packet label number in the head. The data rate is about 6.4k Bytes/s and Baud rate is set to be 115200. Due to large data stream, I set the ringbuffer size to be 204 which is my packet length. The first half of the data is increasing numbers and the second half of data is decreasing numbers which shows below:

I have tested the CC1310 directly connected to PC and there is no packet loss. However, when I connected to my CC2640 client, there will be packet loss on my PC which is connected to the server:

   The third column is packet number.

I tried to change the ringbuffer size which didn't help. And if change ring buffer size to be very large (2040 and 1020), I would get nothing on my server end. During experiment, red and green LED are always on which indicated noitying was enabled.

1. Could you please tell me, what would be the possible reason of this packet loss? Is it due to high UART data rate or notifying?

2. In your git readme, you mentioned that"If the amount of data sent over UART to the device exceeds UART_MAX_READ_SIZE plus the size of the ring buffer, data loss is probable. This is due to the internal UART ring buffer wrapping before the application has the chance to process the previous UART buffer. To be able to handle larger chunks of data, the size of the ring buffer can be increased inside the board file."

Why I could not get any data if I set it to a large number?

Thank you so much!

  • 0
    TI__Guru 57865 points
    Hi Jianlin,
    Have you tried to increase the ring buffer? Or changing parameters until it works, in order to isolate the issue?
  • 0 in reply to J Lindh
    TI__Mastermind 25810 points
    Along the lines of what Joakim mentioned, I think you may be transmitting faster than the BLE connection can support.

    Just to set a baseline, I would recommend seeing how much data (and at what speed) you can consistently receive on the BLE side without any modifications. From there, you can change your BLE settings. In particular, changing the connection interval should help with throughput but will lead to higher power consumption.
  • 0
    Expert 1890 points

    data loss could result from speed mismatch or interference from other ble/wifi devices. 115200 UART speed seem not high enough, or flow control should be considered as BLE could be faster than UART. this post provide some test result for the sss project.

    https://e2e.ti.com/support/wireless-connectivity/bluetooth/f/538/p/762845/2841440#pi320995=1

  • 0 in reply to ke fan
    TI__Mastermind 25810 points
    Any updates, Jianlin?

    I will close this thread for now. You may re-open this post by simply posting a reply. If the thread locks, just hit the "Ask a similar question" button and repost your question.
  • 0 in reply to Ammar N
    Expert 1230 points

    Hello Ammar,

    I was working on my GUI these days and I did some tests. I decrease my data rate to 4.8k Bytes/s(which was 6.4k) and then the packet drop is almost 0. I have a confusion about the "notification interval" and "connection interval".
    If notify is enabled and once my buffer is updated, the client should send the updated data stream. In this case, data rate should be limited by the notify interval and this should be shorter then my data refresh interval. Is it correct?
    If it is correct, how could I change the notify interval?
    If BLE data rate is still constraint by connection interval, what would be a proper way to modify conenction interval when notify is enabled?
    Thank you so much!


    Best,
    Jianlin

  • 0 in reply to J Lindh
    Expert 1230 points

    Hello J,

    1. For increasing ring buffer size:
    I tried to increase the ring buffer and this even gave me more strange result. When it goes up to 10 times of my packet length, I could not receive anything at desktop serial port end. I didn't make modify anyother parameters. This is why I asked "Why I could not get any data if I set it to a large number?". Have you observed this behavior before?
    2. I decrease my UART data rate to 4.8k Bytes/s and UART data packet drop ratio decrease to almost 0. I think that I may be transmitting faster than the BLE connection can support.


    Thanks,
    Jianlin

  • 0 in reply to ke fan
    Expert 1230 points
    Hello Ke,

    Thanks for your reply. I tested it with direct uart connection to desktop which doesn't have ant packet drop issue. I think my UART packet drop is due to my BLE throughput constrain with my connection interval setting.
  • 0 in reply to Jianlin Zhou
    Expert 1890 points

    notification could be sent as soon as possible directly in app event loop, without connection interval restriction.

  • 0 in reply to Jianlin Zhou
    TI__Guru 58425 points
    Hi Jianlin,

    Could you clarify if you mean that you are sending 200k (kilo) or 200 bytes of data over the UART . With a baudrate of 115200 bits/s, you could send roughly 14 kB of data per second.

    I've tested the example default throughput and clocked it around 11 kB/s average. As it depend on dynamic memory allocation, the performance will vary depending on how much available heap there is left for the application.

    There is also a limit to the number of packets you can queue up per connection interval based on MAX_NUM_PDU which put a limit to the number of notifications you can end per connection interval.
  • 0 in reply to IUsedToBeARealPerson (M-W)
    Expert 1230 points

    Dear M-W,

    I double checked my test setting and the actual data rate should be 6.4k Byte/s. 200k was my previous test parameter. Sorry for the wrong number and the confusion caused by it.

    1. For "I've tested the example default throughput and clocked it around 11 kB/s average. As it depend on dynamic memory allocation, the performance will vary depending on how much available heap there is left for the application." -- You are saying that in notify mode, if we want to acheive "better" or less packet drop performance, we have to reserve more memory space. Is this understanding correct?

    2. "There is also a limit to the number of packets you can queue up per connection interval based on MAX_NUM_PDU which put a limit to the number of notifications you can end per connection interval."  I check the MAX_NUM_PDU value in ble_user_config and it is set to be 5. According to your reply, does it mean that I could increase my BLE throughput by increasing this MAX_NUM_PDU to have more packet sent?

    If so, what would be the maximum number I could set? 

    If not, does it mean that this MAX_NUM_PDU 5 which is a universal number for all the connection interval? Or an alternate way to say it is that when notify is enabled, my connection interval has nothing to do with my Bluetooth data throughput? Then, what would be the maximum throughput when notify is enabled?

    3. Could you please tell me if I could or how could I fix my connection interval to garantee the throughput I need? Has it to be on "non-notify" mode?

    Thanks a lot!

    Best,

    Jianlin

  • 0 in reply to Jianlin Zhou
    TI__Guru 58425 points

    Hi Jianlin,

    (1) - What I'm saying is that the packets in this case is always dropped "before" the BLE side, which means that unless there is enough heap for allocating space for he received UART message, it will be dropped. If you are using the latest version of SSS, you will limit the amount of heap the stream profile will use (this is to guarantee that there is enough heap for the stack to operate). If this is the case, you should be able to find the line SimpleStreamServer_setHeadroomLimit(MIN_HEAP_HEADROOM) inside the SimpleSerialSocketServer_init() function. In this case, you could try to adjust MIN_HEAP_HEADROOM.

    (2) - In theory, maybe. It depends on the amount of available data (from the UART in you case). The way the example is designed (to be simple, not for maximum performance), it will only try to queue "up to MAX_NUM_PDU" number of notifications / connection event. Say this happens to be 5 notifications with 5 bytes (as the profile do NOT pack multiple list entries even if there is room in the notification), you would waste the whole connection event on only 25 bytes. 

    Now you are not limited to 5 / connection event as such, this is just the number of PDUs the stack can hold at one point. In the example, you can see that we each connection event perform a "SimpleStreamServer_processStream()" call to queue up new notifications. Being that it is implemented this way, it means that we do not queue up new notifications even if the stack frees up space as the transmit buffer empties. 

    (3) - So to the question, "How could you possibly improve the throughput". One quick test is to simply increase the PDU size (at the impact of RAM requirement in run-time), this does however only "post-pone" the "issue" as it is simply increasing the buffers.

    Another solution is to re-work how the "SimpleStreamServer_processStream()" function is invoked to be a periodic event rather then "on connection event". This means that you could try to periodically fill up the transmit buffers as times goes on, removing the "up to 5 per connection event" design limitation that exist today.