fast pair locator tag example disconnects with no reason

[KevinXu787]

Hello, I am trying to run the nordic example of fast pair locator tag but it is not behaving as I expected. I have an account and model IDs that are validated with Google (I am sure because input device example works perfectly fine)

First, I tried your version of model ID 0x4A436B, I used a google pixel 7 phone to scan for the fast pair packets and there is no pop-up. I then switched to my own model ID and tried the google validator app.The rsult is shown in the following image 

I have captured the in-air BLE packages and have found out that the phone terminated the connection right after an account key write. My NRF5340 UART showed a disconnect event with reason 19.

May I ask what caused this issue please? I haven't changed anything in the code so I expect this example to work out of the box. But the phone keeps terminating the connection. Ironically, the same model ID works perfectly fine on input device example, with no disconnecting and a pairing success on validator app. The set up of the model ID matches that of the model ID provided by Nordic. 

Please advice how I can fix this disconnecting issue. Thank you very much!

[Amanda Hsieh]

Hi, 

I have an account and model IDs that are validated with Google

Do you register your development email account by completing Google’s device proposal form?

What NCS version are you using?

Could you provide the device log and sniffer log?

Regards,
Amanda H.

[KevinXu787]

Hi,

Yes, I registered my email account by completing the proposal form.

As a good proof, the fast pair process (except the pop-up) works fine on your "input device" example.

Your original model ID 0x4A436B could not trigger a pop-up on my phone (my other model ID I registered will trigger the pop-up) so I cant test with your model iD.

I am using NCS 2.7.0, if that's what you are looking for.

I can provide these logs as soon as I go back to work tomorrow by noon (GMT+8). But in short, the log printed that account key is successfully written followed by an immediate disconnect event with reason 19. What may possibly cost this issue? Aside from input device-related characteristics, what else is different between the two fast pair examples?

Is it okay if I send the sniffer log in .cfa format? Or do you prefer a different format?

[KevinXu787]

I confirmed that I have the "include debug results" option on for my phone. As a proof, nordic's other debug model ID in "input device" example 0x2A410B is able to trigger a pop-up on my phone. However, the model ID for locator tag 0x4A436B fails to trigger the pop-up. I suspect that maybe it is only the locator tag model IDs that fails to trigger the pop up, the others (such as headphones or input devices) trigger just fine for the time being. Could you provide a reason why?

As for 

Amanda Hsieh said:

The End-to-end integration Fast Pair Validator test is not applicable for the Fast Pair locator tag sample.

Could you elaborate more on the reason why the locator tag example is not able to pass the validator test? I don't see much differences in the pairing process except for the last immediate disconnection after write to account key.

Besides from using the phone app, is there another tool that I can validate my own implementation of the locator tag service?

[KevinXu787]

nordic_locator_tag_125293.cfa

Please find the following sniffer log, if that helps

[Amanda Hsieh]

We saw issues with the locator tag device type on Android some time ago. It seems that the update of Google Play Services helped with this. Could you open Google Play Services in the Google Play Store and manually click the Update button (if an update is available)?

[KevinXu787]

Google Play services has already been updated to the latest version some days ago when I was testing by myself. 

It's weird that all model IDs registered as "locator tag" refuse to trigger a pop-up.

Again, do you know if there are any tools that help you diagnose your own example while developing?

[Amanda Hsieh]

You can only validate if the DK is advertising the Fast Pair Model ID correctly in the discoverable mode (the same advertising as in the input device sample but different Model ID code). If it is, you should ask the Google team for support regarding the missing pop-up.

The other thing that you should check is whether your test phone is set up with multiple accounts. We have experienced some issues on phones that are set up with multiple accounts. I recommend always having just one account on your test device. This account should also be on the Google accept list.