描述

什么

這記錄了我如何制作一個可以測量地面上積雪量的設備。它能夠使用小電池運行多年，在零以下 (Celcius) 溫度下生存，并使用 LoRaWAN 將測量結果傳輸到互聯網以進行進一步處理。

為什么

這個項目是出于必要而開始的——如果需要清理我們相當長的車道上的積雪，我希望我的起床鬧鐘能提前一個小時響起。在我多風的小鎮，我需要部署多個傳感器來應對積聚。

這可能有許多實際應用，包括

• 道路除雪
• 物業管理，避免倒塌
• 停車場
• 電網管理
• 機場維修

誰

我是電子健康領域的一名軟件開發人員，過去幾年我一直在業余時間研究電子產品和 3D 打印機。我喜歡分享我在本地創客空間的旅程，并撰寫了一些指南，主要是關于 hackster 和 element14。

如何

本指南將涵蓋創建低功耗傳感器設備的有趣步驟，并深入探討某些興趣點。這些原理可用于其他類型的應用，例如替代傳感器。我的編碼風格和方法揭示了我在軟件方面的背景。總是熱衷于學習。

在本指南中，我將提供數據表的鏈接。數據表可能聽起來并不令人興奮，但在嘗試突破硬件極限時卻是關鍵。

傳感器原理

我做了很多搜索，尋找其他人用來測量積雪的原理。這些是我的一些發現：

• 降雪融化
• 高度尺的視覺監控
• 雷達

這些都不符合可以使用電池使用多年的低成本設備。

我最終使用了超聲波傳感器。它實際上不能測量雪的深度，但是通過從已知的地面長度中減去讀數，可以推斷出它。

我使用的傳感器HRXL-MaxSonar MB7374專門設計用于讀取不同類型雪面特征的讀數。它還防水，防護等級為 IP67。

微控制器

我一直想嘗試一種新的 SoC，Seeed Studio Lora-E5 ，它具有小尺寸、LoRaWAN 無線電和低能量要求。Seeed Studio 慷慨地提供了樣品和 Lora-E5-mini 開發板。該項目不以任何方式贊助。如果概念驗證證明可行，我計劃申請 Seeed Studio 提供的PCBA 產品，以圍繞Lora-E5設計定制 PCB 。我找到了一個非常好的項目，只需進行一些修改，它就會成為我的靈感來源。作者查爾斯·哈拉德 ( Charles Hallard ) 幫助我解決了一些功耗問題。

能量源

傳感器和開發板將根據設備的總尺寸設定前提。我的目標是紐扣電池供電設備，但很快得出結論，這對于開發板來說是不可行的。我選擇了 AA 尺寸的電池，SAFT LS14500 。該電池可以安全地提供 50mA 的持續電流，高達 250mA 的脈沖電流，而不會因壓降而損壞電池。它可以提供幾年的運行時間，對于一個 PoC 來說綽綽有余。

拆箱 Lora-E5-mini

開發板手感堅固，帶有 USB-C 連接器。請注意，此連接器僅用于為設備供電和進行串行通信。您不能以這種方式對設備進行編程，因為您可能習慣于使用 Arduino 兼容板。但是，我能夠在幾分鐘內使用工廠提供的 AT 固件為我的 The Things Stack 應用程序配置它。完整的過程記錄在 wiki 中。

我將假定您具備 TTN 的先驗知識（我使用 The Things Stack Community Edition），如果您不走運的話，因為那里有很多很棒的指南。

微控制器編程

程序員

如前所述，開發板不能通過 USB 編程新固件。我以大約 35 美元的價格訂購了一個ST Link V3 (STLINK-V3SET) ，它允許我的計算機對微控制器進行固件編程和調試。你不能使用 USB-to-FTDI 適配器、Atmel-ICE 或類似的東西，我花了一段時間尋找明確的答案。

首要任務是通過 USB更新 ST Link ，需要創建一個 ST 帳戶。真的？！

然后我繼續構建隨附的 MB1440B 板，這樣我就可以實際訪問與 MCU 接口所需的引腳。

此外，我還花了一些時間弄清楚在編程器和開發板上使用什么引腳。我希望 Seeed wiki 能讓這一點更清楚，因為我不得不依靠放大連接圖片然后研究 MB1440B 數據表來猜測相應的引腳。

在 MB1440B 上，您會發現橫向擠壓成排的引腳。其中一組稱為 CN6，但很難閱讀和查找。檢查圖片。下表列出了通過 SWD 接口對 MCU 進行編程所需的連接器（復位是可選的）：

連接表 ST Link v3 <--> LoRa-E5-mini

Color | ST Link (CN6) | LoRa-E5-mini

Yellow | NRST | RST

Green | DIO | DIO

Purple | GND | GND

Grey | CLK | CLK

在此設置中，仍需要連接 USB-C 以提供電源和可選的串行連接。

