文章總列表

ANT+找樂子（2），解析心跳感應器和封包

整活啦

ANT+ Device Profile，Heart Rate Monitor規格，心跳傳輸的速度約4Hz。上一篇範例程式速度怎麼搞都很慢，問Grok AI，或是Chatgpt答案都很怪，這種冷門知識還是得靠自己。這篇要講心跳表的定義，以及怎麼用openant讀出數值


心跳表的規格

  • RF頻率 = 2457Mhz（下表的57代表2400Mhz + 57Mhz）
    • 心跳表用哪個頻率是規定好的
  • 訊息發送間隔是32768/8070=4.06Hz，大多ANT+感應器操作在4Hz附近
  • Device Type是0x78，Transmission Type=1


為什麼Message Period不設定成8192（4Hz）

為了避免無線電波碰撞。ANT+讓每個裝置頻率略有不同，就算發生碰撞也是短時間，稍後還是會錯開。這個是很有智慧的設計！


直接操作Channel

不囉唆，直接上code


  1. node = Node(), set network key
    ANT+的公開鑰匙，幾乎99%的ANT+裝置都用這把鑰匙
    ANTPLUS_NETWORK_KEY = [0xB9, 0xA5, 0x21, 0xFB, 0xBD, 0x72, 0xC3, 0x45]

  2. new_channel，開啟host（電腦）和裝置的通道，這個通道是雙向的
    幾乎所有範例都是雙向，直接抄

  3. set_period(8070)
    根據上表，心跳表的週期是8070照著設定

  4. ch.set_id(54345, 120, 241) # GARMIN WATCH
    ch.set_id(49528, 120, 1) # Magene
    上述的code，連接Garmin Watch或是Magene心跳帶都可以

  5. ch.open()
    node.start()
    開始和ANT+裝置溝通

  6. finally:
        node.stop()
    如果按CTRL+C，有機會能正確結束程式。不然在MAC經常要插拔Dongle才能恢復


解析ANT+封包

來自規格書的照片先來一張，中文資料

  • byte0[bit7]叫Toggle bit，ANT+經常會重送資料以免接收端漏收，招數很土，但是有用
    因為會重送，所以當封包內容改變，toggle-bit會變化；這樣接收端就能判斷是資料有變

  • byte0[bit6:0]叫page，這裡是一個編號，代表後面byte1~7怎麼解析。解讀方法看規格書。以心跳帶來說，page0是最重要的讀數

  • byte1~3未使用，設定成0xFF

  • byte4~5，這次心跳的絕對時間，單位是1/1024s。拿鄰近兩個封包比對，就能知道兩次心跳時間差。假如心跳每分鐘200下，相當於每秒3.33次，時間間隔約300ms，對上1/1024s的單位是非常細緻的

  • byte6，心跳的編號，每次心跳都會讓內部計數器（counter）累加。可以用來偵測是否有封包漏掉

  • byte7，計算過的每分鐘心跳，可以直接拿來顯示；也可以拿上述byte4/5/6，搭配前後筆資料計算


實作

理解封包意義後，寫一小段軟體解讀不是很難。我猜做單車碼表的公司，都會有RD專門搞定各種sensor，順便也得處理傳輸不穩時，怎麼平順的顯示數據


結語

身為通訊工程師，寫寫通訊的軟體也是別有一番滋味


留言

張貼留言

這個網誌中的熱門文章

STM32 UART + DMA，使用HAL實作TX/RX，以及不定長度接收

圖片
前言 我一般用Segger-RTT來debug。不過這東西也有限制，比如MCU進出sleep mode，他的data stream就會斷掉，也是不方便 http://lihgong.blogspot.com/2016/05/segger-rtt-1.html http://lihgong.blogspot.com/2016/05/segger-rtt-2.html http://lihgong.blogspot.com/2016/05/segger-rtt-3_6.html 我不是很喜歡UART，根本原因是把他 用好 其實不容易。當年選用Segger RTT其實就是要逃避這題（笑）；很多年過去了，總是要回來解決這題 STM32 HAL UART driver足足有3726Lines，這代表他的複雜度。假如UART跑在115200bps來說，傳送1byte需要約100us，假設CPU跑在16Mhz就需要1600T。簡單用Polling mode丟資料（或是接收資料）效能很悲劇；用了中斷模式會好一點，但是每個字元都來中斷，遇到高速UART其實效率也不大好；這題的根本解法是需要DMA mode 這篇我會介紹怎在使用STM32CubeIDE，把UART+DMA mode跑起來，TX/RX都有，實作我心裡最佳的框架。這篇直接講結論和步驟，原理很複雜，但是架起來卻很簡單 環境 STM32CubeIDE 你改用STM32CubeIDE了嗎？如果還沒，可以試試看；我用起來很滿意！ Nucleo F411RE Board 上面有ST-LINK加開發版，帶條USB線就能出去玩；缺點是MINI-USB線有點討厭 MobaXTerm 好用的Terminal工具，可以連SSH/ RDP/ Serial Terminal UART-TX設定步驟 STM32CUBEIDE設定UART，關鍵是要打開UART中斷，以及打開TX/RX的DMA Enable UART IRQ Enable UART DMA channels 假如要傳送資料，這一段code能幫上忙。這裡面有個資料結構內藏ring-buf，每次user要寫東西就往buf[]擺，並且更新wptr；資料擺上去會呼叫UART HAL library的API來傳送；或是DMA傳送完了，也會檢查還有沒有剩下的要傳。因為有Global variabl...
Read more »

