PICO/iClass card not responding to CR95HF

gerrys · ‎2015-11-04

Posted on November 05, 2015 at 08:39

I only need to get the UID of a iClass card. According to the IS15693 specification, it is MANDATORY for the card to respond to the INVENTORY command.

After the card is detected, I set the chip to this protocol format:

0x01 0x09

0x01 is ISO15693 protocol

0x09 is 26Kbps, Wait for SOF, 100% modulation, Single sub carrier, Append CRC.

Then I send the INVENTORY command:

0x26 0x01 0x00 // ISO15693 spec, table 1,5 and 9

0x26 is the flags:

Bit 1: Sub-carrier flag = 0

Bit 2: Data rate flag = 1

Bit 3: Inventory flag = 1

Bit 4: Protocol extension = 0

Bit 5:AFI flag = 0

Bit 6: Nb slots flag = 1

Bit 7: Options flag =0

Bit 8: 0

0x01 is the INVENTORY command

0x00 is the length of the mask, no mask used.

I have another ISO15693 card, and it responds in the correct manner to this request.

What needs to be different for the iClass card?

Please help.

#cr95hf-iclass-pico-iso15693

Peter Boringer · ‎2016-10-18

Posted on October 18, 2016 at 17:47

Dear Gerry,

Their is a 2nd difference seen in your command:

When you execute the send receive command on GP you use 0xAA to perform the ACTAll and 0xAC for the identify

Whereas on DL you used 0x0A for ACTAll and keep 0xAC for identify instead of 0x0C

Can you tell why?

Command Format 1Byte description

7 6 5 4 3 2 1 0

P M1 M0 K Instruction

A ACTAll

C Identify

0 0 0 Response data coding ISO15693-2 Manchester

1 0 1 Response data coding ISO15693-2 ???

P=Bit0 xor Bit1 xor Bit2 xor Bit3 xor Bit4 xor Bit5 xor bit6

Regards

View solution in original post

Nickname5101_O · ‎2015-11-17

Posted on November 17, 2015 at 13:57

Hello ,

issue comes from Picopass which is not ISO 15693 complliant ,

timing are not respected .

We have already implemented a triccky commannd which allow us to support Picopass , a new version of CR95HF devevelopment softaware will be soon available including a dedicated window for PICOPASS .

find below log of a CR95HF / Picopass exchange .

04-22-2015 15:39:42 REM, TEST Tag iso 15693 PICOPASS

04-22-2015 15:39:42 >>> CR95HFDLL_ECHO

<<< 5500

04-22-2015 15:39:42 REM, Protocol selection

04-22-2015 15:39:42 >>> CR95HFDLL_SELECT, 010E

<<< 0000

04-22-2015 15:39:42 REM, CR95HFADJUSTMENT:PICOPASSUSEDONQJE(FORTWOSUBCARRIER)

04-22-2015 15:39:42 >>> CR95HFDLL_STCMD, 01 10270003F39310033B90D600930000F247E2F7F6E3E2E0E1930000F3D500F20AE993CEE9F3938011F6

<<< 0000

04-22-2015 15:39:42 REM, ACTALL

04-22-2015 15:39:42 >>> CR95HFDLL_SENDRECV, AA

<<< 8E00 : Reception lost without EOF received

04-22-2015 15:39:42 REM, IDENTIFY

04-22-2015 15:39:42 >>> CR95HFDLL_SENDRECV, AC

<<< 800B37F931E0FE5F02DC600202

04-22-2015 15:39:42 REM, SEL

04-22-2015 15:39:42 >>> CR95HFDLL_SENDRECV, 2137F931E0FE5F02DC

<<< 800BBEC98F01F7FF12E073F002

04-22-2015 15:39:42 REM, READBLOCK 00 CRC reponse UID

04-22-2015 15:39:42 >>> CR95HFDLL_SENDRECV, AC007333

<<< 800BBEC98F01F7FF12E073F002

04-22-2015 15:39:42 >>> CR95HFDLL_SELECT, 010C

<<< 0000

04-22-2015 15:39:42 REM, CR95HF ADJUSTMENT : PICOPASS USED ON QJE (for One Subcarrier)

