• State
  • Locked Locked
  • Replies 7 replies
  • Subscribers 52 subscribers
  • Views 3514 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

Simultaneous BLE (custom SPP) and Br/Edr (regular SPP)

Martin Bertsche
Prodigy 250 points
Other Parts Discussed in Thread: CC2564

We are currently encountering some problems when simultaneously communicating with an iOS device (custom SPP over GATT) and an Android device (regular SPP).

This information might be helpful to answer our question: Both the Br/Edr device and the BLE device are bonded: For BLE we use IRK to resolve iOS's ever changing addresses, and LTK for encryption. The bonding processes work flawlessly for both standards. For Br/Edr the Android devices initiate the connection to our device.  As soon as the connection is established our device tries to assume the master role in the connection (this never failed so far in our tests, if it would we would disconnect the BrEdr device). To do that we use some code from the SPPLE example. For BLE connections we make the iPhone behave like a peripheral, so the iPhone advertises and our device initiates the connection assuming the master role by default. Secuity is successfully reestablished using the information stored in our bonding structure. The BLE connection parameters are set to use the minimum connection interval (I believe that this means a 7.5 ms interval), these parameters are acknowledged by the iOS device. Our SPPLE implementation uses notifications to get data from the iPhone to our device. Our device uses write without response to send data to the iPhone. The application protocol is designed for the limited data rates of BLE. We can see that we are using only about 10% of the connection events to transmit something when looking at the communication between host and CC2564B. Our goal is to support a combined total of up to 4 BR/EDR and BLE devices. So the distributions migt be (4/0, 3/1, 2/2, 1/3 and 0/4). 

Problem: Our problem is that if an android device is connected via (Br/Edr SPP) and an iPhone is connected via our custom SPP over BLE/GATT, the BLE side becomes unstable when we start generating traffic. Please don't misunderstand: There is also traffic right after the connection. Our device sends a message every second to each connected device. The connected devices do the same. This works with high stability. BLE alone without Br/Edr connections also works very well. The same holds for 4 simultaneous Br/Edr connections. It seems to be the combination of the two that messes things up.

So what does unstable mean? Well, on the iOS side we are still able to send notifications, so the iOS bluetooth stack still thinks it is connected. On our device's side we are still able to issue write without response calls to Bluetopia without error, so Bluetopia still thinks it is connected. However, neither the iPhone nor our device receives any of the data sent by the other side. The Android (Br/Edr) device still communicates without problems. After 10 s our application disconnects from the BLE device due to inactivity. If the iPhone is still in range and advertising, our device will try to re-initiate the connection. The connection attempt succeeds but when reestablishing security with the iPhone the process stalls and fails after 30 seconds with a "disconnected" error. Only a reboot of our device, which includes a reboot of the CC2564 is capable of fixing the issue. I am open to any suggestions about what might be causing the problem.

Our debugging attempts: We thought that such problems might be related to UART driver problems. We have our own UART driver implementation which we use to implement Bluetopia's HCITRANS.h interface. So we thought mabye we did something wrong there, and replaced our implementation with the one from the Bluetopia examples. This did not solve the issue. Unfortunately we have no HCI protocol analysis tools to dig any deeper.

My current theory: My current theory is that due to the minimum connection interval of 7.5 ms the CC2564B is not capable of maintaining that interval if a BR/EDR device is connected as well. Are there any known limitations that I have to account for when choosing the connection parameters for BLE especially when there are multiple simultaneous Br/Edr connections?

  • 0
    TI__Mastermind 32615 points
    Hi,

    1. Are you using the latest Bluetopia SDK? and what is the host processor?
    2. Are you using the latest Service pack? as there are many BLE stability and few connection patches, see processors.wiki.ti.com/.../CC256x_Downloads


    3. If you are using the latest SDK and SP, and still see the issue (which should not be the case), then can you try with any other remote device other than iPhone (what is iOS version you are using?)
    4. If you still face the issue, try with minimum connection interval of 8 ms?
  • 0 in reply to Sundeep Javvaji
    Prodigy 250 points

    Hi Sundeep,

    1. Yes
    2. Yes

    3. It is not so easy for us because we would need to develop the application or at least parts of it on another platform e.g. Android.
    4. We will do that first.

    Regards

    Martin

  • 0 in reply to Martin Bertsche
    TI__Intellectual 2360 points

    Martin,

    Nice detailed post. A few questions:

    1. What are you setting the min and max connection event lengths to? If you are using the min connection interval of 7.5 milliseconds and setting the connection event length to the max ("the lesser of 10 ms and (connInterval - 1.25 ms)" per spec), BLE will saturate the link. Not sure the CC256x even uses the Minimum_CE_Length and Maximum_CE_Length parameters, the spec doesn't define how they are used, assuming they are recommendations for the value of transmitWindowSize. I'll check on this. Nevertheless, in this situation the BLE link should use all of the bandwidth, but you said you are seeing the opposite.

    2. What's the need for this small connection interval? If it won't affect the performance of your application, I recommend increasing the connection intervals to something much larger than the minimum, this is especially important for multiple connection environments. If all connections are set to the minimum connection interval the radio won't have time to service all of the connections. Increase it as much as possible.

    3. Do you see the problem with only 1 BR/EDR and 1 BLE connection, or do you need 2 BLE connections to reproduce? A problem was seen before when 2 BLE connections both used the same connection interval, only of the devices could send and receive packets. If you see the issue with 2 BLE connections I recommend giving each connection a different connection interval, and have the intervals not be multiples of each other. For example use 200 milliseconds for one interval and 190 millisecond for the other. This issue should be resolved in the latest service pack, but this would be a good test to see if it, or some variation of it, still exists.

    Thanks,

    Samuel

  • 0 in reply to Samuel
    TI__Intellectual 2360 points

    Martin,

    I checked and the Minimum_CE_Length and Maximum_CE_Length aren't used by the controller. You can disregard my comments in item 1.

  • 0 in reply to Samuel
    Prodigy 250 points

    Hi Samuel, hi Sundeep,

    we played around with a variety of settings for the connection interval, many of them even longer than you suggested, however this did not help so far. The connection stays unstable.

    Today we got our hands on a pretty high end Bluetooth testing device from ellisys called the "Bluetooth Explorer 400". We are simultaneously monitoring the communication between Host and CC2564 B, and between CC2564 B and iPhone 6 (iOS 8.1.3) and an Android Galaxy S5. Please see the diagram in the screenshot below.

    So far we can see that everything works fine on the HCI layer. However on the Low Enery LL Layer we can observe the exact moment when things break with the iOS device. On the HCI side a Write request is issued to the CC2564 B, on the LL Side an ATT Write Command Packet procedure begins. The CC2564 B tries to send data to the iOS device. We see an awful lot of retries for this. The reason is obvious, because according to the Sniffer, the CC2564 B is using an incorrect MIC/CRC. The iPhone does not respond to these messages.

    We would like to send you the actual log data for your reference but it contains information that we cannot share here. Could you contact me so I can send you the log file. You will also receive a link to the sniffing software that opens the file.

  • 0 in reply to Martin Bertsche
    Intellectual 310 points
    Martin,

    Thanks for sharing the logs. This looks like very useful information. I'll reach out to you within the next few business days to download the actual logs and decoders.

    Thanks,
    Samuel
  • 0 in reply to Martin Bertsche
    TI__Intellectual 2360 points
    Hi Martin,

    I've sent you a friend request so that we can start and private conversation and send the log file.

    Thanks,
    Samuel