阿簡生物筆記

2026年3月28日

用 AI 讓 10 年前的小型電腦切割機在 Linux 重生

許多年前在網路上購入了一台「理鋒科技小型電腦切割機」，當時環境還是在 Windows 下，廠商隨附了專用的驅動與操作軟體。但隨著我的工作環境全面轉向 Linux，這台機器便因為軟體不相容而長期閒置。

最近因為臨時有割字需求，我開始研究如何在 Linux 下驅動這台老機器。

從 Inkcut 到硬體限制

起初我找到了開源專案Inkcut，它確實能讀入 SVG 並執行切割。但實際操作後發現一個致命問題：硬體緩衝區（Buffer）太小。當圖形較複雜時，硬體接收指令的速度跟不上軟體送出的速度，導致傳輸溢位，切割中途就會直接罷工。

轉向底層：直接與硬體通訊

既然 Inkcut 是將指令轉換為 HPGL 格式送出，我想：不如直接撰寫符合我硬體特性的指令發送器？

透過 lsusb 指令，我確認了機器連接的晶片資訊：

Bus 003 Device 052: ID 4348:5584 WinChipHead CH34x printer adapter cable

協同開發：與 Gemini 定義 AI Agent 規格書

我釐清了需求：需要一個視覺化的程式，能讀取 Inkscape 製作的 SVG，並具備「節流（Throttling）」功能。我透過與 Gemini 的不斷對談，最終整理出一份給 AI Agent 執行的專案規格書（Spec）：

AI Agent 專案規格書：Linux 智慧切割傳送器 (PyCutter)
1. 專案目標 (Project Objective)
開發一個輕量化的 Linux 桌面應用程式，能夠讀取 SVG 檔案，自動轉換為 HPGL 指令，並透過 序列埠 (Serial Port) 實時監控並「節流傳送」給割字機，解決硬體緩衝區溢位導致的停機問題。
2. 技術棧要求 (Tech Stack)
語言： Python 3.10+
GUI 框架： Tkinter (內建，確保輕量) 或 PyQt6
向量處理： svgpathtools (解析 SVG)
硬體通訊： pyserial (串列埠通訊)
多執行緒： threading (分離 UI 與傳送邏輯)
3. 核心功能模組 (Functional Modules)
A. 檔案與路徑處理 (SVG to HPGL)
自動解析： 將 SVG 中的 <path>, <rect>, <circle> 轉換為點座標。
動態離散化 (Adaptive Sampling)： * 直線僅保留端點。
曲線根據半徑自動決定點數，確保點間距落在 0.5mm ~ 1.0mm。
單位換算： 固定比例 $1\text{ mm} = 40\text{ plotter units}$ ( $1016\text{ DPI}$ )。
路徑優化： 實作簡單的「最近鄰算法」，減少抬刀移動的空跑距離。
B. 硬體連線管理 (Connection Manager)
自動偵測： 啟動時掃描 /dev/ttyUSB* 與 /dev/ttyACM*。
連線選單： 下拉式選單切換 Port，支援重新整理。
通訊設定： 預設 9600 鮑率，支援 RTS/CTS 硬體流控 設定。
C. 視覺化監控畫布 (Live Monitor)
同步繪圖： 當指令送出時，畫布上的游標同步移動並繪製線條。
座標縮放： 自動將 HPGL 萬級座標縮放至 600x400 的視窗內。
顏色區分： 抬刀 (PU) 用灰色虛線，下刀 (PD) 用紅色實線。
D. 流量控制傳送引擎 (Throttled Sender)
逐行傳送： 讀取 HPGL 陣列，一條一條 ser.write()。
智慧延遲： 提供滑桿調整 Inter-step Delay (預設 0.05s)。
暫停/終止： 支援切割中途立即停止通訊。
4. 使用者介面需求 (UI Requirements)
頂部列： Port 選擇、連接按鈕、重新整理按鈕。
左側邊欄： * 速度延遲設定 (Slider)。
曲線平滑度設定 (Slider)。
檔案選擇按鈕。
中央區域： 繪圖監控大畫布。
底部狀態列： 顯示 當前指令/總指令數、預計剩餘時間、連線狀態。
5. AI Agent 的開發任務分解 (Task Breakdown)
你可以要求 Agent 按照以下順序執行：
Task 1: 編寫一個獨立的 Scanner 類別，列出 Linux 所有序列埠。
Task 2: 使用 svgpathtools 編寫轉換邏輯，輸入 SVG 路徑，輸出符合 1016 DPI 的 HPGL 字串列表。
Task 3: 建立 Tkinter 主視窗，包含 Canvas 繪圖與基本的 UI 佈局。
Task 4: 整合 pyserial 傳送引擎，確保在 threading 模式下運作。
Task 5: 優化：加入 stty 權限檢查邏輯，若無權限則彈窗提示。
6. 預期錯誤處理 (Error Handling)
Permission Denied: 提示使用者執行 sudo usermod -aG dialout $USER。
Disconnected: 若傳送中 USB 拔除，應立即捕捉異常並停止計時。
Scale Error: 若圖檔太大超過畫布，應具備 Fit to Canvas 的自動縮放邏輯。

