Bonding PSoC 4 BLE with an iPad Air 2

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

cross mob
DeCo_1926091
Level 4
Level 4
First like received

Using the PSoC 4 BLE Pioneer board and the example project called "BLE Proximity Bonding- Peripheral" by GRSR I can connect to my iPad Air 2 using the "LightBlue" app just fine, and they both act as if they are bonded if I power down the Pioneer board and power it back up....unless I leave its power off for 7 minutes or more.   Less than 7 minutes and they re-connect as they should.  More than 7 minutes and it's as if they never heard of each other before.  I've also tried the same test using an app I created for the iPad with TechBASIC with the same results. 

Any thoughts or advice anyone?

Thanks,

Dennis

0 Likes
1 Solution
Anonymous
Not applicable

Interesting thought; Yeah, powering stuff off is usually straight forward, but it was a thought

Bonding information has to be explicitly stored by both parties for it to work. I assume you are already storing it on the local PSoC4, so we can rule that out. And from the sounds of it, the iPad Air 2 holds the bond information for 7 minutes before wiping the bonding data and not using it.

One of the two devices needs to either: Request bonding when they connect together, or you need to access bonding-restricted attributes with the Central device when connected to initiate a bonding sequence (you should have code for handling this already).

You can still do bonding/authentication without input/output, BUT you will need to determine how you want it to truly authenticate then, as the easiest way is to have the human user verify both sides of the device for confirmation (OutOfBand key passing using a human).

You can either do this with a first device bonds, some button/procedure to initiate bonding for a new device, some alternative human interface to bond, etc. The software can be written to handle custom bonding/authentication with no Input/Output, but it makes it much harder than it would be otherwise

View solution in original post

0 Likes
6 Replies
himam_31
Employee
Employee
50 likes received 25 likes received 10 likes received

Hello ,

Kindly attach the project.

thanks,

Hima

0 Likes

File attached to original message. 

Thanks

0 Likes
Anonymous
Not applicable

The only thing that would change depending on how long you leave the unit off is whether a potential battery/capacitor discharges within that time frame. Are you sure the unit is turning off in the first place, and not just having the power source disconnected? (The unit might have enough power stored to hold data for 7 minutes for example before the capacitor/charge runs out).

0 Likes

e.pratt, 

I did think of the power held up by a cap but with power off there remains only about 1mv of noise on vdd.  To be sure, though, I connected a short wire from vdd to Gnd (with power disconnected) and it had no effect.

Thinking more about this, it seems like the power being held up by a cap, etc. shouldn't keep it from reconnecting when power is reapplied. Unless, somehow, that erased the stored bonding info from flash.

I would like to bounce another thought off of you:   According to several things I picked up on the net it sounds like iOS decides to store bonding information only after it figures out the peripheral wants it to by reading a secure characteristic or service. It also seems like that may mean that my PSoC4 BLE Component has to be set for bonding and authentication with encryption.   It doesn't seem like this is possible when it doesn't have input/output for authenicating it.  What do you think?

thanks,

Dennis

0 Likes
Anonymous
Not applicable

Interesting thought; Yeah, powering stuff off is usually straight forward, but it was a thought

Bonding information has to be explicitly stored by both parties for it to work. I assume you are already storing it on the local PSoC4, so we can rule that out. And from the sounds of it, the iPad Air 2 holds the bond information for 7 minutes before wiping the bonding data and not using it.

One of the two devices needs to either: Request bonding when they connect together, or you need to access bonding-restricted attributes with the Central device when connected to initiate a bonding sequence (you should have code for handling this already).

You can still do bonding/authentication without input/output, BUT you will need to determine how you want it to truly authenticate then, as the easiest way is to have the human user verify both sides of the device for confirmation (OutOfBand key passing using a human).

You can either do this with a first device bonds, some button/procedure to initiate bonding for a new device, some alternative human interface to bond, etc. The software can be written to handle custom bonding/authentication with no Input/Output, but it makes it much harder than it would be otherwise

0 Likes
DeCo_1926091
Level 4
Level 4
First like received

I fixed it!  The problem turned out to be that the module I was using (CYBLE-2140009-00) was built to support BLE 4.1 and the iPad, running iOS 11.3 supports BLE 4.2.  The pertinent difference is that 4.2 handles resolvable private addresses (RPA) in the Link Layer and in 4.1 it's done in the host which requires programming to be done by the developer.  There are other differences that may or may not affect the problem.  If I was smarter at coding maybe I could have made it work.  It appears that what was happening is that iOS changes the RPA randomly on some schedule (maybe every 7 minutes??) expecting the server to know how to resolve the new number in it's link layer.  When it can't, the connection can not be re-established without re-bonding.  To solve the problem I changed to the CYBLE-214015-01 module which does support BLE 4.2, and is a drop-in replacement for the first one.

[At least this explanation is what I think was going on.  In any case, it works now.]

Dennis