So this is just a noobie question but would it be possible to store data on the xNT.
Yes! I know at most it would be a TINY image or paragraph of text So pretty impractical but im just curious is it possible?
Ive used the Dangerous things app to lock my xNT (I read something about locking/ReadOnly the tag) But im scared of braking my tag.
Whats peoples thoughts?
Yes, you can store Ndef data on it. For example, your vcard/contact info or emergency info, or a uri sending phones that scan it to a specific Rick Astley video…
Text is easy, and you can store quite a bit. You have around 888 bytes if storage, so a paragraph is very doable, and if you scan the tag with a phone, the stored text will probably come up automatically.
Images are harder. You can store the binary data directly on the xNT, but since there is no NDEF record type for an image, you would have to make your own app to read it from the tag and display it
Thanks guys!
One more thing you may be able to clear up for me, 888 bytes.
If I make a plain text document on my computer to see how much text data I can hold I quickly get to 3 4 and 5 KB. Does this mean the xNT has 888 KB or do I have just under 1 KB ??
Thanks
Just under 1k. 888 characters. But less if wrapped in NDEF envelopes.
888 bytes is around what the NTAG216 can store, just to give you a visual idea of how much text data that is I will paste a block of text below which I believe is around 888 bytes, someone more experienced may be able to correct me if I’m wrong.
~888 bytes of text:
Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laboru
If you want to calculate how many bytes your text of choice might be then you can use this online text-to-byte calculator I just found: https://mothereff.in/byte-counter
Your operating system and file-system on your computer will likely be adding additional meta-data to the newly created text document or word document you created on your system. Essentially when you created that new blank file (or at least what you thought was blank) it already starts consuming a tiny amount of space on the disk due to meta-data. But when you get around to writing pure text data to your chip then that will be in a more raw form with little to no meta data surrounding it.
I hope that helps you.
So, I’m back with another question.
If I write an amount of text into a .txt file and then zip it with a password. It comes back at 272 bytes so it easily fits.
Now my question is how can i put this file on my chip?
Also is it possible to write 00s to the chip lets say 700 bytes in an effort to remove the old data?
The question is more about how are you going to read it. I’m pretty sure there is no NDEF record that handles zip files. So if the file is for you and you just want to carry it around, and you are going to read it back at some point, I’m pretty sure it can be done, though I believe it will require custom software. If you are expecting to be able to share the file with people by having them scan your tag like you share a URL written to the tag, it’s probably not going to work.
So I guess what you’re saying is the tag is not really going to be able to store the data, it’s simply a way of linking to a url or file already saved on the scanning device.
Yes like you think, I’m effectively wanting to put some text on my hand with a password so if a phone reads the chip it downloads the (zip) file. It’s asked for the password within the phone (or then copied to a computer) where the receiver enters the password and is able to read the data?
Thats my goal anyway haha! Maybe I’m dreaming?
The issue is the transport. There are built in mime handlers for certain types of data. So when the phone reads the tag the tag says (for instance) “I have some URL data” and sends the URL… THen the phone knows it’s a URL and sends it to the URL handler.
There is no standard handler for zip files so while you could get the data on the tag, the phone wouldn’t know what to do with the data.
https://gototags.com/nfc/ndef/
Your best bet would be to use a url to link to the zip file hosted somewhere, or a password protected web page.
As I’m sure you are starting to notice I’m pretty new to all of this, It’s surprising to learn how all this works. I assumed that if you copy a zip file (1s and 0s) from one machine to another they understand what to do. I thought that if i copy the 1s and 0s to my chip it could then be moved to a computer and read? but it seems thats not the case?
sad times !
While in the end it’s 1s and 0s, there’s still a lot that goes on behind the scenes… Copying and pasting a file isn’t just copying the bits, there are allocation tables on the disk that have to be updated, and the handlers for this understand that you wanted to copy a file and they are programmed to handle moving the bits, as well as all the other stuff that needs to go on behind the scenes.
An NFC tag is not a flash drive. It wasn’t designed with the intent to move collections of bytes that make up a traditional disk file in and out of it’s internal memory or store arbitrary data. There are a lot of protocol layers and standards between your bits in the memory and the outside world. These standards have dictated the protocol to be used to store data on the chip. This is a standard so any reader/phone that is compliant with the standard can read any tag that is also compliant with the standard and can be able to handle any data (within the standard) that may be on the tag. Unfortunately that standard does not standardize a way to get zip files stored or transported over the RF interface.
Within the Android SDK there is actually a way to move files back and forth between two android devices over NFC using NDEF records, but it requires an android device on both ends. The NTAG216 in the xNT does not support this method.
Amazing information. Very clear and idiot friendly!! thank you very much!
I appreciate you taking the time to reply to me! Im clearly asking something from the device thats not whats its made for !
Just a couple notes to tag on to this thread. Basically NDEF is a wrapper for data which complies with the NFC standard but as @turbo2ltr said, it’s not required when working with the xNT… the ntag216 chip at the heart of the xNT stores binary data and has commands to read and write it directly. The problem is you will likely need custom software to do that because everything you might find elsewhere is NFC related and hence only works in terms of NDEF enveloped data.
So, you can write binary data, or, you could probably encode it in base64 and if it still fits, write that as the txt NDEF data type… or, since you’ll probably have to use custom software anyways, you could encapsulate it as binary data inside a custom NDEF record type and use custom app to use the NDEF library to handle all the complex read / write commands and tag communication. It’s really annoying that part so if you are going to go the binary data route I highly suggest you still wrap it into an NDEF record.
My second note is that the ntag216 has 888 “user bytes” but user pages go from 04 to E1 (225)… that’s 221 pages with 4 bytes each, which equals 884. The missing 4 bytes are page 03 which is user writable but ultimately unavailable for user data because they are OTP bytes that make up the CC or “capability container”… a required NFC standard header on type 2 tags.