Mittaustulokset päivityksen jälkeen

Moi

Kyselisin sellaista että päivittelin noi ruuvitagit uusimmalla softalla dfu.2.5.9 ja sen jälkeen mittaustulokset ovat olleet aika kirjavia…

Samalla pöydällä olevien laitteiden kosteus%'ssa on 20 yksikön eroja sekä lämpötilassakin reilun asteen heitto… Olisiko nämä pitännyt jotenkin erikseen vielä kalibroida tai jotain? Esim jääkaapissa on kaksi tagia rinnakkain liimattuna samalle seinälle ja liitteen kuvassa näkyy hyvin miten lukemat eroaa… Siirsin pari pv sitten tuon olohuone tagin kaapin seinälle tuon toisen viereen kun kosteuslukema pisti silmään suuruudellaan. Screenshot_20200125-152145-01|623x500

Ennen päivitystä kaikkien tagien lukemat pysyivät muutaman kymmenyksen sisällä toisistaan… Ideoita miten tämän ongelman saa korjattua?

Moi,

Mielenkiintoinen ilmiö. Ensimmäisenä voisi kokeilla päivitystä takaisin versioon 1.2.12, https://lab.ruuvi.com/distribution-packages/ruuvi_firmware_dfu_1.2.12.zip . Jos tagit ovat sen jälkeen taas samassa tasossa niin alamme tutkimaan onko ohjelmistossa jokin bugi joka sotkee mittauksia joillain tageilla.

Pudotin noihin tuon linkkaamasi firmiksen ja suljin vuorokaudeksi kannet avoinna lasikaappiin… Nyt pysyy lämpötilat yhtä tagia lukuunottamatta nipussa, kahdessa uudemmassa tagissa (sauna&jääkaappi) kosteus menee hivenen korkeammalla, mutta ei sentään enään ole muutamia asteita / kymmeniä % tuo ero.


Klikkaamalla näkee kokonaan

Kiitos, tutkin mikä niissä olisi muuttunut ja miksi tämä näkyy vain joissain tageissa.

Kävin nyt koodierot versioiden 1.2.12 ja 2.5.9 välillä läpi, ainakaan näin nopeasti en löytänyt sieltä mitään mikä selittäisi eron. Tämä on myös ensimmäinen ilmoitus siitä että firmispäivitys olisi johtanut eroon ilmoitetuissa tuloksissa.

Me mietimme hiukan lisää mahdollisia syitä ja palaamme tähän pian

Nämähän on toki yksilöitä ja voihan se olla että esim tuo linjasta edelleen eniten poikkeava jääkaappi anturi on vikaantunut oltuaan kuukausia jääkaapissa. Koti käyttäjälle tuo ei ole kuin kosmeettinen ongelma listalla ja kun tuon heiton tiedostaa niin sen voi ottaa ynnäämällä huomioon… Täytyy mielenkiinnosta testata kuinka se toimii saunassa… Tuleeko aiempaa enemmän hajontaa vai pysyykö tuo poikkeama samana myös asteikon yläpäässä… Yleisesti ottaen olen erittäin tyytyväinen näihin ja meinaan kyllä tilata lisää.

Itsekin ihmettelin samaa ilmiötä, mutta en alkanut systemaattisesti tutkimaan siinä yhteydessä. Nyt varmaan pitää testata kun on toinenkin havainto.

Samaten vaikutti, että vaihdettuani päivitysjakson harvemmaksi (n. 6s) entistä harvempi havainto tulee läpi. Minulla on kolme sensoria, joista yhden firwarea EN päivittänyt hankalan sijainnin vuoksi. Viimeisen puolen tunnin aikana siitä on yuulut läpi 18 mittauspistettä (-71dBm tasolla) kun kahdesta päivitetystä 6s väliin muutetusta on tullut 4 data pistettä (- 99 dBm) ja 10 (- 86dBm). Saattaa johtua matalammasta signaalin voimakkuudesta.

Ylipäätään mittaustulosten näyttäminen kahdella desimaalilla on jossain määrin arveluttavaa todelliseen tarkkuuteen nähden. Voihan toki olla, että muutokset on mitattavissa sen verran tarkasti, että sillä voisi perustella vaikka itse numeerinen arvo onkin väärin.

Kiitos, jos tagit ovat esimerkiksi pakastusrasiassa kansi auki olosuhteet tasoittuvat nopeasti.

Tämä on ihan odotettua, yksittäisen BLE-datapisteen havaitsemiseen on jokin todennäköisyys (noin 5 % … 95 % vastaanottimesta riippuen) joten kun dataa lähtee harvemmin sitä myös saa talteen harvemmin.

Resoluutio antureissa on paljon absoluuttitarkkuutta parempi, siksi tuloksetkin näytetään korkealla resoluutiolla.

No niin, jatkoin hiukan testaamista.

Laitoin kaksi päivitetyn firmwaren Ruuvia pakastimeen vierekkäin ilmanpääsyreiät vastakkain (ja molemmissa piirilevyn uritus em rriän kohdalla ajatuksena, että kosteus anturi on ehkä piirilevyn takapuolella).

Noin vuorokauden vakiintumisen jälkeen tulos oli se, että lämpötilassa oli liki kahden asteen ero, eli aika hurja. Eritoten kun resoluutio on sadasosa.

Kosteus oli sen sijaan täsmälleen sama ja painekin erittäin lähellä. Otin exportilla CSV:n talteen molemmista, mutta en nyt liitä niitä tähän, koska vaatisivat käsittelyä ollakseen järjellisesti silmällä luotettavissa.

Eihän tuo mitään todista muuta kuin mittaustarkkuudesta uudemman firmiksellä jos ei vielä palauta toista vanhaan.

Miten mahtaa olla anturin lähetyksen ja sovelluksen kuuntelun aikaikkunan overlap? Ajattelin, että onko jossain määrin sattumaa, että 6s välein oleva lähetys sattuisi juuri kuuntelun vaikka 2min puhumattakaan esim 10min ikkunaan. Luulin alkuun, että sovelluksesta valittava päivitysväli pyytäisi datat sensoreilta, mutta näinhän ei olekaan. Ilmeisesti tälläinen ‘pakkopyyntö’ ei ole edes mahdollinen, Ruuvi tagissa ei taida olla vastaanotinta?

Hyvä juttu on, että sovelluksen asteikot ovat zoomattavissa. Lisäominaisuurena toivoisi, että autoscaling olisi valittavissa päälle/pois. Tuli mieleen kun jossain vaiheessa ainoat vastaanotetut data pisteet poikkesivat 0,2 ast toisistaan ja koko asteikon (näytön) skaala käytettiin siihen.

Pakastimessa tuo ero saattaa olla myös oikeasti olemassa, jos jäähdytysputki on toista tagia lähempänä niin ero voi olla aika hurja. Olemme itsekin nähneet parin aseteen eron pakastimessa joka korjautui siirtämällä tagit toiseen osaan pakastinta.

Se on sattumaa osuuko kohdalleen. RuuviTageissa on vastaanotin, mutta virran säästämiseksi sekä tietoturvan takia emme pidä tageja yhdistettävänä. Meillä on 3.x beta-firmware johon saa yhteyden, mutta sen patteri kuluu noin 6 kuukaudessa mikäli yhteys on jatkuvasti päällä ja suosittelemme sitä toistaiseksi vain iOS-käyttäjille jotka haluavat graafit.