Fan Controller Feature Request - differential sensor reading for delta-T sampling - English forum

Teasuti

Junior Member

Fan Controller Feature Request - differential sensor reading for delta-T sampling

Montag, 29. Dezember 2025, 12:12

1

Hi,
If there's a better place for this request, would you be so kind to direct me there?
Otherwise I was hoping this thread might get backed up by the community.

The idea is to have two sensor readings - physical sensors that are connected to the microcontroller (Quadro, Octo, etc) of course - and get the differential of them. It's a simple subtraction really.
It should be extremely easy to implement into the firmware. It's so basic that in fact I wonder why we don't already have it.

Why? I moved to Linux. Since Aquasuite doesn't have a Linux version, my Octo runs on fallback settings, which isn't ideal.
But I doesn't really need Aquasuite that much when we take away all the experimentation. It really just provides a few software sensors to control the
watercooling with delta-T in my case. I don't even use any driver monitoring, just the physical sensors connected to Octo.
Well, not exactly, as I also have a reading from a Highflow Next, but fundamentally I could get away with the basic independent functionalities of each device on a daily basis without any intercommunication.
Since not even Aquaero can do subtraction of two sensors - as far as I know - and put a curve onto that, I plead that the devs give my suggestion some thoughts.

Having a simple subtraction set up and run independently on the microcontrollers would add maybe a few extra lines into the code? I don't see why not.*
This would allow me to set the Octo up in Windows once, having the pump and fans run on delta-T sampled from connected physical sensors only, and effectively remove the software dependency altogether should I want to.Isn't that the core principle of having external fan controllers in the first place? To be software independent?

Loosely related, but with what's going on in Redmond, the user base of Aquacomputer may see a significant shift away from Windows gradually (the excuse the devs gave us why not to make a Linux Aquasuite).
Especially since gaming on Linux is also getting mainstream with Steam Deck and Proton, slowly but gradually.I'm not asking for much. If Linux Aquasuite isn't viable yet, at least can we add a few extra lines of code into the firmware to make your solutions a little smarter?

Thank you!

*In fact making a DIY Arduino fan controller would also not be that difficult for a maker, but I already invested heavily into Aquacomputer devices that should have the same hardware capability. So a clean solution would be preferred over some janky one-trick-pony custom board screwed onto the back of the case.

Or maybe if we could get the source code of the FW, we could flash our own desires onto the uC?

Dieser Beitrag wurde bereits 9 mal editiert, zuletzt von »Teasuti« (29. Dezember 2025, 12:35)

Remayz

Senior Member

Dienstag, 30. Dezember 2025, 00:31

2

I believe what you're asking for is called Aquaero

Teasuti

Junior Member

Mittwoch, 31. Dezember 2025, 19:58

3

Quoted from "Remayz"

I believe what you're asking for is called Aquaero

Can Aquaero do this without Aquasuite? On it's own, in the hardware. Not a sarcastic question, I don't have one, so I can't tell. I ask this genuinely.

Teasuti

Junior Member

Mittwoch, 31. Dezember 2025, 20:08

4

Oh, I just got an idea.
Perhaps I should make a separate board with sensor inputs and outputs, that would do the mixing itself and just feed the output to the Octo.
This would be a nice Sunday afternoon Arduino project for baked-in fix functionalities.
From then on the customizability and adjustability would all depend on how far the maker is willing to take the project on the coding side of things.
(Aquacomputer this is your chance to take notes for your next product before I patent it.)

Dieser Beitrag wurde bereits 2 mal editiert, zuletzt von »Teasuti« (31. Dezember 2025, 20:23)

Remayz

Senior Member

Mittwoch, 31. Dezember 2025, 22:31

5

Citation de "Teasuti"

Citation de "Remayz"

I believe what you're asking for is called Aquaero

Can Aquaero do this without Aquasuite? On it's own, in the hardware. Not a sarcastic question, I don't have one, so I can't tell. I ask this genuinely.
[attach]11261[/attach]
[attach]11262[/attach]

Yes it can. i don't own one but i believe it can have up to 4 virtual sensors managed onboard

Speedy-VI

Senior Member

Donnerstag, 1. Januar 2026, 04:11

6

Quoted from "Remayz"

Yes it can. i don't own one but i believe it can have up to 4 virtual sensors managed onboard

