Searching \ for 'Smart cards' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/index.htm?key=smart+cards
Search entire site for: 'Smart cards'.

Truncated match.
PICList Thread
'Smart cards'
1997\08\19@201826 by Rick Trostel

picon face
<< Subj:        Re: Magnetic card reader.
Date:  97-08-19 16:49:30 EDT
From:  spam_OUTkcw.kcwccTakeThisOuTspamSYMPATICO.CA (KcW)


I agree. Magnetic cards are old hat. Standalone smart card reader/writers
can be built very inexpensively (read <$20 in pats) and the ISO7815 cards
are about a buck in small quantities with gobs of room for data. As well,
the cards can be made secure, reducing the need for PIC based algorithms.
 >>



Does any one know of any links or other info on smart cards?
Any kind of introduction or beginner info would be great.

Rich

1997\08\19@204310 by WF AUTOMAO

flavicon
face
Rick Trostel wrote:
>
> << Subj:        Re: Magnetic card reader.
>  Date:  97-08-19 16:49:30 EDT
>  From:  .....kcw.kcwccKILLspamspam@spam@SYMPATICO.CA (KcW)
>
>  I agree. Magnetic cards are old hat. Standalone smart card reader/writers
>  can be built very inexpensively (read <$20 in pats) and the ISO7815 cards
>  are about a buck in small quantities with gobs of room for data. As well,
>  the cards can be made secure, reducing the need for PIC based algorithms.
>   >>
>
> Does any one know of any links or other info on smart cards?
> Any kind of introduction or beginner info would be great.
>
> Rich

http://www.xicor.com

1997\08\19@204704 by .EDU>

flavicon
face
>> I agree. Magnetic cards are old hat. Standalone smart card reader/writers
>> can be built very inexpensively (read <$20 in pats) and the ISO7815 cards
>> are about a buck in small quantities with gobs of room for data. As well,
>> the cards can be made secure, reducing the need for PIC based algorithms.
>
>Does any one know of any links or other info on smart cards?
>Any kind of introduction or beginner info would be great.
>
>Rich

Not only are mag-stripe cards old hat, but contacted (ISO-7816, not -7815)
smartcards are old hat, too!  See our contactless smartcard web page at
http://www.racom.com.

Peter F. Klammer, Racom Systems Inc.                   PKlammerspamKILLspamACM.Org
6080 Greenwood Plaza Boulevard                            (303)773-7411
Englewood, CO  80111                                  FAX:(303)771-4708

1997\08\20@115917 by Glenn Johansson

flavicon
face
part 0 274 bytes
Talking about old hats - I thought all personal identification was done in fingerprint scanners nowadays? No cards to issue, carry around, forget and lose... Identifying vehicles (which was originally the topic) should of course be done via license-plate reading cameras.


1997\08\20@132936 by Tim Kerby
picon face
Hi
I like the technology of smartcards but the stick in a slot action is not
as pleasing as swiping a card through a reader.  How about a swipe based
card anyone?


Tim


At 16:27 20/08/97 +-200, you wrote:
>>Not only are mag-stripe cards old hat, but contacted (ISO-7816, not -7815)
>>smartcards are old hat, too!  See our contactless smartcard web page at
>>http://www.racom.com.
>
>Talking about old hats - I thought all personal identification was done in
fingerprint scanners nowadays? No cards to issue, carry around, forget and
lose... Identifying vehicles (which was originally the topic) should of
course be done via license-plate reading cameras.
>
>
>Attachment Converted: "e:\eudora\attach\Re Smart cards"
>


------------------------------------------------------------------
Personal Web Pages: http://web.ukonline.co.uk/members/tim.kerby/
Email: .....tim.kerbyKILLspamspam.....ukonline.co.uk
------------------------------------------------------------------

1997\08\20@183427 by David Bramham

picon face
Hi,
       Could you please advise as to what format your attachment is in.
Thanks -David


At 04:27 PM 20/08/97 -0200, you wrote:
>>Not only are mag-stripe cards old hat, but contacted (ISO-7816, not -7815)
>>smartcards are old hat, too!  See our contactless smartcard web page at
>>http://www.racom.com.
>
>Talking about old hats - I thought all personal identification was done in
fingerprint scanners nowadays? No cards to issue, carry around, forget and
lose... Identifying vehicles (which was originally the topic) should of
course be done via license-plate reading cameras.
>
>
>Attachment Converted: "C:\EUDORA\ATTACHMT\Re Smart cards"
>

