Pi4 cooling fan

It is pin 14.

Thanks, Chris: that’s reassuring.

I don’t know the correct syntax.

I have a Debian-formatted SD card, so decided to enable fan control on that and then copy the fan control details from that into Config.txt on the RO bootloader. The Linux syntax is: ‘dtoverlay=gpio-fan,gpiopin=14,temp=8000’ (for an 80C default trigger – I figured this should be set higher than the CPUClock 50C trigger).

The short answer: it makes no difference, the fan still runs full-time (current temp is 36C), so back to the drawing-board.

I don’t know if that was a typo, but the number should be in milliCelius, e.g. 60000 (80000 is to high the Pi4 is likely to start throttling before then).

But this isn’t used on RISC OS, and if it were CPUClock would not be able to use pin 14 to control the fan itself.

milliCelius

As soon as I see something like that, I start wondering about the actual accuracy of the sensor.

For a start, how well calibrated is it? And how accurate is it really? Thermocouples aren’t terribly (often +/- ½ to 5C). Thermistors are better, typically +/- 0.05C to 1C). But nothing that’s stuck in a processor in order to stop it overheating is going to have an accuracy of milli anything.
I’m sure such things exist for military and, particularly, aerospace applications, and I’d reckon the sensor alone will likely cost an order of magnitude more then the entire processor.

So… what’s with this milliC nonsense?

I don’t know if that was a typo

It was: since corrected to 80000.

and if it were CPUClock would not be able to use pin 14 to control the fan itself.

CPUClock uses pin 14: see Chris Johnson’s reply to my query above.

UPDATE: whether or not the pin is the correct one, the fan uses PWM (Pulse Width Modulation), as opposed to simple On/Off, signals. If CPUClock requires the latter all bets are off regardless. Despite correcting the temp as above, the fan continues to run non-stop…

As soon as I see something like that, I start wondering about the actual accuracy of the sensor.

Nothing to do with the accuracy of the sensor, it’s using an integer rather than a float, so it is common for many sensors to use Celcius * 1000

CPUClock uses pin 14: see Chris Johnson’s reply to my query above.

On Linux the overlay takes over pin 14 and switches the fan on above the set temperature, if that worked on RISC OS !CPUClock would not be able to control the fan.

It was: since corrected to 80000.

That’s far too high, the Pi will already be throttling by then. Anything from 50000 to 75000 is better.

Nothing to do with the accuracy of the sensor, it’s using an integer rather than a float, so it is common for many sensors to use Celcius * 1000

Also, it isn’t just accuracy that we care about for these things: resolution can also be important in a lot of applications. Seeing things expressed as milli- (or centi-, or deci-) whatevers isn’t at all uncommon.

Also, it isn’t just accuracy that we care about for these things: resolution can also be important in a lot of applications.

This, exactly. I might not care whether I’m controlling temperature to the nearest tenth of a degree, but I might care very much exactly the way the temperature wanders up and down – how far, and how fast.

True, but if the resolution of the sensor is accurate to only a tenth if a degree, then doesn’t that imply that changes of a hundred milliC either way is quite possible when there’s no actual change?

If your sensor can only manage 0.1C resolution, then that’s really all the result should be. The rest is just noise.

And, no, we don’t really need any higher accuracy as this isn’t an application where accuracy is particularly important. The trend, relative to itself (as noted above) plus a figure that can determine when to turn on fans or start to throttle. Plain regular C would suffice for most of this.

If it’s too accurate, there’s a pretty good chance that the act of monitoring the temperature will cause a detectable increase, which will in itself skew the result slightly.

Fun, huh? ;)

If your sensor can only manage 0.1C resolution, then that’s really all the result should be. The rest is just noise.

The problem with that is if you change you sensor to one with a 0.05C resolution you need to change the code to divide the integer reading by 100 instead of 10. Using a multiplier of 1000 makes it more independent of the sensor used.

For example the popular 1-wire DS18B20 sensors have a resolution of 1/16 of a degree i.e. 0.0625C, so returns an integer value of milliCelcius, it does not mean they have a resolution of, or are accurate to 0.001C

Is there anyone out there who has installed a fan on a Pi4B and controlled it via CPUClock, and if so, what parameters and settings did you use? I can’t be the only RO user interested in cooling an overclocked Pi4B; many are sold in cases by R-Comp, RISCOSBits et al where cooling is mandatory even at standard CPU speeds. My 3-wire, GPIO pin 14-connected, PWM fan continues to run full-time i.e. uncontrolled, and it would be nice to know if there is a solution under RISC OS.

Is there anyone out there who has installed a fan on a Pi4B and controlled it via CPUClock,

Yes. All I did was plug the 3 wires into the required GPIO pins and ticked the ‘Enable Fan Control’ in CPUClock.

Once CPUClock is running the fan stays switched off until 55C is reached and switches off again when the temperature goes below the differential. (4C).