寫設備應用

Lora-E5 包含來自 ST 的微控制器STM32WLE5JC 。我過去只使用 STM32（或與此相關的任何 STM 系列）進行過簡短的開發，因此我不得不決定使用工具鏈和 IDE 對其進行編程。我一直想測試Mbed-os 框架和 IDE并試一試。Mbed 提供了對不同類型硬件的抽象，隱藏了庫，并且應該讓您專注于編寫應用程序代碼。聽起來不錯！雖然我能夠在設備上編譯和運行它，但我并不喜歡 Mbed。原因有很多，但主要是 IDE 感覺太基礎了，缺乏重構支持，調試，例如 Charles Hallard 有一個很好的演練，告訴你如何設置它，如果你想試一試的話。

下一個明智的選擇是帶有用于 STM32WL 的 STM32Cube MCU 包和可選的 STM32 Cube Programmer 的 STM32 Cube IDE。我遵循了Lora-E5 wiki ，從擦除工廠 AT 固件開始，但無法編譯示例項目。事實證明示例項目已經過時，并且還基于用戶代碼嚴重交織在一起的模板。我收到確認這將在不久的將來更新，并且該回購已從我測試時的位置移動。

經過大量實驗和搜索后，我發現了一個不錯的存儲庫，其中包含最新的 LoRa-E5 代碼庫，并演示了在物聯網 (TTN) 上發送傳感器數據. 我做了一個叉子，花了很多晚上研究和調試代碼。乍一看，STM32 Cube IDE 令人不知所措。我過去使用過類似的 IDE，這幫助我建立了一個粗略的概覽。我發現最令人困惑并且在某種程度上仍然如此的是生成代碼和用戶代碼的混合。盡管我定期進行 git 提交，但我還是花了很多時間因為我的更改被覆蓋而感到沮喪。我學會了嘗試使用配置向導而不是在某些區域直接更改代碼的艱難方法。我對配置工具的許多方面仍然不滿意，但現在我對結果并不感到驚訝。

/* USER CODE BEGIN */
/* USER CODE END */

代碼的關鍵方面太多，無法詳細介紹，我將擴展一些。我希望您能夠編譯和運行該項目，如果是這樣，請使用調試器來理解代碼流。

調試設置

首先，確保您養成在調試模式和低功耗模式之間切換的習慣。這由 sys_conf.h 中的以下定義決定：

VERBOSE_LEVEL
APP_LOG_ENABLED
DEBUGGER_ENABLED
LOW_POWER_DISABLE
STATUS_LED_ENABLE

我使用最后一個來切換 LED 指示燈，但為了追蹤 LED 的所有可能使用，我將實際的切換注釋掉了。請注意，當通過 USB 進行串行通信時，您無法控制是否使用 LED，正如您在板原理圖CP2102N USB 橋上看到的那樣。這讓我有點頭疼，直到我發現在斷開連接時情況并非如此。

例如，如果您設置 DEBUGGER_ENABLED = 0 和 LOW_POWER_DISABLE = 0，任何調試嘗試都會很快超時。

我沒有找到在 STM Cube 內顯示串行輸出的方法，所以我使用具有正確波特率的Termite RS232 終端來捕獲通過 USB 的日志記錄。MCU 有多個 USART，USART1 用于日志記錄，可以通過 USB 或 LoRa-E5-mini 引腳 TX（SoC 上的 PB6）讀取。

LoRaWAN 配置

繼續，您需要通過新設備注冊來設置您自己的 LoRaWAN 設置。通過在 STM32CubeIDE 中打開 .ioc 文件，選擇 Middleware-> LoRaWAN -> LoRaWAN comissioning 來使用配置工具。不要直接寫入 se-identity.h 文件，因為它會被覆蓋。

• “App/Join EUI”映射到 LORAWAN_JOIN_EUI
• “應用程序密鑰”映射到 se-identity.h 中的 LORAWAN_APP_KEY
• “網絡密鑰”映射到 LORAWAN_NWK_KEY 出于安全原因，無論如何不應使用“靜態設備地址”，因此不會使用網絡和應用程序會話密鑰。

• TTN "AppEUI" 對應中的LORAWAN_JOIN_EUIse-identity.h
• TTN "DevEUI" 對應中的LORAWAN_DEVICE_EUIse-identity.h
• TTN "AppKEY" 對應 LORAWAN_APP_KEY 中se-identity.h

經常出現的問題是：如何在不公開私鑰的情況下在公共代碼存儲庫上跟蹤我的項目？一個選項是提交一個帶有假值的配置版本，停止在 git 中跟蹤文件，并更改為真實值。這帶來了一些問題：如何在其他計算機上繼續開發該項目，甚至在以后接手該項目時確保保持正確的值？另外，如果配置文件包含我實際想要更改和共享的其他設置怎么辦？我愿意接受建議。

