Closed nztvar closed 2 years ago
Quick note: my first attempt to modify and recompile failed with errors, which are likely my fault though I did try to follow your and wiringPi's guidance.
Updated the build cmd in readme, with gcc 10 in raspios bullseye the linked libraries order has changed. This should work: sudo gcc fan-control.c -o fan-control -lwiringPi -lsystemd
This worked perfectly for me to compile with my hard-coded values. The only issue I see is, presumably, a circuit issue with the TACHO, which fan-control
is reporting as 0.0 Hz. (I am using the circuit outlined on rpiforum with the 3.3v -> r1 2.2 ㏀ -> join ( fan green + GPIO 23 ).)
I am still using this code on my RPI4 with Noctua fan for almost a year and half and it works fine. The issue you are facing is with the circuit (also take a look into noctua white paper, may be because you connected tacho through 3.3v) I connect fan directly to the 5v pin and pwm pin directly to the gpio without any circuit in between. I do not connect anything to the 3.3v. Main idea behind writing this code and using noctua pwm fan was to avoid any circuit, use hw pwm and utilize noctua fan's internal pull-up resistor.
Tacho pin code was written during development for testing purpose, it does not add any value in the final service for controlling fan speed (unless you want to utilize software pwm), that is why it is commented out in the final code.
Anyways I tested Tacho pin output right now and it is working fine. Fan should be running to see the tacho output. When fan is not running tacho output will be 0Hz. Also change the delay to 2 sec (WAIT = 2000) to get more accurate tacho output.
May be in some future release when I get time I might take a look into configuration file option. But it is low priority right now. The code I shared is very well documented and it should not be very hard to customize it according to a specific need.
Yes, I figured out my circuit problem eventually - a case of not thinking clearly. The software works fine. And, like you, with a working solution it becomes a lower priority to add features.
Added params.conf for configurable parameters. Instructions updated in readme. It is a very basic configuration file as long as you stick with the provided format, it will work fine. I did not add any extensive checks for trailing and leading spaces, it is going to increase binary size.
RPM_OFF It is very specific requirement that you want to keep fan always on at some low speed. It is available now in params.conf. My recommendation is rather than using this to keep fan always on at some specific minimum speed, use TEMP_LOW, and adjust it to the temperature value according to your environment. It will keep fan spinning at min RPM and the fan will still switch off if temperature goes below that.
THERMAL_FILE This can be used to select thermal filename. Make sure the path+filename should not be longer than 37 characters, this is the default thermal path+filename length. I did not increase the array length because it is again very specific need and remaining array will be wasted for generic use. Also the file you use for thermal should have only temperature in it just like the default file (I think you already know this)
PULSE / TACHO_ENABLE / TACHO_LOG
They are not provided through configuration option. PULSE is always going to remain same for Noctua fan. Tacho params are useful only in very specific use case as I mentioned earlier in my comment. You can still enable Tacho from code. Also you can expand the params.conf functionality to add them for your specific use case.
Edit: Configurable TACHO_ENABLED is available through params.conf from release v2.0
Hard coded values prevent easy customization, reuse. A configuration file could make the rpfc more flexible, and it is clearly a very popular project in the raspberry pi community. E.g. I need to control 3x Noctua A6 5v fans I am using to cool a small blade case (a slightly modified Cloudlet by C4Labs.com), and the temperature to be checked will need to be the highest reported by a monitoring script - probably a custom file location rather than
/sys/class/thermal/thermal_zone0/temp
.Feature request: Read custom values for a setup from file:
Likely there are other values which could usefully be drawn from a configuration file, but these would be a great (for me!) start.