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.
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.
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.
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.
Any interesting findings you have there?
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.
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.
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?
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.
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.
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.