Grove - Gas Sensor V2(Multichannel) | Seeed Studio Wiki

[giscus[bot]]

Grove - Gas Sensor V2(Multichannel) | Seeed Studio Wiki

Grove - Gas Sensor V2(Multichannel)

https://wiki.seeedstudio.com/Grove-Multichannel-Gas-Sensor-V2/

[abramsba]

I know the guide says that this instrument can't give accurate quantitative measurements, but I'm having trouble making sense of the readings when using your library.

The carbon monoxide sensor after running for 3 days has a rather high voltage and is reporting that I live in a CO cloud of about 600 to 900ppm, which as far as I know would be absolutely deadly within minutes. This is using the library available in this post.

There are two other things which are rather disappointing as well. There is discussion on forums on trying to find ways to normalize the values and it doesn't seem like anybody has come to a conclusion on what the correct way to read the numbers is. The other thing is I had come across a library for version 1 of this board (Grove_MultichannelGasSensor.h) that is able to read out more types of gasses:

#include <Grove_MultichannelGasSensor.h>

...
  Serial.print(MiCS6814.get(CO));
  Serial.print(MiCS6814.get(NO2));
  Serial.print(MiCS6814.get(NH3));
  Serial.print(MiCS6814.get(C3H8));
  Serial.print(MiCS6814.get(C4H10));
  Serial.print(MiCS6814.get(CH4));
  Serial.print(MiCS6814.get(H2));
  Serial.print(MiCS6814.get(C4H10));
...

[MatthewJeffson]

Hi, it seems that some are missing in "tech support and product discussion" section. We have offered our users several communication channels to cater to different preferences and needs.
I am sorry that I can't help you more. But I will be really grateful if you solve it out and share you projects with us! :D
Thank you in advance!

[RaphTronic]

That's because their code does NOT report ppm, unlike what it displays on the screen and on the serial port in all their example sketches.
Instead, the code actually reports the STM32's ADC count for each sensor output voltage. From 0 at 0v to 1023 at 3.3v (ie 10 bit range).
Despite this issue having misled users for years, instead of fixing the sketches, a "qualitative, not quantitative" disclaimer was just added to their product pages.
Very poor way to address the user issues that their own code creates...

[abramsba]

Hi, it seems that some are missing in "tech support and product discussion" section. We have offered our users several communication channels to cater to different preferences and needs. I am sorry that I can't help you more. But I will be really grateful if you solve it out and share you projects with us! :D Thank you in advance!

Obviously a very late reply, but if you're so clueless about your own product why are you even selling it? This is borderline a scam.

[gmacario]

Obviously a very late reply, but if you're so clueless about your own product why are you even selling it? This is borderline a scam.

Please correct me if I am wrong, but I believe you have purchased the Hardware from Seeed Studio, not the software which is offered for free and under an Open Source license, so I do not quite understand why you claim you were scammed.

That being said, what @MatthewJeffson asked in his reply was if you figured out how to improve the software, and if so, to please share the instructions for everybody benefit.

This is just how Open Source works, by the way 😉

[abramsba]

Obviously a very late reply, but if you're so clueless about your own product why are you even selling it? This is borderline a scam.

Please correct me if I am wrong, but I believe you have purchased the Hardware from Seeed Studio, not the software which is offered for free and under an Open Source license, so I do not quite understand why you claim you were scammed.

You have a twisted idea of what open source means if you think makes it OK for a company to more or less blatantly lie about how their product works in the description of the hardware and not really make it transparent that the device will not operate as you think it does, especially for the price (almost above 40 euros!). If I'm going to put the effort in reverse engineering a product than I'll just spend a fraction of the price on individual sensors and then release outside of Groove.

That being said, what @MatthewJeffson asked in his reply was if you figured out how to improve the software, and if so, to please share the instructions for everybody benefit.

This is just how Open Source works, by the way 😉

No, it's not.

[devvjhaveri]

Hey! I was working on the smart nose project by Benjamin Cabe - https://www.seeedstudio.com/Tiny-ML-powered-Artificial-Nose-Project-kit-with-Wio-Terminal-p-4999.html - however, the multichannel gas sensor v2 is not recording any change in compounds when I place alcohol near the sensor. I have done the warming - up process and even tried to reset the Wio Microcontroller, but nothing is working. What should I do?

[Avinash-py]

Hi Devvjhaveri ,
First you should upload Firmware.uf2 (https://github.com/kartben/artificial-nose/releases/tag/1.0.0) with Training mode go with further process i hope it will work for you.

[bvernham]

Something seems to be off with the library. From what I can read, the STM32F030F4, which is included on the board is 3.3V and has a 12 bit ADC. So I think the ADC to vold conversions are incorrect. The libary pick 5.0 or 3.3V based on the platformed being compiled for but the sensor board is running a 3.3V per the schematic so #define GM_VERF 3.3 (the #define GM_VERF 5.0 should be removed). Also the #define GM_RESOLUTION 1023 I think should be #define GM_RESOLUTION 4096?

Any ideas?

[RaphTronic]

Agree w GM_VREF 5.0, that should be removed. 1023 seems right for this design. I forced a voltage on Vsensor for each sensor and read from 0 at 0v to 935 at ~3v. So between the STM32's firmware and the library they somehow use a 10b range.

These sensors will never work properly for someone trying to measure gas concentrations bc the board designer did not respect the conditions under which Winsen's datasheet is valid. Examples:

• the R divider is fixed on each sensor output (instead of variable per Winsec's design). So, unless they introduced an adc read calibration compensation in the STM32 after board assembly (doubt it), their Rs/R0 reference value in 'clean air' can't be Winsec's value of 1. Therefore making all Winsen's curves invalid for this board.
• 3.3v is used for the sensor output dividers instead of Winsec's 5V rqmt (can be compensated for but doubt this was done)
• The 102B's heater is powered by 2.5v instead of Winsen's rqmt of 1.8v (again, rendering all the 102B datasheet charts moot)

There are more issues too, including w Winsen's hilarious datasheet misses and errors. The above explains why many people who developed corrected code that implements Winsec's normalization & sensitivity curves still don't get correct results.

Cherry on the cake my board was displaying a strange VOC behaviour. Kept wandering, non repeatable values, etc. Found out that the corresponding adc pin on the STM32 was lifted and not touching the solder pad... How did that pass QA testing ?

Bottom line: this design can't ever be used for absolute measurements, only relative ones (ie seeing trends). Unless one redoes all the gas concentration tests performed by Winsen (clean air, low to high ppm, T & RH sensitivity, etc) on each board. Per Seeed's new stance in their product Warning box: 'only qualitative, not quantitative'.

Why they don't remove in all their example codes the "ppm" unit and replace it w "count" or something, is incomprehensible. This is what confuses people and led many down wasteful rabbit holes. A $30 joke at the expense of users...