NFC reader detection field?

[Jeff King]

Hello:

I've got a application where I want to detect if the NRF52 is near a NFC reader. I don't need two way communications, but it would be good if the reader could modulate the 13.56 mhz signal (and I can do this custom in hardware if need be).  Using just a oscilloscope and a raw NFC 13.56mhz antenna I can detect energy out to about 10 inches with just a stock reader or Android phone. 

Can the NFC hardware/software be set to detect a NFC field? 

[endnode]

Yes indeed Jeff, nRF52 NFC front-end can detect the field and you can get event FIELDDETECTED event callback. You can also wake up the device by 13.56MHz field from SYSTEM_OFF mode (see SDK "./examples/nfc/wake_on_nfc/").

[Jeff King]

Thank you, that gave me enough direction to dig into it further. But I had some followup questions.

Under the hardware spec, the field detect needed 1 volt peak to peak signal to trigger. I didn't see where it was settable in firmware. I'm able to get good decodes on the scope in the 10mv  (0.01 VPP) level.   I realize the assumption of 1 VPP is with the back-channel (loading) modulation which I don't need.

To expand on what I am trying to do, I want a NRF52 tag to recognize when it is near a NFC reader, which will be configured as a beacon... thing of active RFID vs. passive. So my "reader" will be custom, and won't be a reader, just sending out a modulated 13.56mhz signal that the NRF52 needs to decode via the NFC pins in/antenna.

So the specific followup questions would be:

Can I get the decoder to trigger/work below 1Vpp?  (if not I imagine I can add a amp ahead of things)

Can I decode one way data? 

I realize this is out of spec for the part, but using NFC would allow me to use the NFC module as a choke point decoder for finer accuracy in location applications. 

[Jeff King]

It's already in the public domain, known as choke-points. The difference here is the NRF52 has the hardware already on board, or at least it appears to.

So where we are at it seems is it can detect a field, but we don't know if there is a way to set it less then 1 Vpp

Also we don't know how low a level the NRF52 will decode the 13.56mhz signal.

Is there anyone on here from Nordic, who is familiar with the hardware of the chip?

[Kaja]

Hi Jeff, 

I'm sorry but I can not advice you to go out of spec, the specifications are there for a reason. 
As endnode said, it's difficult to achieve range with NFC, and you have to design, test, tune the NFC antenna. 

Best regards.
Kaja

[Jeff King]

This isn't for NFC usage per say, at least passive tags. I want to use part of the NFC hardware for a different application.

Should I write Nordic privately? It's not clear to me if you guys are forum users or Nordic employees. This is for a high volume application and it's not unusual, at least with past chip vendors I've worked with, to use what's on the chip for differening applications. I realize it's "out of spec". 

Thank you

[awneil]

Jeff King said:

It's not clear to me if you guys are forum users or Nordic employees

https://devzone.nordicsemi.com/backstage/f/welcome-to-the-devzone/30115/how-to-know-the-respondent-is-nordic-employee-or-not

[Jeff King]

Here is a bit more detail as to what I am trying to do explained on video

https://youtu.be/ECejqZ7MNk8

[endnode]

Nice video Jeff, making it slightly clearer. (I'm not Nordic employee btw., Kaja seems to be part of official Nordic support team and I hope she or some of her colleagues will add more ideas how to solve your problem). Still one question persists: do you want just to detect there is 13.56MHz field or do you want (as you say in the video) really perform data transfer (one way communication as you say)? This is huge difference.

My two cents to NFC "tag" front-end on nRF52 in general:

• It has FIELDDETECT AND FIELDLOST events. You can forget for the moment what is written in the chip specification regarding field strength, simply write small piece of code which activates NFCT peripheral block and check when the events occur. The distance where you get FIELDDETECT or FIELDLOST (depending on direction you move) is the maximum which gets some chance for communication (but still not guaranteed, there might be too noise or other disturbance which will make actual data transfer failing). I would also expect some hysteresis so take the less favorable result.
• Nordic provide some NFC "tag" libraries which make the FW development relatively easy, however they are indeed designed for standard use case (NDEF Tag Type 2 and 4 communication over ISO14443 TypeA). If you cannot achieve your goal with them (I would anyway invest few days into that by recompiling the examples and test these with your antennas so you do understand how close or far are you from your thresholds) then you can still try to build your own NFC stack on top of HW registers but that is long way to go. We are pretty large volume NFC/RFID device manufacturer and we were thinking to do some PoC project in that direction but in the end it was always down-voted by upper management because even we have lot of in-house experience the project was estimated in many men months of development so hard to justify such "PoC" without clear ROI prospect (= there are many many RFID/NFC chips/solutions which are exact fit for our purpose so we can just put them next to nRF52 to do our job, cost is reasonable and difference in development effort enormous...)
• In the end nRF52 HW is only capable of PICC (card) role as specified in ISO14443. Nothing more, it's "hard wired" into the HW design. As far as I understand ISO14443 there is nothing like one-way communication, you always need to "hear" also the other side because otherwise you cannot complete anti-collision on layer 3 and cannot operate "link" on layer 4. So you would need to have good RF properties (= meaning antenna design, maybe some amplifier?) on both sides. If you want one way communication then just use BLE beacon concept (one side can only listen, one can only transmit and you can transport - of course unreliably - data on pretty large distance even of few kilometers). Indeed you can use some proprietary 2.4GHz protocol as well... so to summarize: only detecting 13.56MHz field by nRF52 from larger distance? Probably feasible with good RF design on both sides. Long distance communication over 13.56MHz? Again maybe feasible but much less likely, you would really need huge antennas on both sides and the thing would be quite power hungry. My advice: go with other technology (e.g. higher frequency like UHF) and just stick the chip over SPI/I2C/UART to nRF52.

Cheers!