F2F decoding 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

Reply to
solmaz
Loading thread data ...

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.

Reply to
Howard Goldstein

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
 Click to see the full signature
Reply to
Tim Hubberstey

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?

Reply to
Howard Goldstein

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
 Click to see the full signature
Reply to
Tim Hubberstey

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)
Reply to
Tsvetan Usunov

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?

Reply to
Howard Goldstein

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
 Click to see the full signature
Reply to
Tim Hubberstey

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.