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?

Zitat von »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.

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.)

Zitat von »Speedy-VI«

Zitat von »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.

Zitat von »InfoSeeker«

Zitat von »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.

Zitat von »Speedy-VI«

Zitat von »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?

Zitat von »Speedy-VI«

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.

I ordered some clones of the Adafruit 3502 and the 1841 breakout boards. I have a hunch the logarithmic pot would do the trick. I didn't do the math for the thermistor and the log pot, but by a quick glance at the graphs that just looks right to me.
I'm curious to see what temp range the 3-22k resistance - or whatever it was - and precision the 128 steps could mimic. If my early prototype works as expected, I may look into a more sophisticated solution and a high resolution multi-channel digi pot, perhaps on a custom board.
Jeez, those fancy digipots are not cheap. After the prototyping it will be a hassle to find one that JLCPCB could ship directly.

In the meantime I found the time and motivation to dust off my old Arduino Starter kit and experiment with an NTC and the DS3502. I was more interested to see the DS1841 in action, but that unit I got was a dud...
Well, at least I learnt enough of the Octo's sensor input to say it has got a simple voltage divider on the ADC, and the 2-pin connectors are the GND and the ADC input with a 5.6k pull-up resistor on it.
Sadly I did not have that exact value in my shoe box of components. I'll have to put it on order, just to copy the Octo as closely as possible.

The Uno was connected to the usb port of the PC, so the common ground is also sorted through the usb connection.

As for the digipot, I connected it to the Octo in several configurations and found that in pure rheostat mode it only serves as a 0-10k variable resistor. That with the 5.6k pull-up gave me a very narrow window of 25-30C. The starting point of 25C matches the expectations of the Steinhart–Hart approximation, but the high end has fallen way short of expectations.
Oddly enough the temperature reading in Aquasuite wasn't consistent. Over the course of a minute or so it was sort of "wandering" up and down +-1 degree, which I don't understand why. On paper the resistor ladder is electronically separated from the chip's control circuit, so the Uno's 5V logic and Vcc, plus any sort of noise or Vdrop should not affect the sampling on the voltage divider in the Octo.

Now in a different configuration - after identifying the pin-out of the Octo - if I use a 3v3 reference on the high terminal of the potentiometer and use it as an actual potentiometer (GND on the low terminal and of course the wiper is on the ADC input), I could effectively bypass the pull-up and achieve the full range from -15C to around 40. I expected it to show well above 100C as well when the resistance gets in the low two digit Ohm (zero on the ladder, but the wiper itself also has some resistance). It didn't go much higher though, which I also fail to understand. No matter though, for the intended purpose of dT functions, I'd hardly need a range bigger than like 0-15C.

And I didn't observe much variance in potentiometer mode, when the voltage is fed into the ADC directly via the digipot. I guess the pull-up resistor along with the external 3v3 reference could bias it a little, but the consistency is much better for some reason than in rheostat mode.
If an electrical engineer reads this and have a better idea what's going in with that +-1C uncertainty in the temp readings, please let me know. It also could be the works of the firmware in the Octo, as it seems to smooth out the reading. Some sort of post-processing is going on it there too.

My next step is to get some pull-up resistors and start to toy with a couple NTCs to implement the functions I want, then try to feed the result into the Octo.
The DS3502 proved to be very limited in the resolution. When used as a potentiometer, the average step size was about 0.74C. If I wanted something with an error of less than 0.1C, than I believe even the 10-bit digipots would barely able to do it (and I'm not aware of higher resolution digipots), and only in a limited scope of 0-10k. I think a 50k digipot would be much more useful if I wanted to simulate an NTC close to its full range (and of course the Octo can have a +-15C offset as well). The problem is that big of a range would cripple the effective step size and the 10-bit resolution is just not enough to achieve an error of <0.1C.

Could I perhaps get a 20k digipot and put a 13-15k resistor in series with it to get the ~33k resistance for a 0C reading in the Steinhart–Hart equation? It could still go down to the 13-15k (where the resistor becomes the limiting factor), which would get me a range from 0 to 15-20C in Aquasuite (Octo), which is very manageable for the intended purpose. Plus a lower end-to-end resistance would give me smaller steps, so with the 20k digipot I estimate an average step size of 0.2C. That's way better than what my motherboard can do (BIOS temperature readings on the NTCs are rounded integers), but much worse than what the Aquasuite (Octo) can do - which has 2 digit precision.

As for a suitable digipot candidate, I'm currently eyeing this one:
https://ww1.microchip.com/downloads/aemDocuments/documents/MSLD/ProductDocuments/MCP41U83-Data-Sheet-DS20007000.pdf


Sadly there are no breakout boards available with this chip on it, so I would need to prototype one myself.

Zitat von »Remayz«

Zitat von »Teasuti«

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.

You are in the extreme that he talked about :p

at those very low flows, there's not enough for the coldplate to work properly so the temperature skyrockets, which can be fine at idle, but the second load increases, you have to immediately accelerate the pump.
If you ran the pump constantly at 30% or beyond, you wouldn't see much effect at all changing speeds.
D5 are a bit finnicky with noise, they have noisy regions where they vibrate, so it's worth testing if you haven't yet to find higher speeds that remain silent.
Mine hums at around 50, 66, and above 75% PWM. clear of those spots it's pretty much inaudible, and below 35%; my GPU starts complaining.

Yeah, I just learnt a week ago about the PWM whining or humming of the D5. I always thought it's fan vibration that comes through the PC case and I have been hating it since day 1 some 3 years ago! It's sooo annoying that specific harmony I can hear through the headphones, through music, through anything really.

Then since I moved to Linux and lost software control, I don't know why but I turned it up to 100% one day and left it there. Yeah, it was loud initially. But miraculously after a day or two I forgot I left it running on full speed, because I didn't hear it! I guess it worked out the air in the system, or the vibration went away, or the ceramic bearing is just happier, dunno.
Now it's quieter at 100% than it was in the 1-30% range. I guess the constant DC voltage also removed the harmonics somewhat (not completely). All in all the D5 is a disappointment for me after the air cooling. At least the fans doesn't have whining noise that comes through the headphones.

I made some progress today on the Arduino side of things.
So I have a working prototype now.
I hooked up the board to the Octo, stole two sensors, calculated a quick delta T, then fed it back to the Octo via the DS3502.
As imprecise as it is with the large steps (I get in potentiometer mode - RH, RW, RL all connected), the concept works like a charm.
Next phase will be to design a breakout board for the chosen digital potentiometer and experiment with that in place of the DS3502.
See what kind of precision do I get. If the 10-bit ADC is anything to go by, with the Steinhart-Hart formula I get temperature readings with a two digit precision. If I can reproduce that on the Octo with a 10-bit digipot, I'll be happy.