Fan and pump speeds revert to defaults after a few seconds

[jonasmalacofilho]

Issuing

# colctl --fan_speed 100 --pump_speed 100

makes the fans and the pump to spin up.

This can be confirmed both audibly and through --status:

# colctl --status
fan_speed 1786
liquid_temperature 28.6
pump_speed 2803

However, after approximately 10 seconds the fans spin down again, and so does the pump:

# colctl --status
Device status:
fan_speed 756
liquid_temperature 28.4
pump_speed 2239

I assume the firmware is reverting back to its defaults for some reason. Have any of you experienced this already or can reproduce it?

Note: I'm running a brand new unit, with firmware version 4.0.2. ~I'll later boot into Windows and post the firmware version.~

[jonasmalacofilho]

It looks like running the fans or the pump at "fixed" speeds requires sending regular updates. CAM does that every few seconds or so. Not sure if this was always the case or if it is related to the recent firmware.

Still, profiles do (seem to) persist, even on this firmware. I ~will~ might try to open a PR later.

EDIT: working on something else at the moment, might revisit this later.

[jneumaier]

For me it behaves exactly like you descibed with firmware version 4.0.2. Pump speed resets to previous value after around 5 seconds. I guess it just regulates with the default silent mode curve. I found no information about how to edit theses curves in the protocol yet.

[jonasmalacofilho]

I think it might be a failsafe: if CAM crashes, the cooler reverts to the configured profile. From what CAM sets (and from what I have read the firmware ensures), the profiles will always ramp fan and pump speeds to 100% if the liquid reaches its maximum (un)safe operating temperature of 60°C.

An issue with profiles is that they default to 5°C steps (with no interpolation), which is kind of useless on the sensible 20-60°C range, and overkill elsewhere. It is possible to set other steps, but I have experienced issues with the fan profile somehow interfering with the pump profile, and vice-versa. CAM seems to bypass this (while it is running) by brute forcing and sending manual fan and pump speeds every ~second~ five seconds.

[jneumaier]

Very nice! Would be perfect if flat was the default and you could optionally set a minimum and maximum pump speed with linear interpolation. Or maybe all values but I guess linear would be fine for a pump.

On the other hand interpolation between 0°C and 100°C does not really cover our use case :-) Maybe we would have to give some start/end temperatures for the min/max values as well. Do we have to cover this range or is it also possible to set less data points, e.g. 5 points between 30°C - 50°C? What do you think?

Here are some interpolation alternatives.

[jonasmalacofilho]

I absolutely agree with not using flat profiles: personally, I use a quite aggressive curve with the stock Aer P fans, for low noise during light loads (most of day), while still capable of handling the considerable peak heat output or even increased air temperatures.

Originally I tested a mechanism to automatically interpolate and adjust the temperature increments where it made more sense but, as I mentioned above, there were issues with one channel interfering with the other. I think that the firmware only finds the appropriate table offset for the first channel, and reuses it for the other one, with the assumption that both will share the same temperature steps.

Since that failed, I decided to go back to interpolating with fixed 2°C increments between 20°C and 60°C. I think this covers all use cases for those using dynamic fan or pump speeds; those exploring sub-ambient cooling or extremely low ambient temperatures will probably want to max out everything anyways.

That has been working well for me for the past week or two, and I think is ready to be contributed back to krakenx. How does the the following interface look?

` colctl -fs (20,30),(30,50),(34,80),(40,90),(50,100) `

---

The reasons for another tool were both personal and technical. Regardless, I will still contribute to krakenx in whatever way I can.

[jneumaier]

@jonasmalacofilho I like your source code very much and the approach to support multiple devices is great. You even mentioned your inspiration by this project and took a lot of effort to improve and document the procedure. So everything done perfectly IMHO :-) It's great if both projects benefit from another and you even contribute here. My understanding of the protocol is not as advanced as yours. And you even already got the whole interpolation covered. Your example looks very good. I guess you want the same syntax for the fan and pump profile? Looks great. Maybe we can also add some/this profile as default if nothing is specified in the command.

[jonasmalacofilho]

@jneumaier I'm finally starting to work on the custom profiles for krakenx.

One thing that comes to mind, also considering #22, is that maybe we could import liquidctl's driver. Its API is modular enough that we could use it here. What do you think?

Either way, I ~will continue to implement~ implemented this without the external dependency, at least for now.

[jneumaier]

@jonasmalacofilho Thanks for the offer. I also thought about this. The new driver seems very mature and well coded. Not that our library is bad but it is clearly more grown from a small script and yours is rewritten with a more complete protocol background derived from other libraries, thorough testing and USB debugging. I would be fine with it. Overall it is both GPLed open source code and I guess we are all thankful for the working solution and happy to provide it to others. So why rewrite the same code. We can provide a more specialized CLI in the krakenx project and benefit from both projects. From the Kraken water coolers perspective I guess it is very close to be feature complete anyway.

But that is something I am not really willing to decide alone. At least the project owner should get the chance to decide with us here :-)

@KsenijaS Maybe you can help us with a decision here. I propose to:

1. Invite jonasmalacofilho as a collaborator in this project as he helps a lot already. This would also simplify the code review process for both of us.
2. We would like to integrate jonasmalacofilho's Kraken specific code as a library to this project, as it is a mature rewritten version of what you started here. It includes many additional features and fixes we would otherwise rewrite anyway and we would have to maintain two artificially separated code branches (like temperature profiles #24). We would keep and improve the existing CLI but only maintain one driver (in his repository) to execute the USB commands. https://github.com/jonasmalacofilho/liquidctl/blob/master/liquidctl/driver/kraken_two.py

What do you think? If you have no time to decide this in a hurry, please just leave us a note to postpone the decision.

[KsenijaS]

Hello, Sorry for the late reply. This sounds like a good idea, I seen your code @jonasmalacofilho and you have much better knowledge of protocols than any of us, also I would like you to add you as collaborator if you don't mind. But in that case we should also update README file and I wonder if PROTOCOL.md should also be updated?

[jonasmalacofilho]

I accepted the invitation, thanks.

Yes, I agree that we should update the README to reflect the change. Not sure about PROTOCOL.md, maybe move it to liquidctl and keep it close to the implementation (besides, of course, updating it)?

[jneumaier]

Fixed with #24. Thanks @jonasmalacofilho. Feel free to close. Just leaving it open for README.md and PROTOCOL.md feedback for now. Maybe a slim protocol description poiting to the relevant source code parts would be enough. It is deep tech stuff anyway and the source code explains it pretty well.

[jonasmalacofilho]

Closing after moving the remaining bits to #27.