小米掃地機器人S20+ review

圖片
貓吉與新的掃地機器人 初代小米掃地機器人 我的初代機是 2017四月上市 購買，報價8895元。八年來出動4269次，執勤2130小時，非常耐用 換過不少耗材，模組化設計，幾乎什麼都買得到 常見耗材：主刷，濾網，邊刷 不常見耗材：行走輪，雷射感應頭，主刷馬達，電池*3 經過八年以後，機器開始會不大可靠，也別再逼他了 不容易啟動，似乎馬達需要啟動幾次才開始動 充電失敗，有時候抱怨充電異常，有時候是充電座沒電 小米掃拖機器人S20+ 前一台表現良好，我決定再買一台；我偏好簡單的機器（比較不會壞）。官網有兩台，我分不出明顯的差異，所以買貴的，價格都比8895便宜 S20 ：4495 S20+ ：6795 使用體驗，都過八年了，變厲害也不過分 基於全室地圖運作 初次使用建立地圖後，可以針對某個區塊掃地或拖地 舊機器每次都是獨立事件，沒有房間的概念 機器比較安靜 睡前按下去掃，噪音不影響睡覺，睡醒就掃好了 拖地功能 平常不用。額外多買了抹布，每個房間拖完換下一條抹布，用抹布海解決問題 除塵盒改善 多了初級濾網，沒讓高階濾網直接碰灰塵；比較好清洗 速度 似乎掃得比較快 電力 似乎有改善耗電量，能用較低的功耗，達成一樣的效果 辨識功能加強 能辨認地毯，並且經過時增強吸力 希望這台機器能像小米初代機一樣耐操。舊的機器還是能當救援投手，每天掃貓砂
Read more »

玩CAN bus的傢伙們 (1) CandleLight-based USB-CAN

圖片
硬體介紹 要玩CAN bus，準備一條USB-CAN的線，搭配一台筆電就能樂無窮，我們就從這條線講起。這條線的檔次變化很大，這篇先從[最便宜]的版本說起 這上面其實就是兩樣東西 MCU:  STM32F042x6 or STM32F072RB CAN Transceiver:  NXP TJA1051/3 簡單看一下MCU的block diagram，關鍵是圖上紅框的CAN和USB介面，完成介面的轉換。我愛用的STM32 F103 C8T6也有這兩個介面，但是USB/CAN不能同時開；倒是比較低階的F0就沒這個限制 這東西的結構簡單，其實網路上很多來源都買得到這個硬體 https://github.com/HubertD/candleLight https://wiki.linklayer.com/index.php/CANtact https://canable.io/ TAOBAO 想要自己做可以參考這個 線路圖 ，很簡單 韌體介紹 最早Geschwister Schneider Technologie生產USB-CAN裝置（以下簡稱gs_usb），他的 Linux kernel driver 已經合入公版，各大Linux版本可以直接使用。驅動程式揭漏gs_usb通訊協定，於是有高手仿照通訊協定寫了 CandleLight FW ，燒入MCU後，電腦就認為這是gs_usb！ 分析一下FW的效能，這些介面轉換的東西，不掉封包是基本的需求。STM32F0的記憶體不大，只有16K，他的source code宣告QUEUE深度是64層 假設我們的封包都是8byte放到滿（沒放到滿時case，狀況更差了），不同CAN bus速度能承受的時間如下 1000Kbps, 1us per bit, ~100bit per packet = 100us, 64x = 6.4ms 500Kbps, 2us per bit, ~100bit per packet = 200us, 64x = 12.8ms 125Kbps, 8us per bit, ~100bit per packet = 800us, 64x = 25.6ms USB是主機主機端定期詢問裝置是否有封包要傳送，如果電腦USB很忙，比如正在傳輸檔案，能分到的頻寬就變少；或是CAN bus很滿，buff...
Read more »