High CPU load by daemon_rfid_reader.py and MFRC522

[kaoz3000]

Hi,
I'm using the MFRC522 Module with the scripts from @keinkurt: https://github.com/keinkurt/RPi-Jukebox-RFID/tree/MFRC255/scripts on a Raspberry Pi Zero W
I just recognize that the daemon generates a pretty high CPU load between 50–80%:
pi 486 **80.4** 1.7 11608 7624 ? Rs 20:47 17:29 /usr/bin/python2 /home/pi/RPi-Jukebox-RFID/scripts/daemon_rfid_reader.py
This is much more then mpd, which make about 7–10%

Maybe communicate with the reader less often?

[varac]

Lower the CPU load would be great indeed.
The problem is that the used MFRC522.py class comes from the MFRC522-python project. This project has anunresolved issue with high CPU load because it's not possible to use interrupts easily to listen for events, and the only way to read tags is a nasty while loop, which looks for tags over and over again.
Adding a time.sleep(0.3) in this loop will lower the CPU load, but it's still not ideal.

The solution would be to migrate to the pi-rc522 class, which solved this issue by adding support for listening on events and introduced a wait_for_tag() function which just waits until a tag is detected.
Moving from a simple while loop in a different project to wait_for_tag() in a different project decreased CPU load from 80% to 1-2% with this class!

[varac]

@keinkurt thx for bringing RC522 support to this project - don't you experience this high CPU load issue yourself ?

[varac]

Just for the numbers, adding a time.sleep(0.3) as described above decreased the CPU load at my system (rpi 2) from 100% to 40%.

[fenkman]

Lower the CPU load would be great indeed.
The problem is that the used MFRC522.py class comes from the MFRC522-python project. This project has anunresolved issue with high CPU load because it's not possible to use interrupts easily to listen for events, and the only way to read tags is a nasty while loop, which looks for tags over and over again.
Adding a time.sleep(0.3) in this loop will lower the CPU load, but it's still not ideal.

The solution would be to migrate to the pi-rc522 class, which solved this issue by adding support for listening on events and introduced a wait_for_tag() function which just waits until a tag is detected.
Moving from a simple while loop in a different project to wait_for_tag() in a different project decreased CPU load from 80% to 1-2% with this class!

I just submitted a pull request ( #345) doing what you suggested. Thanks for the tip. Saved my Pi-zero-based project.

[MiczFlor]

Hi, I merged this with the develop branch
@fenkman
#345
and it will go to the master branch soonish. Please test develop, if this works for you. My fear, that happened before: the merge will break all USB RFID readers - and that caused me sleepless nights and unnecessary work. that happened before. See:
#231

[varac]

I am successfully using develop together with my MFC522 reader.
I needed to do 2 adjustments:

• Use Reader.py.experimental as Reader.py
• Let daemon_rfid_reader.py work with Reader.py.experimental

So @MiczFlor please judge yourself my commits, I'm not sure how to do a proper PR since I don't know if Reader.py.experimental will replace the current Reader.py.

Btw, the CPU usage improvements are great due to the new use of pi-rc522 and wait_for_tag() !

[cubertt]

i used the master classic Version with the deamon_rfid_reader.py from the Version of Kein Kurt successfully.

The orginal deamon_rfid_reader.py gives the following error:

pi@raspberrypi:/RPi-Jukebox-RFID/scripts $ python daemon_rfid_reader.py
/home/pi/RPi-Jukebox-RFID/scripts
Traceback (most recent call last):
File "daemon_rfid_reader.py", line 14, in
cardid = reader.readCard()
AttributeError: 'Reader' object has no attribute 'readCard'
pi@raspberrypi:/RPi-Jukebox-RFID/scripts $

(sorry for the wrong formated text)

Btw, the CPU usage improvements are great due to the new use of pi-rc522 and wait_for_tag()

Yeah this is great!

[varac]

@cubertt See how to solve the Reader' object has no attribute 'readCard' error in this commit, l. 14.

[fenkman]

Thank you for merging this so quickly and thank you for testing. Unfortunately I cannot verify USB readers - not having one and going for the seemingly cheaper RC-522 module was the reason for me to work on this anyway :-)

Btw, the CPU usage improvements are great due to the new use of pi-rc522 and wait_for_tag() !

All the credit goes to you @varac for pointing us in the right direction.

One caveat to be mentioned here: The connection layout for the RC-522 that you find all over the internet is not sufficient to make this work. You have to connect the RC-522 IRQ pin with GPIO25 to make this work as described here: pi-rc522

[Ardios]

It doesn't work for me. After a fresh installation don't get my reader correctly activated anymore he deactivates himself after I try to read a card

Has anyone tried this with the current version 1.1.8-rc3 classic?

[MiczFlor]

Please read this
https://github.com/MiczFlor/RPi-Jukebox-RFID/wiki/RFID-Reader-Special
I hope that helps.

[Ardios]

Thanks @MiczFlor

I have already tried this manual but as soon as I try to read a card it's over.

[alex-voigt]

I can't get it to work as well.

I have a RC522 module that did not work with the latest version of the install script. After reading here #11 and switching to the Version-1.1.5-dynamicRFIDreader branch I could register the device and use it. But CPU load was so high that my pi couldn't play audio from Spotify without interruption.

So I checked out the develop branch and now the reader doesn't work again.
Running RegisterDevice.py results in an empty reader list.

The additional pin is connected.

@varac Could you please help on how to set up? The changes suggested didn't work for me. But they don't seem to be the problem right now because the reader is not found at all. Setting the device in deviceName.txt manually also didn't work.

[alex-voigt]

Ok, I got it working now. Using the get_devices method from the Reader did the trick...

alex-voigt@aca4519

[varac]

@alex-voigt Have a look at my varac branch.
This is how I got it working.

[MiczFlor]

Hi @Ardios @alex-voigt @fenkman
I merged alex-voight's pull request to develop branch. Please check if this works for you now, before I merge this to master.
Thanks for the input, support and good ideas!

[fenkman]

I checked out the most recent develop branch and it (still) works for me. Thanks for all the good work! 👍