設(shè)計多個傳感器的設(shè)備來檢測水中是否存在藻類

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

有害藻華 (HAB)

藻類是地球生命的基礎(chǔ)，是水生生態(tài)系統(tǒng)的基礎(chǔ)，也是通過光合作用產(chǎn)生氧氣的發(fā)起者。即使在今天，藻類也能產(chǎn)生地球大氣中 50% 的氧氣。所有藻類都無害。

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

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

水參數(shù)和HAB

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

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

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

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

如您所見，上述所有讀數(shù)（以及我沒有包括的溶解氧）在某種程度上與 HAB 的生長或 HAB 的存在有關(guān)。因此，使用這些讀數(shù)，我們可以預測有害藻類是否正在開花，并通知當?shù)毓矙C構(gòu)采取進一步行動。

原型制作

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

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

城鎮(zhèn)或任何組織都可以通過提供回調(diào)端點來訂閱實時通知。每次有新數(shù)據(jù)，都會發(fā)送到回調(diào)端點。

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

數(shù)據(jù)采集

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

pH,tds,turbidity,temperature,light

6.72,256.5,1.47,71.3,682

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

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 是領(lǐng)先的邊緣設(shè)備機器學習開發(fā)平臺，對開發(fā)人員免費。下面是來自一個 csv 文件的數(shù)據(jù)的樣子。

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

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

太陽能板

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

3.7V 2400mAh 鋰電池。

Wio Battery Chassis 還配備 650mAh 3.7V 鋰電池。所以總?cè)萘渴?050mAh。

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

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

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

通過 Helium 發(fā)送數(shù)據(jù)

智能湖設(shè)備通過 LoRaWan 協(xié)議向氦氣控制臺發(fā)送數(shù)據(jù)。每個設(shè)備都在 helium 控制臺中配置并與 AWS IoT 核心集成，以便將數(shù)據(jù)轉(zhuǎn)發(fā)到 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 核心接收到數(shù)據(jù)（在氦控制臺中完成的配置主題中），創(chuàng)建的 IoT 規(guī)則涉及傳遞值的 lambda 函數(shù)。

儀表板

開發(fā)者門戶和與第三方機構(gòu)的集成

通常我們構(gòu)建的系統(tǒng)可以產(chǎn)生良好的數(shù)據(jù)，但大多數(shù)時候我們可以利用這些數(shù)據(jù)，因為第三方應(yīng)用程序無法利用這些數(shù)據(jù)。我們考慮了這個問題并設(shè)計了一個“eventer”系統(tǒng)，它可以很容易地通過 REST api 與外部應(yīng)用程序集成。

公共衛(wèi)生機構(gòu)或當?shù)厥姓d系統(tǒng)等外部應(yīng)用程序可以通過提供回調(diào) url 和電子郵件來注冊接收來自“智能湖”系統(tǒng)的事件。此回調(diào) url 必須是“POST”api。每次有來自設(shè)備的新數(shù)據(jù)時，都會發(fā)布到回調(diào) url。如果“Smart Lake”系統(tǒng)無法發(fā)布消息，將通過電子郵件通知集成商。

?

?