我們正在設計一種配備多個傳感器的設備，以檢測水中是否存在藻類，并為城鎮居民提供實時更新。該設備應部署在我們鎮湖泊的多個地方，居民應獲得實時更新，以免發生此類事件。

有害藻華 (HAB)

藻類是地球生命的基礎，是水生生態系統的基礎，也是通過光合作用產生氧氣的發起者。即使在今天，藻類也能產生地球大氣中 50% 的氧氣。所有藻類都無害。

有害藻華 (HAB) 一詞的出現是由于光合生物世界中的次要參與者，尤其是淡水湖泊、水庫、河流和溪流中的有毒藍綠藻，以及佛羅里達赤潮甲藻Karenia brevis等有毒硅藻和甲藻在沿海環境中。“有害藻華”描述了這些問題物種的過度生長，被認為是有害的，主要是因為它們能夠產生毒素。

藍藻，也稱為藍藻，自然存在于康涅狄格州的湖泊和池塘中。這些微生物經常被忽視并且不會造成傷害。然而，當養分負荷超過一定水平時，水體可能會出現令人討厭的藍綠藻大量繁殖，可能會產生和釋放毒素。當藍藻大量釋放毒素時，利用水體進行娛樂的人和動物都會受到影響。重要的是要注意，并非所有的藻華都是有害的藻華 (HAB)，但如果沒有更詳細的評估，就不可能確定藻華中的藻類類型。[來源] 所以避免接觸水是人類和寵物最好的預防方法。因此，任何藻類水華形成的早期檢測都是非常有幫助的。

水參數和HAB

以上所有參數都與有害藻華直接或間接相關。HABs 是光合作用的——它們使用二氧化碳、水和陽光來產生葡萄糖和氧氣。這個過程減少了水中溶解的二氧化碳（碳酸，H2Co3），提高了水的 pH 值。已觀察到 HAB 水的 pH 值達到 8 至 10。

研究表明，變暖的水（最好在 60 到 80 華氏度之間）有利于藍綠色 HAB 的生長。在美國東海岸，有害的藻類大量繁殖從仲夏到初秋。

濁度是衡量水透明度的指標，懸浮在水中的物質減少了光通過水的通道。雖然濁度不是 HAB 的原因，但它是在檢測到水華存在后對水華強度的定量估計。

產生的葡萄糖（碳和氫）不足以供微生物生長。氮、磷、硫、維生素和其他微量營養素是從環境中獲取的。水中這些物質的存在會增加 TDS 的讀數。因此，高 TDS 表明情況良好。

如您所見，上述所有讀數（以及我沒有包括的溶解氧）在某種程度上與 HAB 的生長或 HAB 的存在有關。因此，使用這些讀數，我們可以預測有害藻類是否正在開花，并通知當地公共機構采取進一步行動。

原型制作

這必須建立在低功耗微控制器上，但在原型設計期間，我們使用的是 Wio 終端。TDS（總溶解固體）傳感器、濁度傳感器和 pH 傳感器連接到 MCU。每小時讀取一次，并通過 Helium 網絡傳輸到 AWS 云。設備還運行 tinyML 模型，以根據捕獲的傳感器值預測正常與危險水的狀況。

Lora 模塊（Wio Lora Chassis）連接到 Wio 終端，以實現 MCU 和 SenseCAP 數據專用熱點之間的連接。有一個儀表板網站，其中每個設備都被映射并顯示實時數據。

城鎮或任何組織都可以通過提供回調端點來訂閱實時通知。每次有新數據，都會發送到回調端點。

除了傳感器和閱讀外，要考慮的一件主要內容是功耗。為了最大程度地減少功率使用情況，該設備將每隔幾個小時發送數據，并在其余時間內進行深度睡眠。太陽能電池板也被考慮在內。一旦原型成功，我想參與我們的城鎮并部署這些設備，讓我們的湖泊變得智能。

數據采集

一旦連接了所有傳感器，我們就開始訪問附近的水體并收集數據。來自死水湖的樣本數據如下。

pH,tds,turbidity,temperature,light

6.72,256.5,1.47,71.3,682

目標是收集盡可能多的數據（有和沒有藻類）。由于項目提交的時間限制，到目前為止，我們收集的數據有限，但這應該足以構建原型。我們需要繼續努力收集越來越多的數據。

We have programmed the Wio Terminal's top 3 buttons ( A, B & C) to collect data as csv ( comma separated value ) file.

A= Normal

B= Warning

C = Danger

Tiny ML

As you can understand all the parameters explained above are related to presence or growth of HAB but building an alerting system based on combination of values is a nightmare. We will be talking about hundreds of IF-ELSE condition in the program and keep updating the program when new set of data is observed. Machine learning makes perfect sense here. We collect data from water where there is no HAB and where we have. Then train the model and predict.

我使用Edge Impulse來收集、標記和訓練模型。Edge Impulse 是領先的邊緣設備機器學習開發平臺，對開發人員免費。下面是來自一個 csv 文件的數據的樣子。

對于 DSP，我選擇原始數據作為入門，Keras 作為學習塊。

老實說，雖然模型是經過訓練的，但創建的數據集非常有限。我們將在設備上閃爍程序，但最初可能無法正確預測。這就是為什么在部署后從真實環境中收集數據很重要的原因。

太陽能板

12V 3W 太陽能電池板，尺寸為 145mm x 145mm。

3.7V 2400mAh 鋰電池。

Wio Battery Chassis 還配備 650mAh 3.7V 鋰電池。所以總容量是3050mAh。

太陽能電池板電流 = 3W % 12V = 0.25A = 250mA。

總充電時間 = 3050 % 250 = 12.2 小時。這是一個粗略的估計。所以我們的目標是讓設備至少用電池運行一周，這樣我們就可以永遠用太陽能運行設備。

在這個原型設計過程中，我使用了帶顯示屏的 Wio 終端，這肯定會消耗大量電力，并且在實際部署時不需要。我們應該關閉顯示器，我們應該使用“深度睡眠”，以便設備每隔一段時間（每小時或每 3 小時或每 12 小時）運行一次，這將消耗更少的電量。

通過 Helium 發送數據

智能湖設備通過 LoRaWan 協議向氦氣控制臺發送數據。每個設備都在 helium 控制臺中配置并與 AWS IoT 核心集成，以便將數據轉發到 AWS 云進行進一步處理。

Once device is created on helium console, we need to create a label, attach a function to the label and create a flow to connect to AWS.

These steps are documented in one of my past projects. Check out this link.

Also checkout helium documentation for step by step guide to create AWS IoT topic here.

Device is sending 64 bit encoded string which is decoded by helium integration function before sending to AWS. Code can be found in my github repo.

Application Architecture

The system is designed keeping "serverless first" approach in mind. It's no-brainer that server less architecture makes perfect sense here as it can scale automatically as load increases.

一旦 AWS IoT 核心接收到數據（在氦控制臺中完成的配置主題中），創建的 IoT 規則涉及傳遞值的 lambda 函數。

儀表板

開發者門戶和與第三方機構的集成

通常我們構建的系統可以產生良好的數據，但大多數時候我們可以利用這些數據，因為第三方應用程序無法利用這些數據。我們考慮了這個問題并設計了一個“eventer”系統，它可以很容易地通過 REST api 與外部應用程序集成。

公共衛生機構或當地市政廳系統等外部應用程序可以通過提供回調 url 和電子郵件來注冊接收來自“智能湖”系統的事件。此回調 url 必須是“POST”api。每次有來自設備的新數據時，都會發布到回調 url。如果“Smart Lake”系統無法發布消息，將通過電子郵件通知集成商。

?

?