補充規格：原點校正與座標偏置 (Origin & Offset Calibration)
1. 核心邏輯 (The Logic)
割字機通常有兩個原點概念：
Machine Home (機械原點)： 機器開機後感應器觸碰到的物理極限點。
User Origin (用戶原點/工作起點)： 你手動將刀頭移動到材料邊角後設定的 (0,0)。
2. 功能需求 (Feature Requirements)
AI Agent 需要在 UI 上增加一個「校正面板」，包含以下功能：
Jog Control (手動微調)： * 提供上下左右按鈕，發送微小的移動指令（例如每次移動 1mm 或 10mm）。
指令範例：PU{current_x + 40},{current_y};。
Set As Origin (設為原點)： * 當用戶把刀移到滿意的位置後，按下此鍵。
軟體會將當前的機械座標記錄為 Offset_X 與 Offset_Y。
之後所有的 SVG 座標都會加上這個 Offset。公式：Final_X = (SVG_X * 40) + Offset_X。
Go To Origin (回起點)： * 快速測試指令：PU0,0; (相對於用戶原點)。
3. 視覺化配合
在畫布（Canvas）上，用一個「十字準星」或「紅色方框」標示出目前刀頭的預期位置。
當用戶點擊微調時，畫布上的準星要同步移動。

我將這份 Spec 投入 Gemini CLI，讓它進行實作。經過幾輪的 Debug 與邏輯修正，我的切割機終於在 Linux 上完美復活了！

如果你也有類似的老舊割字機在 Linux 下無法使用的困擾，歡迎參考或 Fork 我的專案，並利用 AI Agent 針對你的硬體特性進行微調。

專案位址： https://github.com/chihhsiangchien/pycutter

2026年3月27日

久違了，雷文霍克顯微鏡的製作

真的久違了，上次把我的單式顯微鏡材料箱打開來，已經是好幾年前的事了。

這次重啟是因為輔導團的增能活動，我規劃了這個活動，以及用這個活動做AI相關的課程。

以往我做這個活動，其實有一個不確定性，因為過去總說雷文霍克這樣製作顯微鏡，但其實科學家們並不確定，因為鏡片被緊緊鑲嵌在兩片黃銅板之間，孔徑極小，科學家過去無法在不破壞文物的情況下觀察鏡片的完整形態所以，大家只能猜測他的做法。不過2021年《科學進展》（Science Advances）的科學研究刊出了這篇文章，秘密揭曉！

Neutron tomography of Van Leeuwenhoek’s microscopes〈雷文霍克顯微鏡的中子斷層掃描〉

研究團隊決定使用中子輻射來進行非侵入式掃描，因為中子能輕易穿透金屬，並對玻璃產生良好的對比度，從而重建出精確的 3D 模型。

研究人員掃描了兩台保存在荷蘭的原始顯微鏡（一台放大倍率 118x，另一台則是現存最強的 266x），結果出人意料：

中倍率顯微鏡（118x）：證實使用了傳統的研磨與拋光技術，鏡片形狀如同一顆對稱的扁平豆子（透鏡狀）。但高倍率顯微鏡（266x）：內部竟然是一顆球形鏡片（Ball-shaped lens），3D 影像清楚顯示球形鏡片上連接著一根細小的玻璃梗（Stem）。

這種形狀完全符合虎克在 1678 年發表的「簡易熔融法」，是將玻璃絲末端加熱熔化成球狀。就是過去我帶課程時使用的方法，也就是說我過去說雷文霍克用這樣做顯微鏡鏡片，這是可以確認的。

