With an ACR122U I know you can transmit direct messages to the NFC controller (PN532) by using the direct transmit command: 0xff 0x00 0x00 0x00....
When I read the manual of the ACR1251U it say: The reader's peripherals control commands are implemented by using the PC_to_RDR_Escape.
What does this exacly mean? Does this mean it isn't possible to send direct messages to the NFC controller? If it is possible, where can you find which NFC controller it use?
Any information is welcome!
Thanks in advance.
The "direct transmit command" is an APDU format that permits you to send native commands to the PN532 NFC controller embedded in the ACR122U reader device. So this basically defines the wrapping to fit native commands into the APDU-based protocol that you talk to the reader over PC/SC (& CCID):
0xFF 0x00 0x00 0x00 <Lc> <DATA>
where <DATA> is actually a command for the PN532.
PC_to_RDR_Escape is the CCID message (device class/protocol that is spoken over USB) that is invoked by the PC/SC stack when you send an escape command. For instance, if you use the Java SmartcardIO API's Card.transmitControlCommand() method, the PC/SC stack will send a PC_to_RDR_Escape message over USB. THe reader answers this message with a RDR_to_PC_Escape response.
Similarly if you use the method CardChannel.transmit() method, this cause the PS/SC stack to issue one (or more?) PC_to_RDR_XfrBlock messages over USB.
As you found out in this answer, it seems as if you would use the APDU format of the "direct transmit command" for both command exchange methods.
Whether you need to use the escape command or the transmit command seems to depend on the firmware version of the reader. For instance, for firmware version 101, 102 (and 103?) you would typically only need the transmit command, but the next generation versions (2xx) seem to prefer/require (if they don't emulate an ATR) the escape command approach.
Related
I started reading into the topic of NFC/Smartcard-Communication and I found many different standards and commands depending on the Tag type (for example see here)
I also came across the APDU-commands which seem universal to the communication of nfc/smartcards?
Does this mean, that these higher level protocols are all based on apdu and can be translated?
As an example, I found NFC 14443-A commands implemented with the android.nfc.tech.NfcA library, such as:
Action
Byte
Read
0x30
Write
0xA2
And APDU commands like these:
Action
CLA
INS
P1
P2
LC
READ BINARY
0xFF
0xB0
...
...
...
UPDATE BINARY
0xFF
0xD6
...
...
...
GET DATA
0xFF
0xCA
...
...
...
MIFARE CLASSIC READ
0xFF
0xF3
...
...
...
MIFARE CLASSIC WRITE
0xFF
0xF4
...
...
...
The commands seem to be completely different.
It would also help alot, if someone could point to good documentation on the topic
Documentation I have found so far:
The Android documentation on nfca (Link)
APDU description on wikipedia Link
(The german version contains some return codes)
APDU commands (by a card-reader manufacturer) Link
You have it a bit wrong, 14443-3A is lower level that APDU's which come from the higher level ISO 7816 protocol.
But the Byte's ( 0x30 and 0xA2) you reference as NFC 14443-A are not from NFC 14443-A but look like vendor specific Mifare Ultralight protocol commands which are again above NFC 14443-A
There is also a complication and probably the reason you are confused with APDU's you listed according to the ISO 7816 spec, all the APDU's you specified have a CLA of 0xFF are "invalid".
The reason for this is that a USB readers also use ISO 7816 for the host CPU to talk the NFC chip to work mainly with NFC Type 4 Tags, because 0xFF are invalid for ISO 7816 the reader uses them for other non ISO 7816 things the NFC chip can do, e.g. communicate to non standard Mifare classic commands, turn on/off the LED's on the USB reader, etc
So really CLA's of 0xFF are just a way to wrap other commands.
Or in a rough pictorial form
I would read as much of the Standard specification documents shown in the Stackoverflow you linked to and I wrote. There are a lot of specifications used/part used
I know that they are really pay for items but they are out there on the Internet.
e.g.
http://www.emutag.com/iso/14443-3.pdf
http://www.emutag.com/iso/14443-4.pdf
For the higher level NDEF stuff https://github.com/haldean/ndef/tree/master/docs
For the Various NFC Forum Standards
Google Index of the 4 Types
I'm simulating a Mifare Classic (1K) tag, and following the o ISO/IEC 14443 Type A protocol.
I could not found any information about what should be a proper response in case of receiving an unknown command from the reader (the reader supports other protocols).
Should I respond with an invalid operation NAK? Should I just ignore the command?
Mifare Classic EV1 datasheet ยง9.3 suggests Invalid operations should return 4h as response. It's quite unclear to me wether undefined commmands should be considered Invalid operations. I don't have a MFC EV1 at hand to test on. In my experience older MFCs simply do not answer to erroneous commands, though.
I have an app using ACR122U and NTAG203. I have no problem to read or write NDEF messages with ACR122U.
My clients are expanding and I'd like to change all platforms to use Prox-SU.
I acquired a Prox-SU to test. Almost all works well except when reading NTAG203.
With NTAG203, the Prox-SU is identifing my tag as MIFARE Ultralight. So, I am able to read only until page (block) 0x0F according to documentation of Prox-SU. But I have data saved above of page 0x0F because my tag is really a NTAG203 (41 pages in total).
When I use ACR122U reader, I have no problem to read or write to this tag and I can read beyond page 0x0F.
I have been searching for support, but it has been too hard to find technical support from Gemalto.
Is it possible to use NTAG203 with Prox-SU to read pages above 0x0F?
I have a modbus device I am trying to communicate with using an ethernet to RS485 device. I'm not sure whether the device uses modbus ASCII or RTU.
I am trying to format a request to a device with address 1. The command code is 11h. I'm not sure I'm formatting the request properly
Here is the string I am using for ASCII - ":010B000000000C\x0D\x0A"
Here is the hex I'm using for RTU: "\x01\x0B\x00\x00\x00\x00\x0B\xA4"
When I send this command it is echoed back but I'm not getting responses. I've been through the modbus documentation and I think I have the correct byte structure. I'm wondering if I'm encoding it right for ruby?
It turned out my ethernet to RS485 device wasn't capable of the correct timing for modbus. Once I purchased a new unit the ascii strings worked.
Are you sure the checksum should be written in pure bytes, not in ASCII? I mean, try to send :010B000000000C0D0A instead of :010B000000000C\x0D\x0A.
Also, you wrote that the command is 11h - for my understanding it is 0x11 (hex), and you are sending 0x0B. Or the command is 11 (dec)?
I can't find information about if it's possible change AFI number in RFID chip with NFC. I'm sure it's possible read AFI number with NFC. AFI number has some special block on RFID chip thats reason why I'm not sure if it's possible change it. Thank you
For a ISO 15693 tag you can use the NfcV command transceive(byte[] data) to send a "write AFI" command to the tag, followed by a "Lock AFI" command to lock the AFI value.
Write AFI has the command code 0x27. Lock AFI has the command code 0x28.
This should work as long as the RFID chip supports AFI (AFI is optional) and the AFI of that tag has not been programmed beforehand.
You can find more details about AFI in the ISO 15693-3.
See: See Android reference for transceive()
Have you seen this post about the application family identifier : google
In ISO 15693, the AFI describes the type of application targeted by the reader. This identifier is used to extract all transponders in the reader field that meet the required application criteria. After the reader sends out the AFI, only the AFI-compliant transponders of the appropriate family will respond. Programmed by the transponder issuer, the AFI is read-only and its value cannot be modified.
However I see some systems seem to allow you to write the AFI code, and sa well as lock it. I guess it may be up the individual the chip manufacturer. So while its not locked, I guess you could change it. Who makes your the card you are trying to write to?