Hey Gang,
What would it take to interface with one of these?
Page 8 has pinouts, I see RS232 & I2C, do you think it just outputs the RFID info when it reads one, or would an Arduino connected to it need to provide a lot more support?
The idea is that users are given a card upon entering a building and the serial number of the card is linked to their name, they swipe the card at different locations and a record is kept of where they went via Arduino back to central location via RS485, when they turn in the card upon leaving, they get a print out with info about the location swiped at.
Pretty informal, does not need encryption or anything.
Or is there a simpler reader solution?
From section 5.1 of the third document above
It seems like getting a number back from a card should be pretty straightforward.
I got to this one from the ACS122, which seemed to require having USB host capability.
If I can go straigth serial, or I2C, that simplifies the interfacing, and not have to deal with PC APIs and all that.
Looks like it's true RS232 voltage levels since it's able to talk to a PC, so you'll need to handle that. Apart from that it looks like you can just talk to it in ascii mode and tell it to do continuous read.
I am not committed to any module. I started with ACS122 and was working my way backwards to a module that was easier to work with at the uC level.
The e-bay module looks pretty compact. I am thinking of arranging a bunch of these in an area, so low cost is good.
I don't know if one can buy a bunch from e-bay, that's always a drawback.
I had been looking at modules from alibaba also, there's a bunch listed with not much data provided.
I'll be testing the module I ordered as soon as it gets here (up to 60 days )
Since I'm into a similar project, I'm interested in knowing what kind of protocol would you use to communicate between the reeading stations an the central arduino.
I was thinking to have the central station poll each remote; if they had data, they'd be requested to send it:
master to remote1: got data?
remote1 to master: no
master to remote2: got data?
remote2 to master: yes, xx bytes
master to remote2: send data
remote2 to master: data, data data...
master to remote2: xx bytes received
(remote2 then deletes the data, master sends data to the PC it connected to)
master to remote3: got data?
remote 3 to master: no
...
I am guessing probably not.
Probably something simpler:
master to remote1: got data? >> 0xAA, 0x01 AA indicate query to a remote, 01 indicates address
remote1 to master: no >> 0x55,0x01, 0x00 00 indicate no data
master to remote2: got data? >> 0xAA, 0x02
remote2 to master: yes, xx bytes >> 0x55, 0x02, 0x01 to 0xFF, 1 to 255 bytes
master to remote2: send data >> 0xA5, 0x02 A5 indicate send data, 02 says who is to send
remote2 to master: data, data data... >> 0x55, byte1, byte2, byte3, ...byteN, 0x5A when done
(master receives data, check that correct number of bytes received, with start & end 55/5A as simple check)
master to remote2: 0xA0, 0x02
(remote2 then deletes the data, master sends data to the PC it connected to)
master to remote3: got data? .. 0xAA, 0x03
remote 3 to master: no 0x55, 0x03, 0x00
...
CrossRoads:
What would "standard serial commands" be?
I meant Serial.read, Serial.print, etc.
In my case, I plan to have up to 70 readers, so polling all of them every time might be time consuming. After reading this article http://www.allaboutcircuits.com/vol_4/chpt_14/7.html, looks like a CSMA/Collision Detection is better. I'll assume a collision if the recipient doesn't answer.
CrossRoads:
Still thinking about the protocol to use, want it fast, simple, expandable.
Open to ideas for improvement.
how about packets like this: ......
All bytes. If you really need more than 255 commands, FF in the first command byte means extended command specified by the second. Gives you a little bit of defence against corruption.
)