04-22-2015 15:39:42 >>> CR95HFDLL_STCMD, 01 10270003F39310033B90D600930000F247E2F7F6E3E2E0E1930000F3D500F20AE993CEE9F3938010F6

<<< 0000

04-22-2015 15:39:42 >>> CR95HFDLL_SENDRECV, 0A

<<< 8E00 : Reception lost without EOF received

04-22-2015 15:39:42 >>> CR95HFDLL_STCMD, 01 10270003F39310033B90D600930000F247E2F7F6E3E2E0E1930000F3D500F20AE993CEE9F393C00EF6

<<< 0000

04-22-2015 15:39:42 >>> CR95HFDLL_SENDRECV, 0C

<<< 800B37F931E0FE5F02DC600202

04-22-2015 15:39:42 >>> CR95HFDLL_SENDRECV, 8137F931E0FE5F02DC

<<< 800BBEC98F01F7FF12E073F002

04-22-2015 15:39:43 >>> CR95HFDLL_SENDRECV, 0C007333

<<< 800BBEC98F01F7FF12E073F002

gerrys · ‎2015-12-04

Posted on December 04, 2015 at 14:39

Thanks!

Now I can read from the iClass card.

gerrys · ‎2016-03-23

Posted on March 23, 2016 at 20:31

Hi

I suspect that I am not reading correctly from the iClass card.

When I send this:

04-22-2015 15:39:42 REM, Protocol selection

04-22-2015 15:39:42 >>> CR95HFDLL_SELECT, 010E

<<< 0000

I get the correct response: 00 00

But when I send this:

04-22-2015 15:39:42 REM, CR95HFADJUSTMENT:PICOPASSUSEDONQJE(FORTWOSUBCARRIER)

04-22-2015 15:39:42 >>> CR95HFDLL_STCMD, 01 10270003F39310033B90D600930000F247E2F7F6E3E2E0E1930000F3D500F20AE993CEE9F3938011F6

<<< 8100

my response is 81 00. I do not see a 0x81 error code??? Why do I get this response?

If I send ACTALL

04-22-2015 15:39:42 REM, ACTALL

04-22-2015 15:39:42 >>> CR95HFDLL_SENDRECV, AA

<<< 8E0E0000000000000000000000000001

This is a summary of my comms with the card:

iClass Select(>>01 0E): 00 00

ST(>>10270003F39310033B90D600930000F247E2F7F6E3E2E0E1930000F3D500F20AE993CEE9F3938011F6): 81 00

ACTALL(>>AA): 8e 0e 00 00 00 00 00 00 00 00 00 00 00 00 00 01

IDENTIFY(>>AC): 80 0b f4 c9 36 20 ff 5f 02 dc f4 bb 02

SEL(>>21f4c93620ff5f02dcf4): 80 0b a6 4f b6 01 f9 ff 12 e0 86 14 02

READBLOCK0(>>AC007333): 80 0b a6 4f b6 01 f9 ff 12 e0 86 14 02

Why do I get the same response for the SEL and READBLOCK requests?

The bytes I receive from the CR95HF has no relation to any byte I receive from an iClass reader.

For this same card, the iClass reader sends me this string(iClass GP type card):

00 11 0a 44 00 00 00 00 bd 09 9e 07 81 05 06 56 8d 1e 40 0f 89

I would like to get the same info from the card as the iClass reader.

Thanks

NFC/RFID Customer support · ‎2016-03-29

Posted on March 29, 2016 at 10:47

Hello,

to be able to set PicoPass specific RF protocol on CR95HF, you need to send : CR95HFDLL_SELECT, 010E.

Anyway, depending on CR95HF IC revision you will use, you will need to send additional command : CR95HFDLL_STCMD, 01 10270003F39310033B90D600930000F247E2F7F6E3E2E0E1930000F3D500F20AE993CEE9F3938011F6 -> but this additional command must be sent only if the CR95HF IC revision number is

QJE

. This command must NOT be used for QJC revision. Sending it on QJC will answer 8100 when sending it on QJE answer 8000.

To be able to detect CR95HF IC revision, you can use IDn command :CR95HFDLL_IDN.

for QJC , the answer is 000F4E4643204653324A415354320075D2 (ASCII=

NFC FS2JAST2)

for QJE , the answer is 000F4E4643204653324A41535434002ACE (ASCII=NFC FS2JAST4)

