2015-08-25 3 views
0

J'ai donc une étiquette NTAG216 de NXP. Ils ont 888 octets de mémoire. S'ils sont utilisés uniquement avec mon application Android, le téléphone les reconnaît comme 888 octets. Mais après que je leur ai envoyé un message avec mon Raspberry Pi en utilisant libnfc, le téléphone les reconnaît comme étant de 238 octets (le téléphone et le Pi utilisent le format NDEF et n'écrivent que la mémoire utilisateur de la balise). Le Pi peut relire ses messages et peut utiliser les 888 octets entiers de la mémoire, contrairement au téléphone: /, le téléphone ne peut lire le message que s'il est plus court que 238 octets ... (J'utilise le mode d'écriture de compatibilité du NTAG216 avec le Pi)Le téléphone reconnaît l'étiquette NFC erronée après l'écriture avec Raspberry

Est-ce que quelqu'un a une idée de ce qui ne va pas?

+0

Quelles données écrivez-vous sur l'étiquette? Plus précisément, à quoi ressemble le conteneur de capacités (bloc 3)? –

+0

La capacité ressemble à E1 11 6F ... J'ai trouvé une solution possible. Dans la fonction qu'est-ce qui crée le message ndef, la longueur est juste de 1 octet. Donc, c'est toujours un court message. Et la fonction que j'ai expérimentée est juste pour les messages courts. –

Répondre

0

J'ai donc trouvé quelques explications à ce problème. Et créé une sorte de solution.

Le problème est que la fonction dans la bibliothèque NFC d'android crée toujours un message court NDEF et la longueur du message est stockée dans un octet. Ce qui signifie que la longueur maximale est de 256 octets avec la partie ndef. Pourquoi le programme NXP-s OWN a-t-il découvert cette balise au format 238 octets ... Et bien parce qu'il a certainement quelques erreurs à l'intérieur, mieux vaut avoir un problème avec NFC, car avec un microsoft Lumia, ces balises sont 888 octets sans aucun problème. Enfin, la solution consiste à utiliser des classes NFC avancées et à les écrire d'octet en octet. Cela permettra de mieux comprendre comment fonctionne cette NFC entière. Avec cela, vous pouvez créer votre propre protocole de message un peu mieux que cette chose NDEF. Pour moi, la solution consistait à utiliser quatre octets supplémentaires à la fin de la mémoire. Avec ceci je peux adresser des messages beaucoup plus longs (2^32) que ces étiquettes peuvent stocker. J'indique également dans ces quatre octets si Ndef est présent dans l'étiquette, car dans ce cas je dois couper les 7 premiers octets du message. Et oui, comme vous pouvez le constater, j'ai créé manuellement la partie ndef du message (pour des raisons de compatibilité, j'ai besoin qu'une partie du message soit lisible avec n'importe quelle application). J'écris juste des messages courts, parce que les longs messages d'android et Lumia sont différents (Lumia ne peut pas lire ce que android a écrit et vice versa). Donc, passez un bon moment avec la programmation si vous voulez utiliser toute la mémoire avec Android et utilisez le nfc avancé :). J'espère que ce sera plus facile dans Windows Phone OS.