New ESP8266/Arduino framework, to update or not to update?

The recently released ESP8266 framework has caused some issues. The first issue is compile errors of ESPAsyncTCP. To solve this error, you can simply force to use old version of the framework, by editing platformio.ini

platform = espressif8266@~1.5

I do migrate to latest ESPAsyncTCP/ESPAsyncWebServer with latest framework(1.6), but that is the real issue. The new framework is about 26.5k bigger than previous release 1.5, and the image built with 1.6 framework will make OTA impossible.

The current flash layout of ESP8266 use 1M for program, or sketch. To support OTA, the sketch size must be smaller than half of the total program space. The image of default BPL is about 500k, so using latest 1.6 framework breaks the limit.

The latest ESPAsyncTCP/ESPAsyncWebServer libraries work pretty with latest 1.6 framework but seem to have some issues with 1.5 framework. The README.MD of ESPAsyncWebServer states that latest framework might be necessary, and I encountered some no-response issue when using latest libraries with old 1.5 framework.

(BTW, one extra advantage of latest libraries with latest framework is that WebSocket is pretty solid, compared to the result I had a few months ago. My other Project, BrewManiacEx does benefit from WebSocket because of the short latency of uplink data transmission. BrewPiLess, on the other hand, does not gain much from that.)

Staying with old 1.5 framework is a simple solution but I am not sure if it is a good idea.

To upgrade to latest 1.6 framework, something will have to be removed. It’s unlikely that I can squeeze 25k or even 10k program space for it. A few solutions I come up:

  • Remove OTA update support
    It’s unlikely that I would do this. Opening project boxes to flash it is PITA.
  • Remove embedded files.
    Manually uploading the HTML file will be necessary.
  • Expanding the sketch space to 1.5M or 2M.
    IMO, this might be the best solution. 2M file space is good for 5~6 months. The drawbacks will be

    • Editing of flash configuration file needed. 2M file system is not built-in standard configuration while 1M file system is. However, 3M for sketch is a waste.
    • Upgrading to latest version might require formatting of SPIFFS.

Reference:

LoDO低溶氧釀造

在啤酒釀造過程中避免氧化不是什麼新的想法,但把這個想法推到一個極致,是開始於2016年4月在德國釀酒論壇發表的這一篇文件:Brewing Bavarian Helles: Adapting to Low Oxygen Brewing。這份文件中主張,要做出某些德國啤酒真正風味的秘訣在於低溶氧,文件中主張,在還沒開始接種酵母前,氧氣就會氧化麥汁,所以要追求整個過程中最少氧氣溶入麥汁;目標是低於1ppm。這個主張後就是Low Dissolved Oxygen(LoDO)。

1ppm的溶氧是什麼概念呢?這邊有些整理好的資料中有些數據:

  • 冷的自來水或RO出來的水溶氧大約是 8-12ppm
  • 如果聞得到麥汁中麥香,代表這些香氣不會出現在最終的啤酒中。LoDO的目標就是要保留這些香氣。
  • 在一般的糖化溫度63-71度C,可溶氧量是4-5ppm
  • 先煮沸釀酒用的水並迅速冷卻有可降低溶氧量到0.5ppm
  • 正確的入麥芽會導入1-3ppm
  • HSO(熱端氧化)在家釀的範圍中比商業釀酒還容易發生,因為液面對體積的比例上,家釀通常大很多。
  • HSO發生的高峰在入麥芽的30秒到1分鐘。
  • 轉桶到keg會導入0.8-1ppm的溶氧。

