I fermented an ale @ 20.0C, and then used a profile to lower the temperature over a few days to reduce suckback in the airlock. After that, the temperature was set to 0.5C before bottling.
I’m noticing that the compressor runs quite often, and never more than 6 minutes.
I would guess it could cool the beer faster if it would allow the compressor to run for a longer time?
The only change I’ve done to the BrewPis static settings is allowing the fridge to go down to -4C.
Looks like you have the temperature setting minimum (in advanced settings -> control constants) set to -4.
Your fridge temp is just cooling to that set point.
Near the end, you can see that the fridge setting goes up again, because the beer is getting near the setpoint. If you want to fridge setting to be more agressive, increase Kp.
You can use small bottle or something for your cooler ambient temperature. It mellows out the temp. swing.
What causes the “suckback”? I never had this happen unless I lifted the fermenter. Did that once and that was enough 
BTW, if you have a closed vessel and you reduce the temperature, the gases and liquid will shrink inside the vessel.
For the small bottle, I am normally using this when I’m using the fridge for other than fermenting, for instance to cool som food or wine, so that works well, but I am normally not using it when fermenting. Maybe I should try it to even out the temperature swings.
For the suckback part, you said it, the gases an liquid shrinks inside the fermentor, and the air lock sucks air in.
I want to avoid this as much as possible due to the (very tiny) risk of infection, and also oxidizing the beer.
At the end of fermentation, the beer releases some CO2, there are still some bubbling in the air lock even when the FG is reached.
My idea was to cool it a bit slower down, so the the pressure in the vessel was still positive due to the CO2 still coming out of the beer.
It seemed to work for the first 24 hours, but later on, I saw that air was drawn in through the air lock, so my theory was not 100 % correct.
Not surprised at all because as I mentioned, liquid and gases are shrinking a bit.
As long as you get a nice layer of CO2 on top of the beer, you are probably fine and absurdly small amount of air will have no ill effect.
You can always add little bit CO2 into your fermenter (not to the beer) if you have a valve or something in your fermenter lid.
I am planning to cold crash my latest bitter but I’ll go as low as 7C or maybe 5 C. I have never done this before because there is no real need for it.
Or just get a blow off tube. Never worry about too active fermentation or suck back again. Although I do remove the blow-off tube before cold crashing. The shrinking beer can indeed suck back from the blow-off bottle when crash cooling.
Some aluminum wrap and an elastic band is a good enough seal at this stage.
I just finished cold-crashing a 15-gallon batch of IPA, going from 67F (19.5C) down to 32F (0C). All of my BrewPi advanced settings are default, except that I allow the fridge/beer to get to as low as 20F (-6.6C). I never actually program the beer to go that low but I sometimes need the chamber ambient temp to get that low.
My chamber (freezer) can probably complete this cold crash in the expected 24 hours, but under the BrewPi Beer Profile mode this took more like 36 hours and ~240 cooling cycles. During all of that cooling the compressor was typically engaged for 3 minutes at a time, followed by the standard 5 minute rest and then more compressor activity. But there were definitely occasions during the crash where the compressor was engaged for as much as 18 continuous minutes. In fact there were 140 cooling cycles which lasted the minimum of 3 minutes, vs. 110 cooling cycles which lasted longer.
I have calculated the duty cycle during this cold crash: 62% idle vs. 38% cooling. The same duty cycle could be achieved through longer cycles of cooling & idling, but it’s not clear whether this would get the beer to the end temperature faster (closer to the expected time). But even if the time-to-crash were the same it does seem that this would cause less wear on the compressor itself.
Does anybody have enough experience with compressor lifetimes to render an opinion?
Dan, I have done a lot of work this week on how actuators work. In the new firmware, the compressor will run with PWM, instead of On/Off with overshoot prediction.
The PWM cycle will be user configurable, for example 10 or 15 minutes.
The PWM actuator will wrap a time limited actuator, which ensures the minimum ON/OFF time off the compressor are honored to prevent overpressure/overheating.
I suspect most of the problems you describe here will go away with the firmware update, so I don’t want to spend too much time addressing them. If the current firmware works, but is just too slow, please just wait for the next update. It is a complete rewrite of the control algorithm.
My understanding of PWM (mostly gleaned from Wikipedia) is that pulsing a fixed current can make what is inherently a digital load behave more like an analog one. In the case of a CF or LED bulb, which have only ON or OFF states, cycling faster than is perceptible by humans makes the bulb behave like an (analog) incandescent filament.
For electric heater elements this seems OK, since they don’t have minimum ON or OFF times, don’t need to warm up or cool down, etc. But for a refrigerator, which does have physical limitations around cycle times, I need a safeguard against me doing something dumb like configuring it to cycle every 30 seconds in my attempts to get the max performance out of it.
You can see in the image below (thanks Plot.ly!) of my recent IPA cold crash that my freezer went through many 3-minute cycles. In fact I posit in this case that my freezer was effectively under PWM-like control; the relatively rapid cycling of the freezer mimicked what a PWM dimmer does to turn an LED bulb into an analog device.
But my BrewPi dimmer was turned down too low, because even though my freezer was cycling at its physical limit it was not chilling at its physical limit. I theorize that if the cooling cycles had been longer during my cold crash then this would’ve caused the green Beer Temp to come down faster (follow the dashed orange Beer Setting more closely),
Q: In the upcoming PWM-based controller algorithm, will it be possible to configure a cooling device to “find the necessary pulse width pattern, up to the physical limitation of the device, to get the job done”?
Your understanding of PWM is correct. PWM for a fridge will use a very slow cycle (e.g. 15 minutes), where a heater will use 4 seconds.
The new PWM algorithm is smart and can deal with user configurable minimum ON and OFF times.
Even if you have a minimum ON time of 3 minutes and a 10 minute cycle time, it can reach 1% ON values by skipping ON cycles.
It will cool a lot faster than your current plot, because only close to the setpoint it will start doing short ON times.
What about release time for this new firmware? Reilly looking forward to it!