About READ & SELECT, the block 0 of PicoPass products contains ID of the tag reply in SELECT command, this is the reason why the answer is the same.

For iClass reader communication management & response, we don't know what communication is done between the reader & the iClass IC, You can use a RF SPY to decode RF communication done.

Best Regards

RF/NFC support team

gerrys · ‎2016-09-08

Posted on September 08, 2016 at 15:34

Hi

Our first batch of readers was built with QJC, FS2JAST2.

I could read the iClass GP and iClass DL cards.

To read GP card:

send: CR95HFDLL_SELECT, 010E

send: 10270003F39310033B90D600930000F247E2F7F6E3E2E0E1930000F3D500F20AE993CEE9F3938011F6

send: CR95HFDLL_SEND_RECEIVE, AA // ACTALL

send: CR95HFDLL_SEND_RECIEVE, AC // IDENTIFY

I can now read the card.

To read DL card:

send: CR95HFDLL_SELECT , 010C

send: 10270003F39310033B90D600930000F247E2F7F6E3E2E0E1930000F3D500F20AE993CEE9F3938010F6

send: CR95HFDLL_SEND_RECEIVE, 0A // ACTALL

send: CR95HFDLL_SEND_RECEIVE, AC // IDENTIFY

now I can select and read the card.

NOTE: the only difference in the long string sent to the chip is the second last byte , 0x11 to 0x10. Also, the ACTALL command is different for the 2 cards.

The new batch of readers was built with QJE, FSJAST4 chips.

Now I can read the GP cards, but not the DL cards.

Please advice what to do, as I need to deliver the readers by next week, and I have tried everything to read the DL card.

Thanks

Gerry

Peter Boringer · ‎2016-10-18

Posted on October 18, 2016 at 17:47

Dear Gerry,

Their is a 2nd difference seen in your command:

When you execute the send receive command on GP you use 0xAA to perform the ACTAll and 0xAC for the identify

Whereas on DL you used 0x0A for ACTAll and keep 0xAC for identify instead of 0x0C

Can you tell why?

Command Format 1Byte description

7 6 5 4 3 2 1 0

P M1 M0 K Instruction

A ACTAll

C Identify

0 0 0 Response data coding ISO15693-2 Manchester

1 0 1 Response data coding ISO15693-2 ???

P=Bit0 xor Bit1 xor Bit2 xor Bit3 xor Bit4 xor Bit5 xor bit6

Regards

Charles Walker · ‎2017-01-26

Posted on January 27, 2017 at 01:40

Hi,

I m trying to do the same here. Using SPI to communicate with the chip. I retrieve the IDN with 0x01 00.

My chip is 4E 46 43 20 46 53 32 4A 41 53 54 34 00 2A CE so i m trying to send your workaround command:

0x10 27 00 03 F3 93 10 03 3B 90 D6 00 93 00 00 F2 47 E2 F7 F6 E3 E2 E0 E1 93 00 00 F3 D5 00 F2 0A E9 93 CE E9 F3 93 80 11 F6

but still unable to detect any badge iclass px .

Can you please details the long command string you provide ? 0x10 do not match any possible command code (unless it is part of the undescribe command : Other codes ST Reserved (from table 6 of CR95HF documentation) ?

It is hard to implement the solution proposed without understanding it a little more in detail (especially since i m not using your software but raw SPI)

Thx in advance, Charles Walker

SJova · ‎2021-02-09

Hello,

after a lot of unsuccessful retries i finally read the card ID, but when i compare the number which the reader give me with real card number there is a difference.

Real card number: E0 12 FF F9 01 62 F9 F8

Card number from my reader: 3F 5F 2C 20 FF 5F 02 1C 20 74

I suppose that 10 bytes from the reader contain 2 bytes CRC, but the card number is complete different.

I read a lot of documentation for HID iclass, i do not found that card ID is encoded.

Please give me advice how to extract the real number from the number which the reader send me.

Ulysses HERNIOSUS · ‎2021-02-09

Hi Sjova.2,

as far as I know these cards have two different identifiers. One only being reported during anti-collision. And with this first identifier you then need to retrieve the card's real UID.

Please inspect the data sheet, I found some on the web detailing such.

Best Regards, Ulysses