decoding F2F algorithm-magnetic stripe reader pro.

hello

I need some algorithm that will decode the F2F signal and output
data+clock signals simultaneously. I will load the program into a
flash based microcontroller. I already have the circuitry that reads
the magnetic analog signal from a magnetic card and amplifies and
converts it to F2F waveform. Remaining part is to decode the F2F
waveform and get the clock+data output. I somehow figured out how to
get data output but I still havent found a way to obtain clock output.
any little suggestion will work.
:-)
regards

MemeT

On 22 Jul 2003 01:09:25 -0700, solmaz <> wrote:
: Remaining part is to decode the F2F
: waveform and get the clock+data output. I somehow figured out how to
: get data output but I still havent found a way to obtain clock output.
: any little suggestion will work.

You can't have data without the clock, so you're mostly there already.
Use the time between pulses during the leading 0s to establish the bit
clock period. Thereafter, a pulse around the middle of that time
period indicates a 1. No pule and it was a 0. A little DPLL could go
a long way here.

Howard Goldstein wrote:
>
> On 22 Jul 2003 01:09:25 -0700, solmaz <> wrote:
> : Remaining part is to decode the F2F
> : waveform and get the clock+data output. I somehow figured out how to
> : get data output but I still havent found a way to obtain clock output.
> : any little suggestion will work.
>
> You can't have data without the clock, so you're mostly there already.
> Use the time between pulses during the leading 0s to establish the bit
> clock period. Thereafter, a pulse around the middle of that time
> period indicates a 1. No pule and it was a 0. A little DPLL could go
> a long way here.

As so often happens, this problem is far more complex than it sounds.
Card velocity often varies radically throughout the swipe so picking a
fixed sampling interval is a recipe for failure. Flexing the card while
swiping introduces various kinds of bias which show up as differences in
pulse position and amplitude. Head magnetization causes skews in pulse
size (e.g. wide "highs" and narrow "lows"). All these things need to be
dealt with in order to get reliable reads under all conditions.
--
Tim Hubberstey, P.Eng. . . . . . Hardware/Software Consulting Engineer
Marmot Engineering . . . . . . . VHDL, ASICs, FPGAs, embedded systems
Vancouver, BC, Canada . . . . . . . . . . . http://www.marmot-eng.com

On Tue, 22 Jul 2003 18:31:55 GMT, Tim Hubberstey <> wrote:
: As so often happens, this problem is far more complex than it sounds.
: Card velocity often varies radically throughout the swipe so picking a
: fixed sampling interval is a recipe for failure. Flexing the card while
: swiping introduces various kinds of bias which show up as differences in
: pulse position and amplitude. Head magnetization causes skews in pulse
: size (e.g. wide "highs" and narrow "lows"). All these things need to be
: dealt with in order to get reliable reads under all conditions.

Good and valid points. Would you find a DPLL a bad place to start? A
fuzzy ANN stuffed onto a cheap 87LPC76x?

Howard Goldstein wrote:
>
> On Tue, 22 Jul 2003 18:31:55 GMT, Tim Hubberstey <> wrote:
> : As so often happens, this problem is far more complex than it sounds.
> : Card velocity often varies radically throughout the swipe so picking a
> : fixed sampling interval is a recipe for failure. Flexing the card while
> : swiping introduces various kinds of bias which show up as differences in
> : pulse position and amplitude. Head magnetization causes skews in pulse
> : size (e.g. wide "highs" and narrow "lows"). All these things need to be
> : dealt with in order to get reliable reads under all conditions.
>
> Good and valid points. Would you find a DPLL a bad place to start? A
> fuzzy ANN stuffed onto a cheap 87LPC76x?

It falls more into the realm of digital filtering rather than a DPLL.
I've seen velocity variations as high as 5:1 over a few hundred samples
so trying to track that with a DPLL would be difficult. Hardware I've
been previously involved with captured the time intervals between
transitions and then post-filtered the result to extract the data.
--
Tim Hubberstey, P.Eng. . . . . . Hardware/Software Consulting Engineer
Marmot Engineering . . . . . . . VHDL, ASICs, FPGAs, embedded systems
Vancouver, BC, Canada . . . . . . . . . . . http://www.marmot-eng.com

(solmaz) wrote in message news:<. com>...
> hello
>
> I need some algorithm that will decode the F2F signal and output
> data+clock signals simultaneously. I will load the program into a
> flash based microcontroller. I already have the circuitry that reads
> the magnetic analog signal from a magnetic card and amplifies and
> converts it to F2F waveform. Remaining part is to decode the F2F
> waveform and get the clock+data output. I somehow figured out how to
> get data output but I still havent found a way to obtain clock output.
> any little suggestion will work.
> :-)
> regards
>
> MemeT

go to Magtek web there are plenty of appnotes

Best regards
Tsvetan
---
PCB prototypes for $26 at http://run.to/pcb (http://www.olimex.com/pcb)
Development boards for PIC, AVR and MSP430 (http://www.olimex.com/dev)

On 24 Jul 2003 01:48:37 -0700, solmaz <> wrote:
: thought that it might be easier to do the reading and encoding job
: with a PIC microcontroller(16f628, 16f84 etc.) rather than PLL because
: of the flexibility of the software routines.

DPLLs are easy to implement in software. Realizing a robust decoder
with one is another kettle of fish. How much clock/speed variation
is expected within a swipe?

Howard Goldstein wrote:
>
> On 24 Jul 2003 01:48:37 -0700, solmaz <> wrote:
> : thought that it might be easier to do the reading and encoding job
> : with a PIC microcontroller(16f628, 16f84 etc.) rather than PLL because
> : of the flexibility of the software routines.
>
> DPLLs are easy to implement in software. Realizing a robust decoder
> with one is another kettle of fish. How much clock/speed variation
> is expected within a swipe?

The greater than 5:1 variations I mentioned in a previous post is what I
have seen within one swipe. The way many people use a reader is they
position the card in the slot near the read head and then accelerate the
card throughout the swipe. "Dunk" readers are even worse as the card is
already in contact with the head and accelerates from a standstill as
the card is removed.
--
Tim Hubberstey, P.Eng. . . . . . Hardware/Software Consulting Engineer
Marmot Engineering . . . . . . . VHDL, ASICs, FPGAs, embedded systems
Vancouver, BC, Canada . . . . . . . . . . . http://www.marmot-eng.com