Supporting other tag types?

[bofh69]

My printer has a PN532 NFC reader. It can't read ISO15693 vicinity cards. However I noticed Prusa's app could write to NTAG215/ISO14443 proximity cards.

I use the python nfcpy module to read the data from tags. There it could find the ndef records fine, but when sending all the tag's data (I think, I used tag.ndef.octets to get it, which looks right) to Record, Record complains about wrong magic number. It seems to assume a newer version of NDEF than the tag supports.

I then hacked Record to instead expect the payload of the right ndef records, instead of it doing it's own parsing. That seems to work fine for reading the contents. For me that's enough as I don't care about writing to the tag, spoolman keeps track of the weights for me.

I don't have the ndef spec, so I can't add proper support for parsing the ndef records right now, but I could make a version where Record takes the ndef record's payload as an alternative to the whole tag's data for read only use.

Would you be interested in a PR with that?

[CZDanol]

Hello, at this moment, we don't want to expand our scope to NFC standards other than NFC-V. This goes beyond just the app, it is about ensuring hardware support for the printers, verifying reading/writing distances, required antenna shapes, and so on.

We may decide to explore other NFC standards sometime later, but now we need time to polish our current implementation and hardware designs.

[bofh69]

What hardware the standard recommends/requires is a different thing compared to what your python code can support. The Prusa app already supports writing to type 2 tags so it would be nice if the python code could be used to read them.

No problems though. I'll just fork it.

[CZDanol]

What hardware the standard recommends/requires is a different thing compared to what your python code can support.

Well, yes, but we don't really want to endorse adoption of out-of-spec solutions, because it breaks the purpose of having a standard.

[yanshay]

I probably missed that one. Doesn't PN532 support NTAG-V? It's the most commoly used NFC module in OpenSource projects. It surely would mean I can't support these tags in SpoolEase. I missed that part.

Any other cheap NFC modules that support it?

[CZDanol]

Looking at the PN532 spec, it indeed does seem that it does not support the ISO 15693 (NFC-V) standard.

[bofh69]

@yanshay PN5180 does, but it requires between 5-8 pins for its interface (an extended SPI) and there are no good python modules for it. NXP has a proprietary, gratis, C library for it though. You're allowed to distribute binaries built with it, but not the source.

I bought some of Prusa's tags, but they don't fit most of my spools. Looking quickly at AliExpress, I only found one NFC-V tag and it was pretty expensive so I'm not sure I'll add support for it in nfc2klipper either. For people using klipper and Spoolman, adding a cheap type 2 tag makes a lot more sense. They've fit all my spools this far. There it is no need to fill it with data, just use the UID to connect it to the spool in Spoolman. I've added support for OpenTag3D though.

It would be interesting to know if any of the existing rfid readers on printers support it, or if they would have to replace the readers if they want to support OpenPrintTag.

[yanshay]

Agree with every word you wrote. As if I wrote it myself.

The only option I can see to make it still valuable to the open source community is if there would be a central DB where from some bar-code or qr-code on the spool it would be possible to reach the NDEF data and use it as a standard structured format.

NDEF is not limited to tags and can serve as a standard to just pass data so that way it could be helpful to some extent. But that would be less likely to be adopted.

And in this space, being unable to use it in open source reduce the likelihood of this being adopted, but maybe I am wrong on this one.

[yanshay]

Btw - any spools out there with OpenTag3d? Or any other standard that caught traction?

[CZDanol]

The only option I can see to make it still valuable to the open source community is if there would be a central DB where from some bar-code or qr-code on the spool it would be possible to reach the NDEF data and use it as a standard structured format.

We're working on this as well (though the DB format will be slightly different to the tag one, but we will provide transformation scripts).

[bofh69]

@yanshay I've made a python module that uses the PN5180 to read/write both ISO-14443A and ISO-15693 cards. I've connected the PN5180 to a RPi Pico Zero (some cheap Waveshare clone) and then connected the pico to my computer via USB. The RPi Pico uses an arduino sketch for its firmware. No proprietary code. It is probably easy to port to other Arduino supported boards too.

The project is here.

It doesn't provide any higher level API for handling NDEF records etc, but it should be enough for Prusa's code. One can probably combine it with nfcpy's NDEF record parsing for NFC Type 2 cards too.

It has not seen a lot of testing and I will update the API in the future releases.

[yanshay]

Thanks for sharing.

I've also seen some CPP libraries on GitHub, unfortunately I am using Rust so will probably need to develop something on my own in the future . Might use this project for testing when my code doesn't work and I need to figure out why 🙂

[bofh69]

@yanshay I found it to be pretty straight forward. I didn't know much about low level ISO-14443/15693 before (and not so much more now...), but it went very smooth with the datasheets and app notes from NXP for their tags and PN5180.

The only thing that confused me was when I tried to implement proper ISO-14443-3 anticollision handling. Basic card discovery (without anticollision support) is shown in NXP's app note so I started with that.

The ANTICOLLISION CLx requests can also be sent with a mask at the end. If you send say a 7 bits mask, then the first 7 bites are not sent in the response... To get this right, there is a CRC_RX_CONFIG register where you set the alignment of the first received bit (so you set it to 7 in this example). Of course in some cases I failed to set it back to 0 after...

In retrospect, I should have gotten a copy of ISO-14443-3 before implementing the anti-collision handling instead of asking copilot/chatGPT to summaries it for me...

[yanshay]

Thanks for the insights.

Did you run it over SPI?
I saw it has in addition to the standard SPI also busy signal and maybe another signal? Did you deal with it or some underlying library?

Those needs to be considered between commands or before every byte?

[bofh69]

There's an arduino sketch in the repo that does the SPI communication and implements the whole SPI API (well, almost, this far...) and has a SimpleRPC interface for communicating via USB (it support other interfaces as well).

To send an SPI request, lower NSS, send the SPI data (ignore what's being received), wait for the BUSY signal to go high and then raise NSS and wait for BUSY to go low again. If the request should have a response, do the same thing again, but this time just read the response and send whatever.

There is an IRQ pin. I poll it, but one can just read the IRQ_STATUS register via SPI instead.

There is also a REQ signal, but it is only used for firmware updates of the PN5180 and there is a reset signal. If you don't want to update the FW, you don't have to connect the REQ signal. The reset signal is probably a good idea to connect, but this far the chip has not gotten stuck for me. Good way to reset all registers to their default though.