PICO/iClass card not responding to CR95HF

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.

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 .

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?

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

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.

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.

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)