具體的做法也有整理:

  • 去除糖化用水的溶氧。先煮沸五分鐘,然後用不鏽鋼冷卻器迅速冷卻。
  • 加入Sodium Metabisulfite(SMB)做為吸收氧氣的方法。多餘的硫會被酵母消耗掉,殘留的硫會和商業德國啤酒的10-15ppm差不多。
  • 使用RO水,加入產生30-50ppm鈣的calcium chlorde。因為會加入SMB,不用RO水很難計算礦物質的含量。
  • 文章建講糖化用水加內SMB量為100mg/l,洗糖水為10-15mg/l
  • 不洗糖的話,SMB可以減少為55mg/l
  • 把水加入麥芽。或者麥芽加入水中時要很小心,避免飛濺,攪拌要很輕柔。
  • 如果有使用pump,要檢查所有接頭有沒有氣密。
  • 用pump移動麥汁的話,速度最好在3-4l/m(1 gpm)
  • 不洗糖比較好
  • 不要用銅製品,用不鏽鋼
  • 糖化時用蓋子減少麥汁上方的空氣
  • 30%的苦花用FWH
  • 煮沸60分,不要煮太滾。微滾。
  • 儘速冷卻,不要飛濺。
  • 冷渣可以進入發酵桶,但熱渣和酒花不行。
  • 儘快接種;接種後再打氣(打氧)
  • 在離FG 0.004(1plato)時轉桶;需要採用FFT以預測FG
  • Spunding
  • 使用secondary fermenter當servering keg,避免轉桶引入氧氣
  • 如果要裝瓶,用帶(等)壓裝瓶

我看完的感覺是:在麥汁旁呼吸太用力可能就會導入超過1ppm的氧氣了。

那麼實際上的結果如何?brulosophy.com做了一個實驗,結果是38個人中有25個人可以分辦,而分辦得出來的25人中,有15個人表示比較喜歡LoDO的版本。有趣的是,John Palmer被問到對LoDO的看法,他表示LoDO釀出來的是另外一種啤酒(影片,3分鐘開始)。

在Brulosophy.com的實驗中,格主表示加入SMB導致了明顯的硫味。另一個可以用來去除溶氧是Brewtan-B。Brewtan-B是Wyeast的產品,是一種從植物提煉出來的單寧酸產品,據說可以延長產品的保鮮期。以前只賣給釀酒廠,沒有零售給家釀客戶,最近開始有少數網售開始賣小量的產品給家釀用。

另一篇討論LoDO的部落文,有些看法蠻中肯的;他認為LoDO的大部分做法和理論都是對的,但堅持每個步驟都要嚴格執行才有效就有點走火入魔了。

參考資料:

  1. https://www.winning-homebrew.com/low-oxygen-brewing.html
  2. http://braukaiser.com/blog/blog/2016/04/30/low-oxygen-brewing/
  3. http://www.lowoxygenbrewing.com
  4. http://brulosophy.com/2017/04/10/the-lodo-effect-evaluating-the-low-oxygen-brewing-method-exbeeriment-results/
  5. Brewtan-B的資料和討論: https://www.homebrewersassociation.org/forum/index.php?topic=26830.0

壓力發酵與Spunding

Spunding(應該)是源自德文Spundungsapparat,是把發酵產生的co2留在啤酒中,自然充氣(碳酸化)的一種方法。如果對最終的FG值預估正確,發酵進行中的比重量測也很精準,只要在適當殘留比重的時候,把發酵桶密封起來就可以了。實務上為了監控及安全起見,會有一個可以洩壓的裝置叫Spunding Valve,設定好壓力,如果超過了這個壓力,CO2就會被排出;可以維持正確的壓力。

Spunding或Spundungsapparat符合德國的啤酒純淨法,不需要添加任何東西(包括CO2),而且發酵結束也同時完成充氣碳酸化。商業釀酒很多都採用這種方法。

一般家釀用的Spunding Valve並不複雜,就是一個洩壓閥,通常再加上壓力表用以監控及正確調整壓力。Spunding真正的困難在於:需要一個耐壓的發酵桶。市面上有耐壓的發酵桶(通常稱為unitank)價格昂貴,比較便宜的作法就是用keg來發酵。

