When I do the compare to eeprom off of a subsequent read, I print the results of the bytes until I get the first failed match. These tags are failing on the first byte with the following serial print:
You are writing to EEPROM a byte apart when you are trying to write 5 bytes. So they will overlap. There is a library EEPROM Write Everything that will simplify what you are trying to do:
I'm hearing you but I'm not following. The RFID tag is a 5 byte code, it is stored as a 5 byte character array code[].
If one eeprom write is for one byte and I increment the index each time, then I should be writing 1 byte of the code to the next byte of eeprom.
I clear the eeprom on startup. If I use the old tag, I can scan only it and it will read and write to eeprom. It will then compare correctly everytime. If I scan only one of the new tags, it will read the first time and write, after that it will not compare correctly. If I subsequently add the old tag, It will read and write to the next 6 eeprom bytes, and on subsequent scans of that tag, it will compare correctly to the second set of written data.
The point is that the old tag will work no matter what sequence of scanning tags. The new tags will never work.
Could it have something to do with the actual tag ID? I can't imagine why that would matter since it says it is writing the correct data.
So here is what I did. First, getting code to the web is a pain for me because my dev machine is not connected and everything else is wireless.
So as I started to go through and comment the code, I realized that I had overcomplicated the compare function. I was reading the values out and writing them to a temporary char array. So instead of doing that, I simply compared the code array byte by byte as I read the bytes from eeprom. This seems to be working. So whatever the problem was it was in how I was writing the data from eeprom to the temp char array.
You are probably comparing an unsigned byte against a signed integer. When treated as a signed integer, the hex byte "84" is a negative number and when it is sign extended to a 32-bit signed integer it is "FFFFFF84".
We still need to see all your code.