發表文章

文章總列表

關箱 LattePanda v1:x86邊緣求生

圖片
緣起 多年前買的 LattePanda v1 開發板,丟掉前給他最後一次機會 硬體 WIFI天線得拉出一條線,爛透了 處理器不能被動散熱,風扇很吵 板子很挑電源,平板電腦的架構,假設有顆鋰電池供應瞬間大電流;USB孱弱的供電讓電壓瞬降重開機。這顆行動電源推5.2v,搭配短線,輕負載,才讓板子啟動。跑Linux待機2W,起碼跟規格一樣 Bye bye WINDOWS10;Hello Debian 13  原裝是WIN10,只有4G記憶體,很慢的內部儲存空間,又有Windows Update和Defender搶頻寬,體驗非常爛 改跑Debian13,不接螢幕,只用ssh倒是不錯,用起來和pi完全一樣;裡面跑docker,mqtt,tailscale倒是很f好用,可以當居家server 裁決:關箱,但是不 丟掉 硬體不行:WIFI天線外拉,供電爛 跑簡單的Linux服務器,我傾向用Pi,沒有外露天線,供電簡單,我學一種就好 x86單板電腦 非常稀少 ,裝上Debian就有整個x86生態系;ARM-based一些開發板,沒人維護就死掉了 後記 2011年Intel領先業界,率先量產22nm FinFET;這顆處理器2015年以傳奇的14nm打造,歷經無數次製程延遲,一路打磨到14nm+,14nm++,14nm+++;他也見證了Intel在平板電腦,手機,IoT市場奮力一搏,狂虧幾十億美金 這板子當年起價105美金,隔壁棚Pi4只要35美金,能耗更漂亮,實在拚不過;Intel後來完全撤出低功耗處理器的生意 也在同一年TSMC正式量產16nm FinFET,被大客戶(蘋果)逼著推進製程,成長成今天這樣 曾經我覺得Intel是自我糾錯能力極佳,執行力驚人,永遠不會被打敗的公司。也許我留著這個板子,是記錄這段歷史,沒有任何組織能永遠強大

自製WIFI喇叭:藍芽音訊編碼原理,瑞昱RTL8716B設定不同MAC addr

圖片
緣起 我的proxmox裡面住著兩台虛擬機,分別連了紅黑喇叭,但是他們的藍芽MAC位址完全一樣!藍芽的跳頻序列(frequency hopping sequence)由MAC位址和clock的週期數共同決定。位址不同的碰撞機率是1/79,可以用錯誤更正碼還原;位址完全一樣,碰撞機率大增 另外一個錯誤是兩個Dongle距離近,彼此干擾可能很嚴重 我做實驗時,喇叭在旁邊,聲音一下飽滿,一下單薄 藍芽音效編碼 藍芽的音效編碼公式 M = (LEFT + RIGHT) / 2 相當於中置單聲道, 能量集中 ,投資頻寬保這塊 S = (LEFT - RIGHT) /2 左右聲道的差數值,一般很小, 壓縮省頻寬 還原的方式 LEFT = (M+S)  RIGHT = (M-S) 如果通道錯誤率高,藍芽優先保護M,放掉S,聽起來就乾乾的;連線穩定,聲音又回來 FIX1 準備USB延長線,把兩個port隔開一點,這題很簡單 FIX2 瑞昱RTL8761B的量產工具沒有現身,沒辦法擺弄IC裡的eFuse改MAC;不過網路上有 工具 可以改MAC,記錄一下原理 Linux開機會灌入兩個檔案進藍芽Dongle,韌體fw.bin,設定config.bin 設定檔的原裝貨 黑喇叭,經過工具,設定成00:E0:4C:23:99: 77 紅喇叭,經過工具,設定成00:E0:4C:23:99: 88 上面三張圖,原裝貨沒有加料,經過工具注入額外設定 紅色:lengh = 0x0009 bytes 綠色:inject opcode = 0x0030,代表要寫入某個設定,大概是對應到MAC 黃色:inject length = 0x6 bytes 藍色:mac address = 0x00E04C239988,順序剛好倒置 以紅喇叭為例,還真的改成了! 工具操作的小抄,下次用 結語 大學念電信,這些音效編碼,天線干擾我也只是一知半解,動手擺弄通訊系統(藍芽)也是很苦手。學過一點基礎,能推敲原因,動手解決問題,感覺很不錯

ESP32的BLE-BEACON

