Amint megint megáll kipróbálom. Ezt építettem meg:DS18B20 (Digital Temperature Sensor) and Arduino csak mellé csaptam még egy DHT11-es szenzort és kicsit módosítottam a kódot:


A proci egy ilyen pro mini: AR-PM328-5V, ennek van a 3-as lábán.

Proci reset után magához tér? Nem lehet hogy hibás átvitel/kommunikáció miatt pl riasztás módba kapcsol és húzza a buszt, a proci meg hajtja a buszt(már ha nem OC-ben hajtja a proci)?

Megmértem az áramot is. Most amikor normálisan működik 1mA alatt ugrál a műszer.

A DS lábain 5V-van, amikor "hibaállapotba" kerül akkor leesik 4,4V-ra, szóval jó nagy áram folyhat ilyenkor. Áramot még nem mértem, mindjárt megejtem azt is.
A felhúzó ellenállás 5kΩ.

Mekkora a tápfesz a DS lábain? Mekkora az áramfelvétele? Mekkora a felhúzó ellenállás?

Üdv!
Segítségre lenne szükségem mert lassan a falnak megyek. Van egy DS18B20 tokozott szenzorom ami a kazán előremenő csövére van szerelve, annak hőmérsékletét méri. Egy Pro Mini fejlesztőpanelre csatlakozik kb. 15m vezetékkel. Használta már valaki közületek ilyen hosszú kábellel ezt a szenzort? A felhúzó ellenállás a kontrollernél van, a kábel több eres riasztókábel aminek az árnyékolása a védőföldre csatlakozik az egyik végén. A szenzornál a tápvezetékere egy 4,7µF-os elektrolit kondi van kötve, a tápot 2x0,5mm²-es dróton kapja (értelem szerűen a riasztókábelből). A kábelben ezen kívül még kapcsolt DC 24V van, ami a kazánban egy relét működtet (termosztát funkció).
A hibajelenség:
Bekapcsolás után szépen működik, küldi az adatokat majd egyszer csak gondol egyet és -127C^o-ot kezd el küldeni (gondolom végállásba ragad) közben pedig fizikailag megérinthetetlenül felforrósodik. Tapasztalt már közületek valaki ilyet? Mi okozhatja? Szenzorhiba, vagy a hosszú vezeték zavar be neki? Másik szenzorral ugyan ez, bár egyszerre lettek vásárolva...

Mennyire akarod túlbonyolítani?
A: 2,5" csőbe mérőhüvely beépítése, és abba a DS...
B: alu ragasztó szalaggal ráragasztani a csőre az érzékelőt, kivülről meg kis csőszigetelés
C: ABA bilincsel ráfogatod a csőre az érzékelőt

Mivel a levegő hővezetése sokkal rosszabb mint a fémeké, az utolsó megoldás is tökéletes

Én spec, a fűtéscsövekre hegesztettem egy félcolos 5cm.es csődarabot. Aluból kiöntöttem a közepét, majd kifúrtam 6-ossal a szenzornak, az alut is és a szenzort is hőpasztával tettem a helyére.

A gázkazán szerelő, az ugyan ilyen átmérőjű fémtokos pt100 -at hozzá awa bilincsezte a rézcsőhöz, az is működik....

Csupasz szenzort rögzíted a csőre pl. ragasztószalaggal, maj tekersz rá valamilyen hőszigetelést, hogy a környezeti levegő ne hűtse/fűtse a szenzort.

A véleményekre, tanácsokra lenne szükségem.

Üdvözlök mindenkit.

Adott egy DS18B20-as szenzor, olyan, ami egy rozsdamentes 6-os átmérőjű csőbe van szerelve. És adott egy 2,5"-os fűtéscső. E kettőt szeretném házasítani, a lehető legjobb hőátadással. Másik opció, a sima cső nélküli DS18B20-as szenzor, és a 2,5"-os fűtéscső.

Nos, erre keresek megoldást, köszönöm.

A problémáim egy kisház rendszerében vannak, ott 5 percenként mérek helységek és hmv hőmérsékletét.
A csatolt képen egy új cucc készül, jól sejtetted, itt sűrűn, 5 másodpercenként.
Egy projekt miatt készült, hogy a gép több pontján lássam valós időben a kőmérséklet változásokat.
Köszönöm a tanácsot, ilyenre nem is gondoltam

Ha a Raspberry kapcsolja a tápfeszültséget a szenzoroknak, akkor egy kimenet váltás is elég lehet.

A képről nem tudom eldönteni, de két hőmérséklet lekérdezés között tarts legalább 15 másodpercnyi szünetet, különben az IC-k saját magukat melegítik. Ha ennyi megvan, akkor nem szóltam.

OK, akkor bizakodó vagyok
Most találtam egy videót ami szerint is okozhat zavarokat a hamis szenzor.
Nálam volt hogy egy hónapig elment gond nélkül, volt hogy eltűnt néhány szenzor értéke, majd pár nap múlva magától visszajöttek. Vagy gnd-t megszakítva-visszakötve javult meg. Távolról csak az RPi-t tudtam újraindítani, az nem segített.

