CC2564 transfer rate

Hi , Your query has been assigned to BT expert. We will get back to you shortly
Saurabh

Hi,

This transfer rate is dependent upon the host (MCU) speed and the baud rate of the UART between Host and the CC2564. This is not part of the BT specification since large part of this is HW/UART peripheral dependant. Since this data is transferred over the SPP profile, it will be parsed at different layers of the BT stack. The processing required for this parsing adds little bit to this time.

Increase the HCI baud rate between the MCU and the CC2564 will help reduce this time. The CC2564 can support as much as 4Mbps.

Best regards,
Vihang

Hi, Vihang.

Thank you for reply.

I'll make sure to change the baud rate of the UART of MCU and CC2564.
Do you raised the transfer rate in the setting change of BT Stack side?

I want to improve to about half the current communication time(about 17mS).

Best Regards.
hamada

Hi, Vihang

I want to interact with detailed content.
Please let me direct contact.

Best Regards,
hamada

Hi, Vihang.

I have carried out additional checks.

●Confirmation method 1

・32bit data transfer from PC (on Teraterm)
・We measured the time in the following point.

　(4)Server UART TX ---- Server UART RX


●Check result 1
　1st : 23.0mS
　2nd : 34.0mS
　3rd : 16.4mS
　4th : 31.0mS
　5th : 29.0mS


Q1)
There was a difference in arrival time of the data despite the same environment.
The reason why the arrival time is different, Could you tell me a view?




●Confirmation method 2
I have confirmed the operation to change the UART baud rate between the CC2564 and Tiva (Host).
However, it can not be implemented Bluetooth communication with the following error occurs.

==================================================================
Initialization Complete.
OpenStack().
HCI_VS_InitializeAfterHCIReset
VS_Update_UART_Baud_Rate success.
HCI_VS_InitializeAfterHCIReset Success
Bluetooth Stack ID: 1
Device Chipset: 4.1
BD_ADDR: 0x0017e9e57ca6

******************************************************************
* Command Options: Server, Client, Help *
******************************************************************

Choose Mode>client

******************************************************************
* Command Options: Inquiry, DisplayInquiryList, Pair, *
* EndPairing, PINCodeResponse, PassKeyResponse, *
* UserConfirmationResponse, *
* SetDiscoverabilityMode, SetConnectabilityMode,*
* SetPairabilityMode, *
* ChangeSimplePairingParameters, *
* GetLocalAddress, GetLocalName, SetLocalName, *
* GetClassOfDevice, SetClassOfDevice, *
* GetRemoteName, SniffMode, ExitSniffMode, *
* Open, Close, Read, Write, *
* GetConfigParams, SetConfigParams, *
* GetQueueParams, SetQueueParams, *
* Loopback, DisplayRawModeData, *
* AutomaticReadMode, SetBaudRate, Send *
* Help, Quit *
******************************************************************

Client>Inquiry

Client>
Inquiry Entry: 0x00225832542e.

Client>
Inquiry Entry: 0x0022583b47de.

Client>
Result: 1,0x00225832542e.
Result: 2,0x0022583b47de.

Client>SetBaudRate 3
VS_Update_UART_Baud_Rate(3): Success.

Client>Inquiry

Inquiry Failed: -14.
Function Error.

Client>
====================================================================

Q2)
　How can I eliminate this error and communicate?


Best Regards,
hamada

Hi, Vihang.

How about this case?

I especially want to know the following.

1. Specification of the communication speed of the experimental results is Bluetooth SPP (TI Bluetooth Stack)?
2. If it is not a specification, Setting change in the Stack side. Can speed improvement be done?

I need your help!!

Best Regards,
hamada

Hi, Vihang-san

Thank you for reply!!

I am sorry.
Please also tell us about the next two points.


3.
>2. Yes please see the link above.

>The error "Inquiry Failed: -14." that you are getting is due to an error in the HCI transport after using the SetBaudRate command.
>BTW, when the SPPDemo is loaded on the DK-TM4C129X, the baud rate is automatically set to 921600 bps.
>Please see the VENDOR_BAUD_RATE macro in the HALCFG.h

I have confirmed the VENDOR_BAUD_RATE of HALCFG.h.
VENDOR_BAUD_RATE is 921600L was defined.
Still error has occurred.
Are there any factors in the other?


4.

>●Confirmation method 1

>・32bit data transfer from PC (on Teraterm)
>・We measured the time in the following point.

>　(4)Server UART TX ---- Server UART RX


> ●Check result 1
>　1st : 23.0mS
>　2nd : 34.0mS
>　3rd : 16.4mS
>　4th : 31.0mS
>　5th : 29.0mS


> Q1)
> There was a difference in arrival time of the data despite the same environment.
> The reason why the arrival time is different, Could you tell me a view?

About arrival time of the data, I have to validate several times.
There are variations in the results in arrival time.
Could you comment on here?


Best Regards,
hamada

Hi Hamada,

3. Not quite sure why the error occured. But the point I was emphesising on is that there is no need to increase the baud rate to 921600 since the default baud rate after initialization is already set to this value.

4. As defined in the Bluetooth specification, the SPP uses asynchronous (ACL) data. Since it is asynchronous data transfer, the data events do not have to occur exactly at a predetermined time-interval. This feature is by design in the specs and it is one of the main reasons that allows us to have multiple profiles connected to multiple devices; all running on the same system without missing any data (there are other methods like CRC that contribute to this as well). So, I would not expect a constant arrival time for every instance in the first place.

Hope this answers your question.

Best regards,
Vihang

Hi, Vihang-san

Thank you for immediate answers!!

>3. Not quite sure why the error occured. But the point I was emphesising on is that there is no need to increase the baud rate to 921600 since >the default baud rate after initialization is already set to this value.

If set to VENDOR_BAUD_RATE is 921600L,
I understand that setting the baud rate is set to 921600bps.


>4. As defined in the Bluetooth specification, the SPP uses asynchronous (ACL) data. Since it is asynchronous data transfer, the data >events do not have to occur exactly at a predetermined time-interval. This feature is by design in the specs and it is one of the main >reasons that allows us to have multiple profiles connected to multiple devices; all running on the same system without missing any >data (there are other methods like CRC that contribute to this as well). So, I would not expect a constant arrival time for every >instance in the first place.

OK.
For the variation of the data arrival time,
I understand that the Bluetooth specification.


If there is a question,
Please let me questions again.


Best Regards,
hamada

Hi,

Sure.

But I do ask you to open a new thread everytime there is a new question. It makes tracking easier for different questions. If necessary, you can link this discussion in the new thread for reference. Thanks.

Best regards,
Vihang

Hi, Vihang-san.

I am always grateful for your help.
I want to check with additional.

Attach the operation check the contents.

CC2564MODA_Operation check.xlsx

I transfer the data of 32byte from both the Server / Client,
It measured the arrival time.

Q5)

From the confirmation result,
Regardless of the data transfer from the Server/Client,
"Server UART TX to Client UART RX" is a large variation in the data arrival time.
※"Client UART TX to Server UART RX" has less relatively variations

Would you have any views on this matter?

I will wait for the reply.

Best Regards,

hamada

Hi, vihang-san

Because it was the question related to the previous content,
Continued questions.

I will wait for the response.

Best Regards,
hamada

HI, vihang-san.

Could you some kind of contact?
I am waiting for the contact!!

Best Regards,
hamada