Hello, Sebastien!
I’m working in reader’s manufacturer company J At this time I try to build a list of requirements to upgrading of functionality of driver to our RFID-reader. At this time we think that simple consecutive reading of all present chips in the field are enough. Do you know use cases where reader should work with more than one card and capability of consecutive reading is not enough(for example, use case with reading first card, reading second card, processing data on terminal, writing something on first card)? Sincerelly, Alexei. From: [email protected] [mailto:[email protected]] On Behalf Of Sebastien Lorquet Sent: Friday, January 28, 2011 12:04 PM To: MUSCLE Subject: Re: [Muscle] Access to multiple contactless cards using PCSC-Lite I was affirmative because I'm working in a contactless card company ;-) Apart from that, I'm totally OK with your advice: avoid it, because of reliability (but cards advertising CID support shall work as expected), but also availability on cards, and availability via pcsc/ccid. This is a possible, but low level feature, and far from supported by all cards and readers. Sebastien On Thu, Jan 27, 2011 at 11:41 PM, s.ferey <[email protected]> wrote: Hi, To be honest I hesitated a bit before being so affirmative :) You are right, "if the card supports CID" and reader firmware / middleware let you manage the full frame building, you should be able to talk to different chips (identified by their CID) w/o halting them. But (based on experience) some chips do not support CID (or NAD) and reader SDKs won't always let you manage the CID (ie the targeted chip). So my advice was actually: try to avoid it because of the leak of reliability. Sylvain. Le 27/01/2011 15:31, Sébastien Lorquet a écrit : Hi, are you sure the CID function is not usable to keep a live context in more than one card (in the same field of course)? Only the card with the targeted CID value will reply to a command that contains this CID. At least, IIUC... it means that with CID support, you don't need to halt the cards you're not talking to... Sebastien On Thu, Jan 27, 2011 at 2:57 PM, s.ferey <[email protected] <mailto:[email protected]>> wrote: Hi, As Ludovic yet answered you can manage that sequence (ie card requests, tag/chip enumeration, selection of one of them) yourself as long as some API give you access to such functions; but for most of readers the PC/SC driver is opaque to these operations -- in short PC/SC manages APDU exchanges as per ISO 7816/14443-4 but hide details of protocol stack as per ISO 7816/14443-3; or other way to explain the reader firmware implements 14443-3 while the reader driver implements 14443-4 with PC/SC syntax. That said, some readers manufacturer provide proprietary API offering direct access to the protocol - this includes (and is not limited to) Integrated Engineering (SmartID), ID3 semiconductors (CL1356), Pro-Active (SpringCard), certainly also OmniKey or DUALi that offers a valuable SDK. Last point, your sequence: "Select one of them and read it; Select another and read it" is valid but do not expect to read several chips simultaneously (it's certainly not required); indeed some several chips are in the field the reader shall "select" one and "halt" the other ones, from the chip point of view the "halt" is (more or less) a soft reset (it will keep its UID but will lose its context) and thus it is not possible to suspend and then resume the exchange of APDUs. Sylvain.
_______________________________________________ Muscle mailing list [email protected] http://lists.drizzle.com/mailman/listinfo/muscle