圖片
緣起 通用資料紀錄器 啟用藍芽功能,在裝置名稱加上IP,手機用 nRF connect 直接看好了;這一篇紀錄ESP SDK怎麼打開藍芽BLE 藍芽Stack選擇 ESP SDK支援兩種藍芽框架,我選NimBLE因為記憶體開銷低,也許有其他坑(無法判斷) Bluetoothd 支援傳統藍芽,以及BLE,記憶體開銷比較大 NimBLE 只支援BLE only,記憶體開銷低很多 設定SDK 在sdkconfig.defaults新增以下的編譯選項 開啟ESP-IDF Terminal,砍了sdkconfig檔,執行idf.py reconfigure重新產生sdkconfig 編譯選項有改,執行full clean,重新編譯 加入BLE Beacon 原始檔在 這裡 ,留著下次複製貼上用 藍芽和WIFI會互相搶設頻電路,增大藍芽廣播週期,減少對WIFI干擾 裝置名稱ble_beacon_devname是全域變數,在適當時間呼叫下面API就能塞給藍芽stack WIFI連線管理器呼叫下面的API,收到IP或是斷線都要呼叫,更新BLE裝置名稱 SDK設計成事件驅動(event-driven),下面的片段是WIFI抓到IP,把IP字串送給藍芽 WIFI斷線,也要更新BLE裝置名稱 吃記憶體怪獸 ESP32C3跑藍芽,剩餘記憶體從100KB變10KB,我想辦法壓掉一些才回到40KB;實在代價不低 我和藍芽BLE 我在 12年前 研究過藍芽BLE心跳帶,感覺這技術有用得掌握,所以買了很多開發板放著生灰。多年後終於用來解個小問題:廣播自己的IP。藍芽BLE還有GATT服務,裝置能定義一張表格,每個欄位讀寫都有附加效果,例如: 寫入:1開燈,0關燈 讀取:得知當下LED狀態(開 or 關) 這種通訊介面很有用,能合成出各種介面。所以廣播擺上去,之後繼續折騰GATT服務的機會就大一點...

Spotify Connect音箱,多喇叭同步

圖片
緣起 三年前整的 樹莓派做Spotify Connect音箱 ,還有 這篇 ,體感差強人意,藍芽連線不穩常斷線,一次只能推一顆喇叭 2026 臺灣光復節趁著颱風假,跟AI一起解這兩題。現在手機 Spotify 會出現三個設備: 紅、黑、紅加黑(全屋同步) ! 單顆喇叭(不管是水母、 齊柏林還是 BOSE)覆蓋有極限;把兩顆快10歲的 UE Megaboom 放客廳與餐廳, 聲音完全同步, 走到哪都飽滿均勻,舒服!這篇紀錄架構,核心設計,和關鍵採坑點。音效底層改用Linux PipeWire 系統設定 主控端採用Proxmox架構,拆分虛擬機與容器 公播主控(LXC / Ubuntu 26.04 LTS / music) 音訊源:spotifyd(GRP-ALL-PLAYER) 輸出:snapcast server,對全網廣播 節點 1(VM / Ubuntu 26.04 LTS / musicRed) 硬體:直通USB藍牙Dongle連線紅喇叭 輸入:spotifyd(UE-RED)與snapcast client(廣播) 輸出:PipeWire 混音後送進藍牙 節點 2(VM / Ubuntu 26.04 LTS / musicBlack) 硬體:直通專屬 USB 藍牙 Dongle 連線黑喇叭 輸入:spotifyd(UE-BLACK)與snapcast client(廣播) 輸出:PipeWire混音後送進藍牙 關鍵設定:藍芽連線 避免無腦重連,藍芽音箱斷線才重新連線 WirePlumber Headless 藍牙關鍵設定(關閉 Seat 偵測) 預設的 WirePlumber 會監聽桌面登入狀態(Seat 偵測),在無螢幕的 Server 環境下,沒有實體使用者登入而拒絕啟用藍牙 Audio Sink Snapcast server/client snapcast會讓server/client彼此對時,持續追蹤;會把1秒的聲音灌入client,足夠穿越網路,應付藍芽重傳;時間差不大就resample追上,差很大就快速跳躍追趕 實測重新開機,或是喇叭中途開關,都能在幾秒內追上 每新增一顆喇叭,就是多一台電腦(虛擬機或是pi),裡面執跑snapclient連接喇叭,可以擴展 單機雙藍芽Dongle翻車 原本曾嘗試在同一台 Linux 接兩顆藍牙 Dongle 同...

瘋系列SUPER TAIWAN超級台灣大滿貫

圖片
一切的起點是 2024雙塔520 ,從凌晨12點騎到2點,在屏鵝公路差點被風吹歪,嚇死人;三個月後騎 瘋系列 東三塔,集滿四塊獎牌湊滿台灣,然後換一面大的 2025東三塔 (O) 2025中雙塔, seg1 , seg2 (O) 2026東三塔 2026環台賽, seg1 , seg2 , seg3 (O) (O) 2026瘋911 瘋系列的活動都 比較辛苦 一點,我得練身體,研究路線,規劃補給;苦不堪言的片段總是讓人印象深刻:酷熱,低溫,暴雨,體能爆掉,熬夜想睡,熱到抽筋,逆風到定格。騎到終點的成就感也是難以言喻 要集滿四塊牌子,兩年來固定踩檯維持體力,輕度脂肪肝幾乎完全消散,再苦都值了

