🚀 | Support ntag NFC Chips with rc522

[lukruh]

Feature

Extend the Mfrc522Reader class to support cheap NFC chips like ntag215. This might require switching to another library. The currently used pi-rc522 seems not to support the newer ntag chips. There are several other libraries, that might support the ntag type chips as well as the currently supported s50/s70 types.

I don't have experience with RFID/NFC or the phoniebox it self. But I'm happy to share my current workaround or help implementing a more general solution. Maybe some more experienced users/devs want to jump in for discussion.
(I will link related Issues later).

User perspective

From reading the docs (before #2372) here in the repo and/or the description of the RC522 users (like me) might expect all NFC tags are supported as long as the frequency matches. The ntag type chips seem to be very common on the market. For users who got some of these it should be possible to use them without touching the code.

Further information

I managed to use the phoniebox with ntag type chips by adding a reader based on the mrfc522 library with some copy pasted code from their examples and other github issues to work around Auth errors. This could be at least a preliminary solution for users who only want to use this type of chips:

class Mfrc522NtagReader(object):
    def __init__(self):
        from mfrc522 import MFRC522
        self.device = MFRC522()
    
    def readCard(self):
        while True:
            reader = self.device
            status, _ = reader.MFRC522_Request(reader.PICC_REQIDL)
            if status != reader.MI_OK:
                sleep(0.1)
                continue
            status, backData = reader.MFRC522_Anticoll()
            buf = reader.MFRC522_Read(0)
            reader.MFRC522_Request(reader.PICC_HALT)
            if buf:
                card_id = "".join([str(i) for i in buf])
                logger.info(card_id)
                return card_id

    @staticmethod
    def cleanup():
        GPIO.cleanup()

I have adjusted the Reader class and setup script accordingly to switch between the current reader and this workaround.

[s-martin]

Thanks for your feature request.

The current Phoniebox implementation for rc522 readers seems to have issues with tags, which require(?) authentication.

The GitHub repo of the used rc-522 library seems to have recent activity (again).

If I understand the readme example correctly https://github.com/ondryaso/pi-rc522?tab=readme-ov-file#usage the RFID class seems to have support for auth, which might also fix the original issue.

[s-martin]

Looking at our code in V2 the implementation might be too simple, just ignoring auth? @AlvinSchiller

[s-martin]

@lukruh I think you are currently referring to V2 implementation (using Reader.experimental.py), so I tagged the issue accordingly.

Nevertheless we need to check V3 as well.

[s-martin]

@lukruh I think you are currently referring to V2 implementation (using Reader.experimental.py), so I tagged the issue accordingly.

Nevertheless we need to check V3 as well.

Looking at https://github.com/MiczFlor/RPi-Jukebox-RFID/blob/future3%2Fdevelop/src%2Fjukebox%2Fcomponents%2Frfid%2Fhardware%2Frc522_spi%2Frc522_spi.py#L100-L131 the V3 has the same (maybe too simple?) implementation.

[s-martin]

Documentation has been updated (see #2372 and #2374) that ntags are currently not supported. Nevertheless we should try to fix this.

[s-martin]

Documentation has been updated (see #2372 and #2374) that ntags are currently not supported. Nevertheless we should try to fix this.

[s-martin]

If pi-rc522 library supports ntags and we need to improve our implementation this should be the way to go from my point of view.

The mfrc522 library seems to support it, but there is no activity for almost 4 years, so I'm not sure, if this helps us in the future.

We also need to consider the RPi.GPIO issue for Raspberry Pi OS Bookworm (at least for V3), see #2313 (comment)

[AlvinSchiller]

Looking at our code in V2 the implementation might be too simple, just ignoring auth? @AlvinSchiller

Yes, it looks like the case is just not covered, also in v3.
I don't have this kind of tags around to test though.

[AlvinSchiller]

If pi-rc522 library supports ntags and we need to improve our implementation this should be the way to go from my point of view.

The mfrc522 library seems to support it, but there is no activity for almost 4 years, so I'm not sure, if this helps us in the future.

We also need to consider the RPi.GPIO issue for Raspberry Pi OS Bookworm (at least for V3), see #2313 (comment)

Agree in all points 👍

[lukruh]

I got a couple of the ntag215 ones and can try to get to ignore auth in pi-rc522.
So the preferred order of solving this would be:

1. get it running within Reader class using current pi-rc522 library
2. if required request changes for pir-rc522 upstream
3. if nothing of the above works fall back to mfrc522 (at least as a temporary workaround?)

[spelech]

I have a working update for pi-rc522 that does work for ntag215 and the classic cards. Ntag cards tend to cause more read errors (could also be cheap tags being crappy). I modified it based on the pattern from this other repo. I'd prefer to find the official docs laying out the sequence of events but this works. I'll put together an MR for pi-rc522 and see how that goes, that repo is pretty dead aside from a readme change

[spelech]

Would anyone be willing to take a look at something? I am running into some weird behavior and I'm not sure what is going on.
When I run daemon_rfid_reader.py, I can see my new class getting loaded correctly and it picks up the ntag215 chips (less reliably than the mifare 1k card but that could be an antenna size/quality problem on this tags). Since the debug version updates the settings files the same way, I can actually see the ntag215 uids showing up on the web page for registering new cards.

HOWEVER, the service does not seem to be having the same luck - I do not see the load at the end of my custom class's constructor hitting the log. Is this just an issue with relative paths for the new class?

[spelech]

I've hit a wall. I can't understand why the wait_for_tag() method works correctly in debug but not when I run the script normally. Could be a timing issue that needs to be resolved between the two. Here is the doc that outlines the comms, and honestly it looks like the existing code should have handled 7 byte (but not 10) UIDs. I ordered a stack of classic cards in the mean time

[s-martin]

Do you have a branch or a PR yet?

It would probably help, if people could look at the code to help.

[spelech]

Yeah let me clean things up. I am going to separate my changes, revert the repo and diff things. It's just bizarre. I think most of the code to properly grab NTag 21x UIDs is there (maybe minus another select command). I got frustrated with whatever was happening with Python debug vs normal and decided to look into .NET IoT libraries.

I am writing this now looking at my cheap MRFC522 spitting out NTag215 UIDs like crazy, and handling the classics just fine using the .NET libraries. This works for me for now because I can just mimic the script behavior with the dll, but I'll take another look at the python piece since I don't want to leave everyone hanging

[spelech]

Diffing the current pi rfc522 library against the working c# libraries, a few things stand out

• The python class doesn't really use the RST pin we send in aside from pulling it high in the constructor
  -- The c# class does a hard reset on construction, pulling it low then high

• The python class writes a reset to the device on construction
  --The c# class has a SoftReset that does this but it isn't called in my working example

• The way the python library initializes the device via writes is very different than the c# class
  --c# source

• I have zero idea what we're using the IRQ pin for. I did some digging and, although the threads are a little stale, so are most libraries that exist for this device - and most signs point to the library not really supporting it (arduino mfrc522 library), or threads about how MicroPython supports interrupts but circuit python doesn't. The python library allows it, but doesn't provide an example. Maybe this is a shortcoming of the NET libraries, but it isn't used and works fine.

The libraries diverge quick from there. The C# library handles cascading internal to the Select command, and again the registers/values look. I'm a few years removed from working with hardware and rarely use python, but I can't imagine there differences aren't leading to problems. If you check out the class ESPHome uses alongside it's python, the c class write similar values to the c# source, and I haven't seen threads for Home Assistant complaining about it

My apologies but for now this is the most I can do - it's a large rewrite from initial glance but someone more versed in python should double check