可以做Spunding,也就意謂著可以做壓力發酵;壓力發酵是發酵一開始就使用Spunding Valve,酵母一旦開始發酵,產生的CO2很快就會讓壓力達到飽合,有了Spunding valve,多餘的co2就會排出,會維持一在設定的壓力,沒有爆桶的風險。

壓力發酵據說有著以下幾個好處:

  • 抑制酵母的繁殖;發酵過程會比較溫和,發酵桶的頭部空間也就可以比較小。
  • 抑制酯類及高級醇的產生;在比較高的溫度發酵也不會有不好的風味;比較高溫通常發酵速度也就比較快
  • 啤酒的香氣比較不會隨著co2跑掉。
  • Spundungsapparat的效果;自然充氣。

壓力發酵也是有缺點:

  • 酵母繁殖較少,回收酵母不利。
  • 回收酵母時,如果讓壓力一下子降低,可能會造成酵母的死亡。
  • 某些酵母對壓力有不良反應。

商業釀酒據說採用壓力發酵的不在少數;個人去參觀Stone Brewing時,確認他們是採用壓力發酵。

壓力發酵要用多大的壓力?我沒有查到確切的答案,或許不同的酵母和不同的啤酒類型對壓力的反應會有所不同,所以就像發酵溫度一樣,沒有固定的標準答案。但有些原則是大部分人認同的:

  • 不要一開始就用很高(例如30psi)的壓力,會影響酵母繁殖。
  • 比較多人採用的值大約在7-15psi之間。
  • 15psi在Ale適合的溫度碳酸化程度有點不足,所以可以在發酵最後配合想要的碳酸化程度調高psi。

Kolsh書中提到壓力發酵的部分:

  • p153. 通常(商業釀酒的)大發酵桶設在8~10psi
  • p154. Budding開始後,調到4.2psi,一旦到了50%的發酵程度(attenuation),調到25psi

在這篇中Dry Hopping Under Pressure,作者列出了一些實驗結果和數字,並且實驗在高溫(78F/25.5C)高壓 (20psi)發酵釀造NEIPA;據作者所言,結果的酯和高級醇真的有比較低,甚至比低溫發酵的還低,但是酒花的香氣反而不如低溫沒有壓力的來得好。

參考資料:

  1. Brulosophy.com: Under Pressure:the Impact of High PSI fermentation
  2. Build a Spunding Valve! How and Why.
  3. HomeBrewTalk.com: Closed-system pressurized fermentation technique!
  4. Dry Hopping Under Pressure

快速發酵Lager及高溫發酵

一般來說,Lager發酵溫度低,發酵時間相對比較長了,為了縮短Lager的發酵時間,有人發展出了一套方法:

  1. 一開始在10°-13°C溫度區間發酵,直到50%左右。
  2. 用 5°F(2.8°C)/12小時的速度昇溫到18°C-20°C
  3. 維持4-10天,直到比重不再變化
  4.  5-8°F(2.8-4.4°C)/12小時的速度,降低溫度到-1°C~0°C;也可以直接設定冰箱的溫度讓啤酒溫度自然下降
  5. 完成

這個方法會加速後半段,感覺上是提前執行D-REST的時間;也是Lager發酵模式的其中一種。理論上啤酒風味的決定在發酵的前期,這個方法應該不會影響太大,但實際上Brulosophy針對這個作法作了實驗,結果卻是有影響的。


如果直接用相對比較高溫來發酵lager呢?Brulosophy.com針對發酵溫度做了多次的實驗,我把針對Lager酵母的部分整理出來;結果請自行解讀:

酵母比較發酵溫度可分辨/總測試人數連結
WL80010˚C/19˚C13/39 BJCP 7/19pt.3
W34/7010˚C/21˚C12/26pt4
W34/7016˚C/28˚C12/21pt.5
WYeast 21249˚C/22˚C8/20pt.8
WLP94010˚C/19˚C14/27pt.10
Imperial Organic L1310˚C/22˚C8/22pt.11

