Vlákno názorů k článku Inteligentní internetový termostat se sítí digitálních teplotních čidel od anonym - Chválím autora, použil pro daný účel rozumný HW....
-
Chválím autora, použil pro daný účel rozumný HW. 8bit opravdu stačí.
Pro ty co nad 8bity ofrňují nos: v jednoduchosti je síla. Program napsaný v C běžící na AVR je řádově stabilnější než Python a jemu podobní běžící na OS.
Autor trochu přechválil teplotní čidla DS18B20. Ano, teplotu z nich lze vyčítat opravdu mockrát za sekundu, ale vlastní převod je poměrně pomaly. Při rozlišení 0.5 °C trvá převod 94 ms, při rozlišení 0.25°C 188ms, při rozlišení 0.125°C 375ms a při nejlepším rozlišení 0.0625°C trvá převod 750ms (hodnoty z dokumentace). V drtivé většině případu se používá nejlepší rozlišení a tedy i nejpomalejší převod.
DS18B20 má ještě jednu zajímavou vlastnost. Má docela zajímavé šumové vlastnosti. Toho lze využít a za DS18B20 zařadit číslicový filtr a získat tak teploměr s rozlišením lepším než 0.01°C. V topenařině pak lze takový teploměr použít k přesnému měření teploty akumulační nádrže následný výpočet uložené energie a dokonce lze docela úspěšně počítat i aktuální výkon dodávaný/odebíraní do/z akumulační nádrže.
-
Petr StehlíkZlatý podporovatelNepřechválil, ta čidla jsou mnohem rychlejší, než vámi/dokumentací uváděné nejhorší možné časy. Mám to pro vás (při pokojové teplotě) změřit?
-
Petr StehlíkZlatý podporovatel
Ah, I stand corrected!
Knihovna DallasSemiconductors, kterou jsem před lety pomáhal vylepšovat o asynchronní čtení z čidel, mi hlásí, že konverze při 12bitové přesnosti trvá 35 milisekund. Proto jsem v článku napsal co jsem napsal (že je čidlo rychlé jako čert).
Ale teď jste mě vyburcoval ke kontrole všeho možného i nemožného a tak jsem se dogoogloval k tomu, že běžná doba konverze je ve skutečnosti 596 milisekund.
Pátral jsem dál a zjistil jsem, že v knihovně DS, resp. v její spolupráci s knihovnou OneWire, je velmi zajímavá logická nebo elektrická chyba - po resetu sběrnice (který se v tom konglomerátu knihoven odehrává na začátku jakékoliv komunikace) příznak "je už konverze dokončena?" naráz hlásí "ano", i když uplynulo teprve 35 ms...
Takže vzhůru na opravu knihoven!
-
Raději ještě znovu připomenu, je nutné rozlišovat mezi časem konverze a časem nutným pro vyčtení hodnoty.
Hodnoty času konverze, které jsem uvedl výše, jsou z dokumentace a uvádějí maximální délku konverze. Může to tedy být i rychlejší. Ale pokud chcete mít jistotu, že převod proběhl kompletně, stejně nezbývá než počkat minimálně ten maximální čas uvedený v dokumentaci.
Příkaz CONVERT T [44h] sice umožňuje zjistit přesně okamžik dokončení konverze, ale je nutno připojit externí napájení (připojit čidlo třemi vodiči).
V dokumentaci a různých AN lze mezi řádky vyčíst, že vnitřní hodiny/oscilátor DS18B20 asi nejsou příliš stabilní. Zřejmě na ně bude mít značný vliv teplota a kus od kusu to taky bude různé. Také je otázka, zda převod některých teplot, vzhledem k použité metodě převodu, netrvá déle a jiný jde rychleji (v dokumentaci jsem již nenašel).
596 ms je lepší než 750ms uvedených v dokumentaci, ale je otázka jestli u stejného čidla a jiné teploty nebo u jiného kusu to bude taky 596ms nebo ne. -
Petr StehlíkZlatý podporovatel
Tu hodnota 596 milisekund jsem uvedl jako protiklad k 35 milisekundám, které jsem naměřil dříve a podle kterých jsem psal článek. Není důležité, je-li to 596 nebo 604 - důležité je, že jsem byl v omylu s těmi 35 milisekundami a děkuji za naťuknutí, které mě dovedlo včera v noci k poznání. Jistě chápete, že když jsem v článku napsal "mnohokrát za sekundu", věřil jsem právě těm 35 ms, což by dalo i 25 čtení (včetně konverze) za sekundu. Proto je pro mě včera zjištěných 596 ms studenou sprchou, neboť je to řádově víc a o to tu jde. Čili čidla jsem chválil v dobré víře, tedy žil jsem v omylu, ale přechválit jsem je opravdu nechtěl :)
Už jsem identifikoval přesně tu chybu v knihovně DallasTemperature (nikoliv Semiconductors, jak jsem 2x napsal výše) a právě přemýšlím, jak ji správně opravit. Pravděpodobně budu muset nejdřív na github vysypat moje dosavadní změny, zkusit sesynchronizovat s upstreamem a pak teprve začít opravovat tuhle chybu v isConversionAvailable(), která je poměrně zásadní a zatím asi nikým nepovšimnutá.
-
Kolemjdoucí (neregistrovaný)
Princip zde http://www.atmel.com/images/doc8003.pdf
Bohužel je to na DS18B20 nepoužitelné, protože měřením teploty se zahřívá. -
sup (neregistrovaný)
To ze sa meranim zahrieva by nevadilo, pretoze vacsinou je meranie robene nepretrzite a teda sa po malej chvili teplota ustali a rozdiel medzi skutocnou teplotou a meranou je takmer konstantny. Ten rozdiel je aj tak taky maly (mozno desatiny °C), ze vacsinou je to akceptovatelna chyba.
Ale vratil by som sa k cislicovemu filtru. Mam doma do 20 tychto cidiel rozmiestnenych po dome, ktore tiez komunikuju s arduinom a ked som ich chvilu sledoval, tak sa mi nezdalo, ze by tato metoda bola pouzitelna a ak ano, tak len s velmi pomalymi odozvami.
Napr. cidlo s rozlisenim 12bit zobrazuje rozdiely 0,0625°C. Cize, ak by som chcel dajme tomu vediet teplotu na stotinu presne, stacilo by mi zobrat 6 merani a spriemerovat. Cize napr. 10.0625. 10.0625, 10.125, 10.0625, 10.125, 10.0625 a mam priemernu teplotu 10.08°C.
Ide o to, ze cidlo pocas merania zobrazovalo stabilne jednu a tu istu teplotu a len ked sa malo chylit ku zmene, tak zacalo oscilovat okolo novej hodnoty. To znamena, ze priklad, ktory som uviedol v predchadzajucej vete v reale nefunguje.