Csak a 0x28 a biztos, a többi változó, lásd melléklet. Illetve a scratchpad két értéke, ami állandó.

Szia,
megjöttek a szenzorok.
Valahol azt láttam hogy a "28-xx-xx-xx-xx-00-00-xx" formátumú címmel rendelkezők az eredetiek.
Eszerint ezek sem azok...
De a pontossággal nincs baj, 0,2C szórás már bőven jó, vettem hozzá 100n-t is, ha azzal nem fagy a rendszer akkor már boldog leszek
Az elején a két vonal az alis szenzorok, azokat levettem és 5db-ot bekötöttem a most érkezettekből Még egymás mellett vannak összetekerve ahogy jöttek.

Köszönöm a segítséget.

Rendben, köszönöm.
(Itt Arduinohoz 4.7k, Raspberry-hez 10k-t ír.)

Nem, 1-Wire vonalanként egy felhúzó ellenállás kell, viszont szenzoronként egy-egy 100 nF-os kondenzátor.

A DS18B20 adatlapján 5 kΩ körüli ellenállás van írva.

Köszönöm.
Jelenleg a Raspberry-nél van egy 100nF és 4.7k felhúzó ellenállás.
Szinte mindenhol 4.7k felhúzót használnak, a DS1820 adatlapján RPi-hez 10k-t ír.
Erre még pluszba szenzoronként a 3.3k?

HEStore-os DS18B20-as szenzorral soha nem volt bajom.

Árnyékolt kábel nem javasolt, ellenben a szenzor lábaira a tövéhez a Vcc és a GND közé egy 100 nF-os kondenzátor igen. SMD 1206-os méretűt kényelmesen rá lehet forrasztani. Felhúzó ellenállás pedig legyen 3.3 kΩ.

Sziasztok!

Használok DS1820 szenzorokat egy kis hétvégi házban, egyenlőre a helységek és a bojler hőmérsékletét mérem. Néha az 4 szenzorból 2-3 eltűnik majd pár nap múlva visszajön. Ha inverterről fűtöm a bojlert, akkor még gyakrabban leül az egész. Gondoltam összeszed valami zavart, majd árnyékolt kábelre cserélem ha ott tatok már a felújítással.
Most összeraktam még egy adatgyűjtőt, tesztelésnél látom hogy a két egymás mellett lévő szenzor 1 fokkal eltérő hőmérsékletet mér. Így rákerestem lehet-e kalibrálni, akkor látom hogy ebből is van klón.
Lehet a leállások, zavarérzékenységnek is ez az oka
Szeretnék venni eredetit, csak nem tudom honnan kapok biztosan azt.
Itt a hestore.hu-n vajon eredetit árulnak?

Köszönöm mindkettőtöknek! Már minden világos. Legyen szép napotok!

A maszkolás azt jelenti, hogy bitenkénti ÉS műveletekkel "letakarjuk" azokat a biteket amelyek nem kellenek. 1 & x = x, 0 & x = 0. Tehát amire szükségünk van oda 1-et írunk, amire nincs oda 0-t. Például van egy 8 bites számunk: X = 10011011. Ha ebből nem kell pl az első 4 bit akkor össze ÉS-eljük a 00001111 számmal,tehát 10011011 & 00001111 = 00001011.
Nem tudom mit akart a szerző ezzel a művelettel amit csinált, de gondolom az előjel bitektől akart megszabadulni valamilyen módon, vagy ki tudja.
A második kérdésre már Bakman megadta a választ. Megoldható a feladat, úgy, hogy nem vársz a konverzióra. Ekkor kell egy timer ami méri az eltelt időt, és szól ha kész a konverzió. Még a megszakítás is elkerülhető , ha eltárolod a timer értékét indításkor és a főprogram lekérdezi egy-egy művelet között. Persze a timert úgy kell beállítani, hogy ne induljon ujra ha a végére ér, vagy elég hosszúra kell állítani a lefutását, hogy ne érje el az ujraindítást a konverzió kezdete és a kiolvasás között.

A helyes sorrend:

Bus Reset
Skip ROM (0xCC)
Write Scratchpad (0x4E)
send byte (tetszőleges)
send byte (tetszőleges)
send byte (0b00011111)
Várakozás (1 ms bőven elég)

Ha az értékeket el is akarod menteni az EEPROM-ba (esetedben célszerű), akkor:
Bus Reset
Skip ROM (0xCC)
Copy Scratchpad (0x48)
Várakozás (1 ms bőven elég)

A Write Scratchpad parancs után kötelező három bájtot küldeni, direkt címzésre nincs lehetőség ennél az IC-nél.

Az írásod második felében jók az elgondolásaid. Az alsó 4 bit tartalmazza a tizedes értéket. Kiadod a konverió parancsot, csinálsz amit kell, majd x idő után kiolvasod a konvezió eredményét. Mindegy, hogy a vezérlő vár az IC-re vagy közben mással foglalkozik. 1 s hosszú idő, el lehet költeni másra is.

