Rfid replacing data instead of adding

Hi this is my first time posting on here and Im sorry if its already been covered and I didn’t see it. I am having an issue with accessing the memory storage of my rfid tag i placed a url that is only 53 bytes and have tried to add another 135 bytes worth of data but instead of adding it it tends to replace it. I am using the NXP app on a Samsung phone. any tips of hints on how i can get around this?

Hey there… so yeah this has to do with how NFC works… the user memory is organized into pages on the tags. For an NFC device to properly read/write data to those pages, it organizes the payload into an NDEF message with one or more records.

There can be multiple messages stored on a tag, each containing one or more payloads or “records”. There can also be multiple messages on a tag, but we won’t bother going into that because nobody really uses that with passive transponders, it’s more useful for active peer to peer nfc comms.

Typically the Android kernel only cares about the first message and first record in that message. It does not care to read or handle multiple records. That’s why when you go to write new data to your tag, you overwrite the old data… the Android NDEF library that basically all NFC apps use, will simply say “ok, you want to write some data, cool… starting at memory page 04 and … bzzz”, it writes over your old NDEF record.

There is a way to write multiple records per ndef message, or even multiple messages on the tag… but multiple records per single message is the way to go with Android… and Android even makes this possible, but appending data is not supported. You must create a complete message and write it all at once, and Android only really supports some simple data combinations. One example is writing a mime record to launch an application, then store some app related data in subsequent records… for example, let’s say you have a task trigger stored on your tag… you could write a message with two records; the first record is the app launcher, and the second record is the task trigger data. That way when you scan your tag from basically anywhere (home screen, checking email, watching hulu… anywhere) the tag will be read and the task app will launch first, then the task app can read the remainder of the task data and take action.

If you want to store two disparate types of data, like a vCard and also a URL, you can store those, but Android will only care about the first record and when scanned by someone else, their phone will ignore the URL completely and just ask to put which address book to put the contact details into.

This seems lame, but I get it… you could theoretically have many different messages, each with their own records on a tag… think about 32k Type 4 tags … you could have far too many to present to a user… the UX would suffer and so they just decided that those situations are outliers and decided not to support them.

Your only other option is to write your own NFC apps that can manage multiple messages or multiple records on a tag. If you do make such an app and you write the launcher ID for that app into the first message, if a person scans your tag that does not have the app, they will be taken to the play store to install it… so that part is kinda cool at least :slight_smile:

If you decide to write your own NFC app, then the multiple message thing could make sense… you could pack each message with similar or related data records, and disparate data into separate messages. For example, if you wanted to store a vCard, personal website URL, and social media handles into one message, you could do that, then create a second message to store, maybe, task trigger data, or whatever… all stored on the tag. The only issue will be, if you ever wanted to change anything, you’d have to re-write the entire tag contents, because there is no way to scoot bytes around… it’s not a file system you’re dealing with, it’s raw memory blocks… so you have to re-write all the data on the tag.

Just an FYI to would-be programmers, if you want to manage memory blocks more directly, you can do that by skipping the NDEF library all together and talking directly to the tag… but that’s another entirely different post. :slight_smile:

Lot of info but makes a ton of sense thanks!!