編輯：感謝我的同事 Erling 推薦GitHub Encrypted secrets 。

我決定在開發期間提交我的密鑰，然后在發布之前重新生成它們。

與傳感器接口

我研究了MB7374 數據表以了解它的許多方面和選項。建議通過引腳 5 讀取測量值以確保準確性，因為它提供 TTL 輸出。啟動并打印產品信息后，它將以連續模式輸出每個測量值，作為一串以“R”開頭的 ASCII 字符，后跟使用 4 位數字的以毫米為單位的到表面的距離，例如“R0928”，對應于 92.8 厘米。我在 STM32 上使用 9600 波特率的 USART2。

6HRXL-MaxSonar-WRST7
MB7374-1XX
Copr. 2011-2019
MaxBotix Inc.
RoHS 23b 119 0819
TempI
R0937
R0937
R0936
R0936
R0936
R0936

TempI表示使用內部溫度計。

注意：對于雪地應用，建議使用 5v 電源以實現 MB7374 的最佳運行。LoRa-E5-mini 上的穩壓器AP2112僅在電池供電時提供 3.3v（5v 引腳僅在連接 USB-C 時接合）。因此，這一概念驗證有望提供下一個版本是否需要為傳感器提供 5v 電壓的答案。

MB7374 引腳 5（串行輸出）連接到 LoRa-E5-mini 引腳 TX2（STM32WLE5JC 的 PA2）。請記住，串行只是輸出，不需要輸入。MB7374 引腳 7 (GND) 連接到 GND。我將 MB7374 引腳 6 (V+) 連接到開發板引腳 D0 (PA0)。待機狀態下傳感器的電流消耗太高，我決定在每次傳輸前使用 GPIO 來接通它。該引腳有一個用戶標簽 US_ENABLE（超聲波啟用）。我確保引腳可以提供足夠的電流，閱讀兩個數據表，也通過測量。更穩健的解決方案需要使用晶體管來切換傳感器。查看我的土壤水分指南以獲取示例。

LoRa應用

主要設備邏輯位于文件 lora_app.c 中。SendTxData只是啟用傳感器，獲取讀數并準備一個緩沖區，其中包含要傳輸的實際字節，傳輸，然后進入睡眠（停止 2 模式），重復。

項目 repo 包含用于 The Things Stack 的 Javascript 上行鏈路解碼腳本。

function decodeUplink(input) {
 var bytes = input.bytes
 return {
  data: {
   distance: ((bytes[0] & 0x80 ? 0xFFFF<<16 : 0) | bytes[0]<<8 | bytes[1]),
   temperaturec: ((bytes[2] & 0x80 ? 0xFFFF<<16 : 0) | bytes[2]<<8 | bytes[3]),
   voltage : (bytes[4]<<8 | bytes[5])
  },
 warnings: [],
 errors: []
 };
}

距離：到表面的距離，以毫米為單位。雪越多，數字越低。

temperaturec：這是 MCU 溫度。這不應該是對設備周圍環境的可靠測量，因為它旨在為某些 MCU 功能提供校準參考。該設備是防水的，進一步消除了對環境的敏感性。由于 MCU 做的工作很少，我仍然想看看它是否可以提供有用的數據。我在設備附近安裝了一個可靠的溫度傳感器，到目前為止它們報告的溫度非常相似。由于我的代碼中的一個錯誤，溫度值被報告為整數。

voltage：這應該是電池電壓，是電池即將耗盡的指標。這是使用生成的函數 SYS_GetBatteryLevel 檢索的。我認為這個函數是有問題的，因為它似乎報告了 MCU AREF。我將不勝感激關于如何實施的任何建議。

接收數據如果傳輸之后是 TTN 應用程序返回排隊的下行鏈路消息，則觸發。我已經實現了一個下行消息：傳輸間隔的配置。這使我能夠更改測量之間的分鐘數，從 0 到 65535。這允許最長約 45 天的睡眠時間。請注意，如果要更改間隔，請求將排隊等待下一次計劃的設備傳輸，所以要小心。在 The Things Stack 控制臺中，您可以通過導航到設備、轉到“消息”選項卡，然后轉到“下行鏈路”來對下行鏈路進行排隊。FPort 為 1，Payload 類型為 Bytes。您需要將分鐘數格式化為兩對十六進制數字，最高有效字節在前。例如“01FF”將對應于 511 分鐘。由于懶惰，設備應用程序需要兩對，

物聯網 CLI

一旦將數據路由到 The Things Network，有數以千計的選項可用于處理數據。我在以前的指南中介紹了一些。在本指南中，我想重點介紹一種使用 The Things Network 命令行界面 (CLI) 調查幾天的測量值的簡便方法。

啟用免費短期存儲集成并創建 API 密鑰。

