Broadcast not working correctly with cc2564 in peripheral mode if connected to a device

Hi,

We will take a look at this issue. Do you have any logs that you can share with us to help us with the issue?

Thanks,

Stonestreet One.

I just realised that it should always send three advertisements in a row because it should be advertising in all the advertising channels. So it seems that after the connection CC2564 is advertising mostly using just one channel (or even the protocol analyser is having difficulties to receive the rest).

I have also checked the HCI commands and to me everything seems to be ok. Here is a list of the HCI communication packets seen during the procedure:

...

(We are first updating the scan response data periodically while doing connectable advertising)

> HCI LE Set Scan Response Data

< HCI Command Complete (Success)

> HCI LE Set Scan Response Data

< HCI Command Complete (Success)

(Then we get connection)

< HCI LE Connection Complete

(At the time the code tries to stop the advertising even in this case, but it should be ok to do this)

> HCI LE Set Advertise (Advertising=Disabled)

< HCI Command Complete (Disallowed)

(Then the non-connectable advertising is started)

> HCI LE Set Advertising Data

< HCI Command Complete (Success)

> HCI LE Set Advertising Parameters (Min=250ms, Max=250ms, Type=ADV_NONCONN_IND, Channels=37 38 39)

< HCI Command Complete (Success)

> HCI LE Set Advertise (Advertising=Enabled)

< HCI Command Complete (Success)

... (After this there are some ATT reads and writes depending on the connected device) ...

(After which we do the following periodically once a second)

> ATT Notification Packet

> HCI LE Set Advertising Data

< HCI Command Complete (Success)

...

(And at some point there is a parameter update request)

> L2CAP Connection Parameter Update Request (Min=500ms, Max=500ms, Lat=0, T/o=6000ms)

< L2CAP Connection Parameter Update Response (Accepted)

(Then we continue sending notifications and updating advertisement data once a second)

...

I don't think that the problem is in Bluetopia because the HCI communication seems to be ok.

I have the same issue. I am pretty sure that problem is in cc2564, because everything goes fine on HCI level.

Hi,

Could you please confirm that you are seeing this issue when trying to use CC2564 as peripheral device, right?

I am trying to reproduce this issue, As you can see the issue it will be great if you can share some sniffer/protocol analyser logs?

Hi,

Thank you for replying. The device is indeed a peripheral. I could send you a log file via email.

Ok no problem, sundeep@ti.com

Hi,

Thanks for the logs.

We have tried reproducing the issue on our side with no success.

Connection parameters used are Min Connection Interval =500ms, max Connection Interval = 500ms, Connection Latency= 0, Connection T/o = 6000ms)

And the advertising parameters used Advertise Min interval = 250ms, Advertise Max interval = 250ms, Advertising Type=ADV_NONCONN_IND, Advertising Channel map = 37, 38, 39

Test case:

1. Write advertising parameters  (connectable Undirected).
2. Start advertising.
3. Initiate connection from a (peer 1) remote device (advertising is stopped when the connection is completed).
4. To make sure stop advertising.
5. Write advertising parameters  (non-connectable Undirected).
6. Start advertising.
7. And see if we can find the DUT(CC256x) from another(peer 2) remote device(and also if the devices is advertising in regular intervals).

Could you please let me know you exact parameters, you are using and the test procedure?

Also please confirm if this issue observed with all the remote device(to scan for the DUT, in Non connectable mode)?

Hi,

Those were the parameters that I was using in the earlier tests. What I see with Ellisys Analyzer is that the device is sending advertising packets only close to the connections events and it seems that other peer devices have trouble receiving these packets. The devices that I have used to observe the broadcast were iPad Mini, a USB dongle with TI CC2541 and Ellisys Bluetooth Explorer 400. With all of them I can say that the advertising is not working correctly.

I did some new tests to reduce the number of involved factors. In these new tests the eHCILL protocol is disabled (thus the chip should stay awake all the time), the device doesn't send any notifications to the connected peer and the advertising data is not updated during the connection.

With these I made the following test case:

1. Set the advertsing parameters:    
HCI LE Set Advertising Parameters (Min=60 ms, Max=60 ms, Type=ADV_IND, Own=Public, Direct=Public, Channels=37 | 38 | 39, Filter=Scan Any, Request Any)

2. Start advertising.

3. Update the scan response data once a second.

4. Connect from remote device (peer 1).

5. Set the new advertising parameters
HCI LE Set Advertising Parameters (Min=250 ms, Max=250 ms, Type=ADV_NONCONN_IND, Own=Public, Direct=Public, Channels=37 | 38 | 39, Filter=Scan Any, Request Any)

6. Start advertising.

7. Observe with peer 2 or preferably with prorocol analyzer.

The problem is most visible if the connecting device (peer 1) uses a connection interval that is longer that the advertsing interval. We did a test with the above parameters and connection interval 1000 ms in a Faraday cage to rule out the effect of noise from the surroundings. The average time between received broadcast messages was 2 seconds (maximum was 9.5 seconds). This might be better than the results earlier but far worse than what you would expect with 250 ms advertising interval.

A new twist to the story is that the advertising seems to behave a little better if I use scannable undirected advertising instead of nonconnectable undirected advertising during the connection. Then the advertising interval seems to be the correct (250 ms) and we can see advertising packets on all three advertising channels half of the time. But still half the time there are gaps during which the advertising is not working correctly.

I made traces of the recent tests where you can see the difference between the behaviour when using  scannable undirected advertising instead of nonconnectable undirected advertising. The exact parameters of the tests can be checked from there. Those are probably easier to follow than the earlier ones because I took those above mentioned things out of the question. I could send them to your email again. The traces include a full HCI trace as well.

Hi,

Thanks for the detailed information.

One additional question. Did you try using another CC256x or CC2540 for scaning for the DUT? If so is your filter duplicates - disable?

Send_HCI_LE_Write_Scan_Enable 0x01, 0x0

Since while trying to reproduce this issue, I have observed that If Duplicate filtering is disabled (Send_HCI_LE_Write_Scan_Enable 0x01, 0x0), I see the advertising indications very fast i.e 100ms

And if the Duplicate filtering is enabled (Send_HCI_LE_Write_Scan_Enable 0x01, 0x1), I am seeing the advertising indications very slow i.e 5-15 Seconds ones.

Well the above mentioned thing is only affecting devices that are scanning and it doesn't have anything to do with protocol analyzers. Here is a picture that I made from a trace that should explain the problem:

Today I noticed that I can improve the advertisement scheduling by constantly disabling and enabling the advertisement again. The advertising interval seems to be correct until the next connection event happens. Thus if the connection interval is 1 s, I should re-enable the advertisement once a second after every connection event. However, this is problematic because we don't know when a connection event occured. If a connection event happens rigth after enabling the advertisement, we will still get only one advertisement per second instead of four (we should get four if the advertisement interval is 250 ms).

Hi,

Can you please confirm one more thing. Does it happen after every Connection event or just after the LE connection update parameter which is changing the connection parameter to 1 second.

It is happening at least after every connection event that is used to send a characteristic value notification. We are sending notifications every second so that would mean every connection event in our case. Tomorrow I can check if it happens also with empty connection events. My guess is that it happens.

Hi,

I checked again without the notifications and it still happens even with empty connection events. The advertising interval stays 250 ms until the first connection event. I made a new picture of the new test with advertisement re-enabling done after the connection parameter update.

Hi,

Thank you very much for you valuable inputs and time.

We will try it on our side and update you.

Hi,

Has there been any progress? We are still struggling with this issue.

Hi,

Unfortunately, We didn’t achieve any progress so far on this, and we’ll update you as soon as we have something.