Először is köszönöm a segítséget. A kódot a neten találtam, ezek szerint nem teljesen jó. De teljesen igazatok van. Az adatlapja legyen a barátom. Átnézem. Rögtön merült is fel egy kérdés. Ha változtatnám a felbontást mondjuk 9 bitre (nekem simán elég), melyik hex parancs a jó? A "configuration register" elérését nem igazán értem. Gondolom a "WRITE SCRATCHPAD [4Eh]" parancs kell, amibe egy 3 byte-s változót kell elküldeni, úgy hogy az első byte a Th regiszter, a második a Tl regiszter, a harmadik a konfigurációs byte. Tudom, hogy a R1-t és R2-t kell 0-ra állítani. Nincs lehetőség direkt memória cím írásra?
Kedves usane! A maszkolás kivételével értem mit mondasz, próbálom kiszedni a kódból a felesleges részeket. Leírnád nekem pontosan mit is jelent a maszkolás? Kezdem kapiskálni mit is rontottam el, a konverzió időn túl. Ha nekem nem kell a tizedes pont utáni rész, csak az egész szám érdekel, akkor a megkapott 16 bites adatot eltolom jobbra 4 bittel, így "leesik" a tizedes pont utáni "nem egész rész". Igazam van? Ha szeretném felgyorsítani a program futását (ne várjon a konverzióra), lehet úgy csinálni, hogy elindítom a konverziót, a programom tovább fut, mondjuk elindít egy ADC konverziót, majd kb. 500ms-1000ms múlva kiolvassa a szenzor értékét. Nekem nem fontos az "online" érték, ennyi csúszás belefér. Lehet így?

Valószínűleg ez a hiba oka. Adatlapon olvasd el a protokollt, valamint a hozzá tartotó értékeket mint például a konverziós idő. Ahogy látom Bakman be is csatolta a táblázatot.
Valamint az az átalakítás nekem is elég cifrának tűnik. Nem lett volna egyszerűbb egy maszkolás meg 4 jobbra tolás? 2x kiolvasni a sratchpadot meg pláne felesleges.

Ha a szenzorral való kommunikáció közben fut megszakítás, el tudja rontani a beszélgetést. A 1-Wire protokoll idő alapú, ha sok a megszakítás, eltolódnak az időzítések. Aután várj többet, 120 us alatt nem végez a hőmérséklet méréssel az IC, 94 - 750 ms kell neki, beállítástól függően. Asor nem a teljes hőmérsékletet adja vissza egy lépésben? Nem értem, miért kell a 9. sor.

Sziasztok! Egy kérdésem lenne, ezzel a hőmérővel kapcsolatosan. A hőmérőm IC-m TO-92 tokozású, és az aliról származik. A controller egy 18f4550. A quartz egy 16MHz - es darab. A szenzor egy 4x0.22 biztonságtechnikai kábellel csatlakozik a PIC-hez. A kábel hossza kb. 1 méter. Az árnyékolás nincs bekötve. A szenzor tápján 100nF kondi, de nem közvetlen a hőmérő lábán. A programozás mikroC-ben történt. A hiba jelenség a következő:
A PIC-et 48MHz (HS-PLL) futtatva folyamatosan hibás értéket ad vissza a szenzor, ahogy csökkentem az órajelet, úgy kezd egyre jobban jó értékeket küldeni. 16Mhz-es órajelnél stabilan mér. Minden mérés első parancsa, hogy a Timer0-t kikapcsolom (megszakítás van rá beállítva). Amúgy, ha csinálok, egy 50ms-es megszakítást mondjuk a timer0-val, 20 megszakításnál kapcsolgatok egy ledet ki-be, szemre adja az egy másodpercet. Így szoktam ellenőrizni a cpu sebességet. Ezt minden órajelnél megnéztem, ez jó volt. A timer0 értékek minden esetben újra voltak számolva, az adott sebességhez. A program egy 2x16karakteres LCD-t hajt meg, melyen a hibás adat "I5"-ként jelenik meg. Ebből az következik: ASCII kódja az "I"-nek 73 - 48(dec. szám->ASCII kód) = 35. vagyis 355 fokot küldd a szenzor. Viszont az nem lehet, mert a kód 99-ben maximalizálja. A kód a következő:


Valakinek ötlet? Lehet, hogy a Ow_... függvény csak lassabb órajelnél működik?

Maradék forrasztógyanta is tud érdekes dolgokat okozni. De a lényeg, hogy megoldódott.

2db LOW ESR elko, 1db fóliakondi, 2db kerámiakondi tápszűrésnek, és egy 3,3k felhúzóellenállás, a csatlakozók pedig csavaros sorkapcsok, én is forrasztásra gyanakodtam, kb. 10-szer forrasztottam át tegnap a panelt, ma reggel pedig gyártottam egy újat, nem hozott javulást, a 4cm-es kábel cseréje árnyékoltra viszont igen.

Mi van a kiegészítő panelen? Inkább csatlakozási vagy forrasztási hiba lehetett szerintem.