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
