Comment voir ce qu'une application et un tag échangent vraiment ?
En le journalisant vous-même : chaque commande envoyée, chaque réponse reçue, avec un horodatage, des deux côtés de l'interface qui enveloppe les appels radio. Android garde aussi un journal de son propre trafic avec le contrôleur, filtré par défaut. iOS n'offre aucun équivalent, seulement des erreurs.
Le journal que vous écrivez
Le journal qui existe toujours est celui que votre code produit. Chaque commande en octets, chaque réponse en octets, l'exception quand il y en a une, et un horodatage sur chacune : cela suffit à rejouer un échange, à compter les allers-retours et à voir où un tag a été perdu.
Il se pose au même endroit que recommande la page des tests, autour des appels qui touchent la radio, ce qui veut dire qu'il coûte un endroit dans le code plutôt qu'une ligne par appel. Gardez les octets en hexadécimal et gardez-les entiers : un journal tronqué d'un échange qui échoue ne répond à rien.
Le journal que garde Android
La plateforme garde le sien. Le journal NCI d'Android, dans la pile NFC libre, retient les paquets échangés avec le contrôleur dans une mémoire circulaire de 256 Ko, dans les deux sens, chacun horodaté, et le service le vide sur demande.
Deux propriétés décident de ce qu'il contient. Le mode, persist.nfc.snoop_log_mode, est filtré tant qu'il n'est pas posé à complet, et une version déboguable déverse aussi la mémoire dans un fichier sous /data/misc/nfc/logs. Sur un téléphone ordinaire du commerce, ce que vous obtenez est donc une vue filtrée ; une version de développement montre les trames.
C'est le trafic du contrôleur, pas les appels de votre application. Il répond à une autre question, et à la bonne : la commande que votre code croit avoir envoyée est-elle bien celle qui est sortie.
Ce que donne iOS
Core NFC signale des erreurs, pas des trames. La liste est assez précise pour diagnostiquer avec, une connexion perdue, trop de nouvelles tentatives, un tag qui a répondu par une erreur, un paquet plus long que ce que le tag accepte, une session invalidée sous l'appel, et la page de l'invalidation en couvre le côté session.
Sur iOS le journal que vous écrivez est donc tout le journal, ce qui est un argument pour l'écrire avant d'en avoir besoin.
Lire ce qui revient
Sachez ce que chaque protocole met dans une réponse. Un APDU finit par deux octets de statut, et 90 00 est le seul qui veuille dire abouti, ce que met en tableau la page des APDU. Une réponse ISO 15693 s'ouvre par un octet de drapeaux dont le bit de poids faible veut dire erreur, suivi d'un code, comme le décrit la page ISO 15693.
Et lisez les horodatages, pas seulement les octets. Un écart de quelques dizaines de millisecondes entre une commande et la suivante, c'est votre propre code qui réfléchit, et c'est la part d'un contact lent que vous pouvez corriger.
Questions fréquentes
Faut-il un analyseur pour voir l'échange ?
Pas pour la plupart des défauts. Un journal des commandes et des réponses que votre code envoie et reçoit y répond, et il marche sur les deux plateformes.
Que contient le journal d'Android ?
Les paquets échangés avec le contrôleur, dans une mémoire circulaire, horodatés dans les deux sens, filtrés tant que la propriété de mode n'est pas posée à complet.
Y a-t-il un équivalent sur iOS ?
Non. Core NFC donne des erreurs plutôt que des trames, donc le journal sur iOS est celui que l'application écrit.
Que doit enregistrer le journal ?
Les octets envoyés, les octets reçus, l'exception s'il y en a une, et un horodatage sur chaque ligne, entiers plutôt que tronqués.