按照安裝說明安裝 ttn-lw-cli 并創建配置，

ttn-lw-cli use 1/au1/nam1>.cloud.thethings.network

最后使用OAuth2.0 登錄。

ttn-lw-cli login

現在您可以進行查詢以檢索消息。由于它默認使用 gRPC protobuf，除了冷啟動外，傳輸速度快如閃電。

ttn-lw-cli applications storage get "snowmonitor" --limit 10 --order "-received_at" --up.uplink-message.decoded-payload

將結果轉儲到一個 .json 文件中，您可以使用您最喜歡的繪圖工具在本地進行漂亮的可視化。

功率分析

在整個開發過程中，我積極使用我信賴的 Qoitech Otii Arc來測量和比較更改硬件和代碼時對電流消耗的影響。這使我能夠系統地嘗試不同的電源電壓電平、天線設計、代碼執行順序等。一些有趣的觀察：

• 讓 ST Link 連接到開發板，但與計算機斷開連接會導致更高的電流消耗。這促使我堅持進行測量，每次都斷開 ST 鏈路。

• 自適應數據速率 (ADR) 需要一段時間才能優化。在我的設置中，我不得不等待大約 4-5 次傳輸以確保它已經穩定下來并且我正在比較蘋果與蘋果。在我的設置中，這是 DR5 (SF7BW125)。

• 一個簡單的 8.6 厘米線天線的性能確實不如隨附的鞭狀天線。
• 一種可能的硬件設計在以 HF (868MHz) 傳輸時限制了非常低的功耗。
• 定期日志記錄（VLEVEL_OFF = 非詳細）對消耗沒有顯著的負面影響。
• 傳輸 UNCONFIRMED_MSG 似乎消耗更多電流 - 值得研究實施。
• LoRa-E5-mini 在最小 2.5v 穩壓器輸入電壓下掉電。對于與 LS14500 電池一起使用，這很好，因為它具有非常平坦的放電曲線。

為了您的觀賞樂趣，電源配置文件包含在回購協議中。

總之，我在睡眠期間實現了大約 73uA 的電流消耗。雖然與 SoC 宣傳的 2uA 速率相去甚遠，但這對于 PoC 來說還不錯。開發板調節器可能占了大部分多余部分（數據表：通常為 55uA），其余部分為浮動引腳等。

傳輸峰值約為 80mA，參考。HF 問題。大約消耗 7uWh pr。傳播。使用一個簡單的計算器可以告訴我們，在這種情況下，每 15 分鐘傳輸一次與每 60 分鐘傳輸一次相比，差異微不足道。前者粗略估計電池壽命超過 3.5 年，遠遠超過設計定制電路之前進行測試所需的時間。

計算機輔助設計

這種概念驗證顯然需要在相當惡劣的條件下進行戶外測試。我花了一半的項目時間來設計防水外殼并使用樹脂 SLA 打印機 3D 打印它。容納天線和傳感器是一個很大的挑戰，我最終設計了一個外殼，允許電子設備在擰入傳感器的同時旋轉。橡膠墊圈提供密封。

我首先對所有重要組件進行建模，這樣可以節省大量迭代。

傳感器采用奇怪的美國標準螺紋，NPT 美國錐管螺紋 (ANSI B 1.20.1) ，3/4"-14。什么？！我花了很多時間試圖在 Fusion 360 中打一個匹配的孔，終于finding a plugin that would help. 每次更新 Fusion 360 時都需要安裝此插件，非常蹩腳。

最終結果看起來就像光劍生了一個帶管炸彈的孩子，但它似乎達到了目的。

3D打印

我相信這可以使用質量穩定的 FDM 打印機打印，但我認為您需要使用樹脂涂層將其密封。使用優質 SLA 打印機（例如 Formlabs Form 3）的結果是打印過程非常順利。我需要做一些迭代，因為我還沒有弄清楚線程，我想添加一些文本以防它丟失。作為一項額外措施，我在天線開口周圍添加了一些藍色螺紋鎖固劑。

結果

該設備已運行 14 天，傳輸了 1903 次測量值。令我驚喜的是，傳感器并不像我擔心的那樣依賴與表面的直角。表面粗糙度似乎可以反射足夠多的聲波。它一直保持干燥，這是我另一個非常關心的問題。我計劃讓傳感器測量更長的時間，然后返回平均值以提高準確性。我還必須制作一個更大的帽子來防止積雪，正如在一場特別嚴重的風暴中觀察到的那樣。

?

最后的想法和下一步

我曾希望嘗試使用紐扣電池為裸露的 LoRa-E5 芯片供電。發現高頻傳輸期間電流消耗的高尖峰促使我推遲使用電容器的實驗，直到這個版本的 PoC 完成。定制的紐扣電池供電 PCB 將為減小整體設計的尺寸和復雜性帶來巨大機遇。