這件事實的發現，有很重大的意義，因為這種製作鏡片的方式在虎克的Micrographia這本書裡早有記載。

"...take a very clear piece of a broken Venice Glass, and in a Lamp draw it out into very small hairs or threads, then holding the ends of these threads in the flame, till they melt and run into a small round Globul, or drop, which will hang at the end of the thread; and if further you stick several of these upon the end of a stick with a little sealing Wax, so as that the threads stand upwards, and then on a Whetstone first grind off a good part of them, and afterward on a smooth Metal plate, with a little Tripoly, rub them till they come to be very smooth..."

「……取一塊非常清澈的威尼斯碎玻璃，在燈火上將其拉成極細的絲線，接著將這些玻璃絲的末端置於火焰中，直到它們熔化並匯聚成一個懸掛在絲線末端的小圓球或小滴。
若進一步用少許密封蠟將其中幾顆固定在木棒末端，使玻璃絲朝上，接著先在磨刀石上磨掉大部分（球體），最後在光滑的金屬板上沾一點矽藻土（Tripoly）進行摩擦，直到它們變得非常平滑……」

虎克在 1665 年時建議將球體磨掉一部分以形成「平凸透鏡」，因為他當時擔心多重折射會導致影像模糊。然而，論文研究發現，雷文霍克顯然發現了直接使用完整球體（連帶著那根細小的玻璃梗作為把手）其實效果極佳，只要控制好光圈即可。

雷文霍克生前曾公開批評虎克的熔融法會產生雜質，宣稱自己不使用球形鏡片。但掃描結果證明他其實私下採用了虎克的技術，並將其改良至完美的境界。關鍵在於他對孔徑控制與鏡片安裝的極致追求，將當時已知的技術發揮到了物理極限。

看到這些敘述之後，就讓我想要重新修改材料來試一次。先說結論，以下的做法確實可以得到高品質的影像，比起我之前的作法好很多。

材料改用厚紙板，並使用3mm的打孔器打孔

接著用鋁箔膠帶，先將孔貼住

再使用縫衣針在圓孔正中央，將鋁箔膠帶穿一個小洞，此步驟務必直上直下，使洞口在正中

接著再把燒融的玻璃球或購置的玻璃球放入，用鋁箔膠帶的黏性把鏡片黏著就可以了。

這樣就做完全部的事情了。

這和以往我的材料有幾個不同

1.以前用卡紙，現在用厚紙板更厚實不變形

2.用鋁箔膠帶取代以前用卡點西德，更容易獲得完美的光圈

而光源的部分則是採用自製的LED光源

玻片標本的製作建議使用軟塑膠片，貼上標本(如洋蔥表皮)後貼上透明膠帶就可以。這樣製作的好處是你可以彎曲塑膠片為微調標本的位置，使標本落在鏡片的焦點。

2026年3月17日

ADS-B 數位觀察：分析桃園空域航線、高度與信號傳播特性

時隔兩週，其實我的這項用RTL-SDR V4收飛機訊號的計畫還在持續進行，甚至我還把收到的訊號轉送去Flightradar24與flightaware，當然也獲得了一些很棒的會員權益，基本上就是可以取用資料庫。對這有興趣的話，兩者的官網都有資訊，但前提是你用的是linux的機器才好操作。（像我就是在樹莓派上運行）

從飛機收來的訊號不單是只有位置訊號，而是有這麼多不同的資料，但並不是每一台飛機都的資料內容都有這些，總之我是都即時用我房間的小天線，能抓都抓了。

