I've created a pull request for the BME680 driver, which can be found
at https://github.com/apache/mynewt-core/pull/1286. Regarding the gas
sensor type, as suggested by Kevin, I've allowed that to be modified
via syscfg.

As mentioned previously, the BME680 is ultimately designed to be used
with Bosch's BSEC library. I'll be posting a message to discuss that
on the mailing list soon.
On Thu, 19 Jul 2018 at 20:37, Vipul Rahane <vi...@runtime.io> wrote:
>
> So, I do not feel strongly about one approach Vs another but I think if we 
> are measuring resistance with a sensor, the units need to be in OHMS.
>
> Obviously, the kind of resistance might matter. For example: Gas resistance 
> Vs Fluid resistance, etc. So, SENSOR_TYPE_GAS_RESISTANCE with OHMS as the 
> unit makes sense for me.
>
> Regards,
> Vipul Rahane
>
> > On Jul 19, 2018, at 8:47 AM, Andrey Serdtsev 
> > <andrey.serdt...@yotadevices.com> wrote:
> >
> > Extending ppb to uint64_t definitely doesn't make sense since maximum value 
> > for it is 10^6, which is 32bit value.
> >
> > Sincerely yours, CO :)
> >
> > BR,
> > Andrey
> >
> > On 19.07.2018 18:41, Kevin Townsend wrote:
> >>
> >>> Thanks for your comments @Kevin and @Andrey. I think for the BME680,
> >>> I'll stick with USER_DEFINED for now until we can come up with a more
> >>> general system. Ultimately, the gas sensor resistance is not really a
> >>> final value to be used and so I think it's OK for it to fall under the
> >>> USER_DEFINED category.
> >> We should only define values based on standard and repeatable units, I 
> >> agree,
> >> so USER_DEFINED makes sense here, though you might want to make which
> >> USER_DEFINED entry (1-6) selectable via syscfg.yml.
> >>
> >> This does still bring up a valid discussion about important sensor groups 
> >> like 'gas',
> >> though.
> >>
> >> I was thinking, for example, we could define 1-bit for 'gas' and then 
> >> hijack the
> >> triplet value type, where the first 32-bit value could define the gas 
> >> type, and then
> >> the second value could contain the value in ppb (which could possibly be 
> >> extended
> >> to a uint64_t, though I don't know if that's useful in the real world)?
> >>
> >> K.
> >
>

Reply via email to