CR95HF reader --> Tmoney Card info

[DJeon.4]

I use CR95HF for charging type electric vehicle charger. I'm going to use the T-money card for RFID.

The information you need should be able to read T-money Card number, month, day, and balance check. I need to use CR95HF, so could you share a commander that I can implement?

About 2,000 units will be serviced. We need to consider purchasing the reader, and if this is not implemented, we need to replace the reader.

If it can be implemented with CR95HF, I would appreciate it if you could share the data Tx Rx packet commander.

[Brian TIDAL]

Hi,

the ST25R95/CR95HF supports ISO/IEC 14443 Type A and Type B, ISO/IEC15693, and FeliCa in reader mode. As far as I know, T-money is based on ISO/IEC 14443 Type A and ISO 7816-4 commands. Therefore, it should be possible to read T-money cards with a ST25R95/CR95HF.

Regarding the FW, I would suggest to base your development on top of the ST25 embedded NFC library for ST25 readers (STSW-ST25R017).

Rgds

BT

[DJeon.4]

Thank you for your reply.

I'm developing with arduino IDE, so the library is not available and I want to know the packet contents for Tx Rxing the command with CR9HF SPI communication.

Take the PN532 module as an example.

This code is a code that can read information from the T-money Card.

void loop(void) {

uint8_t success;

uint8_t responseLength = 64;

success = nfc.inListPassiveTarget();

if (success) {

Serial.println("Found something!");

uint8_t cardInfo[responseLength];

uint8_t cardNumSize = 0;

uint8_t selectApdu[] = { 0x00, 0xA4, 0x00, 0x00, 0x02, 0x42, 0x00 };

success = nfc.inDataExchange(selectApdu, sizeof(selectApdu), cardInfo, &responseLength);

if (success) {

Serial.print("responseLength: "); Serial.println(responseLength);

nfc.PrintHexChar(cardInfo, responseLength);

if (responseLength >= 24) {

Serial.print("card number : "); nfc.PrintHexChar(cardInfo + 8, 8);

Serial.print("card date : "); nfc.PrintHexChar(cardInfo + 21, 4);

}

}

uint8_t balance[responseLength];

uint8_t balanceApdu[] = { 0x90, 0x4C, 0x00, 0x00, 0x04 } ;

success = nfc.inDataExchange(balanceApdu, sizeof(balanceApdu), balance, &responseLength);

if (success) {

Serial.print("responseLength: "); Serial.println(responseLength);

nfc.PrintHexChar(balance, responseLength);

if (responseLength >= 4) {

uint32_t money = balance[0] * 256 * 256 * 256 + balance[1] * 256 * 256 + balance[2] * 256 + balance[3];

delay(2000);

Serial.print("money : "); Serial.println(money);

}

}

}

else {

}

delay(100);

}

=============================result===========

Waiting for an ISO14443A Card ...

Found something!

responseLength: 53

6F 31 B0 2F 00 10 01 08 12 12 00 11 90 27 40 90 02 80 95 46 48 20 14 04 18 20 19 04 17 01 00 00 07 A1 20 50 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 90 00 o1./.........'@....FH ... ........ P.................

card number : 12 12 00 11 90 27 40 90 .....'@.

card date : 20 14 04 18 ...

responseLength: 6

00 00 06 36 90 00 ...6..

money : 1590

This is the code I tested after purchasing pn532 myself.

As such, we are currently making and implementing packets in hex form through SPI communication in the arduino IDE development environment with CR95HF module. The above type is necessary for the charging type charger, but I asked for your advice because there is no clear data even when referring to the data sheet.

Here's an example of how to implement it.

Here is an example of Tag ID read.

When implementing with current SPI communication, I do the following.

Txdata[50]=;

Txdata[0] = 0x00;

Txdata[1] = 0x04; // cmd

Txdata[2] = 0x02;//data field length

Txdata[3] = 0x26;

Txdata[4] = 0x07;

readCmd(); //Read response

Txdata[0] = 0x00;

Txdata[1] = 0x04; // cmd

Txdata[2] = 0x03;//data field length

Txdata[3] = 0x93;

Txdata[4] = 0x20;

Txdata[5] = 0x08;

readCmd(); //Read response

if (res == 0x80) {

for (j = 0; j < dataNum - 4; j++) {

ID += String(rdata[j], HEX);

}

TAG_flag = 1;

}

else {

TAG_flag = 0;

Select_ISO_IEC_18092_Protocol();

}

}

When you read the Tag ID, you select the ISO protocol and go through that process like the code above to read the ID.

So to read information from the T-money Card like that example, you need information about what packets you send and receive.

[Ulysses HERNIOSUS]

Hi,

Although exchanging hard-coded hex buffers may often work it is not really a way of implementing protocol stacks. What you need to do on top of CR95HF (and also PN532) is to implement a whole 14443 data-link layer which integrates re-transmissions, frame counters, frame chaining, requests for Waiting Time Extensions, etc.

I would recommend you to port over one of the demos from the aforementioned ST25 embedded NFC lib to your target platform.

If you think you can live with card-coded hex strings, then please feel free to implement the necessary APDUs using our ST25 Embedded NFC lib and just sniff the exchanged frames on one of our STM32 systems.

Best Regards, Ulysses