Az SHT4x szenzorok egyben páratartalmat is mérnek, már ha van erre igény, egyébként pénzkidobás. Az I2C miatt sokkal korlátozottabbak a vonalak hosszai, egy vezeték nem is elég, de kinek a pap, kinek a lan.

Mit értesz sok szívás alatt DS esetén?

Nagy valószínűséggel nem a saját tápját kapcsolgatja, hanem alvó állapotba megy, amikor nincs dolga.

Sokat szívtam már én is ezzel az IC-vel... Érzékeny, pontatlannak találom. Egy SHT41 / 45 jobb választás -ipari, pontosabb is. Persze az ára is.... pontosabb.

Annyira nem néztem utána a DS18B20-nak, de azt látom (meg használtam is), hogy felbontását lehet állítani. Azt hiszem 12 biten 750ms -ig értékeli ki a mintákat mire kihányja magából a vonalra. 10 biten már csak 187ms. Viszont ezek szerint Ő a saját tápját is kapcsolgatja, ha nyugiba van?

Ha a lekérdezések közötti időtartam kevesebb mint 15 másodperc, akkor az IC-k észrevehetően saját magukat melegítik. Ha az IC távolkeleti boltból van, akkor bármi megeshet, erre vannak már példák ezen a fórumon (is).

DS18B20 hamis érték

Üdv!

Konfig:
ESP32-S3, ESPHome 2025.10.3
5db DS18B20-as, R(pull) = 1,5kOhm, U = 3,3V (mérve 3,1V)
A szenzorok Alis, előregyártottak, 5 méteres vezetékkel. Közös onewire pinre kötve.

A mellékelt képen az látható amikor is az egyik szenzor, pont a nappali, ami a szoba hőmérsékletét figyeli, gondolt egyet és 5-6 fokkal elcsúszott. Piros körrel jelöltem.
A két narancs jelölésnél a kezembe vettem a szenzort (melegítettem) hátha visszaáll. Nem...
A többi 4 szenzor jól működik.

Tapasztalt valaki ilyet?

Nincs világvége, a nappali kapott egy másikat. Csak jó lenne tudni az okát.

SB

Bevezetnék oldalról egy lezárt végű réz csövet amibe kívülről menne be a szenzor. Esetleg a csövet menettel cserélhetőre is csinálhatod ha megmarná a cucc.

Vagy egy 3d nyomtatott műanyag házat szerkessz rá aminek a "lukjába" bepattintasz egy széntablettát (az aktívszén minden vegyianyagot megfog) legfeljebb savazás után egy idő múlva kiveszed . A vízpárát nagy valószínűséggel át fogja ereszteni .

A savazás idejére ragassz rá egy műanyag zacskót ....

Én ragasztós zsugorcsövet szoktam a kábelre és a DS18B20-ra melegíteni, eddig még nem tévedett.

Páratartalomra passzolok. Valószínűleg a szűrőt is eltömítené az Oxálsav...

DS18B20 és páratartalom szenzor védelme savas közegben

Sziasztok, kaptárban szeretnék hőmérsékletet és páratartalmat mérni, raspberry PI központtal. Maga a mérés megy, de a probléma az, hogy a kaptárban oxálsavas szublimálás is történik, egy évben kb 30-50 alkalommal. Oxálsav-dihidrátot (C₂H₂O₄·2H₂O) hevítünk 230C fokra, közben a kristály gőzzé válik és ezt befújjuk a kaptárba. Ott nagyon hamar lehűl, kicsapódik mikronméretű részecskékké, és ez elterjed a kaptárban. A baj az, hogy ez a savas kristály a tapasztalat szerint tönkreteszi a páratartalom szenzort.
Tudtok-e ötletet javasolni, milyen szűrővel lehetne védekezni a sav kristály ellen, amely azonban átengedi a párát.
A kérdés hasonló a DS18B20 szenzorhoz, bár ez vízhatlan burkolatban van, de nem vagyok biztos, hogy ez elegendő. (Egy kaptárba érdemes 3 hőmérséklet mérőt is tenni.)

Igen. Minegy, hogy mekkora felbontással dolgozik a szenzor, mindig 16 bites a mérés eredménye. A különbség annyi, hogy az alsó (LSB) 1, 2 vagy 3 bit nulla marad, felbontástól függően.

ds18b20

Sziasztok! Lehet buta a kérdésem, mégis felteszem.
A DS18B20 9 bites konverzió esetén is 16.0-val való osztás megadja a valós, 10-es számrendszerbeli értéket?

Köszönöm szépen!

Igen. A Copy Scratchpad utasításra menti el a beállításokat a benne lévő EEPROM-ba. A tartalom automatikusan bekerül a "RAM"-ba bekapcsoláskor.

Apropó, elírtam. Az utolsó parancs után 20 ms szünetet kell tartani, mielőtt újra megszólítod a szenzort.

Szia! Köszönöm szépen! Most ez a szenzor, amíg át nem állítom a felbontást a szenzorban, mindig 9 bites felbontásban marad. Ugye?

Ha a vonalon csak egy szenzor van:

Bus Reset
Skip ROM (0xCC)
write Scratchpad (0x4E)
send byte (tetszőleges)
send byte (tetszőleges)
send byte (0b00011111)
Várakozás (20 ms)
Bus Reset
Skip ROM (0xCC)
Copy Scratchpad (0x48)
Várakozás (2 ms)

ds18b20

Sziasztok! Tudna valaki segíteni abban, hogy hogyan kell beállítani a DS18B20-t, hogy 9 bites konvertálással működjön?

Én így használom, UART-al. Az az egy nehézség van vele, hogy bitenként kell összerakni az adatot, viszont nem kell figyelni az időzítésre, azt az UART elintézi hardware-ből.

Wow, ezt az UART-os trükköt nem is ismertem, nagyon jó! Mindig tanul az ember valamit! Köszi!

Nagyon köszönöm mindkettőtöknek!
Átszervezem a programot és jelentkezek, mire jutottam.

Szia!
-- Byte között engedélyezhető a megszakítás.
-- 1-Wire vonal kezelhető UART -tal is: AVR318 Dallas 1-Wire Protocol

Nem így működik a szenzor.
A mérés indítása és a kiolvasás 2 külön parancs. Közben azt csinálsz, amit akarsz.
Akár 1 perc múlva is kiolvashatod, a DS tárolja.
Megelőztél!

Ha kellően rövid ideig tartod a megszakításban a programot és elég nagy az órajel frekvenciája, röhögve mennie kell. Két szegmens kb. gyerekjáték.

Mindössze át kell szervezni a programot. Kiadod a mérési parancsot a szenzornak és amíg az dolgozik (750 - 800 ms), mást csinálsz. Magyarán amíg a DS18B20 összelapátolja az eredményt, addig a program fut tovább, nem várakozik, és ezen idő alatt is mehet tovább a megszakítás.

Multiplexelve hajtok meg két szegmenst timerrel indított megszakítással. Nagyon örültem ennek a megoldásnak, itt olvastam a cikkek között. De sajnos úgy néz ki tényleg ez volt a hiba okozója. Minden függvény elején kikapcsolva a megszakítást tegnap nem volt hibás mérésem! Viszont így a kijelzöm meghajtását kell újragondolni, mert a DS18B20-nak többszáz ms-os várakozás is kellhet és addig áll a kijelzésem. Úgy látszik, van mit tanulni még egy ilyen egyszerü áramkör leprogramozásához is.

@asch
Ez a CRC kezeléses dolog nagyon jó ötlet. Pont ezen gondolkoztam, hogy hogyan lehet egy ilyen szenzort hülyebiztossá tenni és, láss csodát, ott van az adatlapban leírva. Köszönöm a tippet, utánaolvasok.

Nézd meg, hogy a libed kezeli-e a CRC-t, és hogy nem ad-e hibajelzést, tehát a te kódod kezelné-e ha adna! C-ben ha mondjuk hibajelzést ad, de te azt ignorálod, akkor számolhatsz tovább hibás értékkel, pedig a lib tudta hogy az nem jó. Ha jön hibátlan CRC és mégis rossz a hőmérséklet érték, az rendkívül gyanús. Bár az is igaz, hogy a CRC csak egy bájtos, tehát időnként előfordulhat olyan is, hogy hibás kiolvasás mellett mégis jó a CRC! Ugye 1/256 valószínűséggel, ha teljesen véletlenszerű minden.

Ha a lib nem kezeli a CRC hibát, akkor érdemes megjavítani, vagy lecserélni egy olyanra, ami kezeli. (Én nem nézem meg a kódot most.)

A one wire protokoll időzítésében emlékeim szerint van olyan rész, aminél nagyon pontosan kell kis idő alatt reagálni (régebben megvalósítottam a protokollt, de az sem tökéletes, ezért nem ajánlgatom a kódomat), emiatt tényleg csak tiltott IRQ mellett tud helyesen működni szerintem is.

Ezt hogyan kell érteni? Mátrix meghajtás?

Ez egy nagyon jó ötlet! Kipróbálom, hogy minden DS-es függvény elején tiltom, végén újra engedem a megszakítást.

Amikor a DS-el kommunikálsz, kapcsold ki a megszakítást!

8MHz-en ketyeg a PIC és van megszakítás benne, egy két digites hétszegmeneses kijelzőt kapcsolgat. Lehet pont amiatt csúszik el a dolog?

Egyébként a szenzort kezelő rutint innen "loptam": Bővebben: Link
Ajánlom mindenkinek, aki PIC-re keres működő megoldást és nem zavarja ez a kis időnkénti félre mérés.

Mekkora a PIC órajele, van-e megszakítás a programban... ?
Érdemes egy logikai analizátorral megnézni, hogy stimmelnek-e az időzítések.

A távolkeleti szenzorok tudnak ilyet, több ilyen hozzászólás született már ezen a fórumon is, ahol egyértelműen tettenérhető a gagyi IC. Ugyanazon áramkörben az eBay-es IC téveszt, míg a biztos forrásból származó nem.
Másrészt maga a kontroller is hibázhat, ezt oszcilloszkóppal és/vagy logikai analizátorral lehet kideríteni.