Hi, I sincerely can't think of a real-world, largely deployable one.
I'm just aware of a specific demo where two cards in the same fields exchanged value. I didn't even see the demo, a colleague described it to me. Given the relatively small reading distance (5 cm) of a normal 13.56 MHz reader, reading more than one card at once does not really makes sense. Moreover, I can think of lots of technical problems with such a reader, for example field strength problems. Regards Sebastien On Fri, Jan 28, 2011 at 1:50 PM, Alexei Soloview < [email protected]> wrote: > 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 > >
_______________________________________________ Muscle mailing list [email protected] http://lists.drizzle.com/mailman/listinfo/muscle
