nRF52832 ANCS could not obtain the application name

[bh.niu]

I am on nRF52840, and ANCS can get the app name. After switching to nRF52832, you cannot get the app name. The driver of the two chip ANCS is the same, but the Bluetooth protocol stack is different, the former is s340, the latter is s332. What is the reason?

[Vidar Berg]

Hello,

Can you please post a screenshot showing the expected behavior? I'm not sure what "app name" is referring to in this context. Is it the name of the iOS device?

[su_ren]

"ancs_c_app_attr_request", Function for sending a get App Attributes request. For example, The APP application attribute returned by the function request of "com.tencent.xin" is named "微信", which can be obtained by using the function interface on nRF52840, but cannot be obtained by using the same interface on nRF52832. No BLE_ANCS_C_EVT_APP_ATTRIBUTE event is triggered.

[Vidar Berg]

I don't see how the Softdevice could relevant to this issue. It sounds like the problem is that the iOS device is not responding to the request issued by your ANCS running on the nRF52832. 

Are both devices paired to the same device?

[su_ren]

Both devices are paired with the same IOS device, and nRF52840 can request app properties, while nRF52832 cannot. But IOS devices can respond to two device request notification properties, so I would like to ask what is the reason?

[Vidar Berg]

I don't know the reason, and I don't have enough information about your setup to try to reproduce and troubleshoot the problem on my end. 

Some troubleshooting suggestions:

1. Capture sniffer traces (nRF Sniffer for Bluetooth LE) to compare the requests sent from the nRF52840 and nRF52832

2. Try different phones.

3. Remove the pairings and try to only pair the nRF52832 device.

[su_ren]

As for your suggestions, I have tried the second and third points and they are still the same.

As for the first point, I used the packet capture tool to see that both nRF52840 and nRF52832 have sent requests, and the IOS device also has data responses, but the data parsing received by nRF52840 is not a problem, while the data parsing received by nRF52832 is a problem.

As shown in the figure, nRF52840 and nRF52832 capture screenshots and data parsing screenshots.

[Vidar Berg]

su_ren said:

while the data parsing received by nRF52832 is a problem.

Where does the parsing fail? Please indicate in the picture where the problem is.  Since the sniffer captures are encrypted, it is not possible to compare the requests and responses from them, please see https://docs.nordicsemi.com/bundle/nrfutil/page/nrfutil-ble-sniffer/guides/common_actions_sniffing_pairing_procedure.html. 

[su_ren]

Looking at where my screenshot indicates, the normal flow receives the data requested by the app property, and the first state after parsing is COMMAND_ID. command_id in command_id_parse should be BLE_ANCS_COMMAND_ID_GET_APP_ATTRIBUTES.

However, from the process of nRF52832 analysis, it can be seen that the received data is problematic.

[Vidar Berg]

I suggest you print the raw payload (LOG_HEXDUMP_*) to compare the response received by the nRF52840 and nRF52832. You should also try debugging the code if you think there is an error in the parser.

su_ren said:

it can be seen that the received data is problematic.

Please point out the problematic part. I don't see any errors reported.

[su_ren]

It may be that my expression is not very clear, I have debugged the code, and determined that there is a problem with the received data, so the parsing is wrong, not that there is a problem with the parsing function. Because there is a problem with the raw data received, I do not know how to solve it.

[Vidar Berg]

You have made it clear that you believe there is an issue with the received data, but I don't see that you have shown or described what you think the actual problem is. What is the difference between the command responses received by nRF52832 and nRF52840 when you compare their raw hex values?