1997\08\21@214742 by .EDU>

flavicon
face
>>Not only are mag-stripe cards old hat, but contacted (ISO-7816, not =
>-7815)
>>smartcards are old hat, too!  See our contactless smartcard web page at
>>http://www.racom.com.
>
>Talking about old hats - I thought all personal identification was done =
>in fingerprint scanners nowadays? No cards to issue, carry around, =
>forget and lose... Identifying vehicles (which was originally the topic) =
>should of course be done via license-plate reading cameras.

But a smartcard is a writeable, portable reservoir of data; your fingertip
can't do that!  (You really don't propose a fingerprint database to allow
entering a subway or bus, do you?)  A smartcard can be a vessel of value,
or a delegated agent to execute your bidding.  You're thinking of something
like ``RFID'' -- which is read-only.  We do ``RFTP'' -- Radio-Frequency
Transaction Processing, which is read AND write, with security, at a wave
of your hand.

Peter F. Klammer, Racom Systems Inc.                   EraseMEPKlammerspam_OUTspamTakeThisOuTACM.Org
6080 Greenwood Plaza Boulevard                            (303)773-7411
Englewood, CO  80111                                  FAX:(303)771-4708

1997\08\22@080242 by rlunn

flavicon
face
Tim Kerby wrote:

> I like the technology of smartcards but the stick in a slot
> action is not as pleasing as swiping a card through a reader.
> How about a swipe based card anyone?

       Well, there is a small problem with maintaining a
       continuous power supply to the smartcard while it's
       being swiped...

       In fact, there have been so many problems with the
       cards being removed halfway through a write to the
       eeprom that most manufacturers are now designing
       captive card readers.  The card is physically pre-
       vented from being removed until the memory update
       is complete.

___Bob

1997\08\22@132807 by .EDU>

flavicon
face
> Tim Kerby wrote:
> > I like the technology of smartcards but the stick in a slot
> > action is not as pleasing as swiping a card through a reader.
> > How about a swipe based card anyone?
>         Well, there is a small problem with maintaining a
>         continuous power supply to the smartcard while it's
>         being swiped...
>
>         In fact, there have been so many problems with the
>         cards being removed halfway through a write to the
>         eeprom that most manufacturers are now designing
>         captive card readers.  The card is physically pre-
>         vented from being removed until the memory update
>         is complete.
> ___Bob

Which is EXACTLY why we DON'T rely on EEPROM; we use FRAM!  Ferroelectric
RAM (there's nothing magnetic about it, folks, the ``ferro'' moniker is
historical accident) is batteryless nonvolatile RAM which writes and reads
as fast and low power as SRAM.  Inevitably (even with a contacted card in
a slot) you still have to cope with abrupt ``tear-out'' transaction
interruption, but when you can complete a transaction in 100 msec, it
becomes a rare event, not a common one.  (And one that any competent
database-aware computer scientist knows how to handle reliably.)

Spend time at http://www.racom.com to see what I'm talking about.

Peter F. Klammer, Racom Systems Inc.                   PKlammerspamspam_OUTACM.Org
6080 Greenwood Plaza Boulevard                            (303)773-7411
Englewood, CO  80111                                  FAX:(303)771-4708

1997\08\23@023356 by John Payson

flavicon
face
> Which is EXACTLY why we DON'T rely on EEPROM; we use FRAM!  Ferroelectric
> RAM (there's nothing magnetic about it, folks, the ``ferro'' moniker is
> historical accident) is batteryless nonvolatile RAM which writes and reads
> as fast and low power as SRAM.  Inevitably (even with a contacted card in
> a slot) you still have to cope with abrupt ``tear-out'' transaction
> interruption, but when you can complete a transaction in 100 msec, it
> becomes a rare event, not a common one.  (And one that any competent
> database-aware computer scientist knows how to handle reliably.)

Unfortunately, Ramtron's two-wire FRAM products are more succeptible than
two-wire EEPROMs to a particular type of glitch that has caused much
annoyance: if the clock wire starts thrashing during a the "write" part of
a transaction, data in the device may be erased (WILL be erased if the
clock thrashes enough times).  Given that all read operations must be
preceded by a "write" to set the address, it's possible for this to happen
even if no code in the processor deliberately tries to write the data in
the chip.

