• State Verified Answer
  • Replies 5 replies
  • Subscribers 87 subscribers
  • Views 913 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 272895
Options
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

NFC Type 2 vs Type 4 - Type 4 is harder to read by phones?

Otso Jousimaa

Hello,

We updated NFC in our product to use SDK 17.0.2 Type 4 NFC, and we are getting customer reports that reading NFC fails on devices which used to work just fine on SDK 12.3 Type 2 NFC. 

After internal investigation we believe that the reading takes longer before phone / user is notified about the NFC scan result and there's more failed reads. Is there something inherent in Type 4 tag that make communication less reliable? Can we improve the reliability somehow in software?

Parents
  • +1

    Hi 

    We haven't seen this particular issue before, but Type 4 is a considerably more complex protocol, and requires quite a bit of back and forth communication in order for the transactions to succeed. 

    Type 2 is one directional only, and there is a lot less room for lost packets to affect the communication. 

    Are there any particular phones that perform poorly, or do you see it across the board on all devices you have tested with?

    Have you ever gotten your NFC antenna design reviewed by us, and tuned the antenna for optimal performance?
    It is possible that the antenna performance is not optimal, and that this makes communication unreliable when using the more complex Type 4 protocol. 

    Also, one of the NFC developers mentioned that the current Type 4 NFC libraries are a bit susceptible to high priority interrupts on the CPU (like the ones generated by the Bluetooth stack). If you have a lot of CPU activity at the higher interrupt levels this could also lead to reduced performance in Type 4 mode.
    Do you know if there is much CPU activity when the issue occurs? 
    If yes, would it be possible to run a test where you disable this activity and run NFC only, to see if this could be the cause of the problem?

    Best regards
    Torbjørn

  • 0 in reply to ovrebekk

    Hello,

    We don't have objective measurements, but the gut feel is that this affects all the phones. 

    The NFC antenna has had an external review, but I'm not sure if it was by Nordic or some third party.

    We increase Bluetooth advertising rate on NFC read, this would cause high-priority interrupts for sure. I can look into disabling Bluetooth on NFC field activated and enabling fast advertising on field lost. It would be the same user experience anyway. 

    Thanks, I'll follow-up once I've checked the CPU activity

  • 0 in reply to Otso Jousimaa

    Hi 

    Sounds good. Just let me know once you have been able to test it. 

    Regards
    Torbjørn

Reply Children
  • 0 in reply to ovrebekk

    Hello,

    TLDR: It seems that T2T and T4T work with same reliability on our hardware, we just paid more attention to issues after investigating customer reports. 

    Longer version:

    We tested reading with our old firmware (SDK12.3 T2T), new firmware (SDK17.0.2 T4T), SDK17.0.2 record_url example (T2T) and SDK17.0.2 writable_ndef example (T4T). We keept track on "good read" when tag is read almost instantly, "bad read" when tag is read after a few seconds and "fail read" when tag is not read at all or reader gives error. 

    All firmwares performed similarly at least on one phone: ~50% good reads, ~25% bad reads and ~25% failed reads. We'll keep track of reports from our users, but won't be investigating this further for now.

  • 0 in reply to Otso Jousimaa

    Hi

    Thanks a lot for the update. I will consider this case resolved for now then. 

    Best regards
    Torbjørn

Related
Terms of service