在HomeBrewTalk.com有一個討論串專門在討論(相對)高溫發酵Lager的:HBT。這個討論串中的共識是有的酵母可以,有的不適合。其中以W34/70最受歡迎。有趣的是W34/70的技術文件中寫的發酵溫度是9-22°C,理想溫度是12-15°C。


Lager酵母基因定序後被發現是Saccaromyces Cerevisiae和Saccharomyces Eubayanus兩種混種而成。(Ale酵母是屬於Saccaromyces Cerevisiae,但Saccaromyces Cerevisiae不全部是Ale酵母,不過Lager酵母是Ale酵母混種的可能性很高。)Lager酵母又可以分成兩大群,Saaz和Frohberg。Saaz群的沈絮比較好,產生比較少的酯類,比較耐低溫,但高溫比較不好,而且Saaz類對麥芽三糖處理能力不佳、或者無法處理能力。Frohberg保留了比較多S.Cerevisiae(可能是Ale酵母)的DNA,高溫表現相對好。Weihenstephan WS34/70是Frohberg群中被廣泛使用的酵母。


參考:

  1. http://braukaiser.com/wiki/index.php/Fermenting_Lagers
  2. http://brulosophy.com/methods/lager-method/
  3. http://brulosophy.com/2016/09/19/lager-methods-pt-1-traditional-vs-quick-fermentation-exbeeriment-results/
  4. http://www.fermentis.com/wp-content/uploads/2015/12/Saflager-W-3470-en.pdf

 

Fast Ferment Test快速發酵測試

FG是釀酒過程中很關鍵又相對難以掌握的值;因為影響FG的因子有許多

  • 麥汁的組成:不可發酵糖的比例
    • 糖化溫度、時間
    • 特殊麥芽比例
  • 酵母的發酵能力
    • 發酵的溫度
    • 充氧的多寡
    • 酵母的活性、數量

FFT的做法:

  1. 取出同部分的麥汁,數量要略大於可以量比重;通常是200~250ml
  2. 加入大量的酵母(依比例 5-10倍)
  3. 用攪拌器當成擴培一樣處理

由於攪拌器和大量的酵母,發酵會很快就結束,就可以拿出來量比重。啤酒酵母比較貴,用麵包酵母也可以,因為麵包酵母和啤酒酵母對糖的處理能力接近。

與其說FFT是一種用來預測FG的方法,不如說是用來判斷麥汁可發酵性的方法。因為發酵的條件不同,發酵的結果會有一些差異。甚至如果不是採用同種酵母,結果可能差異更大。所以在家釀的範圍內,不是很多人會這麼做;如果在商業釀酒的條件下,一包乾酵母或從酵母庫取得相對大量的酵母量,成本不高。


以下是我曾經做過的FFT實驗;麥汁的OG是1.072:

  • 左邊:加入5g左右麵包酵母;採偶爾搖晃;目測40小時左右發酵結束。FG:1.016
  • 右邊:接種後12小時取出,未添加酵母;用攪拌器加速發酵;目測72小時後結束。FG1.011
  • 主麥汁:第三天量右邊比重時比重為1.040;最終在第10天達到FG 1.011

參考;

http://braukaiser.com/wiki/index.php?title=Fast_Ferment_Test

 

Poorman’s Glycol system

A real glycol chiller is expensive, and DIY glycol chiller from an air conditioner is kind of too hardcore for people like me. Therefore, I am using a re-purposed fridge as “glycol” chiller. The air is bad heat conductor, so I ended up using a bucket of water and bending the plate into water. It works really well except that the water sometimes gets frozen because I  use no glycol but plain water. One thing I also observe is that the beer temperature seem to be more stable if the temperature of “glycol” is not too cold.

In a nutshell, a temperature controller is necessary to control the poorman’s glycol chiller.

I have a spare BPL, but somehow I don’t want to use it. The BPL I am using has a two way relay board, and I am using only one for cooling, controlling the pump. The temperature of “glycol” is monitored by the “room” sensor. Simple hysteresis temperature control with timed constraints to protect the compressor would do the job.

