M6E Nano RFID Read specific address from user bank

Sensors NFC & RFID
1

Hello, I purchased a few of the RFID LED tags from Alibaba.

https://www.alibaba.com/product-detail/ … wbk85r&s=p

I can write userdata and read userdata, but I cannot make the LED light up.

When I inquired about this to the manufacturer, they said to read USER from address 4.

I am using the update library found on github from Jan of 2022.

Using Example_16_read_bank_continuous, how would I go about this?

There are 2 definitions that I modified below:

#define BANK TMR_GEN2_BANK_USER

#define STARTWORDADDRESS 4

I would assume they mean the userbank and start at address 4?

Any help is greatly appreciated.

Thanks

2

hi

The example you refer to is not from Sparkfun, but written by me. The library is an extended version of the Sparkfun library.

The answer to your question is yes with 2 remarks:

  1. On RFID each address is on a 16 bits / word boundary. So depending on what they mean with ‘4’ it could be bytes or address. So try startwordaddress at 1 of 2 if it does not work.

  2. you can also use example13 and set the wordstartaddress around line 81.

3

Thanks for the response Paul.

I tried your recommendations to no avail.

I asked them for some documentation and they only sent me that read USER from address 4.

I can definitely read and write the data, I have cranked the power up to max and all the way back down to 500, but no luck on the LED lighting up.

Is there a way in the libraries to query a specific tag? To say like only read where tag EPC = EPC?

Or basically - read tag data where userdata = “ABCD” ?

I did notice the filter function in the library. I tried enabling it, but I am not sure exactly how to use it.

4

Maybe it needs even more power, but then you may need to apply external power directly to the M6E Nano on the extra connector. I only know about one other supplier with a passive tag and led that does not need a battery. They recommend as fast reading as possible to create enough power for the LED to switch on. (http://www.farsens.com/en/products/batt … nsors/led/)

When continuous reading is happening, it is all performed in the M6E Nano. The library just receives the data from the M6E Nano. The big, large, official MercuryAPI which runs on Windows or Linux, supports setting filtering in the M6E Nano, but this library does not.

What you could is to run a loop which is a combination from the examples :

first read the EPC only (example 2)

check this is the tag with to select based on the EPC.

Then only read the user bank from the selected tag (example13).

5

I did read that article from Farsens.com. I have the Sparkfun Arduino shield hooked up to the M6E and have it powered using the external 7-15 V DC connector, but also plugged into the computer (to read the data via serial). Do I have to do something special to make sure it is getting the power directly from the wall plug instead of over USB? I thought I read that as long as I was using the shield, it would automatically pull power from the DC plug and bypass power from USB. As far as the filtering is concerned - yeah, I can figure out the logic needed to only read the specific tag based on either user data or EPC, but I was under the assumption that there was some special function to query a tag where userdata = userdata. I would guess that is how the tag lights up - otherwise all of the tags would light up - just having the userdata bank read without passing a parameter of sorts. Maybe I will contact thingmagic and see what they say. Thanks again for your wisdom.

6

Next to the FTDI connection on the M6E Nano, there is an option to connect power to + and - 3.7 - 5V Here you can connect an external power supply or a LIPO. The LIPO will not charge as there is a diode on the board enabling only 1-way direction of the current ( from the external connector to the board). To be VERY safe you COULD cut JP1 on the board to have the power only to be sourced from the external power. But in my tests, I have never done that.

Maybe it does not matter what you read, as long as you read a lot for a long time to get enough charge. hence reading the user bank is the best (most words). Perhaps try/ rework example15 which will read all banks. The more traffic, the longer the M6E is interrogating the tag, the better I think.

7

I heard back from Alibaba rep - and he said he was mistaked about reading userdata from address 4, he meant password from address 4. I tried it and it works! I had to change the library to look at address 4 instead of 0x2.

//Read the access password. Should be 4 bytes long

uint8_t RFID::readAccessPW(uint8_t *password, uint8_t &passwordLength, uint16_t timeOut)

{

uint8_t bank = 0x00; //Passwords bank

uint8_t address = 0x04; //Access password address - changed from 0x2 to 0x4 for lighting LED

return (readData(bank, address, password, passwordLength, timeOut));

}

Thanks again for your help Paul! Now I have to figure out how to get it to work / lightup further away from the antenna. I have the external antenna setup, but right now - the LED only lights up around 2 feet away. I may be looking to buy a more powerful reader in this case.

8

Have you managed to be able to read that data from a SPECIFIC EPC?

That’s how we light up the LED we want, by polling a SPECIFIC tag. Has this been done with the libraries yet?

9

With the large MercuryAPI- library from Jadak/Thingmagic (running on Windows or Linux) you can apply a TagFIlter. This creates an embedded search which is downloaded in the M6E Nano to look/ filter for a specific EPC. That function is NOT part of the Sparkfun library as it a scaled-down version that only supports a subset of the functions.

What you can do however is use example1 continuous read and then check in the sketch whether the EPC of the tag that has been read equals the one you are looking for and then react on that.

10

Paul,

Appreciate your quick response! In your github, under the ThingMagic repo, https://github.com/paulvha/ThingMagic/b … ted/demo.c

shows a command table that references “readmemwords” and appears to have a flag for specific target - I assume, provided I’ve got mercury API set up and can compile demo.c, that should be exactly what I’m looking for, correct?

To activate one of these LEDs, you need to read a specific memory item from a specific EPC.

11

Just looked at the demo.c. Indeed this is a demo example on how to apply filters like ‘Tag ID: EPC:000011112222333344445555’.

When you have the MercuryApi from Jadak make sure to the demo.c that is part of that version. Interface API’s have changed a little between versions.

12

Paul,

I see in your github that you developed a version of this into an example (ex. 20) so that the reading is only done for a selected EPC. I am trying to figure out a way to do something similar with writing to a specific EPC instead of just reading. I know that it should be possible, since URA has a way for you to choose a specific tag to write to. I am just unsure of how to force the reader to only write to the specific tag and not have a chance of writing to any in range.

So far what I have done works some of the time but is (to my knowledge) not a foolproof method of only writing to a specific tag. I have used logic to check for the desired tag EPC to be read, during continuous reading, and when it is found, it triggers the write command that I want. This seems to work, but to my knowledge it still leaves the vulnerability to one of the other tags having the data written to them. I don’t think that the tag that was last read stays in communication with the reader after the reading is taken.

From what I have seen on the forum and your github, it seems you are quite knowledgeable about this topic and may have a better suggestion for how to make this work. I just am struggling to really understand what is going on from the library side of things (the .cpp file), since I would expect this is what needs modification to allow for this functionality. I am currently using the sparkfun redboard artemis and the m7e hecto reader.

Any thoughts or assistance you may have would be greatly appreciated.

13

Good question. Your approach looks pragmatic, but you are right it is not 100% prove. Sounds like an interesting aspect to include. Working on 2 other projects already (not RFID related). Maybe I find time in January and update my library.
Maybe others have already some ideas/solutions.