Yeah I have a pool of 30 tags but there are more to come....basically what I m doing is writing some programs to get a "Real Life Pac-Man". I cannot check against that pool as there might come additional maps for the game and the values of the tags are therefore stored on a remote server. Communication with the server after each reading would take much too long. Also I m working with Android phones for controlling the robot and there shouldn t be too much logic on the robot in order to be portable to other robots some day...
Waking up the sensor is already implemented and I m not using the supplied tags. I have credit card sized tags but they work on the same frequency (125kHz), have a 5 Byte value and are of type EM4102. So they are pretty much the same as the supplied ones, but they are a bit cheaper and orderable in bigger quantities.
I cannot use the NXC driver as I have a framework running on LeJOS for communication with my android smartphone. So I need to stay with LeJOS.
If I have multiple tags in range the device will give me a value from one of the tags. Seems to select the tag randomly or at least I couldn t figure out which one it selects. Likely it s the first tag that responds. That does not have to be the one nearest to the sensor so you never know which value you will get when you have 2 tags in range. Might be a funny idea for true randomness.
The 'biggest value algorithm' works pretty good for now so I guess I will stick with this solution. It s fast and gets the right values, however it s not such a 'clean' solution....
btw gloomyandy your first comment made me laugh so hard as it s exactly what I was thinking for the last weeks. I m doing all this work for my masterthesis would you mind if I cite you with this sentence:
the RFID sensor is one of the most badly behaved devices I've ever had to work with, so I'm not surprised you are hitting problems.