【AI 文章重點摘要 100 字】這篇文章是「把閒置 10 年的 ASUS RT-AC68U 無線路由器」拿出來 DIY 修復 5G 問題的紀錄。作者原先以為是主控晶片壞掉，但實際拆裝後發現問題依舊，後來參考 ChatGPT 和 Gemini 的建議，最終定位問題出在 5G 的 PA（功率放大器）晶片。更換那顆壞掉的 PA 晶片後，5G 訊號成功恢復，甚至最高連線速度達 1300 Mbps。整個過程不但讓作者重拾舊機，也練習到 QFN 晶片的焊接技巧與 AI 協作維修的經驗。
這台【華碩 RT-AC68U 無線路由器】是 2014 年 12 月以 6,290 元在台南罰站屋（原價屋）的促銷活動買的，活動贈送一顆時價 1,800 元 WD 的 1T 行動硬碟。後來這顆 WD 硬碟以 1,690 元賣掉，等於這台 AC68U 只用 4,600 元入手，在當時很划算。買來玩幾天之後就收起來了，本來想說等當時用的 WIFI 退役再換成這台。隔年小米 WIFI mini 以 665 元超低價橫空出世，因為便宜，用壞了也不會心疼，所以也搶鮮買來用用看，結果就這麼用到現在。後來中華光世代續約時也有附送 WIFI6 全屋通基地台，還派人到府安裝，不裝起來用會覺得不好意思，所以家裡的無線路由器始終夠用，AC68U 一直沒有出場機會。最近突然想把只有 2 埠網口的全屋通換掉，總算把閒置 10 年的 AC68U 請出來，結果才玩不到兩天就出問題了。
問題的症狀是，2.4G 可正常運作，5G 無法讓其他設備搜尋到訊號，指示燈號都有正常亮起。除非手動進入後台將工作頻率鎖定為 20MHz，頻道 56/60/64 擇一，5G 才會恢復正常，但速度也跑不到 100 Mbps。設定工作頻率 40Mhz 、頻道 56/60/64 時，可被搜尋但連線失敗，其他設定則完全搜尋不到 5G。各種韌體和版本都刷過了，症狀相同，始終無法解決。
以往遇到問題時都是上網 Google，如今可以問 AI 。AI 說是硬體故障，設備電路元件老化，不值得修好它，還順勢安麗幾台路由器產品。
此時在心中，一個問題油然而生：
能不能靠 AI 的指示，修好這台 10 年前老機器？
於是我用電子學小白角色 + 低端焊功技能，詢問 AI 如何修好這台 AC68U，所以有了這篇文章。
AI 問題分析：ChatGPT 與 Gemini
最近 Gemini 3 Pro 爆火，所以這次的 AI 使用免費版的 ChatGPT 和 Gemini。將機器拆開，拍照並根據上網查到的晶片資料做了一些標示，將問題症狀輸入 AI。
兩家 AI 給出大同小異的相關建議，分析問題原因大致有三個方向：
- 5G 主控：BCM4360KMLG。
- 5G PA（Power Amplifier，功率放大）：如圖，有三組 PA 電路，每組有一顆 SE5023L (PA 晶片）和 SKY13370（RF 開關晶片）。
- 其他
兩家 AI 的差異點在於 Gemini 認為 PA 問題的機率比較高，ChatGPT 則認為是 5G 主控晶片。不過這兩家 AI 都叫我先從比較簡單的 PA 下手，因為 5G 主控 BCM4360KMLG 並沒有公開的 DataSheet 可查，成本也最高，這類 QFN 晶片的更換也有一定難度跟風險。排查到最後萬一真的是主控的問題，屆時電子學小白再來考慮要不要冒險更換。
然而 AC68U 主打賣點是 3T3R，它的 5G PA 就有三組，我認為若只是其中一組出問題，至少還有兩組，似乎不太可能讓 5G 全數消失，而三組 5G PA 全出問題的機率更低對吧？所以我個人傾向認定是 5G 主控問題。此時上網查到一篇 AC68U 維修文，類似的症狀，文章說更換主控 BCM4360KMLG 就修好了。所以這次我選擇和 ChatGPT 站在一起，直接處理 5G 主控晶片。
處理 5G 主控
AC68U 使用兩顆一模一樣的 BCM4360KMLG ，分別作為 2.4G 和 5G 的主控晶片。至於哪一顆是 2.4G 哪顆是 5G ，該篇文章也圖文並茂的寫明，靠主板中央是 5G 主控。
按照文章的說法，依樣畫葫蘆把晶片拆下，驚然發現拆的這顆並不是 5G，而是 2.4G 的主控：開機後 2.4G 燈號沒亮、2.4G 訊號消失，TNND 拆錯主控了！當下真的傻眼...
其實在查資料時我也傳照片問過 AI（只有框出晶片位置，沒有功能標示），Gemini 跟 ChatGPT 都說是靠邊的是 5G 晶片（離 CPU 較遠），Gemini 還告訴你怎麼判定。但我還是選擇該文的說法，原因是「真人寫的文章」，並且我不能保證 AI 能 100% 理解我的照片。萬萬沒想到，竟然會在這件事踩了大坑。
後來在該作者的網站上找到另一篇文章「ASUS RT-AC68U 不開機維修」，與該文標示的 5G 燈號位置與 PCB 版本比對後，發現文章作者可能是後續彙整時誤植了內容。
不論如何都得把這顆 2.4G 主控裝回去，不然連 2.4G 都沒了，這台就只剩 4 埠 Switch 的功能了。BCM4360KMLG 單邊 12mm 有 28 支腳位，腳位又多又密，焊接時始終對不準焊盤，陸續嘗試幾次都失敗，還把主控周圍的兩顆小電容吹跑了，越搞越沒信心。想到後面還有 5G 主控要搞 ，整個人心灰意冷，一度想放棄算了，於是停擺了一段時間，讓自己的思緒恢復冷靜一下。
後來在 BiliBili 找到一段焊接 QFN 晶片的教學影片，發覺是自己想太多了，照著教學重點終於把晶片焊回去，2.4G 好險恢復正常了，被吹跑的兩顆電容似乎影響不大。接著乘勝追擊，把淘寶買來的晶片（¥18）換上 5G 的主控位置。
滿懷期待的開機測試，結果令人失望。症狀依舊，5G 只能在 20MHz 特定頻道（56/60/64）運作。也就是說，兩顆 QFN 主控都拆過了，依然沒有解決問題，在主控問題這個項目上繞了好大一圈卻還是回到原點。往好處想，拆裝 QFN 晶片沒有搞壞機器，表示我的焊接功力又提升了。
排查 5G PA
兩家 AI 得知更換結果排除 5G 主控因素之後，不約而同提出 PA 的排查項目，我也找到 PA 晶片 SE5023L 的 DataSheet 提供給 AI 參考。雖然兩家 AI 都指出 PA 的嫌疑最大，不過建議內容不太一樣。ChatGPT 列出一系列的排查項目，例如分階段測量 PA 哪些腳位的電壓、測量溫度等等諸如此類，目的是試圖找出有問題的 PA。而 Gemini 的建議就直接、簡單、粗暴，它知道我拆裝主控晶片成功卻沒有效果之後，就直接給出「既然有動手拆裝 QFN 晶片的能力，那就逐顆拆卸 PA 晶片」「拆掉後如果 5G 訊號有恢復，就表示那顆 PA 是壞的」等建議。我想大概是我沒跟 Gamini 說到曾經吹跑兩顆小電容，所以它才這麼回答。保守起見，決定先依照 ChatGPT 建議的跑一遍再說。
使用上次修理二號機主機板時（延伸閱讀）購買的 K 型熱電耦溫度計，觀察到某一顆 PA （SE5023L）的表面溫度比另外兩顆略高約 3~5 度。當我把觀測到的電壓與溫度數字輸入 AI，ChatGPT 建議我先拆掉這顆 PA 之後，再觀察其他兩顆的偏壓值，Gemini 則是直接不演，說這顆是元兇，鐵口直斷拆掉後 5G 訊號應該就會回來了。
拆掉溫度較高的那顆 SE5023L 之後，接下來就是見證奇蹟的時刻! 常言說得好，不管修不修得好，牛逼的口號少不了！兄弟們搬起你們的小板凳，坐穩了！睜開你們的卡姿蘭大眼睛，醒來吧！親愛的～好....開機！3 個大風扇嗚嗚的轉起來了...現在觀察診斷卡...兄弟們不要眨眼啊～精彩的時刻，B2...99...可以看到成功點亮！華碩的 5G 終於回來了！結果如同 Gemini 所言，但連結速度也降至 867 Mbps。
當我把這結果輸入這兩家 AI，ChatGPT 還在糾結電壓的問題，似乎沒意識到已找到問題源頭，Gemini 則是很乾脆，叫我繼續這麼用就好。
當然了，我還是強迫症的把拼多多買來的 PA 晶片（¥9.9）裝回去，5G 連結訊號也順利恢復至 1300 Mbps。前前後後搞了一個多月，終於把 5G 問題修好了。
所以真正的原因就是 Gemini 說的，其中一顆 PA 故障產生錯誤的 5G 雜訊，導致整個 5G 訊號異常，有如一顆老鼠屎壞了一鍋粥。為何手機電腦端看不到 5G 訊號，是因為訊號被搞爛了，而非沒有訊號。如果有示波器，或許就能看得出來。
經測試 5G 連線品質很不錯，雖然 5G 的訊號成功救回來了，不過 2.4G 可能受到吹跑電容的影響，訊號強但品質不是很好，只要距離稍微拉遠一點，傳輸速度就明顯下降。改天有機會再把電容補上。
後記 & 心得
回顧一下兩家 AI 的對話內容，ChatGPT 似乎沒意識到拆掉 PA 後已經找到問題根源，一直糾結「故障 PA 是否導致短路、導致其他 PA 的 5G 全面罷工」或是「SKY13370 是否被誤觸 RF 關閉的動作」等相關驗證。而 Gemini 其實早在第一時間就提過「其中一顆 PA 故障造成整個 5G 都是雜訊」的可能性，後續也有考量「電子學小白 + QFN 銲功」的立場設定，重點完全抓到，廢話也不多，所以從這次的經驗看來，Gemini 比 ChatGPT 略勝一籌，也難怪近期聲量贏過 ChatGPT。至於為何在 5G 主控這個項目繞了遠路，純粹是摻入個人意見和受網路文章的影響，畢竟 AI 都建議把這項目擺在最後。
另外 BCM4360KMLG 這顆 QFN 晶片，單邊就有 28 隻腳全擠在 12mm 長度內，上網搜尋「QFN 焊接教學」也沒找到這麼多腳又這麼密的範例。雖然過程中一度搞得心灰意冷、萬念俱灰，不過搞懂了技巧之後，拆裝時也沒有想像中難，適當的風槍溫度、適量的焊錫膏、適量的助焊劑，以及最重要一點：自動回彈歸位的動作是否確實。這幾個條件都能成立時，就不用特別擔心腳位是否對準焊盤、是否造成短路等問題。這是我拆裝板上三顆 QFN 晶片的小小心得。
繼 GPi Case 、二號機主機板之後，這次 AC68U 的維修，不僅讓我的焊工手藝進步了一點，也是電子小白首次導入 AI 協作的成功案例。只是自己的年齡越來越大，視力也越來越差，操作上感覺越來越吃力，而這類必須動手的細活， 目前 AI 仍無法取代，還得自己動手。但也在這次的經驗中，深刻體驗 AI 的功力。你說 AI 這麼好用的東西，會有泡沫化的一天嗎？或許三次世界大戰、人類文明倒退時，AI 才有可能泡沫化吧。
後續追蹤（2025.12.27 補充）
(a) 5G 訊號再度消失：
自補回 SE5023L 並且 7x24 使用了約一週之後，某次調整設定然後重開機，結果 5G 又突然不見了。這次是連 5G 燈號都不亮了，後台管理看不到 5G 的 MAC Address，ssh 連線 dmesg | grep BCM 指令只有看到一張 BCM4360 的紀錄，經 AI 判斷 5G 主控徹底離線了，很可能是使用低溫錫造成的，重新加熱回焊應該就能解決了（兩個 AI 都這麼認為，且 Gemini 語氣更加堅定）。2.4G 主控也用了低溫錫卻沒出事，單純是機率問題。
至於為何剛好在重開機時出現，Gemini 給出了很有意思的答案：低溫錫在長期高溫與溫度變化的環境下，容易發生「脆化」導致脫焊。而重開機時電流瞬間變化，亦導致溫度變化，剛好滿足這些條件，所以剛好就在重開機之後，焊點就脆化斷裂了。
果然如 AI 說的，重新用風槍加熱回焊，讓主控再一次自動歸位之後， 5G 又恢復了。ChatGPT 建議我把低溫錫換掉，Gemini 則是再度提供黑招，若想繼續使用低溫錫，可以在 5G 主控加墊重物且避免重新開機，應該可以再用上很長一段時間。
後來我想了想，決定找個時間把低溫錫換掉，一勞永逸改用高溫錫。結果這個決定，又差點讓我翻車。
(b) AC68U 就差那一點就徹底涼了
當初拆裝兩顆主控時都用了低溫錫，決定先拿 2.4G 主控開刀。拿下主控並清完焊盤之後，參考網路上的說法，低溫改高溫時最好再用高溫錫拖一遍焊盤，把表層的低溫錫徹底洗掉。然後發現焊槍在 350 度時有點拖不太動，所以就一路升溫到 400 度，高溫錫終於好拖了，但此時最致命的情況發生了：焊盤掉點！這下可慘了！趕緊降溫改用常溫錫，焊槍溫度三百出頭就可以順拖，也不再發生掉點。
算了一下，主控焊盤左上方的位置總共掉了 3 個點，心都涼了，我的手藝沒有好到能飛線 0.4 mm 間距的焊盤，網路上這類飛線影片，全都是在顯微鏡下秀技術給觀眾鼓掌的。心裡默默盤算，如果 2.4G 主控裝回去之後點不亮，這台 AC68U 就要放棄治療了。
不幸中的大幸，就算掉了三個點，用常溫錫把 2.4G 主控裝回去之後，所有的功能依然正常，心裡鬆了一口氣。
接下來換 5G 主控。結果又差點翻車。
(c) 5G 主控徹底涼了
用中溫錫把 5G 主控焊回去之後，開機...萬萬沒想到 5G 燈號又不亮了！但狀況又不一樣了，5G 主控沒有徹底離線，還看得到 MAC Address。想說可能是沒有焊好，再次拆下，當下發現焊盤上有兩處呈現大範圍連錫，看來是短路了，已經拆裝那麼多次，就這次沒焊好。回想前次回焊時自動歸位的動作有氣無力，應該是沒焊好的徵兆，且過程中還吹跑了一顆 5G 主控旁邊的小電容，不太順利。
所以又徹底的反想了一次，可能是大面積的中央焊錫不夠多、主控放上去時又手賤去壓了幾下，應該不要壓才對....等等等等。再一次回焊、有明顯的 Q 彈自動歸位之後，5G 症狀依然故我，看來應該是前次連錫通電時之把晶片搞壞了。
於是我想到最初第一次換下來的原始 5G 主控應該還是好的，所以又把最初的 5G 主控裝回去，見證時機的時刻，開機！兄弟們不要眨眼啊～B2、99，5G 的燈號亮了！所有的功能恢復正常了。
這次主控的常溫錫更換過程不太順利，不僅差點把焊盤搞壞（萬一搞壞就沒救了），還玩壞了一顆主控，最後總算是成功了。
(d) 彌補過程中吹跑的小電容失誤
一波接一波的拆裝主控，總共吹跑旁邊三顆貼片電容。以及當初更換 SE5023L 時在 PIN3 的 RFIN 腳位旁的貼片電容有被焊槍燒灼變色的痕跡，強迫症發作的我又想要把這些小電容更換補上。
本以為隨便找幾顆同尺寸的電容黏回去就好，不過詢問 AI 發現並不是這麼回事。AI 強調用錯電容會發生反效果，強烈建議如果機器能跑的話，吹跑的小電容就不要理它。
所以問題來了：如果堅持要補足電容的話，容值該如何選擇？
我把這問題輸入 AI 之後，又獲得了大量的電子學知識，札札實實上了一門有看沒有懂的電子學課程。
首先是主控的部分，從圖片中判斷：
- 吹跑的電容旁邊還有一顆，也就是電容成對出現。
- 這對電容的另一端是大面積銅箔，應該是接地。
- 吹跑的電容，作用是「耦合電容」，用來過濾電路中的雜訊。
- 耦合電容 100nF 為高頻通用值。
然而再深入探討，高頻 100nF 如果不是「一顆」而是「一組」的話，依設計還會有大中小的組合。根據這些關鍵字又上網找了幾篇有關「耦合電容設計」的文章，100nF 不會是最靠近晶片的這顆，而最靠近晶片的都是最小值，可能是 100nF 的 1/10 或更小。
有關「耦合電容」這部分有大量的電子學知識，最後我選定 1nF 這個值，三顆被吹跑的都是。
再來是 SE5023L 的 RFIN 腳位的電容，從圖片與功能判斷：
- 兩端銅箔都是細線，沒有接地的一端，應該是 5G 訊號線路，而非電源耦合。
- 作用是直流隔離 (DC Blocking)，SE5023L 的 DataSheet 也有寫明必要元件。
- 容值選定有 SRF 規則可循，其中包含大量電子學知識。
這顆我選擇 5pF 容值。
3+1 顆電容規格全都是 0402，為了這個還特地上拼多多買了一本 0402 電容本，裡面有 80 種容值，每一種 50 顆，感覺這輩子應該都用不完了 😂。0402 電容用烙鐵很容易黏在焊頭上，還可能被燒壞，所以改用熱風槍施工。雖然 0402 很小，但只要抓到訣竅，其實焊回去也不算太難。中溫錫大約 320 度、風量開到 4，差不多就能自動歸位。施工時記得用隔熱膠帶把主控貼好，避免好不容易焊回去的主控，又被熱風槍吹出新問題。
至此，從 10 月下旬開始至今（12 月 27 日），AC68U 的所有修復工作全數完成，功能也都全數恢復正常。回顧整個過程，實際上只有一顆 PA 故障導致 5G 訊號異常，但最終還是更換一顆 PA (SE5023L)，一顆主控（BCM4360KMLG-P20），以及 3+1 顆 0402 電容，還差一點把主控焊盤徹底搞掛，仍是繞了好大一圈遠路。
溫度檢視與散熱改善方案
用「AC68 溫度」關鍵字搜尋，可查到這台機器有容易過熱降速的問題，以及各種神奇的外掛散熱方案。不過官方韌體並沒有直觀的溫度顯示，必須刷第三方的梅林韌體才看得到 CPU 和兩顆主控的溫度，操作上實在有點麻煩。其實不論是官方或梅林韌體，都可透過 ssh 登入路由器後，執行指令查看路由器的各種狀態，當然也包含溫度資訊，對碼農來說，「如何快速且優雅的查看溫度」也就成了小菜一碟。
(a)不分韌體版本，查看溫度
首先是查看溫度的部分，ChatGPT 提供了一套完整的 Shell 指令如下：
#!/bin/sh
# ---- CPU Temperature ----
cpu_temp=$(cat /proc/dmu/temperature 2>/dev/null | grep -oE '[0-9]+')
# ---- UPTIME: seconds ----
uptime_sec=$(awk '{print int($1)}' /proc/uptime)
# ---- PHY Temperature ----
get_phy_temp() {
iface="$1"
raw=$(wl -i "$iface" phy_tempsense 2>/dev/null | grep -oE '[0-9]+' | head -n 1)
[ -z "$raw" ] && echo "null" && return
echo $((raw / 2 + 20))
}
eth1_temp=$(get_phy_temp eth1)
eth2_temp=$(get_phy_temp eth2)
# ---- CPU Usage ----
get_cpu_usage() {
read -r cpu user nice system idle iowait irq softirq steal guest guest_nice < /proc/stat
total=$((user + nice + system + idle + iowait + irq + softirq + steal))
echo "$total $idle"
}
# Read twice with 1 second interval to calculate usage
cpu1=$(get_cpu_usage)
sleep 1
cpu2=$(get_cpu_usage)
total1=$(echo $cpu1 | awk '{print $1}')
idle1=$(echo $cpu1 | awk '{print $2}')
total2=$(echo $cpu2 | awk '{print $1}')
idle2=$(echo $cpu2 | awk '{print $2}')
cpu_usage=$((100 * ( (total2 - total1) - (idle2 - idle1) ) / (total2 - total1) ))
# ---- Memory ----
mem_total=$(awk '/MemTotal/ {print $2}' /proc/meminfo)
mem_free=$(awk '/MemFree/ {print $2}' /proc/meminfo)
mem_used=$((mem_total - mem_free))
# ---- Root filesystem ----
root_total=$(df / | awk 'NR==2 {print $2}')
root_used=$(df / | awk 'NR==2 {print $3}')
# ---- Network statistics ----
ifstatus() {
iface="$1"
rx=$(cat /sys/class/net/$iface/statistics/rx_bytes)
tx=$(cat /sys/class/net/$iface/statistics/tx_bytes)
echo "$rx $tx"
}
eth1_stats=$(ifstatus eth1)
eth2_stats=$(ifstatus eth2)
eth1_rx=$(echo $eth1_stats | awk '{print $1}')
eth1_tx=$(echo $eth1_stats | awk '{print $2}')
eth2_rx=$(echo $eth2_stats | awk '{print $1}')
eth2_tx=$(echo $eth2_stats | awk '{print $2}')
# ---- Wi-Fi connected clients ----
wifi_clients() {
band="$1"
# 2.4G: eth1 / 5G: eth2 (可能因 AC68U 設定不同)
wl_iface=""
if [ "$band" = "2.4G" ]; then wl_iface="eth1"; fi
if [ "$band" = "5G" ]; then wl_iface="eth2"; fi
count=$(wl -i "$wl_iface" assoclist | wc -l)
echo "$count"
}
clients_2g=$(wifi_clients 2.4G)
clients_5g=$(wifi_clients 5G)
# ---- Output JSON ---a-
echo "{"
echo " \"cpu_temp\": $cpu_temp,"
echo " \"cpu_usage_percent\": $cpu_usage,"
echo " \"uptime_sec\": $uptime_sec,"
echo " \"phy_temp\": {\"eth1\": $eth1_temp, \"eth2\": $eth2_temp},"
echo " \"memory_kb\": {\"total\": $mem_total, \"used\": $mem_used, \"free\": $mem_free},"
echo " \"root_fs_kb\": {\"total\": $root_total, \"used\": $root_used},"
echo " \"network_bytes\": {"
echo " \"eth1\": {\"rx\": $eth1_rx, \"tx\": $eth1_tx},"
echo " \"eth2\": {\"rx\": $eth2_rx, \"tx\": $eth2_tx}"
echo " },"
echo " \"wifi_clients\": {\"2.4G\": $clients_2g, \"5G\": $clients_5g}"
echo "}"
用 ssh 登入路由器後，將以上的指令存成 .sh 檔並授予執行權限（chmod +x 檔名.ch），執行該 .sh 結果如下：
{
"cpu_temp": 66,
"cpu_usage_percent": 5,
"uptime_sec": 52628,
"phy_temp": {"eth1": 50, "eth2": 53},
"memory_kb": {"total": 255708, "used": 68852, "free": 186856},
"root_fs_kb": {"total": 42112, "used": 42112},
"network_bytes": {
"eth1": {"rx": 12366900, "tx": 22010323},
"eth2": {"rx": 492820210, "tx": 2672551853}
},
"wifi_clients": {"2.4G": 3, "5G": 2}
}
至於如何把 .sh 的執行結果往外面丟， ChatGPT 給了一堆錯誤的方向，到處鬼打牆，原因是路由器韌體支援的指令相當有限，很多指令都不能用。
後來我想到用 python3 跑 ssh 的方法，請 ChatGPT 操刀撰寫一段 python3 的 .py 程式如下：
#pip install flask paramiko
from flask import Flask, jsonify
import paramiko
import json
# 路由器連線資訊
ROUTER_HOST = "路由器內網IP"
ROUTER_PORT = 路由器ssh埠號
USERNAME = "路由器帳號"
PASSWORD = "路由器密碼"
SCRIPT_PATH = "路徑/檔案.sh" # 登入後就是 /tmp/home/root
def run_temp_script():
client = paramiko.SSHClient()
client.set_missing_host_key_policy(paramiko.AutoAddPolicy())
try:
client.connect(
hostname=ROUTER_HOST,
port=ROUTER_PORT,
username=USERNAME,
password=PASSWORD,
timeout=4
)
stdin, stdout, stderr = client.exec_command(f"/bin/sh {SCRIPT_PATH}")
output = stdout.read().decode().strip()
error = stderr.read().decode().strip()
if error:
print("Script error:", error)
return json.loads(output)
finally:
client.close()
def rawtotemp(raw:int = -1):
'''
rawtotemp 將原始 RAW 值轉換為溫度
:param raw: 原始 raw 值，除以2 + 20 則為攝氏溫度。
:type raw: int
:return: 攝氏溫度
:rtype: int
'''
return int(raw) #int((raw)/2+20)
def seconds_to_text(seconds: int):
'''
seconds_to_text 將秒數轉為 x 天 x 小時 x 分 x 秒
:param seconds: 運作秒數
:type seconds: int
:return: x 天 x 小時 x 分 x 秒
:rtype: str
'''
seconds = int(seconds)
days, seconds = divmod(seconds, 86400)
hours, seconds = divmod(seconds, 3600)
minutes, seconds = divmod(seconds, 60)
parts = []
if days:
parts.append(f"{days} 天")
if hours:
parts.append(f"{hours} 小時")
#if minutes:
parts.append(f"{minutes} 分")
#if seconds or not parts:
parts.append(f"{seconds} 秒")
return " ".join(parts)
# ---- Flask API ----
app = Flask(__name__)
app.config['JSON_AS_ASCII'] = False #Flask 2.2 及舊版本
# app.json.ensure_ascii = False #Flask 2.3 及新版本
@app.route("/")
def getroot():
return jsonify({'cpu_temp' : -1, 'phy_temp':{'eth1': -1, 'eth2' : -1}, 'uptime_sec' : 'root'})
@app.route("/allstatus")
def get_temps():
'''
get_temps 對應 /allstatus
'''
try:
data = run_temp_script()
data['uptime'] = seconds_to_text(int(data['uptime_sec']))
return jsonify(data)
except Exception as e:
return jsonify({'cpu_temp' : -1, 'phy_temp':{'eth1': -1, 'eth2' : -1}, 'uptime_sec' : str(e)})
if __name__ == "__main__":
app.run(host="127.0.0.1", port=自訂服務埠號)
這個方法果然奏效，在內網找一台可以跑 python3 的電腦，用 pip 安裝 flask 、 paramiko 套件後，執行這段 .py 程式，就可以直接從該電腦的瀏覽器輸入「http://localhost:自訂服務埠號/allstatus」直接查看執行 .sh 的內容。
「http://localhost:自訂服務埠號/allstatus」這個網址就能寫成各種服務，例如我是先用 php 包起來（隔離後台資訊），再寫個網頁把 php 執行結果讀進來，放在 WWW 主機上，網址公開。以後在全世界的任何一個角落開啟網址，就能讀到路由器的溫度，方便查閱。
(b) 風扇散熱
AC68U 最大的問題就是容易過熱，網路上查到，AC68U 原廠完全不改散熱的情況下，CPU 溫度最高可能飆到 85 度以上。然而我個人拆機實測，拆除金屬屏蔽罩後，在 CPU 放一顆樹莓派常用的13mm 銅鰭散熱片，溫度最高也不過 72 度，由此可知原廠的散熱設計到底有多廢。
在一切原廠配置的條件下，AC68U 最簡單粗暴的散熱方案是購買外掛風扇，風扇電源直接使用本體後方的 USB 埠。效果雖然明顯，但會犧牲一埠 USB 的功能，並且影響 AC68U 的外觀顏值。
我的做法是，拆除無法復原的金屬頻蔽罩後，用銅片 + 導熱墊替代，上拼多多買一顆 3007 的 5V 風扇（¥3.42），黏在原廠的鋁散熱鰭片上，7mm 厚度剛好可以塞入本體內，電源的部分從主機板的 USB2 拉飛線，中間用 1.2mm 的 2pin 公母接頭方便日後更換。考慮到空間的內對流，所以在風扇的兩側打洞。觀察幾天下來，實測溫度 CPU 最高 66 ，主控最高分別是 50 度和 53 度，與實測最高相比降了 6 度，這還是從 800 MHz 超頻 到 1,200 MHz 的結果。應該還有空間換上大一點的 4007 風扇，降溫效果應該會更明顯。
雖然和市售的外掛方案相比還有 6 度的改善空間，不過成本僅為台幣 40 元，不到市售的四分之一，且完美顧及顏值和 USB2 的原有功能，個人已經相當滿意。
超頻方式
手上這台 AC68U 是早期的版本，CPU 是 BCM4708A0，據說原始設計是 1GHz 被降頻到 800 MHz 在跑。官方韌體一樣是無法直觀的查看 CPU 運作頻率，換成梅林韌體才看得到。可以透過簡單的指令超頻 CPU，一樣不分官方或梅林韌體。
使用 ssh 登入後，執行以下指令：
nvram set asuscfeclkfreq=1200,666 && nvram set asuscfecommit=1 nvram set clkfreq=1200,666 && nvram commit && reboot
上述指令中的 1200 就是要超頻的目標頻率，完成後自動重開機生效。要提醒的是，超頻數值會永久寫入 CFE 韌體的某個區塊內，不論後續再刷哪種韌體、或是重置 NVRAM 等，效果會一直存在，所以務必小心操作。
要查看運作頻率的話，除了用梅林韌體，也可以用指令查看：
nvram get clkfreq
此外 AC68U 還有調高發射功率的方法，不過調高功率會有法規、干擾和電磁暴露的風險，家中若有裝心律調節器的長輩更要避免，所以個人完全不建議。
維修成本 & 效益
- 拆換一顆 PA -> 恢復 3T3R，材料成本 ¥9.9 元，約台幣 43 元。
- 裝壞一顆主控 -> 材料成本 ¥18 元，約台幣 80 元。
- 改裝 -> 風扇 ¥3.42 + 公母接頭含線 16 元 + 銅片¥0.7x3，約台幣 40 元。
- 效益：焊功技巧升級、AI 協作成功經驗，以及從 AI 邊做邊學、獲得的海量知識，無價。
技術資訊 (5)