ESP32的韌體更新

圖片
緣起 用ESP32做好的玩具,部署到遠方得提供韌體更新服務。這篇幫 通用資料紀錄器 新增最簡單的韌體更新 用電腦把update.bin(新韌體)放入SD卡 裝置上電,偵測SD卡有update.bin開始更新,每刷4KB閃爍LED,韌體看得到 更新完把update.bin更名成update.bin.done ESP32 SDK 預設採用單一factory分區,沒有韌體更新機制。這篇介紹怎麼加入雙 OTA 韌體更新,寫給未來的我讀(三兩下就忘了) 更改SDK Config vscode設定SDK的頁面,根據 板子WIKI ,這片開發版有4MB Flash,調整設定 調整分割表設定 選擇全客製化表格(我們自己掌控一切) 在專案root folder加入partitions.csv,ota_0 & ota_1是放APP的,尺寸是1.625MB。這裡可以設計Flash的布局 儲存SDK設定 不直接把sdkconfig存到版本控制,因為SDK進版,可能設定和順序都改了;到時候diff分不出是SDK改動,還是我們的設定改動 樂鑫建議的步驟:修改完開啟ESP-IDF Terminal 執行idf.py save-defconfig,他會比對差異,把更動寫在sdkconfig.defaults。這個檔案再寫入版本控制 從sdkconfig.defaults重建sdkconfig idf.py reconfigure 觀察軟體版本,執行的partition 在web介面多印一些資訊,之後能觀測韌體更新是否成功 印出當前的韌體資訊,包括git資訊,最後一次submit的hash,日期,時間;編譯的日期和時間,以及當前是跑哪個partition(把這些放標準printf()也可以) Source code如下 CMakeLists.txt新增"app_update"才吃得到對應header 韌體更新實作 在開機初始化的地方,安插底下的邏輯 需要在SD卡初始化之後才能執行 具體實作 檢查/sdcard/update.bin是否存在,不在就離開 跟OTA系統拿到 next partition,以及宣告開始更新 配置記憶體,讀檔,新韌體寫入Flash,以及每寫一塊讓LED閃爍 告訴OTA系統更新結束,計算checksum,以及下次開機切換成新的partition 重新...

ESP32的開機載入過程

圖片
緣起 我要把 ESP32通用資料紀錄器 加上韌體更新功能,不用都接上VSCODE重燒;理論上這些功能SDK都做好了,但是沒搞清楚來龍去脈總是不踏實,來解謎吧 我得搞清楚韌體的內容怎麼封裝到binary,儲存空間規劃,怎麼載入系統,這樣才紮實 code data-rw data-ro ESP32-C3的記憶體 先在 技術手冊 找到memory map,表格右邊是internal ROM/ SRAM,384K的internal ROM不小:放開機程式,基礎算法,底層協議核心;internal RAM,可以放高速執行的code,也可以放data,data & insntruction bus都有連過去 Internal RAM = 400KB = 16KB + 384KB。前面的16KB是boot ROM執行需要的資料,專門挖一塊;後面的384KB是使用者摸得到的資料區 上圖表格往左,兩塊8MB data & instruction存取External Memory,如下圖,CPU發出的addr先到達$,再經過MMU,最後走SPI0存取Flash,細節如下: Unified I&D$,8-way,16KB,32byte $-line MMU page size = 64KB,負責把CPU發出的vaddr轉成flash的paddr。透過MMU可以把軟體放在Flash的任意位置,但是CPU看出去都是固定的位址。其中一個應用是韌體更新,可以在Flash放上新舊韌體,任意一個都能執行 ESP32-C3有兩套SPI,SPI0是CPU專用,存取Flash開頭0~8MB的位置;SPI1存取同一顆Flash,但是能存取0~16M。比如我們放上大顆的Flash(16MB),透過SPI1存取8-16M,後面可能放影像,網頁這類的resources Linker Script 在build/esp-idf/esp_system/ld/memory.ld定義了內部的RAM & Flash,他們對應到上一節memory map的記憶體區塊 Instruction iram0_0_seg (RX), Internal RAM iram0_2_seg (RX), Flash Data dram0_0_seg (RW), Internal RAM drom0_0_seg ...

奢侈品策略

