Fórum témák

» Több friss téma
Fórum » DS18B20 hőmérő-szenzor
 
Témaindító: Korben, idő: Nov 16, 2005
Témakörök:
Lapozás: OK   37 / 37
(#) kormika válasza Bakman hozzászólására (») Szept 24, 2020 /
 
Nehezen tudom elképzelni, hogy ennyi szűrésen keresztül átjut valami a tápmodulból, de holnap megpróbálom úgy, hogy a szenzorokat másik tápról járatom, mondjuk 3 ceruzaelemről, hogy esély ne legyen bármiféle zajra a tápon.
(#) Bakman válasza Bakman hozzászólására (») Szept 24, 2020 /
 
Mármint annak elektromágneses sugárzása.
(#) Kovidivi válasza Bakman hozzászólására (») Szept 24, 2020 /
 
Jogos...
(#) usane válasza kormika hozzászólására (») Szept 25, 2020 /
 
Kábel nem okozhatja, nekem 5-6 méteres is van az infrás asztalban árnyékolatlanul fut az infrafóliák alatt. Zavartalanul üzemelnek a fóliák fűtése közben is. 7 szenzor 4k7 ellenállással és mégcsak fel sem húztam mindet, csak a multiplexer adatvonalát ha jól emlékszem. Nálam is HEStore-os szenzorok vannak, igaz nem a csöves változat, hanem a normál TO-92, valamint nálam nem kapcsitáp hajtja, hanem csináltam hozzá normál egyenirányított tápot 1117-es LDO-val, és ESP-vel megy nem Arduinoval. Van egy PIC-es változatom is ugyanebben a felállásban, az is simán ment. Nálam is van Nextion kommunikáció is, valamint az ESP-s változat WiFi-n is kommunikál zavartalanul. A kódot nem tudom jó-e, én nem használtam a Dallas könyvtárat csak a onewire-t a multiplexeres megoldás miatt.
(#) kormika hozzászólása Szept 25, 2020 /
 
Megoldódott a probléma, igazából az okot nem tudom műszerezettség hiányában kideríteni, de valószínűleg valami zajt szedett össze az a kb. 4cm-es vezeték, amivel a kis kiegészítő panel és maga a vezérlő van összekötve. Az adatvonal 1,5-es vezetékét lecseréltem egy darab árnyékolt biztonságtechnikai kábelre, aminek a 4 erét párhuzamosan kötöttem, az árnyékolást pedig a kis panelnál bekötöttem a GND-re. Nem értem, hogy ha a szenzorok több méteres árnyékolatlan kábele nem szed össze semmit, akkor az a kis 4cm-es vezeték mit szedhetett össze... Egy szó mint száz, ezzel a kis darab árnyékolt kábellel helyreállt a rend, 3,3k van felhúzónak, minden maradt az eredeti felállásban és most működik. Köszönöm mindenkinek a segítő hozzászólásokat.
(#) usane válasza kormika hozzászólására (») Szept 25, 2020 /
 
Mi van a kiegészítő panelen? Inkább csatlakozási vagy forrasztási hiba lehetett szerintem.
(#) kormika válasza usane hozzászólására (») Szept 25, 2020 /
 
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.
(#) Kovidivi válasza kormika hozzászólására (») Szept 25, 2020 /
 
Maradék forrasztógyanta is tud érdekes dolgokat okozni. De a lényeg, hogy megoldódott.
(#) DJozso hozzászólása Okt 2, 2020 /
 
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ő:
  1. Ow_Reset(&PORTC,6);
  2.      Ow_Write(&PORTC,6,0xCC);
  3.      Ow_Write(&PORTC,6,0x44);
  4.      delay_us(120);
  5.      Ow_Reset(&PORTC,6);
  6.      Ow_Write(&PORTC,6,0xCC);
  7.      Ow_Write(&PORTC,6,0xBE);
  8.      Temp = Ow_Read(&PORTC,6);
  9.      Temp = (Ow_Read(&PORTC,6)<<8)+Temp;
  10.      temp2write = Temp;
  11.        temp_whole = temp2write >> 4;
  12.        Hoertek_BE = temp_whole;
  13.         if (temp_whole != 0){  // Ha a mérés nem nulla
  14.           if (temp_whole>=100) {  //  Ha nagyobb mint 100, 99-et mutat
  15.                 FrontLeft[0] = '9';
  16.                 FrontLeft[1] = '9'}
  17.           else {
  18.              FrontLeft[0] = temp_whole/10+48;
  19.              FrontLeft[1] = temp_whole%10+48;}
  20.              Lcd_Out(1,1,FrontLeft);}


Valakinek ötlet? Lehet, hogy a Ow_... függvény csak lassabb órajelnél működik?
(#) Bakman válasza DJozso hozzászólására (») Okt 2, 2020 / 1
 
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. A
  1. Ow_Write(&PORTC,6,0x44);
utá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. A
  1. Temp = Ow_Read(&PORTC,6);
sor nem a teljes hőmérsékletet adja vissza egy lépésben? Nem értem, miért kell a 9. sor.
(#) usane válasza DJozso hozzászólására (») Okt 2, 2020 / 1
 
Idézet:
„delay_us(120);”
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.
(#) DJozso válasza Bakman hozzászólására (») Okt 2, 2020 /
 
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?

Parancsok.jpg
    
(#) Bakman válasza DJozso hozzászólására (») Okt 2, 2020 / 1
 
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.
(#) usane válasza DJozso hozzászólására (») Okt 2, 2020 / 1
 
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.
(#) DJozso válasza usane hozzászólására (») Okt 2, 2020 /
 
Köszönöm mindkettőtöknek! Már minden világos. Legyen szép napotok!
Következő: »»   37 / 37
Bejelentkezés

Belépés

Hirdetés
Lapoda.hu     XDT.hu     HEStore.hu
Az oldalon sütiket használunk a helyes működéshez. Bővebb információt az adatvédelmi szabályzatban olvashatsz. Megértettem