Question

an application I am working on requires to detect, as quick as possible (in 500 ms maximum), that a card is removed from the field.

Here is what I did to test the time needed to detect that absence of the card:

public static long timeToGetCardAbsent(int version) throws CardException{
    TerminalFactory factory = TerminalFactory.getDefault();

    CardTerminals terminalList = factory.terminals();
    CardTerminal ct = terminalList.list().get(0);

    long connectTime = 0, disconnectTime = 0;

    ct.waitForCardPresent(0);
    connectTime = new Date().getTime();

    ct.waitForCardAbsent(0);
    disconnectTime = new Date().getTime();

    return disconnectTime - connectTime;
}

When the program is running, I tap a (DESFire) contactless card on the reader and remove it immediatly.

Here are the outputs:

1437
1437
1438
1437
1422

I means that the reader (or the program?) needs almost 1.5 seconds to detect that the card is absent, which too long time for me.

Is there a way to speed up this detection? I am currently using javax.smartcardio, would I get better results with another library? I actually don’t know what else I could use, do you have leads?

Thanks,
GChabot

Answer 1

I actually managed to improve the detection time a lot today. I was looking at that web page from “NFC Wizard” and noticed that they were very fast at detecting my card removal. This javascript web page communicates with the reader through a Java applet, so it really uses nothing more than I have.

SpringCard, the creators of NFC Wizard, actually provides complete documentation and even source code for a similar application at that page, under Other resources > Java and “SpringCard PC/SC SDK (ZIP archive)”.

While browsing their code, I noticed that after performing operations on the card, the use the card.disconnect(false); function (I had tried to use card.disconnect(true); but had the same results as before…bad luck).

So here is now what I do :

import java.util.Date;
import javax.smartcardio.*;

public class NewMethod {
    private long connectTime = -1;
    private long disconnectTime = -1;

    private TerminalFactory factory;
    private CardTerminals terminalList;
    private CardTerminal ct;

    public NewMethod() throws CardException{
        factory = TerminalFactory.getDefault();

        terminalList = factory.terminals();
        ct = terminalList.list().get(0);
    }

    public long waitForCardPresent(){
        try {
            ct.waitForCardPresent(0);
        } catch (CardException e) { }
        return new Date().getTime();
    }

    public long waitForCardAbsent(){
        while(true){
            try {
                Thread.sleep(10);
            } catch (InterruptedException e1) { }

            try{
                ct.connect("*").disconnect(false);
            }
            catch(Exception e) {
                return new Date().getTime();
            }
        }
    }

    public void run(){
        while(true){
            connectTime = waitForCardPresent();
            disconnectTime = waitForCardAbsent();
            System.out.println((disconnectTime-connectTime));
        }
    }

    public static void main(String[] args){
        NewMethod nm;
        try {
            nm = new NewMethod();
            nm.run();
        } catch (CardException e) {
            e.printStackTrace();
        }
    }
}

(The thread part is optional but I got the same results with or without it so I preferred to save a bit of processor consumption)

Here are the times I got with the threaded version: 531, 437, 656, 657, 735, 657, 547, 844, 15, 766, 859, 563, 765, 562, 422, 437, 563, 562, 562, 672, 672, 16, 547, 546, 672, 15, 344
and here with the unthreaded version: 984, 547, 796, 656, 796, 718, 656, 812, 625, 781, 813, 547, 797, 532, 407, 609, 719, 328, 469, 328, 0, 546, 625, 0, 843, 703

We may notice that the results are quite unstable (and quite better with the threaded version actually), this might come from the way I tap the card against the reader but I believe this is not the only reason.

It looks good enough for me now. I just hope I won’t get a too great variability when I will actually use it on my application.