I am not going to make it “official”, but I would love to share if anyone wants to try it.

The option is not enabled by default, so you have to build it by yourself.

build_flags = -Wl,-Tesp8266.flash.4m.ld -DEanbleParasiteTempControl=true

You will need a HTML file for setting. It is “paractrl.htm” in “extra” folder at Github. Manually upload it to BPL, and open it. The setting should be straightforward.

  • Enable Parasite Temperature Control
  • Cooling PIN /Inverted.
    Only coolingPin, heatingPin, and doorPin can be used. They are D5, D7 and D4 in default configuration. If they are used by BrewPi temperature control, the options of PINs used will be disabled. You CAN mess it by selecting the PIN and later assigning it for cooling or heating in Device Setup page. Don’t do that.
  • Target Temperature
    The cooling will stop when the temperature is equal or lower than this value.
  • Triggering Temperature
    The cooling will be started when the temperature is greater than this value. This value should be at least 0.5 higher than “Target Temperature”
  • Minimum Cooling Time
    Must be greater than or equal to180 (seconds).
  • Minimum Idle Time
    Must be greater than or equal to180 (seconds).

My setup:

The water level is higher when in use. (I was pumping out the water.)  Before applying the parasite temperature control, the water might get frozen and clog the tubing.

Sharing BPL log online

Here is a new easy way to share BrewPiLess logs over the internet, on-line.

Step 0: Hosting on GitHub.

If you have your own host, it should be easy and you can skip this part. Using GitHub hosting service is simple and easy. I would suggest you too google on this subject to find better illustration and description.

Step 2: Get the log viewer

Get the “BPLog.htm” file from my GitHub:

https://github.com/vitotai/vitotai.github.io

Don’t forget to get the “raw” version.

Step 3: Upload the file and logs to share

The logs will be put at the same place as the BPLog.htm file. Subdirectories can be used. I put my log in a subdirectory, named “log”.

Step 4: Test the shared link.

First open the log viewer page on your browser.  The url should be something like

https://your_name.github.io/BPLog.htm

If you can see the empty log chart page. You are almost done.

Step 5: Create the shared link.

Append log name after the URL above in this format

https://your_name.github.io/BPLog.htm?log=[Your log name]

If the log is put in a subdirectory, replace “/” by “%2F”. You will need to uriEncodeComponent special characters. If you don’t understand previous sentence, please don’t use special characters in the path and log file names.

eg. A log name “nottingham.035.20171114” in subfolder “log

https://vitotai.github.io/BPLog.htm?log=log%2Fnottingham.035.20171114

Copy the URL above to your browser or see it in a iFrame here:

Step 6: Optional with selection range

Select the desired range, right click mouse on the chart.

A menu of “Open Selection” will popup, click that item to open a new window that will zoom to the selection range on open.

BrewPiLess release v2.4

BrewPiLess release v2.4

  • Brew and calibrate iSpindel
  • Use iSpindel temperature reading as Beer Sensor.
  • Display tilt value of iSpindel.
    This is part of the “Brew and calibrate” functions.
  • Enhance SSE re-establishment
  • Default configurable minimum cooling/heating time & back-up sensor. (That is, Glycol supported.)
  • HTTP Port settings in Config page.

    Please note: you will have to run Device Setup to setup temperature sensors and PIN usages if you are upgrading from old version other than glycol option. 

I really like the new “Brew and Calibrate” feature. My iSpindel works great. However, every time I open the cap to charge it, the stuff inside moves a little, and the readings will drift a little bit. The result of using this method is better than that of calibrated one.

BTW, the working principle of iSpindel is exactly the same as a hydrometer. Therefore, temperature correction is necessary.

In the following chart, Purple line is temperature-corrected reading and green line is non corrected readings. Without correction, the gravity reading rises when the temperature drops. The corrected reading also rises a little bit, though.

