又怎么了 多少钱是的，今天我们将再次谈谈广受好评的Winsen MH-Z19二氧化碳传感器。 不，不会重复*。
*差不多
您可能已经注意到，有关该房间中高浓度CO2的危险的
恐怖故事经常出现在此资源的页面上。 并且尽管声称浓度高于1000 ppm会导致地狱和死亡被稍微夸大（
维基百科说，至少有些影响始于1％，即10,000 ppm，而传感器的整个范围为5000 ppm）-CO2可以用作由于通风不足而存在其他不良情况的指示。 因此，我也决定加入迷人的二氧化碳测量世界，并掌握了上述传感器。
当然，第一件事就是将其连接到arduino。 我从
文章中复制了代码（进行了必要的更改），珍惜的数字出现在屏幕上。
但是，当我复制它时，一条令人怀疑的蠕虫蠕动了我的灵魂-为什么此传感器会发出9个字节，而其中只有2个字节用于解释CO2？ 也许他想告诉我其他事情？
互联网上的搜索使我找到了一个
有趣的页面 。 作者对MH-Z19进行了试验，并揭示了其对未记录（和记录）的命令的反应。 他还没有尝试所有的团队，因此我们仍有足够的空间来嬉戏。 这就是我们要做的。
首先，我们将与“经典”团队0x86（或简称为134）打交道，利用它我们可以得出CO2的浓度。 Revspace报告：
对命令0x86的响应通常如下所示：
0xFF CM HH LL TT SS Uh Ul CS
在哪里
CM是命令重复返回
HH / LL是CO2 ppm值，高/低部分
TT是摄氏温度加上40的温度。例如，当温度为25摄氏度时，TT = 0x41
SS是某种状态字节，此字节始终只有一位！
h / Ul是一些未知值，也许与压力有关？ 引导传感器后，它精确地从15000开始，然后通常稳定到大约10500。
CS是校验和
也就是说，传感器对此命令的响应还包含温度T（偏移40度）和两个未知的目标值-一个字节的S和两个字节的U。S取值为2度，传感器启动时的U值从15,000下降到略大于10 000
如何理解数字S和U的含义？ 当然，您需要绘制图形！ 在任何无法理解的情况下，绘制图表。
无聊的技术细节并绘制一个图形，将传感器的读数驱动到计算机中会很好。 我用Serial.println（）做的。 arduin每五秒钟轮询一次传感器，并将其读数写入USB-UART，剩下的就是在计算机上读取它们并将其保存到文件中。 我这样做（在Linux中）是这样的：
rlwrap cat | cu -l /dev/ttyACM0 > sensor_$(date '+%Y%m%d_%H%M%S').log
不要踢是的，我知道您只能执行cat / dev / ttyACM0> ..，但是由于某种原因，这对我而言并不总是有效，有时此命令会立即以静默方式结束。 我也喜欢给定的命令（rlwrap cat | cu -l / dev / ttyACM0），因为它允许您以交互方式方便地与微控制器通信（尽管在这种情况下不是必须的）。 当然，有更好的工具可用于此目的，但是不幸的是，我不知道它们。
在另一个终端窗口中，您可以实时观看此文件：
tail -f sensor_.log
事实证明，这样的数字：
... 1188 62 64 42 38 10790 1188 62 64 42 38 10790 1190 62 64 42 38 10790 1191 62 64 42 38 10790 1192 62 64 42 38 10790 1193 62 64 42 38 10790 1195 62 64 42 38 10790 ...
每行包含CO2，T，S，U（U重复两次-作为两个字节和两个字节的数字，不要问为什么）。
现在您可以构建图形。 我将使用ipython --pylab进行此操作。
y = map(lambda a: map(int, a.split()), open("sensor1.log", "r").readlines())
因此，CO2图：
原则上，这似乎是正确的。 悲伤只有周期性的爆发。 看来这是因为传感器只是躺在桌子上，微微的微风使它的读数丢失了。
温度：
我打开窗户的那一刻清晰可见。 旋转1-2度，这对于没有记录的机会来说还不错。 但是，如果我们回想起
NDIR传感器的原理，我们可以理解，不要期望内置温度计具有很高的精度。 这些仪器测量的是远红外范围内的光吸收，伊利希（Ilyich）的老灯泡用来产生这种光，您甚至可以透过窗户看到它每五秒钟点亮一次（这样的瞬间被KDPV捕获了）。 而且，该灯泡消耗大量能量，因此会加热整个传感器，而将其加热多少取决于气流的瞬时接合点。
我们处理最有趣的事情。 S值：
什么都没说 我也是 悲痛的是，我们在同一张图上绘制了二氧化碳和硫，并略有增加：
是的 现在一切都清楚了！ 当一切正常时，S为64，而当CO2传感器开始烤香肠时，其下降至4。因此，您可以使用S来找出传感器的感觉以及读数的准确性。
就像伞兵所说的，极值仍然是U：
不幸的是，叠加技巧在这里没什么用。 只能看到，正如revspace所承诺的那样，一开始它等于15,000，然后下降到10,000多一点（但是很长一段时间后它可能会下降一点）。 每天重复一次。
但是当我将传感器电源连接到5伏而不是arduino的3.3伏时，情况发生了变化：
arduino上的3.3伏特来自LP2985芯片，该芯片是160毫安的线性稳定器。 根据互联网上的文章判断，灯泡吃得差不多。 观察传感器时，值得注意的是，带有此电源的灯泡在比在5伏电压下更长的时间内会发亮。 U的值高出一半半。
出现以下假设-传感器自动确定点亮灯泡所需的时间，以获取足够的红外辐射，如果电流不足，则它将使灯泡燃烧更长的时间。 U的值仅反映灯泡的燃烧时间（或其他一些相关的值，例如消耗的能量）。
为了测试此假设，我们使用锂离子电池为传感器供电，这显然会产生更大的电流：
实际上，U有时会降至10,000以下！ 但是，这显然不是绝对的证明，而且24小时后，一切都几乎相反了。 因此，该假设只是一个假设，但我没有提出更好的建议。
UPD：亲爱的
unsvp 解决了 U值的
难题 。我请他发言：
在某些内部测量单位中，U值显然是每天测得的IR CO2吸收的最小值。
除了时间表，没有什么可添加的：
我为什么自己没有想到这个？ 一切都很简单。 我一次绘制了四个值的图形，并以此为基础。 但是有必要提取两个数量（如上图所示），然后面对大小为S的多余垃圾不会干扰感知。 不要重复我的错误。
也许我要补充一点：您在48小时内看到的步幅大于1000 ppm吗？ 这样自动校准了传感器。 在这种情况下，与校准前相比，U值下降。 显然，此期间的实际CO2浓度仅增加了。 由此得出的结论非常简单-U值不是一个非常“粗略的”吸收值，但已针对当前校准进行了计算，显然代表了当前和先前校准周期中最小读数的一些差异。
在我看来，总的来说，自动校准（至少以MH-Z19实施的形式）是邪恶的。 Revspace表示可以使用0x79：ABC逻辑开/关命令禁用它。
/ UPD好吧，有一个团队整理出来了。 现在该走得更远了，然后这篇文章即将结束，另外255个团队尚未经过测试！
在
revspace文章中，经过测试的命令列表如下所示：
命令0x89-0x8F
没有响应返回，但是命令0x8d似乎重置了传感器。
命令0x99（范围）
...
此外，人数较少的团队并没有全部通过验证。 因此，剩余的未知团队总数只占一半多一点。
事不宜迟，我决定随机发出命令（准确地说是伪随机地）。 这是我得到的：
... Command: 255 1 47 0 0 0 0 0 208 Response: 0 0 0 0 0 0 0 0 0 CRC: 00 CO2/t/s/u: 0 0 0 0 Command: 255 1 17 0 0 0 0 0 238 Response: 0 0 0 0 0 0 0 0 0 CRC: 00 CO2/t/s/u: 0 0 0 0 Command: 255 1 45 0 0 0 0 0 210 Response: 0 0 0 0 0 0 0 0 0 CRC: 00 CO2/t/s/u: 0 0 0 0 Command: 255 1 5 0 0 0 0 0 250 Response: 0 0 0 0 0 0 0 0 0 CRC: 00 CO2/t/s/u: 0 0 0 0 Command: 255 1 88 0 0 0 0 0 167 Response: 0 0 0 0 0 0 0 0 0 CRC: 00 CO2/t/s/u: 0 0 0 0 Command: 255 1 245 0 0 0 0 0 10 Response: 0 0 0 0 0 0 0 0 0 CRC: 00 CO2/t/s/u: 0 0 0 0 Command: 255 1 107 0 0 0 0 0 148 Response: 0 0 0 0 0 0 0 0 0 CRC: 00 CO2/t/s/u: 0 0 0 0 Command: 255 1 214 0 0 0 0 0 41 Response: 0 0 0 0 0 0 0 0 0 CRC: 00 CO2/t/s/u: 0 0 0 0 Command: 255 1 136 0 0 0 0 0 119 Response: 0 0 0 0 0 0 0 0 0 CRC: 00 CO2/t/s/u: 0 0 0 0 Command: 255 1 7 0 0 0 0 0 248 Response: 0 0 0 0 0 0 0 0 0 CRC: 00 CO2/t/s/u: 0 0 0 0 Command: 255 1 153 0 0 0 0 0 102 Response: 255 153 1 0 0 0 0 0 102 CRC: 102102 CO2/t/s/u: 256 0 0 0 Command: 255 1 146 0 0 0 0 0 109 Response: 0 0 0 0 0 0 0 0 0 CRC: 00 CO2/t/s/u: 0 0 0 0 Command: 255 1 72 0 0 0 0 0 183 Response: 96 249 2 211 215 212 17 215 204 CRC: 159204 CO2/t/s/u: 723 215 212 4567 Command: 255 1 51 0 0 0 0 0 204 Response: 93 151 80 143 212 255 255 255 217 CRC: 185217 CO2/t/s/u: 20623 212 255 -1 Command: 255 1 98 0 0 0 0 0 157 Response: 16 136 252 75 66 50 48 48 13 CRC: 9313 CO2/t/s/u: -949 66 50 12336 Command: 255 1 65 0 0 0 0 0 190 Response: 10 0 0 0 0 0 0 0 0 CRC: 0 0 CO2/t/s/u: 0 0 0 0 Command: 255 1 243 0 0 0 0 0 12 Response: 0 0 0 0 0 0 0 0 0 CRC: 0 0 CO2/t/s/u: 0 0 0 0 Command: 255 1 13 0 0 0 0 0 242 Response: 0 0 0 0 0 0 0 0 0 CRC: 0 0 CO2/t/s/u: 0 0 0 0 Command: 255 1 35 0 0 0 0 0 220 Response: 0 0 0 0 0 0 0 0 0 CRC: 0 0 CO2/t/s/u: 0 0 0 0 Command: 255 1 229 0 0 0 0 0 26 Response: 0 0 0 0 0 0 0 0 0 CRC: 0 0 CO2/t/s/u: 0 0 0 0 Command: 255 1 95 0 0 0 0 0 160 Response: 0 0 0 0 0 0 0 0 0 CRC: 0 0 CO2/t/s/u: 0 0 0 0 Command: 255 1 48 0 0 0 0 0 207 Response: 0 0 0 0 0 0 0 0 0 CRC: 0 0 CO2/t/s/u: 0 0 0 0 Command: 255 1 209 0 0 0 0 0 46 Response: 0 0 0 0 0 0 0 0 0 CRC: 0 0 CO2/t/s/u: 0 0 0 0 Command: 255 1 200 0 0 0 0 0 55 Response: 0 0 0 0 0 0 0 0 0 CRC: 0 0 CO2/t/s/u: 0 0 0 0 ...
这里的Command是发送给传感器的内容（命令编号本身是从头开始的第三个数字），Response是传感器回答的内容，您看不到其余的内容（CRC是计算得出的/实际校验和，CO2 / t / s / u是故障结果）传感器对四个数字的响应，就好像它对“默认”命令做出了响应一样）。
如您所见，数量不多。 而且，从某个时候开始，传感器完全拒绝给出零以外的任何东西。 我从传感器得到的最后一件事是：
Command: 255 1 134 0 0 0 0 0 121 Response: 0 0 0 0 0 0 0 0 0 CRC: 0 0 CO2/t/s/u: 0 0 0 0 Command: 255 1 130 0 0 0 0 0 125 Response: 242 98 200 201 207 216 178 130 33 CRC: 50 33 CO2/t/s/u: -14135 207 216 -19838 Command: 255 1 134 0 0 0 0 0 121 Response: 204 91 151 80 143 212 255 255 236 CRC: 93 236 CO2/t/s/u: -26800 143 212 -1 Command: 255 1 200 0 0 0 0 0 55 Response: 181 156 252 77 79 68 66 85 83 CRC: 241 83 CO2/t/s/u: -947 79 68 16981 Command: 255 1 134 0 0 0 0 0 121 Response: 13 10 0 0 0 0 0 0 0 CRC: 246 0 CO2/t/s/u: 0 0 0 0 Command: 255 1 216 0 0 0 0 0 39 Response: 0 0 0 0 0 0 0 0 0 CRC: 0 0 CO2/t/s/u: 0 0 0 0
然后为零。 我尝试按顺序输入命令，从0x8e-再次为零。 我试图给“标准”命令0x86-零。 我杀死传感器了吗？ 实际上，所有条件都存在-我输入了很少的未记录命令，因此我也将传感器接口直接连接到5伏arduine，尽管数据表明确指出它是为3.3伏设计的。
首先，我尝试了任何enikeyshchik的老方法-将其关闭然后再打开。 就是说，他拿出它，将其卡在传感器上，然后加上其他所有工作所需的电源。 传感器产生的结果与上一段引用的结果大致相同（但数字略有不同）。 是的，这意味着传感器并没有完全死掉，每次启动时都会说些什么，猜测是这样。
然后，我付出了更多的大脑，甚至在一个真相之前就已经猜到了-我们在上面看到的那些零根本不是传感器的答案。 实际上，传感器是无声的，我的程序绘制了接收n个字节的Arduin函数给出的结果（比如说零）。 而且，如果每次接待前都要确保有东西要拿，那就证明没有什么可以接受的。 除非传感器刚刚重新启动。
事实证明，传感器完全停止接受任何命令。 显然，串行接口上的5伏电压没有白费。 是的，文章没有提出任何疑问。 谢谢大家的关注。 我们不同意，没有什么可看的。
哦等等...
看到这些数字了吗？
13 10
看起来不一样吗？
当然，这是一个很好的旧
换行 ！ 换句话说，0x0D 0x0A-这是一种转换字符串的方式，例如在Windows上（在Unix上，它更容易-0x0A，因为某些文件在Windows笔记本中打开时丢失换行符）。
那么也许传感器想用人类语言告诉我们一些信息？ 但是，如果该语言是中文，那对我没有太大帮助。 因此，我们希望这是一种更易理解的语言，并根据
ASCII表对消息进行解码：
print reduce(lambda a, b: a + b, map(lambda a: chr(int(a)), "255 255 255 250 24 220 207 254 77 79 68 66 85 83 13 10".split())) MODBUS
收到多达六封信。 这是同一传感器在较早加载时所说的：
print reduce(lambda a, b: a + b, map(lambda a: chr(int(a)), "96 249 2 211 215 212 17 215 204 93 151 80 143 212 255 255 255 217 16 136 252 75 66 50 48 48 13 10 ".split())) ` ] P KB200
区别很明显-KB200行已更改为MODBUS行。 其余的-似乎根本不是文本，甚至不是汉字-仅仅是因为它们中的大多数会不时更改。
那么传感器告诉我们什么？ 应KB200的要求，互联网搜索产生了一个键盘，一个核心采样器，一个熨斗，一个尿布台，一个用于控制PTZ摄像机的控制器，一个调音台（秃头除外）。 好吧，但是尚不清楚如何将这种知识应用于我们的案例。 好吧，让我们寻找MODBUS。 这次，
维基百科本身为我们服务：
Modbus是基于主从架构的开放式通信协议。 它在工业中广泛用于组织电子设备之间的通信。 它可以用于通过串行通讯线RS-485，RS-422，RS-232以及TCP / IP网络（Modbus TCP）传输数据。
假设本身表明了自己-在未记录的命令之一之后，传感器切换到Modbus协议，现在它使用可用的方法将其告知我们。 由于没有其他选择，我们将直接检验该假设，即让我们尝试通过Modbus与传感器联系。
在Internet上，发现了针对arduins的Modbus
实现 。 但这真是不走运-不支持Arduino Leonardo，但是我只有Leonardo。
但是，正如我很快意识到的那样，这甚至是最好的。 Modbus协议只需三个便士。 并且除了痛苦地类似于“本地”协议MH-Z19。 那么，当您自己在两分钟（两小时）内实现所需的一切时，为什么还要从Internet上拖动任何讨厌的东西并痛苦地理解它呢？
因此，在较早的时候，我们想找出读数，要求传感器按如下方式发布它们：
0xFF, 0x01, 0x86, 0x00, 0x00, 0x00, 0x00, 0x00, 0x79
或十进制：
255, 1, 134, 0, 0, 0, 0, 0, 121
其中255是幻数，1是传感器地址，134是命令，121是校验和的字节。
在Modbus中会是什么样？ 不会有完全匹配的内容，但是您可以这样做，例如：
1, 4, 0, 0, 0, 4, 213, 197
1-传感器地址。
4-团队编号。 Modbus中的命令可以用手指指望，到目前为止，我们只对其中的两个感兴趣-3和4。由于隐藏在数百年的黑暗中的原因，它们被称为读取多个保持寄存器和读取输入寄存器，但实际上它们给出了读取给定命令的命令。给定地址的双字节数字的数量。 命令3读取可用于读/写的数字，命令4只读。
0，0是我们要读取的地址（在本例中为0）。 如果您以3或4为一组设置相同的地址，我们通常会得到不同的结果。
0，4-我们要读取的数字数（在这种情况下为4）。 这里有一个有趣的时刻。 尽管您可以指定最多65535个数字，但实际上，该协议允许您一次读取不超过125个数字。 所有这些都是因为响应指示发送的信息的字节数，并且仅占用一个字节（并且该数字为两个字节）。 另外，据我了解，响应本身的长度限制为255个字节。
213、197-校验和的两个字节（
CRC16 ）。 总的来说，这是我们整个实施过程中最困难的时刻。 实际上，我什至没有深入研究它的含义，只是
从此处复制了代码。 由于存在大量不同的CRC16，因此必须负责任地选择功能。 例如，您可以
在此处检查特定功能是否适合Modbus。
实际上，这就是我们需要了解的有关Modbus的全部信息。 至少是一个开始。
尽管您很早就猜到我对Modbus上的MH-Z19的吸引力是成功的，但让我们假装这种吸引力仍然存在。 到目前为止，我们甚至都不知道我们的传感器地址是什么（尽管“原始”地址是1，但与Modbus上的地址完全不同）。 因此，您需要使用不同的地址（只有255个）重复该命令，并查看我们的传感器将响应什么：
... Command: 254 4 0 3 0 1 213 197 CRC: 213 197 Response: Command: 255 4 0 3 0 1 212 20 CRC: 212 20 Response: Command: 0 4 0 3 0 1 192 27 CRC: 192 27 Response: Command: 1 4 0 3 0 1 193 202 CRC: 193 202 Response: Command: 2 4 0 3 0 1 193 249 CRC: 193 249 Response: 1 132 2 194 193 Command: 3 4 0 3 0 1 192 40 CRC: 192 40 Response: Command: 4 4 0 3 0 1 193 159 CRC: 193 159 Response: ...
看来地址是2。我用地址2重复了几个命令-没有答案。 我将地址更改为1-有答案！ 因此，传感器地址与-1相同。
为什么段落2到达地址2？ 在这里，我的代码的印度性再次出现。 发出命令后，我检查是否有任何字节要接收。 但是由于我马上执行了此操作，因此传感器没有时间发送任何东西，因此传感器响应仅在下一个周期被程序接受。 正如您在给定日志中看到的那样-答案中的第一个数字是1，它仅表示传感器的地址。 我通过在接收响应之前增加50毫秒的延迟来解决此问题。
考虑传感器对我们命令的响应：
1 132 2 194 193
1-我们已经发现-传感器的地址。
132-命令代码和错误代码。 如果没有错误，则此数字将与发送的命令相同-即4。但是发生错误，如最高有效位设置为1所示，因此该数字变为4 + 128 =132。因此，顺便说一句， Modbus中的命令不能大于127-对于这样的命令，成功代码将与错误代码相同。
2-错误代码。 准确说出是哪个错误。 正如Wikipedia所说，02-请求中指定的数据地址不可用。 因此，此地址没有鱼，也没有任何可捕获的东西。 我们将尝试其他地址。
194193-CRC16。
现在，最后是时候抓取传感器的地址空间，以了解鱼在哪里。 我这样做很简单-我发送了一个命令，每0.1秒读取一个带有新地址的数字。 因为地址是65536，所以此过程将在大约两个小时内完成。 结果简要如下：
命令1（读取线圈）-错误2，带有任何地址。
命令2（读取离散输入）-任何地址错误2。
命令4（读取输入寄存器）-错误2，带有任何地址。
小组3（读取多个保留寄存器）-在0到289之间的地址上提供成功。
用于写值的命令（例如6）似乎可以使用，但是似乎已记录的值很快被其替换。 但是我没有仔细调查这个问题。
因此，搜索范围缩小了-我们需要在命令3处输入数字，地址从0到289。可以从以下几行中获得传感器丰富的内部世界的概念：
Command: 1 3 0 0 0 64 68 58 CRC: 68 58 Response: 1 3 128 0 0 0 255 0 1 0 1 0 255 0 255 0 255 0 255 0 255 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 255 255 0 255 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 158 124 Command: 1 3 0 64 0 64 69 238 CRC: 69 238 Response: 1 3 128 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 27 165 Command: 1 3 0 128 0 64 69 210 CRC: 69 210 Response: 1 3 128 0 4 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 73 82 0 153 0 8 0 17 0 177 0 19 0 19 0 196 0 18 0 20 0 214 0 18 0 21 0 232 0 18 0 22 0 250 0 5 0 24 0 255 0 5 0 18 1 4 0 3 0 23 1 7 0 25 0 0 0 0 0 0 0 0 0 0 0 255 0 255 0 1 0 0 0 5 0 0 0 0 0 0 0 0 0 0 137 122 Command: 1 3 0 192 0 64 68 6 CRC: 68 6 Response: 1 3 128 165 165 0 165 0 0 255 255 255 255 255 255 255 255 0 15 3 232 0 100 0 90 0 0 0 63 128 0 0 255 0 15 0 5 0 10 0 5 0 5 0 30 0 15 0 0 0 20 0 40 0 60 0 80 0 100 0 0 0 5 0 5 3 232 255 255 255 255 165 165 0 165 0 0 16 3 0 6 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 163 198
没错，这些数字仅保存在归档文件中的地址255中。这里，同样，地址和命令为1 3，传输的字节数为128，末尾的两个字节为CRC，其他所有内容均为存储器的内容。
在所有这些辉煌中，我们显然对那些内容随时间变化的地址感兴趣。 在这里，传感器对我来说是两个新闻-好与坏。 很好-有这样的地址。 不好的是-只有261和264这两个。与“过去的生活”相比，一次命令给四个数字！ 我已经rolled之以鼻-我以为我可以使用所有内部变量。 好吧，两个两个。
是时候再次建立图表了！
地址261的值：
看起来像是二氧化碳的浓度。 当我尝试呼吸传感器时可以看到。 的确，最小值明显低于“参考值” 400 ppm，因此校准尚有许多不足之处。 传感器以某种方式被宣布已复活。
264的价值：
大致相同，只是比例不同且上下颠倒。而且这两个数量都在同一张图上：
一个自然的问题出现了-也许其中一个数量是来自ADC的“原始”值，并且传感器使用从方法将其转换为CO2估算值？如果是这样，这为重新校准和提高传感器的精度，以及可能将其用于其他目的提供了巨大的机会。这个问题（以及其他一些问题）的答案我们将尝试在下一个系列中得到。意见和建议被接受-在下一篇文章中还将如何模拟MH-Z19。是的，我不会承诺任何事情。