SGP30 baseline handling (_P083_SGP30.ino)

[Rampler]

Hi together,

in the source i see the following line:

Code: Select all

addLog(LOG_LEVEL_INFO, F("SGP30: Restore last known baseline values"));

Could anybody so kind to explain the Baseline handling of the sensor ?
When will the baseline stored ?

regards Klaus

[Ath]

The baseline values are periodically stored in the (hidden) 3rd and 4th output value fields, as these are retained across a warm restart (and reset to 0 on a cold start/power cycle).
If these values are <> 0 then these earlier determined values are restored to the sensor, to speed up auto-calibration & adjustment.

[Rampler]

Thanks for the information ..

[Rampler]

Will the _P083_SGP30.ino intergrated into the normal builds ?
What are the conditions in order to migrate the plugin into the normal builds ?

[Rampler]

Is it possible to implement temperature and humidity compensation, like the p090_ccs811 plugin does ?

[Ath]

According to the list of plugins this plugin is in the TESTING A build-set, so it is available for use.

Because of the size of the combined set of plugins, it is not feasible that it will end up in a NORMAL build, but the best alternative to that are the MAX builds, that hold all available plugins, but can only be used on ESP32 with 16 MB Flash. Until we max-out that too (but that will take a while, and there are other restrictions, like the max. Plugin ID being 254, that will probably be hit first)

I'm not sure if the SGP30 needs any external compensation, but I think it has that capability/compensation itself.

[Rampler]

I'm not sure if the SGP30 needs any external compensation, but I think it has that capability/compensation itself.

SGP30 Datasheet:
The SGP30 features an on-chip humidity compensation for the air quality signals (CO 2 eq and TVOC) and sensor raw signals
(H2 signal and Ethanol signal). To use the on-chip humidity compensation an absolute humidity value from an external humidity
sensor like the SHTxx is required.

[Rampler]

According to the list of plugins this plugin is in the TESTING A build-set, so it is available for use.

In my understanding, TESTING builds are builds to test.
But it seems, that TESTING A B C .. are normal builds with different plugins.

IMHO:
NORMAL A B C .. convention would be better.. (instead of TESTING A B C)

Also confusing is, that the plugins are labeled with (TESTING) in the device list.

I thought,that testing builds are unstable, therefor a was unmotivated to try testing plugins.
(OK shit, this sensor is great, but is only TESTING A)

[TD-er]

"Testing" is a legacy naming schema which we need to change as it is confusing.
I'm open for suggestions for a better name.

[Rampler]

"Testing" is a legacy naming schema which we need to change as it is confusing.
I'm open for suggestions for a better name.

As i mentioned before:
NORMAL A B C .. convention would be better.. (instead of TESTING A B C)
And
Leave the [TESTING] behind the sensor name in device list

[TD-er]

I think the "normal" should then also be renamed.
Maybe we can name it like "base" or something.

Anyway, the reason it has not yet been changed is partly because people have become used to it and also that it needs quite a bit of work and later takes time to reply to questions like "where is my build?"
The other reason is that I have not yet found proper names for it.

[Rampler]

On the other hand, many users do not use TESTING A B C builds, because they think that they are "only" test builds.

[TD-er]

That's also a possibility.

I will see what I can do and also how much effort it takes to change the "testing" naming.
I am affraid it still may require quite a lot of effort, but I can see your point here.

[Rampler]

For those who have doubts...
It is difficult to explain that [TESTING] is stable...

Testing.JPG (49.69 KiB) Viewed 7936 times