• State Resolved
  • Locked Locked
  • Replies 4 replies
  • Subscribers 52 subscribers
  • Views 1925 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.

Data rate (throughput) in SPP by changing scheduler period

Ankur Agrawal
Prodigy 50 points
Other Parts Discussed in Thread: MSP430F5438A

Hi,

I am using SPP to transmit a large file over Bluetooth from a mobile app to MSP430F5438A (the file is written on an SD card in chunks as data packets are received). BT UART is running at the maximum possible baud rate of 921600 bps (~115.2 kB/s). Due to RAM constraints, the frame (and RX buffer) size is fixed at 800 bytes. As I receive one data packet, I write that data on to the file on SD card, and then send an acknowledgement byte to the mobile app to send the next chunk of data. This way, I am able to send a file of size 600 kB. However, the time it takes to accomplish that is around ~40 seconds, which seems a lot high for a baudrate of 115.2 kB/s, even after considering overhead of acknowledgement bytes. The system clock as well as SPI clock is 20 MHz

Now if I look into the variable SchedulerInformation[0] in debug mode, I see there is a non-null value for SchedulerInformation[0].SchedulerFunction with SchedulerInformation[0].ScheduleExpireCount = 50. My understanding is that there is a function added to the scheduler by default with schedule period of 50 ms (I did not add any function to the scheduler),  and this is the function that is being used for polling the RX buffer. This hypothesis also conforms to the math:

Number of data packets = 600*1024 bytes / 800 bytes = 768,

Time to receive those packets = 768 * 0.050 s = 38.4 s (~ 40 s)

Here are my questions:

1. Is my understanding correct? If yes, is it possible to reduce the schedule period of the default function polling RX buffer during data transfer to get faster data rates? Or perhaps have something similar to interrupts for data RX.

2. If my understanding is not correct, why is the data rate so low compared to the actual baud rate, and what are ways to obtain faster data RX/TX?

Thanks.

Ankur Agrawal

  • 0 in reply to Miguel
    Prodigy 50 points

    Hi Miguel,

    Many thanks for the link. Not only was I able to achieve throughput rates as mentioned in the wiki, I also learnt that I had implemented a redundant flow-control scheme with back-and-forth communication between my MSP430 and mobile app. It was completely unnecessary. 

    Now although I am quite satisfied with the throughput rates, I'd really appreciate if you could answer a few more questions (or direct me to appropriate resources):

    1. What exactly do the variables MaximumFrameSize, ReceiveBufferSize and UART Buffer sizes mean?

    2. Are the parameter values for maximum throughput mentioned on the wiki optimum in the sense that no other parameter combination exists for an even higher throughput? If yes, how were these values obtained? If no, should I keep trying to achieve better performance?

    3. I am assuming this wiki page corresponds to the Default MTU (335 bytes) library. Is there any similar resource for Large MTU (800 bytes) library? (I tried Large MTU library with these values and the performance was actually worse).

    4. Lastly, back to my original hypothesis on a polling function in the scheduler, which was completely wrong - So what is this function that I see running in the scheduler with a period of 50 ms in SPPDemo?

    Thanks again.

    Ankur

  • 0 in reply to Ankur Agrawal
    TI__Intellectual 2360 points

    Ankur,

    "1. What exactly do the variables MaximumFrameSize, ReceiveBufferSize and UART Buffer sizes mean?"

    Max frame size controls the MTU used for the RFCOMM (the underlying protocol that SPP uses) L2CAP connection. It hast to be less than or equal the max stack MTU. The transmit and receive sizes control how large the internal allocated buffers are within the Bluetopia library. Larger buffers means the application can interact less with the Bluetopia library code which could reduce overhead and improve performance, even if only slightly. The UART buffer sizes are specify how much data is buffered in HCITRANS.c by the UART driver.

    "2. Are the parameter values for maximum throughput mentioned on the wiki optimum in the sense that no other parameter combination exists for an even higher throughput? If yes, how were these values obtained? If no, should I keep trying to achieve better performance?"

    The tests performed weren't exhaustive. You might be able to improve the performance but I don't think you will see any significant differences.

    "3. I am assuming this wiki page corresponds to the Default MTU (335 bytes) library. Is there any similar resource for Large MTU (800 bytes) library? (I tried Large MTU library with these values and the performance was actually worse)."

    There's aren't any test results available for the larger MTU testing. I would expect improved performance with the larger MTU library, however, it also depends on the over-the-air packet type negotiated by the 2 radios. If a packet type is used that only accepts small payloads, then having a large MTU could decrease performance. On the other hand if a packet type is used that supports a large payload then a large MTU would improve performance. There is a list of all of the possible packet types and the payload sizes of each in section "6.7 PACKET SUMMARY" of the Bluetooth Core 4.0 specification. Please have a look. You could try to change the packet type with the HCI_Change_Connection_Packet_Type() API function, although the packet in use is probably already the best that is supported by both radios. Unless you are always going to connect to the same type of device which would always result in the same packet type being used, the safest solution would probably be to choose an medium sized max frame size, referring to the table in the spec, try using the size of a 3-DH3 packet, less 4 for the L2CAP header, so 548. Be sure to use the large MTU library if you try this.

    "4. Lastly, back to my original hypothesis on a polling function in the scheduler, which was completely wrong - So what is this function that I see running in the scheduler with a period of 50 ms in SPPDemo?"

    The function you see running at 50 milliseconds is an internal Bluetopia function which manages any timers within the Bluetopia library or the application.

    Thanks,
    Samuel

  • 0 in reply to Samuel
    Prodigy 50 points

    Thanks for the detailed answers!