The gravity readings used to calibrate iSpindel should be NOT temperature-corrected. The way of deriving gravity values from TILT values is using a function(formula) having a single parameter, the tilt value. We assume that there exists such a function exists and try to find one that is approximate to the perfect one.

The physics principle of iSpindel is the same as a floating hydrometer. A hydrometer will show different values for wort at different temperatures.

For example, wort of 2.6% BRIX will be measured as 1.010@20C, 1.011@4C, and 1.009@24C. The Specific Gravity, which is the value after temperature correction applied, will all be 1.010, calibration to 20C.

The TILT values should be different in the same wort at different temperatures because the density of the liquid is different. Let the TILT values of 1.009, 1.010, 1.011 be x1, x2, x3. It’s not possible to have a function, f(x), so that f(x1) = (fx2) = f(x3) = 1010. Obviously, finding a function, f(x), so that f(x1) = 1.009, f(x2) = 1.010, f(x3) = 1.011 is possible. Applying the temperature correction, the correct Specific Gravity can be derived.

BrewPiLess for Glycol

BrewPi is derived from BrewPi v0.2.x, which is designed for fermentation chambers made by fridges. The latest BrewPi v0.4.x has evolved to be a general temperature control unit. The code is very different from v0.2.x, and porting v0.4.x might not be an easy job. Instead, I implemented two main features that might make glycol possible: fallback sensor and adjustable minimum time.

In addition to using binary for glycol or building with “EnableGlycolSupport” defined, there are setups and settings that must be tweaked.

Setup

  • Don’t use Fridge Sensor. The “fallback” feature will use the reading from Beer Sensor as Fridge reading.
  • (optional) Use second sensor as Room Sensor to monitor glycol temperature.
  • Beer Constant or Beer Profile mode is preferred.

Settings

  • minimum times: including minCoolTimeminCoolIdleTimeminHeatTimeminHeatIdleTime,and deadTime
    All except deadTime are self-explanatory. deadTime defines the minimum idle time between heating and cooling, and the waiting time at power-up. 10 seconds seems to be good for all of the values.
  • idleRangeHidleRangeL
    The values define the temperature range to stay in idle. That is, no action will be performed if the fridge temperature(from Beer Sensor) stays in this range. The default values are 1.0, so it will start cooling when the temperature reaches 21 degree if the set temperature is 20.
  • maxHeatTimeForEst & maxCoolTimeForEst
    After cooling or heating, the algorithm expects the temperature to go lower or higher. Usually the temperature won’t go too far in glycol setup. Therefore, set a smaller value for these two, so that it won’t wait too long for detecting peaks.
  • PID settings. Kp, Ki, Kd
    If all of them are set to zero, the FridgeSet will be equal to BeerSet.
  • (optional) filter settings: fridgeFastFilt, fridgeSlowFilt, fridgeSlopeFilt, beerFastFilt, beerSlowFilt, beerSlopeFilt
    Even the data is from the same sensor, the temperature readings of beer and fridge sometimes differ. It is because that they use different filters. The temperature of fridge is volatile, while the beer temperature changes slowly. If you want them to be strictly the same, the filter parameters should be set to same same.

After setting, you can use “c” (single lower case c) to read back the setting for verification.

My testing

This is my initial test by filling 6 gallons of water in my newly purchased Spike CF10 with coil.

glycol

My test was conducted with a cooler with frozen PET bottles. The room temperature is  the temperature of water in the cooler.

I set all minimum times to 10 seconds, idleRangeH to 0.1. maxCoolTimeForEst to 30 seconds. PID parameters are left untouched. The result seems acceptable except that more PET bottles (or, a glycol chiller) are needed.

釀酒中水的計算

計算水的用量,有一些參數要考慮:(由於我參考的資料都用美制,所以下列都用gallon,採用公制請自行換算)

麥芽吸水率 0.125 gal/lb  或 1.04 L/kg,不同的麥芽會有不同的結果,但這個數字應該是可以通用。比起來,最後有沒有讓麥芽中的水全部滴出來或擠出來,造成的差距可能會比較大。

