100 nF kondenzátor a táplábakra, nem az adatvezetékre. A nem használt vezetékeket ne kösd sehova, növeli a kapacitást az adatvonalon, ami káros (gyári ajánlás).

Ha ez sem segít, akkor kicsit másként kell kiépíteni. A szenzor oldalra egy kis mikrokontroller, amihez csak a DS18B20 csatlakozik. A kis kontroller kérdezgeti a hőmérő szenzort akkor, amikor a mester erre utasítja, majd RS485-ös adatvonalon (MAX483, MAX485) küldi vissza a mesternek az adatot. Az 5 V-os tápfeszültséget helyben kell előállítani, célszerű 10-12 V-ot felküldeni.

+12 V
GND
RS485 A+
RS485 A-

Négy ér elég a dologhoz.

szerk.:
Milyen hosszú kábelről van szó?

Ok, közben észrevettem a távolságot, első olvasatra elsiklottam felette.

Sziasztok!
A kínai vízhatlan tokok általában szoktak tartalmazni felhúzó ellenállást? Ùgy mérem, mintha benne lenne, de ez lehet magának az IC-nek is az ellenállása, azért kérdezem.

Passzolok, de kideríthető. Adsz neki 5 V-ot, a jel és a GND közé kötsz egy 100 kΩ-os ellenállást. Ha a jel vezetéken közel nullát mérsz, akkor nincs felhúzó ellenállás benne. Ez utóbbi lenne egyébként is logikus. Egyrészt mindenki azt csinál a szenzorral, amit akar, másrészt öbbet is párhuzamosan lehet kötni és ha mindegyikben van felhúzó ellenállás, az eredő akár túl kicsi is lehet.

Köszönöm a válszodat! Kicsit tovább gondolkodva, egyszerüen megmértem a helyén beforrasztva az ellenállássa együtt. Kb. annyit mértem, amennyi az általam beforraszott felhúzó, szóval gondonolom nincs a tokban ellenállás.
Azért merült fel a kérdés, mert azt produkálja, hogy néha fals értéket mér véletlenszerüen. 1-5 percenként egy hibás mérése van, teljesen random. Eddig 10kOhm volt a felhúzó, most csökkentettem 4,7kOhm-ra, de így is csinálja. Az interneten sok erre vonatkozó kérdés van, lehet, hogy a kínai IC-k a rosszak? Vagy már arra is gondoltam, hogy lehet a PIC-em idözítése nem elég pontos a belsö saját oszcillátorával és azért megy félre valami?

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.

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.

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.

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

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.

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

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.

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.

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.

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!

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

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

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

É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.