I don’t own one either, but I think Remayz is right. Section 11.2 in the manual explains how the 4 virtual temp sensors can be assigned 3 temp data sources, and have 3 “modes” or functions - calculate the highest/lowest temp, the avg temp, or the temp difference between 2 data sources. I think you select the mode for each virtual temp sensor in Aquasuite or via the touch panel. This is separate from software temp sensors for which the data is brought into the Aquaero via USB.

Teasuti

Junior Member

Donnerstag, 1. Januar 2026, 13:52

7

Quoted from "Speedy-VI"

Quoted from "Remayz"

Yes it can. i don't own one but i believe it can have up to 4 virtual sensors managed onboard

I don’t own one either, but I think Remayz is right. Section 11.2 in the manual explains how the 4 virtual temp sensors can be assigned 3 temp data sources, and have 3 “modes” or functions - calculate the highest/lowest temp, the avg temp, or the temp difference between 2 data sources. I think you select the mode for each virtual temp sensor in Aquasuite or via the touch panel. This is separate from software temp sensors for which the data is brought into the Aquaero via USB.

That's a good call. I haven't read it past section 7.1 which didn't mention other functions than just min/max/avg.

I'm
just going out on a limb here, but I'd be curious how clever is that
part of the firmware. Could a Virtual Sensor take the output from
another Virtual Sensor as an input? Currently in Aquasuite I have 3
thermistor readings on the GPU/CPU inlets and outlet to measure the heat
each component adds to the water, and having the Octo to do PID control
and adjust the pump speed to keep to a target temperature (difference)
of 1C of either the GPU or CPU block, whichever is higher.
This would
look like a stack of Virtual Sensors, where there're two Virtual
Sensors calculating the difference on the GPU and CPU inlet/outlet
separately, then a third Virtual Sensor would take these two and feed
the higher of the two into the output. It could be done with 3 Virtual
Sensors IF the firmware can reuse their output as input between them.
This is just an elaborated pump control I have in Windows Aquasuite.

Then I could still have the 4th one to calculate a differential between room temp and the water for the fan control.

InfoSeeker

Senior Member

Freitag, 2. Januar 2026, 04:47

8

Quoted from "Teasuti"

That's a good call. I haven't read it past section 7.1 which didn't mention other functions than just min/max/avg.

I'm
just going out on a limb here, but I'd be curious how clever is that
part of the firmware. Could a Virtual Sensor take the output from
another Virtual Sensor as an input? Currently in Aquasuite I have 3
thermistor readings on the GPU/CPU inlets and outlet to measure the heat
each component adds to the water, and having the Octo to do PID control
and adjust the pump speed to keep to a target temperature (difference)
of 1C of either the GPU or CPU block, whichever is higher.
This would
look like a stack of Virtual Sensors, where there're two Virtual
Sensors calculating the difference on the GPU and CPU inlet/outlet
separately, then a third Virtual Sensor would take these two and feed
the higher of the two into the output. It could be done with 3 Virtual
Sensors IF the firmware can reuse their output as input between them.
This is just an elaborated pump control I have in Windows Aquasuite.

Then I could still have the 4th one to calculate a differential between room temp and the water for the fan control.

For most single loop systems (CPU > GPU > Radiator), your hottest coolant will be at the 'in' side of the radiator.
Generally, ramping the pump up and down has little effect on the cooling plate. The increased coolant flow across the plate is offset by less time in the radiator.
120 to 220 lph is normally acceptable (find quietest pump setting in that range).
Then take the delta of ambient and the 'out' port of the radiator for the fan control, and leave the pumps alone.

Speedy-VI

Senior Member

Samstag, 3. Januar 2026, 02:09

9

Quoted from "InfoSeeker"

Generally, ramping the pump up and down has little effect on the cooling plate. The increased coolant flow across the plate is offset by less time in the radiator.
120 to 220 lph is normally acceptable (find quietest pump setting in that range).
Then take the delta of ambient and the 'out' port of the radiator for the fan control, and leave the pumps alone.

The effect that pump speed and flow rate has on cooling loop heat transfer efficiency has long been debated. The general consensus is that outside of extremes, it has little effect. I have confirmed this through my own testing. I set my D5 Next pump to 100% and let the temperatures stabilize. I then reduced the pump speed in 5% increments. I did not see any change in temps until the pump speed was below ~20%. I don’t think constantly changing the pump speed by having it chase a delta-T will significantly improve the loop heat transfer efficiency, and it may put undue strain on the pump.

