Thank you for your clarification. So perhaps I can try your first tutorial. If no luck, then I can try the second tutorial. Wish me luck. Cheers.

Well, I just finished reading the tutorial by Gus of PiMyLifeup, also skimmed the 70+ comments. I understand 90% what is going on, except the SPI library which seems not exactly the same library I am using. This might be one thing I might get stuck. Anyway, I am now starting to follow the tutorial, not step by step, but skipping steps and using not exactly the same tools. Eg, I will use Rpi4B buster Thonny IDE to edit and run the programs. (One reader commented using IDLE python 3, but IDLE is not longer available), / to continue, …

No problem. I can also use CLI bash, pip, nano etc for the preliminary setsup, and perhaps more GUI later. I am getting started with the PN532 module which I tested OK with I2C some time ago. Now I am switching from LibNfc library to PyMyLifeUp library.

Yesterday evening I already used “pip3” to install “mfrc522”. As I said earlier, I don’t know nothing about SPI-Py, so I did not use the newbie scary “git-clone” and “python setup” to install the SPI-Py module. I noticed that what you built is a python 2.7 SPI-Py module. But I started learning python already with Rpi IDLE python 3.5.3. So I am not going back to the old python 2.7. Just now I checked out that pip3 seems happy with pip3 installed GPIO, SpiDev, and mfrc522 requirements. So I am hopping that I don’t need SPI-Py and go straight to python programming.

No luck! Now I am googling to debug. I need to make sure a couple of things, including: (1) Must I use python 2? (2) Must I use SPI-Py and not buster preinstalled SPI? You might like to check out the following discussion: raspberrypi.org/forums/viewtopic.php?t=207328#p1282986. Ah, supper time, see you tomorrow.

I just found out that I have forgotten to make the reset pin connection. So my module is not reset to start working. There might be other careless mistakes.

I also found out that there are at least two mfrc522 gitHub library. Perhaps I ppip install the wrong library: github.com/mxgxw/MFRC522-python. Of there are other reasons, say the library is only for Rpi 2, 3, not for Rpi4 buster. I also check the source code that SPI speed is set to 10MHz, which is too high for my long wiring. I need to set SPI speed lower, perhaps 400kHz. In short, too many possible bugs. libnfc 1.1.7 is very smooth, it took me only less than 30 minutes. Perhaps I tried the SPI librnfc version to verify that SPI speed can be set to 10MHz.

I also read that PN532 old versions 1.x are not reliable. So everybody is using V3. Are you on V3?

The following also says must lower SPI frequency from 5MHz to 50kHz. That means PN532 cannot do high frequency: wiki.sunfounder.cc/….

Now I am thinking of going back to libnfc and test the spi version, to make sure both libnfc v1.1.7 I2C and SPI version are OK, then I will come back to do PyMyLifeUp SPI version. I am also configuring minimal number of SPI, I2C, and UART channels/ports.

I am still debugging. About SPI Py, my quick and dirty conclusion is that it is an old thing, developed 7 years ago, in the Rpi2, python 2.7 days. Gus’s tutorial started 2017, so he might use SPI Py which is universal for the general Rpi users.

Please let me know if you know a reason that we must use PI Py and python 2.7. Otherwise I will still try pip3 mfrc522 and python 3. I am also using Version 3 module. I will also try the Blue PCB Version 1, just to make sure yours V1 module is not working.

Your question says: “read RFID MFRC522 Mifare blue tag not working. … when i put the tag to read it doesn’t show up as quick?” (1) To read quick, you need to use the module interrupt output signal to interrupt Rpi, otherwise loop scanning might be slow,

(2) But your problem is not quick or slow, because the module might be reset/ setup ready to read, or your tag is bad. I forgot to wire the module reset wire to Rpi, so this might be a bug, among other more possible bugs. So I am going to wire “interrupt” and “reset” between Rpi and the NFC module. See you later.

Now I am reading the following tutorial to learn how to connect the Reset pin. I found that the signal Low power downs the modules, and Rising Edge resets the module. In other words, I can just connect a jumper wire to manually reset the module. It is a bit confusing if I can leave the Reset pin floating. I need to check the schematic to see if this pin is pulled high.

The LatMinuteEngineers’s colourful MiFare Classic 1k memory map is also very good to refresh my memory.

