Hello,
I have been using the m6e with the constant read capabilities and have come across the limitation of its 12 byte limitation regarding tags. Any chance this is going to be increased to say, 16 bytes, in future libraries?
Ryan
Hi Ryan.
Unfortunately I don’t know if the libraries are going to get a re-write, but you might post an issue in the Github repository as that will get the attention of the libraries author.
actually… the library is supporting longer EPC’s.
With the call nano.getTagEPCBytes(), you can get the amount of of EPC bytes for the TAG.
If you increase in Example2_read_EPC, in loop() (around line 55), the definition of
byte myEPC[12]; //Most EPCs are 12 bytes
to say 16 bytes it will try to read 16 bytes. if however only 12 bytes were received from the TAG, only 12 bytes of stored in myEPC.
I have been using the nano.readTagEPC for tags with 16 bytes but that is just using the loop capabilities and the functions from Example 2 as opposed to nano.startReading() and the functions available to it . It struck me that the constant read as in Example 1 was much faster and picked up more tags than adapting the Example 2 to do a continuous search using the loop. Hence, looking for leads on how to put this request in given my experience that Example 1 was faster albeit lacked the 16 bytes my tags carry.
Example1 is sending an embedded instruction to the NANO where is NANO is constant checking for new TAGS. In example 1 it is only checking in with the NANO to see whether it has a new tag detected. As the Nano has some buffer to store already received Tags, hence it is faster.
You can speed up example 2 by removing all the buzzer code (tone / delay etc). Not necessary for you.
In example1 it does check how many the EPC bytes the tag has : tagEPCBytes = nano.getTagEPCBytes();
So it your tag has 16 bytes EPC… it should be displayed as such…
Thank you for the follow-up Paul. I shall have to go back and check that route out.