Quoted from "Teasuti"

Could a Virtual Sensor take the output from another Virtual Sensor as an input? ...This is just an elaborated pump control I have in Windows Aquasuite.

When you set this up in Aquasuite, did you perform testing to determine what, if any, improvement it provides? You may want to reconsider what you use the calculation output data for. Unlike pump speed, radiator fan speeds do have a significant effect on coolant temp, which in turn has an effect on CPU and GPU coldplate temps. This is why many people use Aquasuite to subtract ambient temp from coolant temp and assign the delta-T data to a fan speed curve or PID controller.

Whether virtual sensor outputs can be temperature inputs to another virtual sensor is an interesting question, but unfortunately, I do not know the answer. Manual Section 11.2 says, “Mode and up to three data sources (temperature sensors) can be selected for each of the four virtual temperature sensors.” I think this means each of the 4 virtual sensors can have different temp sensors assigned to them, but it does not say whether one or more of these temp sensors can be the output of one of the other virtual sensors. Maybe someone who owns an Aquaero or an Aquacomputer rep will chime in here.

Quoted from "Teasuti"

Oh, I just got an idea.
Perhaps I should make a separate board with sensor inputs and outputs, that would do the mixing itself and just feed the output to the Octo.
This would be a nice Sunday afternoon Arduino project for baked-in fix functionalities.
From then on the customizability and adjustability would all depend on how far the maker is willing to take the project on the coding side of things.
(Aquacomputer this is your chance to take notes for your next product before I patent it.)

This is a cool idea! You could set up a microcontroller and a few temp sensors as a stand-alone device and write code that will perform the mathematical functions you want on the temp sensors’ data. I would use Arduino-IDE, ESP-IDF, or STM CUBE-IDE, since all of these compile source code into native machine code and flash it as firmware stored in non-volatile memory on the microcontroller. This part is relatively easy. The tricky part is getting the final delta-T value into the Octo and not via USB. The Octo temperature sensor inputs are designed for a 10KΩ NTC thermistor. Internally, I think the Octo provides a known excitation voltage (probably 3.3 V) and includes a fixed precision resistor that forms a voltage divider with the external thermistor. The voltage at the divider junction is measured by an ADC input on the Octo’s microcontroller. From this measured voltage, the known excitation voltage, and internal resistor value, the firmware calculates the effective resistance of the connected thermistor. The calculated resistance is then converted into a temperature value in degrees Celsius using an assumed thermistor model, likely implemented as a Beta-based approximation, commonly B3950Kor an equivalent lookup table derived from a 10 KΩ NTC thermistor characteristic curve. I doubt that the Octo is using Steinhart & Hartcoefficients to calculate the temperature as these are used for levels of precision that are higher than what the Octo targets.

Your microcontroller would have to output the delta-T data in a format that emulates the resistance of a 10KΩ NTC thermistor when it is measuring a temperature. I think the way to do this is add a Digi-Pot that the microcontroller talks to over I2C or SPI. The microcontroller would tell the Digi-Pot what DC resistance to output on its analog pins that are connected to an Octo temp sensor input. For this application, I would go with I2C and a Digi-Pot like the Analog Devices AD5241. It may require a series fixed resistor depending on the range of the Digi-Pot. If you have an idea for an easier way to get the temperature value from your microcontroller into the Octo, please share. Maybe I am overcomplicating this.

Teasuti

Junior Member

Sonntag, 4. Januar 2026, 02:43

10

Quoted from "InfoSeeker"

Quoted from "Teasuti"

That's a good call. I haven't read it past section 7.1 which didn't mention other functions than just min/max/avg.

I'm
just going out on a limb here, but I'd be curious how clever is that
part of the firmware. Could a Virtual Sensor take the output from
another Virtual Sensor as an input? Currently in Aquasuite I have 3
thermistor readings on the GPU/CPU inlets and outlet to measure the heat
each component adds to the water, and having the Octo to do PID control
and adjust the pump speed to keep to a target temperature (difference)
of 1C of either the GPU or CPU block, whichever is higher.
This would
look like a stack of Virtual Sensors, where there're two Virtual
Sensors calculating the difference on the GPU and CPU inlet/outlet
separately, then a third Virtual Sensor would take these two and feed
the higher of the two into the output. It could be done with 3 Virtual
Sensors IF the firmware can reuse their output as input between them.
This is just an elaborated pump control I have in Windows Aquasuite.

