I need to be able to program RFID buttons to hold additional data. I haven’t been able to find a whole lot of information but I think SFE sells all of the required components. A pointer to a tutorial or something would be great.
In my project, I have multiple (up to 100) remote devices. When the user presses a button on the device, an Xbee transmits data to a base station. The user then must reset the device at a different station. I want to use RFID for the reset. The logical solution is to include a reader in the remote. However, this is also the most expensive solution. So the cheaper solution is to include the RIFD button in the remote. However, when the remote is scanned, the reader needs to sends back data to the remote to tell it to reset after a preset amount of time. If the RFID had the Xbee ID number of the remote, it would greatly simplify this process. Since they all of the Xbee’s will operate on the same PAN, it is the MY id that becomes important.
The other solution seems to be that I would have to have a massive lookup table with the RFID number tied to the MY number. This would work but could lead to problems in the future if new remotes are added.
I have VERY Limited space in my remote. This is like reversing the application so that the stationary unit is always on transmitting the needed header and when the remote comes within range, it wakes up and does its job. While this is an attractive possiblity, I am already having to do some creative squashing to get everything into my remote unit and this is using mostly SMD components. The Xbee being the largest footprint coupled with a 20mm battery and a tactile switch. Leaves very little space for the ATmega, boost convertor and all of assocaited components.Still worth looking a little deeper into.
However, this does give me another otion on a different aspect of this project that I posted in a different post.
Why must the RFID tag be reprogrammed ? I"m probably not understanding your whole concept here but …
Why can’t the DIO of the Xbee be used to drive an indicator (an LED ?) of the state of the button. After any button has been reset and it’s able to transmit, the indicator is “green”. At some point the button is pushed and RF is transmitted from it to the base station. Then what happens is the base station transmits a signal to the Xbee which flips a DIO line to off and the indicator changes. The XBee doesn’t need (so far as I can tell) to actually be disabled, just that further RF transmissions be “ignored” by the base station. Ignored meaning that whatever action normally happens when the button state is enabled and a transmission from the button is recieved, now doesn’t happen. Ignored until the button comes into some proximity of a reset station. When that happens the base station is informed and then that the button can be taken off the ignore list. A transmission to the button’s XBee also happens to re-enable the indicator. The smarts of the button’s state isn’t kept at the button but at the base station, the state of the button is transmitted to the button using the existing bi-directional RF link.
For that matter why RFID ? That 100+ tags may be cheap enough, but a reader for each reset station could be pricey. Does the proximity of any button to a reset station need to be determined by RF or could it by some other means ?
Agree with Mee_n_mac that we need more info to help us help you.
if you have real estate problems, avoid duplications first. Why not use the xbee microcontroller to service the RFID receiver too? What’s the atmega for anyway?
a 100 entry lookup table, on one PAN, is not what I would call “massive”.
More generally, the two separate rf links (xbee and RFID) makes me suspicious that the problem is ill-defined.
Okay more info. I will give you that 100 entry lookup is not that big and when you say it that way it does seem like a bit of a ‘duh’ moment. However, what if I have my 100 remotes and at some point down the line I decide I need to add 10 more. Without buying a large stash of RFID tags, the preset table just won’t work.
This is building on a LARP that I am working on. There is another post on here somehwere about another aspect. The idea is that a player is out of play once they hit the button on the remote. The remote sends back data to a controler station (think GM). In order to be back in play, they have to reset the remote. The most logical way to do this for me was to scan the remote at the reset station (this also works from a game standpoint). The reset station would tell the remote how long to wait before it resets. This could be as much as a day or two later. Until the remote is reset, the player is out of action. The reset time could very likley be player specific or in some scenarios, it might be random. It isn’t practical to relay this back to every remote so it makes more sense to relay this info back to the remote once it is scanned. In order to do this, it needs to know the MY number tied to a specific RFID tag number.
Another option I am trying to get my head around is a first time ‘setup’ scan of the remote. By pressing and holding the remote button for ‘x’ seconds, it puts it can tell the reset station that the next RFID scan is tied to this particular MY. This may be the way I do it. It could then add it to the lookup table and all is well.
This discussion has helped me think through some of these issues so even if appears we are getting nowhere, it has been a big help! So please poke and prod and offer any more advice and suggestions. I am open to anything.
And last, the Atmel does very little but it is a small (TQFP) footprint that gives me a lot of alternatives for the remote beyond it currently planned piece. For example, what if the player needs to prove that they were at point X. By scanning their remote unit, the RFID tag/Xbee combo can once agin provide an interface to the remote and the Atmel stores the data, which might include a time stamp of when it was scanned as well as what point was scanned. In its simplest form, it simply provides a conter for the reset. Yes I could do this with a 555 but like I said, the chip provides a low cost small footprint doorway to a lot of other cool possibilites.
Now if only I had room for a GPS receiver in there…
I may still have misunderstood, but assuming I haven’t, let me try:
In any situation during the game, the player is in charge of initiating a communication when in vicinity of a reset station. There isn’t a situation where a station needs to “scan”, stealthily, a player sneaking by. It is always the player who intentionally interacts, through the remote, with the reset station. And in order to do so, he may for example press a button on his remote. On completing a successful transaction, the fixed station prompts the player with a beep or a flashing LED.
Therefore, the game needs only one, bidirectional wireless link in principle.
the problem is that the link only should work when a remote is near a station, not farther than say 10 feet. And this regardless of the type of operation (register, reset, whatever).
The amount of data transferred between remote and station is relatively small, say 100 bits at most.
Fixed stations are interconnected through a network.
A fixed station is always listening, while a remote only turns on (and initiates a transaction) on a button press.
Assuming all of the above, I’d use an Arduino or similar, and implement the link with one of those cheap OOK/ASK transceivers operating at 315 or 433MHz. Think garage door opener. If one with a well-designed and tuned antenna works over a range of 100ft, imagine what it can do with a crippled antenna, or no antenna at all, just a short PCB trace. So the first step could involve cutting the PCB trace - antenna until the working range degrades to less than 10ft.
In practice, data will be received even at 20ft, but it will be full of bit errors. And the receiver needs to be able to catch those errors, ignoring faulty messages. Usually, this involves including a CRC or checksum as part of the transmitted message. There are other ways to do it, for example using symbols to encode bits. That way you could even estimate the range (a sort of “soft RSSI”) and correct some errors.
All this will need to be implemented by Arduino firmware.
The new twist if that I think the button may be out of RF contact with the LARP network and yet still have to time out a couple of days (on it’s own) and then inform the button holder that he/she is back in the game. This would seem to require a low power RTC of some sort.
Sure, except 2.4G is a bit dicy for this application (multipath). I'd go with a much lower carrier frequency, like this [http://www.sparkfun.com/products/9582](http://www.sparkfun.com/products/9582) at 434MHz. But setup and configuration with these chips can be tedious depending on Sacman's skills, and that's why I suggested something simpler (even this: [http://www.sparkfun.com/products/10535](http://www.sparkfun.com/products/10535)).
Mee_n_Mac:
The new twist if that I think the button may be out of RF contact with the LARP network and yet still have to time out a couple of days (on it’s own) and then inform the button holder that he/she is back in the game. This would seem to require a low power RTC of some sort.
Right, and that would be entirely an Arduino task.
Cheers
E
PS almost forgot: by getting RID of the RFID, you get rid of the 100-entry ID-to-MY lookup table. The MY is programmed into the remote at registration/pairing time, and can be used directly.
I am actually getting two Xbee’s in the mail tomorrow finally. I already have the RFID reader and one button from free day (yeah me!) I got that up and running over the weekend. Considering that this is my first time using the Arduino platform (also a free day purchase), I am extremely happy with where I am.
So with the xbee’s on their way, I was laying out the program for the remote and continued to stumble on this problem. So I looked a little deeper into the Xbee data sheet and found that I can use 64bit addressing instead of the more common 16 bit. Since the RFID tags are unique 5 Byte numbers, I can just adding some padding and use the RFID tag ID as the Xbee MY address. Then using API AT commands on the Reset station I can reset the DL and DH to the Xbee address that it reads from the RFID tag with the padding 0’s to make up the missing 3 bytes.
Anyone see any holes in this approach? This satisfies my need for the reset station to communicate back to only that remote quite nicely without having to worry about lookup tables or longterm data storage.