PN532 - Unreliable reading of 2 tags at once

[sebak]

Hello,

I am running into a little problem with a PN532 based reader and I hope someone can help me here. The problem is this:

Whenever I use the InListPassiveTarget command with a MaxTg number of 2, I get unreliable communication with tags.

As soon as I increase the max. target number from 1 to 2, a single tag within the range of the reader gets read only on exactly every second attempt. On every other attempt I receive the ACK from the chip, but no actual data. If I go and send the command twice each time before attempting to read the data packet, I get reliable readings.

When I have two tags in the field at once, it seems to read 2 tags, then only 1 tag, then none, and repeats. Again, if I send the command twice each time, the readings are reliable.

I am using NTAG216 tags for this, but it is the same with other Mifare type tags. I tried to increase the timeout waiting for the data packet to arrive up to 200ms with no effect. With MaxTg=1 there is no problem at all.

Is this expected behaviour? According to UM0701-02, Fig. 78 I would assume that anti-collision is managed by the chip, and I should receive data packets for both tags in one response. But even the behaviour with only a single tag in the field changes when I increase MaxTg to 2. The firmware version of the chip is 1.6.

[tobiasdiendorfe]

Hey guys.

I am using the PN532 with the adafruit PN532 library and ran into a similar issue.
My host CPU (ATMEGA328P) is attached over SPI to the PN532.
This CPU is connected over RS485 to another device which is polling the ATMEGA.
On every poll the readPassiveTargetID() will be called.
The issue is, that JUST on every second poll an tag is reported back!
It does'nt matter how long you wait in between two poll's (milliseconds, seconds or minutes).
Its always the same.

What i am doing wrong?

Could it be that the target is halted on the second call to readPassiveTargetID()?

I have tried several things to solve the issue and was comming up with an workaround, which is not that pretty.

Changed: See readPassiveTargetID_1.txt
to the following (= just call INLISTPASSIVETARGET twice in short intervalls on every poll): See readPassiveTargetID_2.txt

This changed the behaviour that the readPassiveTargetID() function comes back with 1 targets on every poll.

Is this a known/good workaround or are there other better ways of handling this behaviour?

@sebak did you ever solved your issue and maybe better understand the behaviour readPassiveTargetID() and how it should dealed with?

best regards
Tobias

[Seba_K]

Hello Tobias,

are you actually working with two tags at once, or only a single one? What kind of chip is it?

As I explained in my last post, I figured out how to work with two tags since the behaviour is a little different in that case. But for a single tag I never had that kind of issue. I use the example code from Adafruit on an Arduino and have no problems with that.

Regards,

Sebastian.

[tobiasdiendorfe]

Hi Sebastian.

Thanks for your answer.
I have this issue when just using "one" tag in the field.
Tested with NXP JCOP2, 3 & 4 - same behaviour.

I found another "better" workaround for the issue.
Before InListPassiveTargetTag cmd i am now sending an InRelease cmd to the PN532.
This releases all known tags and also switches the field off.

The result is an longer RF reset period (~4,1ms instead of 2,1ms, meassured with an oscilloscope).
This should not be an issue at all.

All tags (various JCOP's, Mifare classics, Mifare light are working normally).
I think i will go this way!

But the question remains (which should be answered by NXP): Why does this happen?

PS.: I found several other reports on the net with the same issue:

• Adafruit lib @ github: https://github.com/adafruit/Adafruit-PN532/issues/52
• Arduino forum: https://forum.arduino.cc/index.php?topic=334191.0

regards
Tobias

[sebak]

Ok, so I think I understand better now what's going on. Apparently when calling InListPassiveTarget with a MaxTg of 2, the first discovered target gets put in HALT state, which means it doesn't respond to any subsequent InListPassiveTarget requests after that. That explains why if I have two targets in the field they are both read on the first time, then on the second time only one of them (the one not put into HALT), which is HALTed as well, and after that none of the targets are visible anymore since they are both HALTed.

It seems also that when InListPassiveTarget does not find any targets, and gets interrupted by another call of InListPassiveTarget, the RF field is briefly switched off, causing all tags to reset. Which may be the reason why when sending InListPassiveTarget twice before reading a reponse I always read all tags, since they have gone through Power-On Reset.

That also explains why there is a difference with only one target when changing MaxTg from 1 to 2, because then the first target is halted, whereas with MaxTg=1 a discovered target is never halted.

So with that I am able to do what I want to do, and starting to understand better how all this works.

[IvanRuiz]

Hello,

It would be helpful to refer to the following document:

https://community.nxp.com/docs/DOC-335265 

Hope this helps!

Regards,

Ivan.

[sebak]

Hello Ivan,

thank you for the reply. Frankly, looking at the code you posted does not help me much at the moment, I am not even able to identify which commands you are sending to the chip. I hope you're not telling me it takes 3000+ lines of code to program a discovery loop for this chip?

Can you tell me anything else about what might cause the problem? In your article you say when multiple tags are powered the communication may be unreliable so only one should be activated at a time. But I understand it should in any case at least identify that there are two tags, right? I don't think it's a problem with the antenna design, since the sequence in which it detects a tag or not is very reproducible and not random.

Is the InListPassiveTarget command the right one to discover multiple tags? Or should I work with InAutoPoll?

Is there any more information about how the anti-collision works in the chip? I wasn't able to find any documentation on that.