Then I could still have the 4th one to calculate a differential between room temp and the water for the fan control.

For most single loop systems (CPU > GPU > Radiator), your hottest coolant will be at the 'in' side of the radiator.
Generally, ramping the pump up and down has little effect on the cooling plate. The increased coolant flow across the plate is offset by less time in the radiator.
120 to 220 lph is normally acceptable (find quietest pump setting in that range).
Then take the delta of ambient and the 'out' port of the radiator for the fan control, and leave the pumps alone.

Eh, hell no! My D5 goes down to 1% PWM at idle. And up to 30% at full load. 30% is my noise limit. My noise threshold is 2%.

So 1% gives me about 50 l/h, and 30% is around 120 l/h. There IS a huge performance difference on the cold plate between these two. If there wasn't, then the PID control simply wouldn't ramp up as the thermal delta between the inlet and outlet wouldn't run away. There may be not much diff ABOVE 120 l/h. But below it it's day and night.

Plus it's not the CPU temp that matters, as that will stabilize exactly at throttling temps: 95C on my Ryzen. It's not CPU or water temp where you'll see the difference. It's in the boost clocks.

Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von »Teasuti« (4. Januar 2026, 02:49)

Teasuti

Junior Member

Sonntag, 4. Januar 2026, 03:03

11

Quoted from "Speedy-VI"

Quoted from "Teasuti"

Oh, I just got an idea.
Perhaps I should make a separate board with sensor inputs and outputs, that would do the mixing itself and just feed the output to the Octo.
This would be a nice Sunday afternoon Arduino project for baked-in fix functionalities.
From then on the customizability and adjustability would all depend on how far the maker is willing to take the project on the coding side of things.
(Aquacomputer this is your chance to take notes for your next product before I patent it.)

This is a cool idea! You could set up a microcontroller and a few temp sensors as a stand-alone device and write code that will perform the mathematical functions you want on the temp sensors’ data. I would use Arduino-IDE, ESP-IDF, or STM CUBE-IDE, since all of these compile source code into native machine code and flash it as firmware stored in non-volatile memory on the microcontroller. This part is relatively easy. The tricky part is getting the final delta-T value into the Octo and not via USB. The Octo temperature sensor inputs are designed for a 10KΩ NTC thermistor. Internally, I think the Octo provides a known excitation voltage (probably 3.3 V) and includes a fixed precision resistor that forms a voltage divider with the external thermistor. The voltage at the divider junction is measured by an ADC input on the Octo’s microcontroller. From this measured voltage, the known excitation voltage, and internal resistor value, the firmware calculates the effective resistance of the connected thermistor. The calculated resistance is then converted into a temperature value in degrees Celsius using an assumed thermistor model, likely implemented as a Beta-based approximation, commonly B3950Kor an equivalent lookup table derived from a 10 KΩ NTC thermistor characteristic curve. I doubt that the Octo is using Steinhart & Hartcoefficients to calculate the temperature as these are used for levels of precision that are higher than what the Octo targets.

Your microcontroller would have to output the delta-T data in a format that emulates the resistance of a 10KΩ NTC thermistor when it is measuring a temperature. I think the way to do this is add a Digi-Pot that the microcontroller talks to over I2C or SPI. The microcontroller would tell the Digi-Pot what DC resistance to output on its analog pins that are connected to an Octo temp sensor input. For this application, I would go with I2C and a Digi-Pot like the Analog Devices AD5241. It may require a series fixed resistor depending on the range of the Digi-Pot. If you have an idea for an easier way to get the temperature value from your microcontroller into the Octo, please share. Maybe I am overcomplicating this.

Yeah, I thought about that part. There are multiple ways to go about it. If you are willing to hack the Octo, then you could feed a voltage straight into its ADC, bypassing its own voltage divider.
If hacking isn't an option, then presenting a simulated resistance is also not that difficult. There are ways to do it, the simplest being a simple digipot and the more sophisticated being an active programmable-impedance circuit. Well, either way the material expense of the project would be just the fraction of what an Aquaero costs... I really don't see a reason why would we reserve such a simple functionality only to the flagship product, when it's all in the code, not in the hardware (well, if the Octo's ROM had a few KB legroom left in it, but we won't get to know that). An Octo could do the Virtual Sensor thing just the same.