All I did was plug the 3 wires into the required GPIO pins

Thanks, Chris. The ArmorLite instructions indicate these to be pins 4, 6 and 8 on this schematic: https://www.raspberrypi.com/documentation/computers/images/GPIO-Pinout-Diagram-2.png
respectively 5V (red wire), Ground (black wire) and GPIO 14 (TXD – blue wire). Are those the ones you used?

Are those the ones you used?

Those are the same as mine. Does the fan switch off if you boot into debian?

The ArmorLite instructions indicate these to be pins 4, 6 and 8 on this schematic:

Having checked back to the info I was supplied with when I was adding the fan control facility to CPUClock, these are the same pins I used on the Pi I was sent to test on. Thus it looks as if it all should work!

It is quite simple to test the fan off and on capability without involving CPUClock at all. Make two little Basic files as below.

Turn fan off.
SYS “GPIO_WriteOE”, 14, 0: REM Set GPIO 14 as an output
SYS “GPIO_WriteData”, 14, 0: REM Turn fan off

Turn fan on
SYS “GPIO_WriteOE”, 14, 0: REM Set GPIO 14 as an output
SYS “GPIO_WriteData”, 14, 1: REM Turn fan on

Double clicking the two files alternately should make the fan go off and on. This should show whether the fan control is actually operational.

True, but if the resolution of the sensor is accurate to only a tenth if a degree, then doesn’t that imply that changes of a hundred milliC either way is quite possible when there’s no actual change?

You’re now confusing tolerance with noise…

The short answer is that all of the above scenarios are possible, depending on how the hardware has been designed and what the requirements for it were. And, as Druck says, not all of the available resolution needs to be used in practice. That’s why engineers are needed to design and use this stuff correctly. :-)

Does the fan switch off if you boot into debian?

Yes. Back in RISC OS I’ve checked CPUClock-Module Info where it says ‘Fan control = N/A’. I’m using version 2.09 which I believe is the latest. Has something not loaded which should have?
UPDATE: have since downloaded v2.09-2 from !PackMan and installed it. Fan control still N/A in Module Info, and fan still running full-time.

Make two little Basic files as below.

Fired up BASIC in a task window, got an error on pressing Return after inputting line one of the Turn fan off program. Some elementary BASIC error on my part no doubt.

Back in RISC OS I’ve checked CPUClock-Module Info where it says ‘Fan control = N/A’.

When the module initialises, it does some checks – eg isit a RaPi, is the GPIO module available etc. If Fan control is N/A it means one of these checks has failed.

Fired up BASIC in a task window, got an error on pressing Return after inputting line one of the Turn fan off program.

A first guess is that the GPIO module is not available. Do a *h. modules in a taskwindow. Is there a mention of GPIO?

You really need to enter the two programs in an editor (Zap or SEd) and save each as a Basic file. Then you can run them at will.

Do a *h. modules in a taskwindow. Is there a mention of GPIO?

No.

…save each as a Basic file. Then you can run them at will.

Thanks for the reminder re text editor. Sadly however, Turn fan off (saved out of StrongED as Type BASIC) produces an ‘Application may have gone wrong’ error on double-clicking.

I can’t help with the GPIO issues, however did you copy the code from the forum or type it in anew? If it was copied, the forum “helpfully” makes the quotes “sexed”, and also wraps the text to look like some of it should be on a new line.

Try this:

REM Turn fan off.
SYS "GPIO_WriteOE", 14, 0   : REM Set GPIO 14 as an output
SYS "GPIO_WriteData", 14, 0 : REM Turn fan off

REM Turn fan on
SYS "GPIO_WriteOE", 14, 0   : REM Set GPIO 14 as an output
SYS "GPIO_WriteData", 14, 1 : REM Turn fan on

I think those ought to be valid programs now, though if you don’t have a GPIO module…?

You’re now confusing tolerance with noise…

I’m aware of the difference, it was a rhetorical question, as us meatsacks are rather good at seeing patterns where there aren’t any. If the tolerance is too fine then there’s a risk of seeing/recording phantom changes exactly due to said noise.

And, anyway, does a core temp really need more than a .1C accuracy?

an ‘Application may have gone wrong’ error

What does Describe tell you?

If the GPIO module is not present, then there is no way GPIO related operations will be possible.

What do you see if you do a *ROMMODULES? Is there a GPIO module? You could also try a *unplug. What is reported?

did you copy the code from the forum or type it in anew?

Tried both ways, spotted the ‘sexing’ of the double quotes and corrected. Either way it failed. I’ll try your script – thanks.

What does Describe tell you?

will check & report (not at RO machine). Will check *ROMMODULES and *Unplug also.

Will check *ROMMODULES

Reports ‘137 System ROM GPIO 1.00 Dormant’. *Unplug reports no modules unplugged.

What does Describe tell you?

‘SWI name not known’.