Core improvements#1
Open
weoiss1998 wants to merge 32 commits intoweoiss1998:Add-fixesfrom
Open
Conversation
…ionMode options in setRF_on()
…mmunicationMode options in setRF_on()" This reverts commit 2bef556.
Somewhere along the line the DEBUG define was not in DEBUG, which results in formatHex() not being included. Now it is conspicuously uncommentable.
Expanded defines for all registers for reference and future use
Expanded defines for all Host Interface Commands for reference and future use
Fix #ifdef nesting
Improve code readabiility and allow eventual expansion to full ISO18593-3 compatibility.
The bug is: Calling getInventoryMultiple() hangs and times out if there is only one NFC tag and that tag's UID ends in '0'. The library doesn't when calling getInventory() with the same tag. Still unable to see why this is happening. So expand the PN5180ERROR to show deeper calls.
PN5180 Direct Commands These functions are the low level interface to the device: 1. Verify command's parameters 2. Prepare the transmission frame 3. Call transceiveCommand() to send the command 4. No state checking The comments for these direct commands are based on the PN5180A0XX_C3_C4.pdf data sheet. The original setRF_on(), setRF_off() and sendData() calls are the versions that do parameter and state checking before calling the direct commands. This will allow variations of the original calls with different state checking where necessary.
The bug that prevented getInventoryMultiple() from doing collision resolution is fixed. Four cards with UIDs ending in '0' were able to be read at one time. I also had two cards with UIDs ending in 'DD' that were recognized, so the collision avoidance resolution is at least getting to the third round. I do not have any cards with UIDs that all end in the same three or more identical nibbles to see how far it can go, but I think getting to the third round is proves that the algorithm is correct. That alll being said, although my initial problem of the library hanging when reading a stack of cards with at least one ending in '0' has only partially been resolved. In any number of cards within the RF field, if only one of them has a UID ending in '0', getInventoryMultiple() still hangs. Adding a additional tags ending in '0' however does not hang. Even with all the debugging macros I added I still haven't discovered why this occurs only when there is a single tag ending in '0' within the field. And if using the regular single card reading call, getInventory(), cards ending in '0' read just fine. While the latter problem is not yet solved, I have made significant progress on the other two issues arising from errors in collision resolution, so I'd ending this branch here and will send a PR upstream. I will work on the remaining solution in another branch. based on this one. By the way, I have on occasion been able to read 9 NFC Type 5 ICODE SLIX card tags at one time on the PN5180 if the cards are held just above, but not touching, the PN5180 board antenna. But I do find that not all manufacturer's of these cards are able to be read that many at a time. Different manufacturer's use different size or shape or windings of their antennas and possibly use lower quality tag chips inside the cards. I haven't investigated this actual cause of this inconsistency or how to make sure the tags I get are ones that can operate in larger stacks. On another note, I've had communication with NXP regarding the PN5180 and tyriing to get the chip to resolve at a full NFC Type 5 ranges over 10 cm since NFC Type 5 is supposed to be able to be read up to 1.5 m. NXP replied that their PN5180 is NFC compliant, but that their chip is only design to read at ranges up to 10 cm. So word to the wise, if you are looking for the ability to read a single NFC Type 5 tag at ranges longer than 10 cm, you probably don't want the PN5180 unless you are going to design a very complex powerful amplified antenna circuit. NXP offered me no guidance in this respect, other than to suggest contacting another company specializing in long range RFID. Sigh!
Well, I didn't test after turning deactivating all the DEBUG defines. This resolves it.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
No description provided.