參數 (Parameter)	英文全稱 (English Full Name)	中文說明 (Chinese Description)
$t	Timestamp	時間戳記 (接收訊號的時間)
.hex	ICAO Hex ID	ICAO 24位元位址碼 (飛機唯一識別碼)
.flight	Flight Number / Callsign	航班編號 / 呼號
.lat	Latitude	緯度
.lon	Longitude	經度
.alt_baro	Barometric Altitude	氣壓高度
.alt_geom	Geometric Altitude	幾何高度 (GPS 高度)
.gs	Ground Speed	地速
.ias	Indicated Airspeed	指示空速
.tas	True Airspeed	真空速
.mach	Mach Number	馬赫數
.track	Track Angle	航跡角
.track_rate	Track Rate	航跡變化率 (轉彎率)
.roll	Roll Angle	滾轉角 (飛機坡度)
.mag_heading	Magnetic Heading	磁航向
.true_heading	True Heading	真航向
.baro_rate	Barometric Vertical Rate	氣壓爬升/下降率
.geom_rate	Geometric Vertical Rate	幾何爬升/下降率
.temp	Static Air Temperature	靜溫 (外界環境溫度)
.wd	Wind Direction	風向
.ws	Wind Speed	風速
.nav_qnh	QNH Setting	氣壓高度表修正值 (海平面氣壓)
.nav_altitude_mcp	MCP Selected Altitude	自動駕駛設定高度 (MCP/FCU)
.selected_heading	Selected Heading	設定航向
.squawk	Squawk Code	應答機代碼 (四位數識別碼)
.rssi	Received Signal Strength Indication	接收訊號強度指標
.messages	Message Count	訊息總數
.rc	Radius of Containment	容納半徑 (位置完整性)
.nic_baro	Navigation Integrity Category (Baro)	氣壓高度完整性類別
.nac_p	Navigation Accuracy Category (Position)	位置精確度類別
.nac_v	Navigation Accuracy Category (Velocity)	速度精確度類別
.sil	Source Integrity Level	源完整性等級
.gva	Geometric Vertical Accuracy	幾何垂直精確度
.sda	System Design Assurance	系統設計保證
.category	Aircraft Category	飛機類別 (重量或類型)
.nav_modes	Navigation Modes	導航模式狀態
.version	ADS-B Version	ADS-B 版本

我用one-liner列出目前收到的每日航班量，命令是

printf "%-15s | %-10s\n" "Date (File)" "Flight Count" && \

printf "%-15s-|-%-10s\n" "---------------" "----------" && \

for f in adsb_*.csv; do

count=$(cut -d',' -f3 "$f" | grep -v "N/A" | sort -u | wc -l);

printf "%-15s | %-10s\n" "$f" "$count";

done

Date (File) | Flight Count

----------------|-----------

adsb_2026-02-17.csv | 693

adsb_2026-02-18.csv | 1140

adsb_2026-02-19.csv | 1114

adsb_2026-02-20.csv | 1019

adsb_2026-02-21.csv | 992

adsb_2026-02-22.csv | 1030

adsb_2026-02-23.csv | 963

adsb_2026-02-24.csv | 971

adsb_2026-02-25.csv | 921

adsb_2026-02-26.csv | 892

adsb_2026-02-27.csv | 1016

adsb_2026-02-28.csv | 937

adsb_2026-03-01.csv | 531

adsb_2026-03-15.csv | 29

中間有幾天電腦重啟，忘記繼續開紀錄的sh，就沒紀錄了，但是可以看到每天都能收到數百筆航班資料。

既然有大量資料，當然就是做我最愛的資訊視覺化，以下都用R來畫某一天的圖。

這用的是飛機的類型來繪圖，有小飛機、大飛機...。

每日收到的訊號點的圖

依照航向和高度來區分，黃線就是小於2000ft的，大部分都是起飛和降落的，可以觀察桃園機場一帶在這段時間是如何進場的。因為看到這張圖，我還因此跑去永安北岸觀海亭，想要實際看從北方來的飛機轉進桃園機場的即時現況。藍綠色線的是往北的高空飛機，紫色則是往南的。

看到這些線，就一定要去看看「交通部民用航空局電子式飛航指南」去找TAIPEI FIR EN ROUTE CHART來對照，才會更好玩。下圖的進入路徑是這樣

你要先到飛航指南 https://ais.caa.gov.tw/aimportalapp/ 去底下按eAIP 看最新的資料
到- Part 2 - 航路 (ENR) 找 ENR 6 航路圖，裡面有很多圖，看到TAIPEI FIR EN ROUTE CHART 點下去就是了

左右對照看到什麼，是不是就看最明顯三條是A1/W4、B1、M750，另外還有淺淺的B591、W8。看著看著想起以前我拍攝天空的縮時攝影時，就透過飛機雲的樣子推測過我家附近至少會看到三條航線，現在透過ADS-B的資料來對照，果然沒錯。

如果根據每分鐘改變的高度，來分類是爬升還是下降，紅色是下降，綠色是上升，當然在國際航線上，就是一直維持高度不變的灰色，而綠色的就對應了桃園機場和松山機場起飛的飛機囉。

再來我們看看信號的強弱和空間的關係。某些地區幾乎沒有訊號，大多是因為飛機本來就不會飛到那。