酒花熱渣等在 20L(5 gal)批次中通常在在0.5L左右,酒花用得多,就更多。

煮沸鍋死角,視器材而定,大部分20L(5 gal)的可能在1L~2L之間。也就是煮完後最後沒辦法進入發酵桶的量。

糖化鍋死角,沒辦法進入煮沸鍋的水量。視器材而定。如果是BIAB,就沒有這個值。

蒸發量可大可小,看火力大小及鍋子的形狀,業界據說是控制在5%,家釀我看到的有人說差不多是1 gallon/hr,實際上也有人只有0.5gallon~0.8gallon,也有到1.5 gallon/hr的。

麥汁冷縮,一般是4%,是水在100度及20度的體積變化,5gal批次約0.8qt。除非你是直使用熱水,這個數值對水量沒有影響,但是在釀造過程中有記錄或調整水的話就需要考慮。

發酵桶的損失:目標5gal的產品,應該要有5.5gal左右進發酵桶,因為發酵過程中會有水的蒸發、酵母或熱渣沈澱、取樣量比重的損失等。

舉例說明:

5.5 gal進發酵桶,10lb的麥芽,”普通”用量的酒花,BIAB,需要的水:

5.5 gal + 麥芽吸水 0.125 gal/lb x 10 lb + 酒花熱渣 0.125 gal(0.5qt) + 器材死角 0.375 gal(1.5qt) + 蒸發量 1 gal = 8.25 gal

從這個例子可以看到,麥芽吸水蒸發量佔很大的損失比例,而且是剛開始使用器材時最難控制的。如果要達到預期的水量,就需要在煮沸前和煮沸的最後完成前調整。

麥芽吸水量在糖化完成後,全部的麥汁進入煮沸鍋就馬上知道了,如果有另外的糖化鍋,也就是多了糖化鍋的死角損失,那麼煮沸前的水量就是全部水量減去麥芽吸水+糖化鍋死角。所以煮沸前量一下水量,就可以知道要這些數值;正確的調整也必考慮比重,在此先不談。要提醒的是,這時候水的體積會比冷卻時大,所以要考慮麥汁冷縮的比例。至於蒸發量要不要算冷縮,其實我也不清楚,總之這些數值都是估算,會和實際有落差。

煮沸完成前(可能是在5到10分鐘前),是最後調整的機會,這時候真的要考慮冷縮的量。這個補水的動作基上只是補水蒸發太多的量。

很多人第一次釀酒,煮完後常常會發現,最後的麥汁比預期的少。比預期多的比較少見,原因是大部份的書都會說滾開時要滾大一點,以利DMS減少,另外,看到大滾比控制在微滾容易直覺得多了。最終麥汁量和預期不符的另一個原因是,初學者第一次釀很多是用配方包,然後配方包也通常有建議用的水量,問題是每個人的器材不同,結果也就相去甚遠。

要注意到的是,需要調整的是比重,不是麥汁的多少;目標是比重達標,不是麥汁的量達標。所以水的計算在開始釀造前估算,調整則是根據比重來調整。幸運的是,糖不會蒸發,所以煮沸前就可以調整好最後的比重,然後,如果蒸發太多,直接調整要算好的目標就行了。

水的調整用點數的概念來算很容易,點數指的是比重的點數,例如1.012=12點。假設煮沸前點數是a、麥汁量是X,目標比重是g,那麼最後的麥汁量是 a/t * X

例: 煮沸前 1.040 5L,目標1.050, 最後麥汁量= 40/50 * 5 = 4 L。如果剛好蒸發1L,比重就會剛好是1.050。如果預計的蒸發量比1L多,那就要加水;如果預計的蒸發量比1L少,那就要兩個選擇:多蒸發一些(加大火力或延長煮沸時間)或加DME提高比重。

如果要煮沸中途或末段加水,要考慮先把添加的水加熱,以免水加入後麥汁溫度降低。