设计多个传感器的设备来检测水中是否存在藻类

我们正在设计一种配备多个传感器的设备，以检测水中是否存在藻类，并为城镇居民提供实时更新。该设备应部署在我们镇湖泊的多个地方，居民应获得实时更新，以免发生此类事件。

有害藻华 (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”系统无法发布消息，将通过电子邮件通知集成商。