Btw, that was quite a writing. Is this your field of expertise or just being a little autistic and overshared, like me sometimes?

Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von »Teasuti« (4. Januar 2026, 03:19)

Speedy-VI

Senior Member

Montag, 5. Januar 2026, 04:49

12

Quoted from "Teasuti"

Yeah, I thought about that part. There are multiple ways to go about it. If you are willing to hack the Octo, then you could feed a voltage straight into its ADC, bypassing its own voltage divider. If hacking isn't an option, then presenting a simulated resistance is also not that difficult. There are ways to do it, the simplest being a simple digipot and the more sophisticated being an active programmable-impedance circuit.

I had not considered hacking the Octo. Sending a voltage straight to its ADC should work. For the other option (into an Octo temp sensor header), because it's just emulating a thermistor, an active programmable impedance circuit could be a simple MOSFET controlled from an ADC pin or a filtered PWM output of the microcontroller. I think a Photo-FET Optocoupler would also work. For a digi-pot, Adafruit #4286 is an Analog Devices DS3502 I2C-controlled digital 10K potentiometer on a small breakout board with a Stemma QT connector.

Quoted from "Teasuti"

I really don't see a reason why would we reserve such a simple functionality only to the flagship product, when it's all in the code, not in the hardware (well, if the Octo's ROM had a few KB legroom left in it, but we won't get to know that). An Octo could do the Virtual Sensor thing just the same. .

I can’t speak to Aquacomputer’s decisions about which devices get certain features, but I agree that it should be trivial to add code to the Octo that allows it to perform simple mathematical functions on local sensor data. Doing so would make a lot of Linux users happy. I don’t know if the Octo ROM is out of space, but its a possibility. I don't think you are the first person to suggest adding this capability to the Octo and Quadro, so maybe there is a hardware limitation that makes this more difficult than it seems to be. A while back, I asked Aquacomputer about the D5 Next not reading flow rate data properly when a High Flow Next Signal output is connected to the D5 Next Fan/Flow header (in Flow mode). They said the calibration was off in the D5 Next firmware, but they did not want to release a firmware update just to fix that, since 99.9% of people never connect the 2 devices this way. They also said the D5 Next ROM was totally maxed out, and they were already tweaking and optimizing code to make it fit, and they don't like messing with it. They did correct the issue in the next firmware update. Regarding Aquasuite, several people in this forum have suggested some really clever, simple things to add to the program, but I don’t recall them implementing any of them. To be fair, some of the Aquasuite updates have added significant new features. It’s an excellent program (other than still using an unsigned kernel-mode driver to acquire sensor data).

Quoted from "Teasuti"

Btw, that was quite a writing. Is this your field of expertise or just being a little autistic and overshared, like me sometimes?

Regarding your last question, I‘ll answer “B” – a little autistic and overshared. I’m an Electrical Engineer by day. Building computers with custom cooling loops is just a hobby. My interest in programming microcontrollers started due to my dissatisfaction with the Aquasuite RGBpx LED effects presets. A few years ago, I asked Aquacomputer if they would add a common LED lighting effect. At first, they said they would if I sent them a video of the effect. After I sent the video, they said they would not add it, and I should just pick one of their presets and like it. I decided to do it myself. I bought a microcontroller and learned how to write code to control WS2812B LEDs, then made the effect I wanted. Now I am thinking about making an LED controller functionally similar to a Farbwerk360, but able to run any LED program/effect I want. Controlling the LEDs is easy. The GUI to control the effects parameters and the USB communication to the MCU is more complex. Thinking about this kind of stuff is my mental bubblegum. I don't consider myself an expert in these things.

If you do attempt to hack the Octo or spoof a 10K NTC Thermistor, please post your results. I think there would be a lot of interest from Linux users and people who want a fully hardware based control system that does not rely on Windows software and USB communication. Heck - you could probably make it a product and sell them on TINDIE

Fan Controller Feature Request - differential sensor reading for delta-T sampling

Ähnliche Themen