圖片
緣起 兩三年前,台灣單車教練 Vanden Cycling (我只知道臉書他的頁面名字)批判Rapha Cycling用時尚,奢侈品的方法賣單車衣服。裡面他舉了一本書, 奢侈品策略 。我花了很大的力氣讀這本書 我和愛馬仕 多年前有幸見過Hermes Birkin包,超高級的手提包。拿在手上,一台Toyota Altis就拿在我手上,要買還得過五關斬六將,有幸見過本尊,我增廣見聞了! 奢侈品的反傳統行銷法則 這是書上第三章,描述奢侈品的反傳統行銷的手法,我一字不漏的把標題全部打上 奢侈品不能比較 產品擁有足夠的缺陷嗎 不要迎合客戶 遠離缺乏熱情的客戶 不要回應增加的需求 主導客戶 不要讓客戶輕易購得 隔離客戶與非客戶,大客戶和小客戶 廣告的目的不是為了銷售 和非目標客群溝通 推測價格永遠高於實際售價 奢侈品需要定價,卻不能根據價格定義奢侈品 隨時間調高售價以提高需求 不斷提高系列產品的平均價格 不要推銷 廣告焦點不在人 為入門者培養藝術氣息 不要搬遷工廠 不要聘請顧問 不要事先測試 不要尋求共識 不要尋求集團合作 不要指望降低成本 慎用網路行銷 凡存在必有道理... 民主化以後,階級(法律上)消失了,但是人就是有分出高低的需要(先不管是否道德),可能是文化,可能是穿著,開的車子,小孩成績,健康檢查紅字數量,手提包 動物界也是,雄孔雀用色彩燦爛,看起來很累贅的羽毛,吸引雌孔雀交配。就是身體強壯的孔雀,沒有寄生蟲,營養良好,才能長出完美羽毛 在路上看到一台Colnago單車,這個昂貴信號,我就是接收到了 Garmin運動產品 Garmin EDGE 10x0是頂級的單車碼錶,我注意到牌價每一代會增加100美金,而且單車族群還買單,這個是了不起的成就! EDGE 1000,500USD,2014 EDGE 1030,600USD,2017 EDGE 1040,600USD,750USD(Solar)2022 EDGE 1050,700USD,2024 Garmin Fenix是運動錶的標竿產品,也是努力提高售價,而且越賣越好 Fenix 1,399,2012 Fenix 2,399,2014 Fenix 3,499,2015 Fenix 5,599,2017 Fenix 6,599,2019 Fenix 7,699,2022 Fenix 8,799,2024 Garmin高...

6G網路研究(3):MRSS

圖片
緣起 高通Blog 這張圖,最重要的結論是:6G網路開台,一開始就能連上現存的5G基地台,覆蓋率不是問題 還是從物理講起 無線電波的頻率越高,信號衰減得越快。如果部署6G只用U6頻段(Upper 6GHz) U6衰減得比C-band(3.5GHz)更快 在現有屋頂架基地台,每站覆蓋面積小,很多地方信號會收不到 所以一定得利用現存的5G基地台,不然資本支出太龐大 這題在5G推出那年,解了兩次 5G NSA,以4G網路為主,然後5G基地台作為補充,提高效率。這樣業者不用立刻採買5G核心網,用現有的設備推出5G服務 手機要顯示5G,得同時收到4G + 5G才能進入5G NSA;如果手機看不到5G網路顯示4G icon會被消費者罵翻(網路沒準備好就收錢) 一切都是為了顯示5G收到錢,在低頻段同時打4G & 5G信號,DSS(Dynamic Spectrum Share)技術讓手機覺得自己還有5G信號,本體是在4G頻段,體驗爛得徹底 DSS的問題是干擾:下圖右4G基地台打的參考信號(reference)會嚴重干擾5G。這東西正在 靜靜的退場 ;台灣的5G部署在n28(700M),n1(2100M),n78(3500M),有低頻拼覆蓋率,有本錢脫離NSA了 再來是6G的路徑 愛立信的blog 講得很通透 6G核心網(CN),愛立信認為是Evolved 5GC + new 6G capabilities。 愛立信的核心網產品,5G/6G是同一套軟體,6G新功能就是付錢買license 這個給運營商一條清楚的升級途徑:蓋好5G SA等於建設6G,設備可以繼續用 中華電信顯然買單開始建5G SA,當前採購的設備,日後能升級到6G 然後我最在意的覆蓋,因為6G能用5G的基站。所以6G開台,一開始就能共用現存的5G基地台,提供完整的覆蓋 4G/5G共用的DSS失敗,為什麼5G/6G共用的MRSS會成功? 4G信號跟5G信號根本不相容,干擾嚴重 4G信號 = user-data + 4G參考信號 5G基地台發送的資料,{user-data + 參考信號},注意大括號把東西封裝在裡面。所以要在5G/6G共享頻段非常簡單,井水不犯河水 {user-data + 5G參考信號} {user-data + 6G參考信號} 所以6G手機看出去,會是什麼呢? 會看到一堆5G/6G共享的頻段,反...