Now I am going to look at the SimpleMFRC522.py library module, add debug print statements for debugging.

Since lsmod spi says spidev and spi_bcm2835 are installed, so SPI part should be OK. pip3 install update also says the other installed modules are OK. So I guess I can do everything in python 3. Actually use bash to open python 3 shell and can import mfrc522 without problem, so I think there is 90% chance I can move on to look at the mfrc522 library to see how to debug.

I found the main library/module is only 400 lines of python statements, and seems well documented, so it should be easy to do minor fixes, such as lowering SPI speed from 1MHz to 50kHz and so on. I am not going to move the main library mfrc500.py and the SimplePI speed from 1MHz to 50kHz and so on. I am not going to make a copy of the main library mfrc500.py and the smaller, 100 lines SimpleMFRC522 in a penzu reading log file and make more newbie comments.

If you don’t have much experience in Rpi and python, then perhaps you can just sit back and watch what I am messing around. But you are welcome to make suggestions, such as preferring python 3 and not python 2.7.

Anyway, if you have a tight deadline, then try libnfc I2C mode, because I have given the answer in the stackOverflow forum. Or google around harder.

This is the guy who had luck using SimpleMRFC: raspberrypi.stackexchange.com/….

I searched this forum for SimpleMRFC and found 11 results. Other forums might have many more we can read and learn something.

I read your question a second time. It appears that you were following two tutorials at the same time, the first one using python 3, second one python 2.7. One tutorial uses SpiPy, and compiled SpiDev, the other does not. I am not sure if you are also using pip/pip2/pip3 at the same time.

If you use pip2 first, the buster might set default to python 2 envrionment. Then if you use pip3 later, the piped drivers might go to the python 2 rooms, causing big mess, or a small dark hole, where garbage goes in will stuck and never come out. So I would suggest the following. Get two unwanted uSD cards, flash new buster, one for buster all preinstalled python 3, pip 3, spidev, only installed is pip 3 install mfrc522.

The above is what I did and summarized in this chat. Now you are in sync with my current configuration. And if you get stuck again, like a reading problem, then I can repeat your situation and program. The SimpleMFRC522 tutorial seem to write first and then read later. But you seem to skip the write part and jump to read part. I need to make sure if the write part does init something that is assumed in the following read part, …

In the mean time, I would study the 400 line MFRC522 library and the 100 line SimpleMFRC program, to see what print statements can be inserted to help debugging.

Ah, I have not yet started looking at the code. I need to catch up now.

Ah, take it easy. I am a slow guy, walking slowly in a locking down city. I just finished a quick reading of the two big program and found it simple. The reading log is here:

penzu.com/p/08d4fdf2.

Ah, supper time! See you late this evening or tomorrow. Cheers.

Now I am zooming in to the critical functions to see where to insert the print statements for debugging. Perhaps we can start with the Write.py program, trace it to as you said, around “where place tag to scan … and new data where you type it in …” I have now made a short listing to show where to insert the print statements:

This is the short listing: penzu.com/p/585c2995. You might trace the simpleMRFC522()’s read function back to the m\mrfc522’s read function which use the low level SPI functions. If the read steps get stuck at the SPI functions, then perhaps (1) Your SPI hardware wiring is bad, or (2) SpiDev is not compaitble to the MRFC module. I think (2) is unlikely. (3) You mixed up python 2 spidev tools with python 3 mrfc modules.

