RFID

Hello

I'm pretty new to micro's, I'm trying to build an automatic door unlock-locking system using RFID. I've searched and found a lot of info, so much in fact that I am now thoroughly confused! Can someone point me in the right direction? I'm not looking for any hand holding, just some info that relates to my specific application.

TIA

Robert

This is a good tutorial. It helped me get started with RFIDs

http://www.arduino.cc/playground/Learning/PRFID

Thanks I'll give it a read.

Well I've hit a big snag! First this is the RFID reader I'm using

http://www.seeedstudio.com/depot/125khz-rfid-module-uart-p-171.html

There is a link to the data sheet on the page. No matter how I wire it up, or which example I try I can't get it to work! Has anyone used this reader before? Any help appreciated.

Robert

Well I figured it out! I'm so pleased with myself that got it working!!

However I'm still working on getting the built in LED/buzzer driver working, so if anyone can help please let me know.

Thanks
Robert
AKA SubMicro

Do you mind posting your code and pin use?

What problem are you having with the LED/buzzer driver?

Here is the code I got this example from alekoy on this thread http://www.arduino.cc/cgi-bin/yabb2/YaBB.pl?num=1248988301

#include <SoftwareSerial.h>
#define rxPin 2
#define txPin 3

SoftwareSerial mySerial= SoftwareSerial(rxPin, txPin);

void setup()
{
Serial.begin(9600);
mySerial.begin(9600);
pinMode(rxPin, INPUT);
pinMode(txPin, OUTPUT);
}

void loop()
{
for (int i=0;i<=13;i++){
Serial.print(mySerial.read(),BYTE);
}
Serial.println(" <<You may enter BITCH!");
delay(1000);
}

My prob is I figured the LED would blink or light up when it read a tag but it dosen't and the datasheet doesn't mention how to implement it. There is a 3 pin header just for this. My plan is to slowly build on the example code. I haven't even gotten to the multiple cards or unlocking the door and I'm stuck! this is going to be a long project!

SubMicro

The center pin gets connected to +5V, the pin away from the end of the card gets connected to Gnd. The pin closest to the end of the card gets connected to the long leg of the LED. The short leg of the LED is connected to Gnd. The LED then blinks whenever a tag is recognized.

Yes I have the datashhet which lists the pinout, do I still need a resistor? Perhaps I need to remove the resistor? I'll try that, if I blow an LED oh well!

Ok Well I thought a had used a resistor, but had forgotten to include one oops! but even so a closer inspection revealed that it in fact was lighting up just very very dim. Probally because i'm not using a wall wart.

New problem, my three key FOB's have their number printed on them. The two credit card's don't.. when the number for the keychain FOB is printed on the serial window it's toally diiferrent than what's on the FOB, with two box symbols, one at each end.
How do I figure out the numbers for the credit cards???

with two box symbols, one at each end.

This implies that it is a non printing ASCII character. If it is at each end it is likely to be a start of block character and the one at the end a check sum.
To test, print out each character in hex (or decimal if you must).

Thanks but how do I

To test, print out each character in hex (or decimal if you must).

??

Also the number printed is nothing like the number on the FOB! it has numbers and letters coming up in the serial monitor!

P.S. You wouldn't be the same Grumpy from ThirdGen??

I use full error checking using the checksum and I found the digit printed on the fob, don`t have any relationship to the rfid tag.

So there is no error there

OR if there is I can`t find it !!!!!

with two box symbols, one at each end.

Looks how the ID20 works :-

it starts with 0x2 , then 12 BCD digits followed by the stop byte 0x3

oops almost forget after the 12 bcd digits is a Cr/Lf

Grumpy from ThirdGen

Sorry no.

OR if there is I can`t find it !

You can't find it. :wink:

Use serial.print(number,HEX); to get the value in hex instead of a character.

I think you are wrong !!!! , or more true sure you are wrong .

But just in case you are right , this is my key fob number printed so what`s the rfid code:-

0003212839 .

and I`ll even give you a clue

3900310xxx , which gives you a 1 in 1000 chance.

What do you mean by the RFID code?

The number printed on the fob is the number you enter into an access control system. The number seen in the field of an RFID reader may be a different number but one must be able to be derived from the other otherwise the system would not work.

Some readers like those from PAC employ a scrambling algorithm inside the reader to convert the number seen in the filed to the number used in the access control system. This is a "one way" algorithm, that is while a unique input produces a unique output you can't take an output and derive a unique input from it.

So from one example of an input and output there is no way I can reverse engineer a solution but there is a relationship that can be found given enough information. That's what I meant by:-

You can't find it.

o.k I do agree with that .

Yes, there most be a relationship between number on the fob and the rfid tag , But I can`t find it.

I don`t know it this is true for ever fob , but the number printered on the fob is a dec number .

eg I can`t say any abcdef of hex .

I don`t know it this is true for ever fob

It is a function of the reader not the fob, I know it is not the case with all readers only some of them.

Well give me all the figures of the RF field and I will see if I can work out a relationship. Is the RF field number hex or decimal? Just because there are no numbers above A doesn't mean it is not hex.
It could also be that there are some bits that are check sum or parity bits and that tends to throw you off as well. Do you know what make it is?

So no one knows how to derive the number from the cards?

No one HERE,SO FAR, knows what the relationship between number printed on the fob and the rfid tag which the card gives out with a card reader.

Getting the rfid data ( tag ) from the card and knowing it MOST be correct, that is different.