The problem with FRAMs that makes them prone to this failure is that there
is no checking to ensure that a command is terminated properly.  On many
of the EEPROM devices, failure to receive a proper "stop" condition
following a byte-write or page-write command will result in the entire
command being ignored.  Since it's unlikely that a flailing CPU would
generate a valid stop condition at just the right time, the glitched
command would most likely not disrupt anything.  Unfortunately, the FRAM
has no "page-write" structure; every byte received is written to the chip
immediately.  Since it is perfectly legal for the CPU to hold the data
line low continuously while sending zero bytes(*) the FRAM will write all
the zeroes it receives to memory without realizing anything is wrong.  By
the time the FRAM receives an improper start/stop sequence, bad data will
have already been written and undoing the command will be impossible.

(*) The FRAM could, I suppose, look for the CPU to let the data line float
   after clocking out the LSB of a byte.  I think normal I2C behavior,
   however, suggests that the FRAM should assert its data line as soon as
   it sees the clock go low following the LSB; consequently it would have
   no way of knowing that the CPU was also holding it low.  Perhaps it
   could let the line float and pull it low once it's been observed to
   float, but this would introduce some additional timing complexities
   and is not, as far as I recall, part of the I2C specification.

Unless/until Ramtron remedies this defect, I would not recommend the use
of an FRAM in applications where reliability is important(**).

(**) In the particular application which failed, unexpected disconnection
    of CPU power would have about a 0.5% chance of disrupting memory
    contents.  Not terribly common, but if you plugged/unplugged the
    thing a lot it would fail.  Although the addition of a CPU/power
    monitor chip solved the problem, I'm still leery of the device for
    having that failure mode.

(***) This particular project used an 8x51-style processor, with the
     FRAM's data tied to P3.6; the stuff on port 0 happened to produce
     a "MOVX A,@R1" opcode.  Those familiar with the 8x51 can probably
     see what this means.  For those unfamiliar with the 8x51, it will
     attempt to fetch code from any address; addresses inside the chip
     are mapped internally.  For those outside the chip, it outputs the
     address on some port pins and then tries to read the data from port
     0.  The "MOVX A,@R1" command, as part of its functioning, briefly
     asserts P3.6 [which doubles as /RD for external memory].  Since P0
     always has the "MOVX A,@R1" code on it, the 8x51 will do nothing but
     flail P3.6 repeatedly.  Oops...

Anyway, I'm sure many people have used FRAMs without problem, but given
the above experience I'm a bit reluctant to do so... after all, there's
never "just one" bug lurking in the corner...

1997\08\24@024644 by rlunn

flavicon
face
John Payson wrote:

> > Which is EXACTLY why we DON'T rely on EEPROM; we use FRAM!
>
> Unfortunately, Ramtron's two-wire FRAM products are more succeptible than
> two-wire EEPROMs to a particular type of glitch...

       Umm, Peter didn't say anything about using a Ramtron FRAM chip.
       He only indicated the use of memory based on FRAM technology.

___Bob

1997\08\25@131724 by Marc 'Nepomuk' Heuler

flavicon
face
Hi John (John Payson), in <@spam@199708230633.BAA22381KILLspamspamKitten.mcs.com> on Aug 23 you
wrote:

> Unfortunately, Ramtron's two-wire FRAM products are more succeptible than
> two-wire EEPROMs to a particular type of glitch that has caused much
> annoyance: if the clock wire starts thrashing during a the "write" part of
> a transaction, data in the device may be erased (WILL be erased if the
> clock thrashes enough times).  Given that all read operations must be
> preceded by a "write" to set the address, it's possible for this to happen
> even if no code in the processor deliberately tries to write the data in
> the chip.

Thank you for explaining the problem in such detail. I was not aware of it,
working on an FRAM implementation right now.

Another note to the topic:  Some FRAMs (24C16 for example) have a write
protection, which allows to protect the upper half of its memory.  You can
control it with one pin, so you end up with a 3-wire-comm in case you want
to protect your memory.


'smart cards'
1998\12\15@034704 by Norayr S. Elmayan
flavicon
Could you tell me the difference between a keeloq smartcard versus PIC16f84
smartcards?

1.Have anyone used keeloq smartcards?
2.Is it easy to interface to any Pics?
3.Any suggestion on costs?
4.How about 16F84 smarcards, it seems even more pwerful than keeloq?

Please comment.
Thanks.

Norayr

More... (looser matching)
- Last day of these posts
- In 1998 , 1999 only
- Today
- New search...