I'm trying to encode a rfid tag using a zebra printer, sending these commands it encodes but I need to cut or hide some part of the number
^XA
^RS8
^RFW,H
^FDD020004D^FS
^XZ
The commands above records this to the tag D020004D000000000000 but I dont need the zeros. How can I remove them or hide them, I have tried to reduce the EPC memory size but results in a different code.
Thanks.
The EPC field has a specific size. When you read the tag you should be able to specify the offset and number of bytes to read. Need to handle this during the read not the write.
Related
I have a access control system from act365. I have Mifare Classic 1k RFID tags, the system works like expected. Now I want to create a software to register the tags in the act365 system.
I read the tags on the act365 reader the cloud gives me a decimal number that representing the UID of the tag. To register a new tag in the system I will scan the tag with an "ACS 1252 Reader" and put the UID in the act365 system by the API.
The Problem is when I convert the HEX UID read from the ACS reader to Decimal number, it is not the same number that the act365 cloud gives me, the System does not recognize the given tag number.
What I have done:
I have tried little and big endian, remove bits from both or the
right. But nothing gives me the same decimal number.
I have tried different NFC readers.
Note:
I called the Vanderbilt support, they told me the reader reads the uid send it to the cloud, they have no idea where the problem is.
Numbers:
Read from the ACT365 System:
78575056
Read from the ACS reader:
76:A2:14:5F
I'm happy for every hint or idea!
I can successfully read and write the (1k) tags that came with the reader, but the tags I need to use have just 4 bytes per block rather than the 16 for the 1k tags, and presumably no security. The data sheet for the reader chip is rather useless (I am going cross eyed looking at it) and the available code for using it does not suggest what settings need changing to read these old tags. Question. Should I be able to read (I am guessing) Type 2 tags with this reader, and any body got any documentation that might help me make the NXP chip (Chinese clone) read 4 bytes instead of 16?
thanks in advance.
P
So no, the tag reader module only reads/writes a 16 byte "block". With block 0 being immutable. The tags I have are "striped" with each 4 bytes being repeated 4 times (with an offset of 1). There you go.
I have a mainframe data file in binary format, with variable records. No copybook works in this case, nor do I know end of line. How do I read such a file?
Assuming you're reading this file in a COBOL program running on the Mainframe, this is really no problem. COBOL doesn't write null-delimited output. It writes variable length records with the length embedded in the first two bytes of 4-byte prefix area called a (R)ecord (D)escriptor (W)ord, which is NOT included in the record layout copybook. To read such a record back into another COBOL, you just need a properly coded copybook.
I am trying to build an RFID based door opener with an Attiny2313 and an RDM630 RFID reader. There has been no Problem with programming or getting the two ICs to talk to each other via UART. The Problem is the interpretation of the data.
I wasn't able to make any sense of what the RDM630 had sent to the Attiny, so I hooked it up via an RS232/USB Adapter, and this is what I get on my PC:
Display = ASCII:
Display set to HEX:
Written on the Card is:
0000714511 010,59151
Can anyone help me make sense of the Data?
Most of the bytes that the RDM630 RFID reader module sends are ASCII characters of hex digits ('0'-'9','A'-'F') which means 0x30-0x39, 0x41-0x46.
It looks like your RS232/USB inverts the bits, comparing to a direct TTL connections.
(RS232 is inverted TTL. It has also different voltage levels, but that's OK as long as TTL transmit output feeds RS232 receive input, as in your case. The other way around is more tricky).
I need to read data from a text file in a tinyos file (nesc file). I searched lot on Internet but couldn't find a way.
Is there any way?
I don't know about TOSSIM, but using a real sensor board its possible to do so.
What you could do, is to write a program using Java, C#, etc that reads the file and passes the acquired data to the serial/usb port as a SERIAL PACKET. But you are limited to maximum of 255 byte for each packet.
So you should make a simple protocol that takes care of data chunks.
Of course you should know that how you can create a serial packet to be readable by sensor boards.
For that you need to read the TEP#113. But short story, a serial packet is consisted of:
HEADER + CONTENT + FOOTER
header contains protocol byte, destination and source address etc...
content is your message_t struct
footer has CRC and some other stuff
You have to take care of CRC calculation and also escaping start/end delimeters (I believe byte 126 or 127 is the delimiter, I mean indicator of starting and ending a packet).