先說，這些都不是我想到的，也不是什麼新東西，原設計者基本上已經不可考了，反正我看巴哈沒人講就發上來。
以下設備實驗都在vanilla 1.16.5進行。
因為排版問題，文章內圖片的顯示大小有縮過，實際畫面解析度沒那麼感人，要看大圖點開來就對了。
以下每台設備我都測過傳輸延遲，方法就掛個指令方塊顯示gametime而已，不是什麼複雜技術所以略過。因為指令玩家和紅石玩家的tick定義不同，所以時間單位一律用秒以減少奇怪的誤解。
放一張測試畫面順便當縮略圖
另外，因為接收端都是用偵測器，所以在輸入的上升緣（rising edge）和下降緣（falling edge）都會輸出一個脈衝信號，在某些時候可能要加上黏性活塞+紅石磚的組合，把脈衝轉換回原本的信號。
(1) 向上傳輸設備之一
原理：鷹架為了實作距離太遠會掉落的特性，有保存一個離支架距離的blockstate，這個變更能被偵測器測到。著地（distance=0）和懸空（distance=1）兩個狀態間的切換用地板門實作。
信號輸入端（power off）：
信號輸入端（power on）：
信號接收端：
傳輸延遲：
| rising edge | 0.05 s/m |
| falling edge | 0.05 s/m |
延遲會隨高度增加而線性上升，而且上升率比直接拉紅石線的延遲（階梯狀上升，小於0.0067 s/m）高一點，應用上大概會出現在對水平面積嚴格要求的地方。
(2) 向上傳輸設備之二
原理：水中氣泡柱的出現和消失可以被偵測器測到。
信號輸入端（power off）：
信號輸入端（power on）：
信號接收端：
傳輸延遲：
| rising edge | 0.05 s |
| falling edge | 1.15 s |
常數延遲，但很大的致命傷是falling edge反應超級慢。
(3) 向下傳輸設備
原理：牆在側邊貼著非牆方塊時，中間會出現柱子，而且會連帶影響正下方連接的所有牆，這個變更能被偵測器測到。兩個狀態之間的切換用地板門實作。
信號輸入端（power off）：
註：只要左半邊的部分就可以了，我多蓋右半邊是為了測延遲。
信號輸入端（power on）：
信號接收端：
傳輸延遲：
| rising edge | 0 s |
| falling edge | 0 s |
最鬼扯的零延遲，只要特別注意中間那條牆不去連到不該連的東西，在稍微有點高度差的機關上很有機會用上。
大概就這樣，知道原設計者要補充的話麻煩留言提醒我，有其他還不錯的設計可以直接迴文，我會在這篇放個發送門連下去。