如果再把訊號與接收端的距離和高度做強度的比較，這樣就能看到經典的自由空間路徑損耗（Free Space Path Loss, FSPL）特性。近距離 (0-25km)：訊號強度（RSSI）從 -20 dBFS 快速掉落到 -30 dBFS。這是因為在距離很近時，距離增加一倍對訊號的百分比影響很大。遠距離 (50km 以上)：曲線開始趨於平緩，衰減的速度隨著距離增加而放慢。

高度 (Altitude) 的分層效應，觀察顏色的分佈：紫色點（低高度）：集中在左側（近距離）。因為飛機在低高度時，受限於地球曲率和地形遮蔽（障礙物），只能收得到近處的訊號。黃綠色點（高度 30000+ ft）：這些點可以延伸到 100km 甚至更遠。這是因為高空飛機與接收器之間通常沒有建築物或山脈阻擋，訊號路徑更接近純粹的物理模型。

除了這些raw data畫出的數據，其實透過這些數據的組合還有更多有趣的事，等下篇再來分享。

2026年2月17日

使用RTL-SDR V4收飛機的 ADS-B畫出畫出航跡地圖

10年前寫過一篇文章《從飛機雲估測我和誰看同一片天空》，那段時間，我的興趣全在天邊那些稍縱即逝的飛機雲。那時候用望遠鏡和 FlightRadar24 的 App，看著高空的飛機雲，手動對照飛航紀錄，確認自己在新竹的窗前，視覺極限大約能觸及 80 公里外的北海岸上空。

十年過去了，現在可以直接在電腦前，直接收集那些從萬米高空來的無線電訊號。這一次用的工具是 RTL-SDR v4-一根像USB隨身碟的小東西，是一個廣域的無線電接收器。

它內部是 RTL2832U 這顆由台灣瑞昱（Realtek）設計的晶片。最初它是為了讓電腦看 DVB-T 數位電視而生，但因為它能將類比訊號直接轉為數位數據（SDR，軟體定義無線電），且價格極其低廉，意外被開發者開啟了「上帝視角」。

我購買的這款 RTL-SDR Blog V4，比起一般的電視棒做了更多專業改進。它內建了 R828D 調諧器，並加上了三路濾波器，可以應對常見的 FM 電台、手機基地台或 Wi-Fi 干擾。價格也不貴，我在前幾周從官網以 $49.95 USD 的價格入手。

最近用它玩了好幾個專案，先來介紹這個收飛機訊號的專案吧。

飛機在飛行時，會透過 ADS-B (Automatic Dependent Surveillance-Broadcast) 系統，不斷地向四周廣播自己的經緯度、高度、速度與編號。要收這個訊號，只要把偶極天線架起來，再安裝 readsb 和 tar1090 這些開源軟體( windows上也有軟體)，就可以直接接收。

飛機廣播 ADS-B 訊號的頻率固定在 1090 MHz。在這個頻率下，訊號像光線一樣是「直視傳輸，只要中間有山頭或建築物擋住，你就收不到它。剛好我的窗戶面東北有廣闊的天空，所以當然可以收到不少訊號。

再來是天線，RTL-SDR Blog V4的套件有兩組偶極天線，有一組長一組短。要收1090MHz就用兩組短的，單根長度6.5cm左右，兩根擺成垂直地面，貼在窗戶上就可以了。

天線長度需從無線電波的波長來計算。偶極天線設計為「半波偶極天線」（Half-wave Dipole），也就是天線的總長度約為半個波長。

光速約 300,000,000 m/s，1090MHz的無線電波在空氣中的全波長是300 / 1090 = 0.275 m
半波長就是27.5 / 2 = 13.75 cm
考量無線電波在金屬導體中傳輸的速度比在真空慢，實際天線長度需要乘以一個修正係數（通常取 0.95）：理論總長度：13.75 cm x 0.95 = 13.1 cm
偶極天線的兩臂長度偶極天線由兩根對稱的金屬棒組成，中央連接同軸電纜，因此單臂長度 13.1 cm/ 2 = 6.55 cm

我使用的軟體 readsb 負責在底層解碼這些 1090 MHz 的原始脈衝，而 tar1090 則提供了類似 FlightRadar24 的視覺介面，讓我能即時在地圖上看到飛機的動向。（其實就和flightradar24界面相似，但看到的就是自己收的飛機訊號）