BCM20736 throughput increases when passkey pairing is enabled?

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
Anonymous
Not applicable

I've been experimenting with enabling and disabling the passkey using the hello sensor app as a basis. What seems odd to me is that the throughput that I'm seeing using a companion Android App actually increases when passkey is enabled. Does enabling passkey turn on BLE built in encryption via SMP? It if does, I'd expect throughput to decrease, not increase. With passkey enabled throughput is about 3 times faster. Does enabling passkey turn on data compression and thus result in increased throughput? Or is enabling passkey allowing more packets to be sent during each connection interval?

Has anyone else seen similar or different behavior?

0 Likes
1 Solution
Anonymous
Not applicable

Hello Kevin,

1.  Can you provide us an air trace of the two cases that you have set up?
2.  It is not clear to us why the authentication mechanism will change throughput.
3.  There is no technical reason for them to be different, according to the developers.

Thanks
JT

View solution in original post

0 Likes
13 Replies
Anonymous
Not applicable

Hello Kevin,

Have you made any modifications to the hello_sensor App?

Thanks

JT

vik86

0 Likes
Anonymous
Not applicable

Hello JT,

Yes. The main similarity to hello sensor is in the way my app uses the code that is is included when PASSKEY_PAIRING is #defined. The similarities stop there. I using a write characteristic to send data from the phone to the app and a notification to send data from the app to the phone.

Regards,

Kevin

0 Likes

For us to better understand your experiment and help you solve, would like to know the following :

Could you mention which Android app you are using for measuring the throughput ?

Secondly there are two concepts a) Enabling PASSKEY and b) white list which needs to be considered for your experiment.

If you have enabled PASSKEY , make sure the that you have not paired previously, if you have paired( delete that key) and try measuring the throughput. Since whitelist would have added your previously added key and might be making it faster throughput.

thnx

vik86

0 Likes
Anonymous
Not applicable

vik86

I have created my own Android app and can't share it because it is proprietary to my employer.

As far as I know the whitelist is not enabled. I have not called any function to enable it explicitly.

I will try deleting the previous pairing per your suggestion.

Thanks,

Kevin

0 Likes
Anonymous
Not applicable

Hi Vik,

I revisited my test code and see that in one case I do have the whitelist enabled and in the other it is disabled.

Case 1: Whitelist is enabled, PASSKEY is disabled

Case 2: Whitelist is disabled, PASSKEY is enabled

What I'm seeing is that the throughput of Case 2 is higher than Case 1. Is having the whitelist enabled causing throughput to decrease?

I will test

Case 3: Whitelist is disabled, PASSKEY is disabled

and see how it compares to Case 2.

Regards,

Kevin

0 Likes

Any interesting findings you have there?

0 Likes
Anonymous
Not applicable

I found that if the whitelist is disabled, then throughput with passkey enabled is less than throughput with passkey disabled. This is as expected, however; I also observed that throughput decreases when the whitelist is enabled.

0 Likes

I'm trying to get my head around this one as well.

My thinking was similar to yours in that unlike ‘just works’ pairing, Passkey allows one to enter a key prior to being provided access to a Bluetooth based resource.  Once the key is entered and validated by the application, then the pairing information  is stored in the whitelist for future  connections.

So here, the two features are not entirely mutually exclusive right?

Then, we know that our whitelist has a bug and while entries can be written, they cannot erased (the developers think this is an issue within the stack).

So I concluded that if the whitelist is full, but the stack is still trying to write to the whitelist when paired, it can’t and eventually times out and provides access anyway, consuming more time, which may appear as an aggregated throughput problem over the period of time that the throughput testing occurs.

Therefore, no whitelist, no constant retry to write upon success pairing, thus consuming less time.

The developers disagree and told me that Whitelisting and PASSKEY cannot be combined for an analysis of throughput.

Their thinking is this:

  • You become whitelisted with PASSKEY enabled – So for next connection its faster and PASSKEY input is not required
  • If you disable whitelist then enabling PASSKEY or disabling PASSKEY, this is a different scenario ( With Enabled PASSKEY – it will take authentication time, with no PASSKEY it will take less time)
  • If you enable whitelist  the PASSKEY provided is of no use( since you have been added to the whitelist group with that key), disabling PASSKEY also would not affect since you it in the whitelist group.

This is now making more sense to me.

vik86 andrew997

0 Likes
Anonymous
Not applicable

In my testing I never had passkey and whitelist enabled at the same time. Do you think that throughput will improve once the whitelist bug is fixed in the case where whitelist is enabled and passkey is disabled?

0 Likes

Whitelist is unrelated to encryption. Whitelist only affects scans and connection establishment. What is the connection interval in the two cases? If I remember right, bleprofile_SendConnParamUpdateReq() is invoked in encryption changed callback, which will happen only when connecting to a paired (passkey or just works) peer. Try moving that call to connection up callback and see if anything changes.

0 Likes
Anonymous
Not applicable

In both cases the requested connection interval is 7.5 mSec. I have looked at the BT HCI log the Android device and see that the 7.5 mSec interval was granted. Also in my code that uses the whitelist,

bleprofile_SendConnParamUpdateReq() is already invoked in the connection up callback.

0 Likes
Anonymous
Not applicable

Hello Kevin,

1.  Can you provide us an air trace of the two cases that you have set up?
2.  It is not clear to us why the authentication mechanism will change throughput.
3.  There is no technical reason for them to be different, according to the developers.

Thanks
JT

0 Likes
Anonymous
Not applicable

Hi kcj

Just curious - how much data are you transferring?  What kind of connection interval did you request and what is Android giving you?

Is this still an issue?

Regards,

Andrew

0 Likes