I suggest you and me doing the following to debuig: (1) BACKUP a couple of micro SD card copies for messing up testing (Note 1). (2) run the Read.py again, inserting print statements when tracing back to where it hangs. (3) If anytime you suspect the spi hardware and software setup is bad, you need to do the SPI LOOP BACK test (I already did it to make sure it is the cause of trouble. Note 1- You know how to use Rpi GUI accessories > SD copier to make back up copies, don’t you?

Ah the simpleMFRC532 and the mrfc532 programs are located in the following directory:/usr/local/lib/python3.7 …, but is you used git/clone, or pip 2, then it might be in /usr/local/lib/python2.7, not very sure. Let me show you the picture again.

This picture is sort of “cheat sheet”. The top dark/black part helps to make sure the right tools are in the right places. The bottom white part shows where are the two most important programs you are going to insert the debug print statement. Of course you the newbie will mess up things:( That is why I said you must make backup SD cards. Of course you also can back up the programs inside the directory.

Actually for initial testing, you can still use your current python 2.7 tools. Since you can do the last two statements “import simple…” reader = … , that means your python 2.7 setup is also OK, perhaps it is only your SPI wiring is bad, …

Ah bed time! I call it a day. Good luck and see you tomorrow.

(see full text)

Good luck and cheers.

If it is indeed the case, then we need to debug SPI by first using the LOOPBACK method, just to make sure if (a) spiDev and python are compatible, (b) if hardware wiring are correct (Note: MOSI and MISO must crossover). You can search “SPI Loopback” in this and other forums for more details. Below are some posts you might like to start with.

(see full text)

So I have done the SPI loop back test OK.

Next step is to use a multi-meter to check the open/short wiring of SPI connection of MRFC522 module to Rpi.

Well, going slow. (1) Appendix E shows where mfrc522.py and SimpleMFRC522.py are hiding. (2) I don’t want to run the programs in their hiding place, worrying that I might mess up things. Instead made a copy of the two programs in a newly created directory “/home/testMfrc”. Now I am testing my version of Write.py which import mfrc522 and try to write something to the tag.

Now a question: Do you have any experience in OOP (Object Oriented Programming), such as Arduino C++? If you are not experienced in nay OOP language, then I can forget the mrfc Class thing and directly do everything using functions, ie FP (Functional Programming).

Question 2 – Do you have a web link to the NFC module your are playing? Is it a cheapy eBay Version 1? I remember when I bought my Version 3 NFC module, the shop says they are Version 3, and that other shops’ Version 1 are bad.

Ah, still walking slowly. A couple of random comments: (1) Your module from Amazon UK looks good quality. I skimmed the comments and found some of them useful – such as that the SimpleMFRC522 is not updated.

I visited the MFRC522 GitHub and found the following IMPORTANT NOTICE: “This library has not being actively updated in almost four years. It might not work as intended on more recent Raspberry Pi devices. You might want to take a look to the open pull-requests and forks to see other implementations and bug-fixes.”

Now I am thinking of writing a very small version of MarioGomez’s MRFC522 class, but not an OO class, instead a couple of python functions. The objective is checking out if a module is basically working. The checking out method is to “ping”, or write something to a MRFC522 register and read back later.

Ha, yes, so I am back to Square 1 – What you were originally doing. Now I have listed the programs I unzipped into a penzu entry for easy reference: penzu.com/p/dff77f0d

But have you already done the SPI loopback check? The reason that you could not read the tag might be because your SPI hardware wiring is broken. If that is the case, you just fix the broken SPI wiring, then your problem should disappear! 🙂 Anyway, late supper time. See you very late this evening or tomorrow. Good luck, cheers.

Ah, to display an image, I usually do this: (1) Use any camera to shoot a 2MB or smaller jpeg image, and copy to a PC Windows directory, (2) click the upload button, browse to the directory and click the image name. I sometimes use imgur.com to upload the images and then paste to the answer in this forum.

I did’t catch you. Did you mean how to test Mario Gomez’s program in Rpi. What I am going to do is the following. (1) Download the zipped programs from GitHub to Win10 PC, (2) Unzip to find the three important programs: (a) mfrc522.py, (b) read.py, (c) write.py. In Rpi, create a new directory under Rpi home directory, say “test_mrfc522”. Copy the above three programs in this new directory, (c) I will use Rpi Desktop GUI Thonny IDE to run read01.py.

You might use terminal command something like this. “$ python read01.py” to run it. My modified read.py program is in this penzu: “mfrc programming log V0.7”: penzu.com/p/df27d289.

Ah yes, you can download the zip file (Ref 27 of my answer) to either Windows PC or Rpi. I am a GUI guy and I can do it in GUI Win10 many times faster than in CLI Rpi buster, perhaps vice versa for you. I sometimes use Windows PureFTP or Samba to transfer files between PC and Rpi. But often I just use a USB finger as a courier. I also have a 500GB SSD in Rpi and also in Win10 to back up things, just in case I mess up things. Good luck.

Ah bed time! I call it a day. Good luck and see you tomorrow.

And before I go –