Bluetooth Sample central_nfc_pairing with PN7160 NFC Controller

[dBest]

Hello,

I am working on using the Nordic nRF TNEP API to support an NFC Bluetooth tap-to-pair application with negotiated handover. I have been working on programming the NFC Poller side using an nRF 52840. I'm using the Central NFC Pairing example in the 2.8.0 nRF SDK as a starting point.

We are using the PN7160 NFC controller instead of the ST25R3911B that the sample is coded around. The command implementation with this PN7160 chip is different and doesn’t quite line up with the Central NFC Pairing example, so we looking to adapt that example to work with our hardware.

Currently I am able to:

• Read the serial number and Capability Container from the tag
• Parse the Capability Container
• Read an initial NDEF message from our tag
• Parse the NDEF message
• Identify a Connection Handover Service

I am trying to select this service using the nfc_tnep_poller_svc_select command right after identifying the service in the initial NDEF message, but the code seems to be hanging up once I run this command. The RTT server is not providing any error logs from this function. The nRF documentation online says that the NFC Poller waits for a “specified period of time”, but I don’t see where this wait time period is set.

Additionally, the section on “Exchanging data with single response communication mode” isn’t very clear about which functions to call.

Here’s a link to the page I’ve been using as a reference: TNEP for polling device

Overall, I have a decent grasp on the low level NDEF procedures with the PN7160. However, I’ve had a lot of confusion about what TNEP API functions need to be called and when, and what the expected behavior from them is.  The PN7160 seems to be a much simpler NFC controller to implement than the ST25R3911B, with automatic anticollision functionality and one interrupt that goes high when a response is available to read from it. Because of this, a lot of the central_nfc_pairing nfc_poller.c code doesn't seem to be directly applicable or useable with the PN7160. If I am able to code low level SPI byte reads and writes to the PN7160, what is the minimum set of function calls required with the Nordic TNEP API to get negotiated pairing to work?

My current idea of the handover sequence is as follows:

• Poller reads initial NDEF message from Tag device
  • Parses NDEF message and finds a Connection Handover Service
• Poller creates a new NDEF message that acts as a Connection Handover Request
  • Sends to Tag Device
• Tag Device sends back a Handover Select NDEF message with the pairing information
• Poller uses the Handover Select message to pair via Bluetooth.

Any help on the above would be greatly appreciated. Thank you!

[Kenneth]

Hello,

Unfortunately I am not much at help on this one. I wanted to take a look at the application note from NFC forum, which describes how the exchange is occurring, but it's behind a paywall, so not able to look into the details there either: https://nfc-forum.org/build/specifications/bluetooth-secure-simple-pairing-using-nfc/ 

Likely getting a board with the ST25R3911B is a good idea for comparison :
https://docs.nordicsemi.com/bundle/ncs-latest/page/nrf/libraries/others/st25r3911b_nfc.html#st25r3911b-nfc-readme 

Kenneth

[dBest]

Do you have any documentation or block diagrams on the Nordic implementation of the TNEP API (beyond what is already on the link I posted)?

[Kenneth]

Sorry no. Some background: The main reason we introduced support for an NFC reader/writer chip was to verify our NFC Tag solution. It provide a complimentary sample for the NFC tag samples available in the SDK. The ST25R3911B was chosen because it supports all the modes that were required for testing the Nordic Tag. So unfortunately we have very little information about the reader/writer in this case.

Kenneth

[Johnny Nguyen]

Hi Derrik,

Sorry I’m just now getting back to this. For posterity and record keeping, I am consolidating our e-mail chain to this DZ case.

The high-level overall flow is:

1. The Central NFC sample initializes the NFC and waits for a Type 2 or Type 4 NFC Tag to appear in the field.
2. When a tag is detected, the read and parses its content.
3. The tag content should include Connection Handover messages and records, which contain the data required to initiate pairing, including the Bluetooth LE address of the peripheral device.
4. After reading the tag or exchanging data over TNEP (Tag NDEF Exchange Protocol), the central device starts scanning for the specific Bluetooth LE address obtained from the tag.
5. Once the advertising device with the matching address is found, the central device initiates the pairing process.

Our initial correspondence was around nfc_tnep_poller_svc_select potentially hanging up and wanting to add logs to the poller implementation. Looking at the log you sent earlier, maybe it’s not getting hung up where I originally thought it was, digging into the library could be an XY problem.

 

Do any callbacks in the connection handover service struct you init ever get called in your application? Are you getting the OoB data across to apply to the central’s scan filter?

I see the capability container being scanned, but I’m not seeing any logs that would be in the application space beyond just reading/parsing the capability container.

The simplified flow should be:

1. Detect and read the NFC tag
2. Read and parse the Capability Container
3. Read the NDEF file
4. Parse the NDEF message for Connection Handover records
5. Extract OOB data (including the Bluetooth LE address, and a key to use in place of a pin code)
6. Use the Connection Handover service to process this data and initiate Bluetooth pairing

(More info at NFC TNEP Connection Handover)

[dBest]

The simplified flow you listed looks to be the Static Pairing method, if I'm not mistaken. I am trying to do the TNEP negotiated handover method. Do you have a simplified flow for that?

I've been able to get a static pairing demo working, because it's just been a simple matter of parsing the NDEF message and using the OOB functions, and initiating a Bluetooth scan.