Pourquoi un lecteur et un tag ne parlent-ils jamais en même temps ?
Le lecteur fournit le champ qui maintient le tag en vie, et le tag répond en modulant ce même champ. Il n'y a qu'un canal et qu'une source d'énergie, les deux parties doivent donc parler à tour de rôle. Chaque échange est strictement une question puis une réponse, jamais les deux à la fois.
Pourquoi le canal ne porte qu'une voix
Le lecteur n'est pas seulement un correspondant, il est l'alimentation. Son champ doit rester établi en permanence, sans quoi le tag cesse d'exister électriquement. Le tag ne peut pas s'emparer du canal, car ce serait scier la branche sur laquelle il est assis.
Il répond donc de la seule façon possible : en faisant varier ce qu'il tire de ce champ. Le lecteur parle, alimente et écoute simultanément, et le tag ne peut répondre que dans les intervalles que le lecteur lui laisse.
Ce que coûte un aller-retour
Chaque échange est une question, une pause, une réponse, et une nouvelle pause avant la question suivante. Ces pauses sont brèves, mais elles se paient par aller-retour et non par octet.
La conséquence est contre-intuitive : deux cents octets en un seul échange sont plus rapides que deux cents octets répartis sur cinq. La ressource rare, en NFC, n'est pas la bande passante, c'est le tour de parole.
Pourquoi beaucoup de petits enregistrements se lisent lentement
Un tag portant un seul enregistrement avec une adresse web se lit en une poignée d'échanges. Le même contenu réparti sur six enregistrements courts transporte davantage d'octets d'en-tête, il demande donc quelques échanges de plus et passe un peu plus de temps à attendre entre eux.
Cela vaut d'être su avant de concevoir le contenu d'un tag. Si un contact paraît poussif, la question utile est le nombre de choses distinctes que le téléphone a dû demander, pas le nombre d'octets revenus.
Ce qui se passe quand un tour est coupé
Déplacez le téléphone en plein échange et le tag perd son alimentation entre une question et sa réponse. Il n'y a ni tampon ni reprise : la séquence s'arrête, simplement.
Pour une lecture, c'est sans conséquence, vous n'obtenez rien et vous recommencez. Pour une écriture, non. Le tag peut conserver le début d'un message et rien d'autre, dans un état qui se lit comme corrompu plutôt que comme vide. C'est la raison mécanique du conseil de vérifier une écriture au lieu de la supposer réussie, et la raison pour laquelle un lot de tags écrit rapidement doit être contrôlé avant expédition.
Questions fréquentes
Un tag pourrait-il interrompre le lecteur s'il en avait besoin ?
Non. Il n'a aucun moyen de signaler quoi que ce soit hors du champ qui l'alimente, et aucune autorité sur le canal. Un tag ne peut que répondre, et seulement quand le lecteur lui a laissé la place de le faire.
Est-ce pour cela que le NFC est plus lent que son débit annoncé ?
En grande partie, oui. Les débits définis décrivent le canal pendant qu'il transporte des données, et un échange réel passe beaucoup de son temps dans les pauses entre les tours. Le débit effectif d'une lecture est nettement inférieur au chiffre nominal.
La même limite s'applique-t-elle à l'émulation de carte ?
Oui. Quand un téléphone émule une carte, il prend le rôle qu'aurait eu le tag et répond à un terminal externe qui fournit le champ. L'alternance est identique, seuls les rôles sont échangés.
Faut-il vérifier chaque écriture ?
Pour tout ce qui part en production, oui. Une écriture coupée en cours de séquence laisse un tag qui a l'air écrit et ne l'est pas, et le coût du contrôle est d'une seconde par tag contre celui d'un millier de tags inutilisables.