cancel
Showing results for 
Search instead for 
Did you mean: 

No ATQB after REQB in custom NFC modul, although Type-A communication works.

adambartyzal
Associate II

Hello,

I'm developing custom NFC modul with CR95HF and I'm having difficulties with reading ISO 14443-B card. So far I've built a hardware prototype and written a simple python class and script for controlling CR95HF protocol. With ISO 14443-A I'm able to obtain cascade level 1 and 2 UIDs but Type-B doesn't respond to REQB message.

log of Type-B communication with commentaries:

> 0x55 # using echo as wake puls

> 0x55 # echo

< 0x55 # echo back

> 0x02020301 # protocol select B, 106 up, 106 down, CRC append

< 0x0000 # ok

> 0x0903680001 # Write the ARC_B register index at 0x01:

< 0x0000 # ok

> 0x0803690100 # Read from ARC_B

< 0x000120 # a little weird answer, datasheet says 0x2F is default value for Type B

> 0x0403050000 # REQ B - all families, param n=1 - card should send ATQB without waiting for slotmarker

< 0x8700 # no card

I've also tried protocol select as:

> 0x020403010180 

as in dataasheet example without luck and all combinations of possible gain and modulation index values.

Unfortunatelly I have very little info about the card itself but using elatec TWN4 reader I've confirmed it's working and read it's UID. 

Right now I'm suspecting impedance matching of the circuit itself, but I've been tuning it using generator and osciloscope and the Type-A card can be read from 5 cm distance.

Any idea what shoud I do now?

the python code is in repo here:

https://github.com/adambartyzal/cr95hf.git

Thanks for any reply,

Adam

1 ACCEPTED SOLUTION

Accepted Solutions
adambartyzal
Associate II

For future visitors of this thread:

It turned out the card is a Calypso card which use a Pre ISO14443-B protocol called B' Prime, also known as Innovatron protocol. After obtaining documentation from Calypso, I discovered that the structure of RF response is different, namely the SOF and EOF have different form, therefore CR95HF cannot be used. I was recommended to use either ST25R3911B or ST25R3916, which can pass raw data to user's MCU.

Thanks one more time for ST's support.

Adam

View solution in original post

8 REPLIES 8
adambartyzal
Associate II

Update:

Using osciloscope I managed to sniff a sequence that TWN4 sends to the card. It's as follows:

x000B3B80

so using sendCommand i replicated the process with my nfc module as

>0x0404000B3B80

and the card does answer (it's visible on the osciloscope) but from cr95hf i get only

<0x6700

which according to the datasheet means error: ETr1 Too Big Too long.

I found that TR1 is a time when card is alowed to transmit unmodulated carrier frequency, but man I feel pretty lost now. Any change of TR1 in protocol select leads to x8700 no card error

ideas?

Brian TIDAL
ST Employee

Hi,

do you have information about this tag (manufacturer and model)? is it a public transport/ticketing tag?

x000B3B80 is likely not a REQB so this tag is likely not a ISO 14443-3 B tag i.e. it does not support REQB.

Rgds

BT

In order to give better visibility on the answered topics, please click on Accept as Solution on the reply which solved your issue or answered your question.
adambartyzal
Associate II

Hi,

thank you Brian for your reply.

It's a transportation card. Namely "Yélo Card" from french city La Rochelle. Here's what TWN4 says about it:

ISO14443B ~ UID Length 32 Bits ~ UID HEX C30ABADD

Which is why i believe it's a type B card. Also, the sniffed message comes right after WUPB command as seen on screenshot from osciloscope:0693W000005AIOzQAO.pngabove is a recording of communication with the twn4 reader since RFon to the card response. The first modulation of the carrier is WUPB command (which I believe is a REQB with 0x08 as a parameter) and just 10ms after comes the x000B3F80 (I miss-typed previously F for B, sorry for that, both produces an answer by the way, probably it's only a parameter).

edit: new observation:

no WUPB is necessary to initiate the answer, so maybe it truly isn't Type B card afterall.

I need to read this particular Yélo card type though, what ever the type is.

another edit:

After several hours of searching the internet I'm now almost sure the card is one of Calypso Cards which uses Innovatron protocol. So my new qusetion is. Is it possible to use CR95HF with that protocol?

Brian TIDAL
ST Employee

Hi,

such public transport tags often use modified ISO14443B framing and are therefore not ISO14443B compliant.Thus, such tags are not compliant with CR95HF reader.

Can you give more information about your application and why you need to support this particular tag?

Rgds

BT

In order to give better visibility on the answered topics, please click on Accept as Solution on the reply which solved your issue or answered your question.
adambartyzal
Associate II

Well that's quite unfortunate.

We're a bikesharing company called freebike (formerly homeport) and in the La Rochelle city we operate a system of docking pedal bikes for many years, but now we've added e-bikes which can be rented by swiping rfid card. One of the city demands was to incorporate their city transport card into our system. We already use the twn4 readers which work fine but are rather expensive therefore we're developing our own one using st microchip.

Since I'm able to make the card reply to me (and i'm hundred percent sure, the UID is coded within the answer) isn't there any way how to read the raw data? It seems the twn4 also use some direct reading method when reading calypso card.

our webpage:

https://freebike.com/en/

Adam

adambartyzal
Associate II

For future visitors of this thread:

It turned out the card is a Calypso card which use a Pre ISO14443-B protocol called B' Prime, also known as Innovatron protocol. After obtaining documentation from Calypso, I discovered that the structure of RF response is different, namely the SOF and EOF have different form, therefore CR95HF cannot be used. I was recommended to use either ST25R3911B or ST25R3916, which can pass raw data to user's MCU.

Thanks one more time for ST's support.

Adam

Hi,

small additions from ST:

Typically these protocols are supported by using no_sof and no_sof configuration bits inside ST25R3911B and ST25R3916 families.

I recommend to experiment with such cards on e.g. the Debug tab of ST25R3911B-DISCO: Set B' or CTS mode and try to exchange frames according to the card's data sheet using TxRxNBytes function. One can also manually play with no_sof / no_eof in the Register map if needed.

Regards, Ulysses

Just a small update after 3 months.

In the end I've decided to choose ST25R3917 since it has less (for me) unnecessary features than it's siblings. It's far less intuitive than CR95HF (at least when you decide not to use RFAL as I did cause I want my code to be as minimalistic as possible) especially the RF settings but it's way more capable. I was able to communicate with both ISO14443-A type cards and Innovatron B' cards. Antenna matching seemed a bit easier than with CR95HF, but that might have been caused by me doing it for the second time. Anyway.. if anyone is going to have troubles with B'prime cards the ST25R3917 is a good choice.

Adam