aquaticus / nexus433

433MHz temperature and humidity sensor receiver that integrates with home automation systems.
GNU General Public License v3.0
192 stars 32 forks source link

CPU usage #10

Closed vnorbix closed 5 years ago

vnorbix commented 5 years ago

I have a question about how the application processes the output from the receiver. When I start the app with the default 1microsec resolution, it takes 40-45 percent of CPU on my RPi3. I have 2 sensors, it finds both of them, but it reports 30-40% quality (received frames), even if I put the sensor next to the receiver. I have a small but proper length and aligned antenna on the receiver. There are other applications are also running on the RPi (desktop), and it seems when the CPU usage is higher, the quality is degraded, even sensors are disappearing for a while. What do you suggest, should the nexus433 be moved to a separate board not to affected by any load to work correctly? I tried to set the priority of the process, doesn't really help. Also the higher idle CPU usage if the app is not really nice, can something be done about this?

aquaticus commented 5 years ago

The issue you described is not an easy thing to fix. The main problem is that Linux on RPi is not real time operating system. You never know how much time scheduler assigns to you app. If the system is not very busy, the app got enough time to process entire transmission more or less in real time. If you run too much other programs, you can easily miss bits. For now the only solution (but unfortunately not guarantee 100% success) is to force system to assign more time for the app:

  1. Increase priority of the app; see nice command
  2. You can change resolution to 0 (CPU usage will raise). In addition you can increase tolerance (but big values can also degrade significantly quality).
  3. Run the app on separate system that is either dedicated to 433MHz reception or does not run too much apps (but that makes this app quite obsolete because you can use cheaper dedicated board just for 433MHz).

To definitely solve the problem, kernel device driver is needed and entire signal processing should be made there. I got that in my plans but this is rather song of the future.

vnorbix commented 5 years ago

Thank you for your detailed explanation!