search

ruuvi / ruuvi.firmware.c

Ruuvi Firmware version 3. Built on top of Nordic SDK 15, uses both Ruuvi and external repositories as submodules. In Beta, no breaking changes are intended but may be done if absolutely necessary
BSD 3-Clause "New" or "Revised" License
52 stars 39 forks source link

Spikes in logged data #254

Closed ojousima closed 3 years ago

ojousima commented 3 years ago

Customer report, data was logged to RuuviTag FW 3.30.0+default. It's uncertain if the problem is in sensor, logging, transmitting data, or receiving on Android. image

DG12 commented 3 years ago

Can you get a download of the data?

ojousima commented 3 years ago

Can you get a download of the data?

Not at this time

ojousima commented 3 years ago

Here's a similar dataset. Log 2021-04-28 12_20_23.txt

It seems that the issue is caused by: 1) Tag has open enclosure or is being handled 2) Something causes fast spike in humidity, e.g. user breathing on sensor 3) SHTC-tags do not have internal IIR filtering, which causes the humidity to spike

Next thing to decide is do we leave everything as is or filter the change somehow?

DG12 commented 3 years ago

In order of desirability and implementation difficulty most desirable and most difficult listed first.

option 1: filter at the firmware level and include a runtime configurable filter(i.e. no compile #define) both to enable/disable filter and define the severity of the filter. This mitigates having any of the various receiving system, by various authors, having to implement a filter on a per Ruuvitag basis. Some use cases may not want to filter.

option 2: filter at the firmware level with a compile time default based on the philosophy that the sensor has an inherent property that may need a variable correction. This very difficult as it requires the end user to set up a tool chain then edit source, compile, load each tailored case and finally requires flashing each Ruuvi tag , perhaps uniquely.

option 3 filter at the firmware level philosophy that the sensor has an inherent property that always needs a fixed correction

option 4: let the firmware transmit what ever the sensor and a particular implementation results in. Require the particular common receiver implement a per Ruuvi tag filter.

option5 . Let the process that acts on or displays or analysis the data include it's own algorithm to deal with possible anomalies that may be of interest.

Although option 1 is most difficult all around, I believe it provides the optimal solution covering various sensor issues and any use case.

laurijamsa commented 3 years ago

I just received a new Android user feedback about the same issue with the latest firmware. The CSV export reveals that broadcasts and GATT history humidity values differ by around 6,2%. User has no access to an iPhone.

"It is very welcome that the latest firmware allows you to synchronize historical data from tags. However, the app does not seem to correct for the calibration of the hygrometer, leading to very noisy charts."

Find here screenshot and CSV export:

image

Guitar Case_20210509-0920.csv

ojousima commented 3 years ago

Is this about applying the calibration constant to data?

ojousima commented 3 years ago

This was found to be Android issue in applying offset between logged / broadcasted data. Fixed in Android