Probáltad az I2C-t? Az lenne a legegyszerübb. A youtubon van egy sereg video az I2C használatára. Én egy berendezésben 8 eszközt használok igy és semmi gond ( egy meg kétbajtos cucokat). Az egyik Arduinot kinevezed maszternak és az fogja az adatokat küldeni meg kérni a másiktol.

Urak, eddig csak 1 ember volt kedves segítséget nyújtani az általam felvetett problémával kapcsolatban!

A 2 panel le van gyártva, össze van szerelve, a kommunikációhoz 2db csatlakozási pont van kialakítva, ami a soros port tx rx lábai.
Így maximum az i2c-re való átdrótozás jöhet szóba, de ezt sem szeretném.
Az eredeti elképzelés a soros kommunikáció, ebben kértem segítséget, nem abban, hogy milyen kommunikációs formát ajánlotok helyette.

Nem arduino panelt használok, amit szabadon át lehet kábelezni bárhogy, hanem maga az atmega328p csip köré van építve a 2 panel.

Ez is egy jó ötlet, ami még kivitelezhető lenne, mivel ez is 2 vezetékes kommunikáció, és 2 sorkapocs van biztosítva, de mekkora távolságig stabil az i2c?
Nálam kb 100-150m-t kell áthidalni, és nem fagyhat le egyik arduino sem, ha ne adj isten elvágják a kábelt.
12 zónás riasztót készítek, így ez egy nagyon fontos szempont, ha elvágják a kábelt, akkor tudnia kell a vezérlésnek sms értesítést küldenie róla.

Azt nem tudom, de biztos elérhetö valahol az I2C speckoja.ott biztos meglesz a távolság. A többi a kodon mulik, ha rendszeresen lekérdezed és a másik nem válaszol akkor már mehet az SMS.

Egy icipicit én azért visszább vennék! Az eredeti hozzászólásban még Arduino Unót írtál, szó sem volt legyártott panelekről! Az a 100-150m is csak most derült ki. Mi próbálunk neked segíteni, de ha csak néha közöd velünk a fontos dolgokat, akkor ne várd hogy rögtön tökéletes választ kapj. Ekkora távolságra lehet hogy a sebességet is vissza kellene venni, a jelcsillapítás is gondot okozhat. Az adatmennyiség csökkentése esetleg segíthet, hogy minél kevesebbet maradjon a kommunikációban (mondjuk valami tömörítés használatával). Én ezeket próbálnám még meg.
Szerk.: vagy esetleg éppen gyorsítani amíg a vezeték bírja, szintén hogy gyorsan végezzen.

Hali! Nem tudom hogy milyen jelszinttel használod a sorost, ha RS232 +-12V jelszint akkor én nem bíznék rá 50m-t sem. A ttl jelszint nyilván még jobban kiesik...
RS485-üt javasolnék erre a távolságra, nekem megy kb 500m-en 6 eszköz van rá feldugva, az eszközök hardveresen azonosak, szoftverben egy kinevezett master van ami megszólítja egyesével az eszközöket, amik ilyenkor válaszolnak. Hallgatni mindenki hallgatja a kommunikációt.

Arduino uno bootloader-rel felprogramozott atmega328p, bocsi, kifelejtettem az aniformációt.
9600baud az átviteli sebesség.

Ha találok megfelelő sebességű optocsatolót, akkor fel akarom ültetni 12V-ra a kommunikációt is.
A bemeneteket fogadó panel, és a kijelzőt és rfid iro/olvasót tartalmazó kezelőpanel is 12V-os tápot kap, saját 5V-os stabilizált táppal, így mindenképp izolálni kell a sorosport ereit, hogy egy esetleges kábel átvágáskor ne süljön meg az atmega csip a visszajutó 12V-tól.

Nem optocsatolo kell neked hanem ttl-rs232 konverter. Nezegesd a MAX232-t es csaladtagjait (boseges a valasztek).
A tavolsag miatt amugy en is inkabb RS485-ot javasolnek (MAX485 es tarsai)

Meg sikeredett oldani a problémát, leírnám ide a megoldásom, ha valaki másnak is hasonló gondja akad, kéznél legyen egy lehetséges adatküldési/fogadási módszer.

A forrást a neten találtam, majd átalakítottam olyan formára, ami számomra szükséges.
Az adatküldés adat tömbként történik.
Az adattömb 1-el nagyobb mint amennyi adatot szeretnénk küldeni, mivel az utolsó tömbrészlethez fűzi hozzá a záróbitet.
Ez a kiolvasási módszer nem akasztja meg a programot a kiolvasás idejére, így nem csúsznak tőle a softwareSerial porton küldött adatcsomagok sem.

Adó oldalon:


Adat vételi oldalon:


Int változókat küldök, és fogadok, majd ennek állapotát dolgozom fel.
Az adatküldés byte-ként történik.

Köszönöm, rálesek.

Első ránézésre egy baja van, a lezáró byte 3e nem fordulhat elő az adatcsomag belsejében. Próbáld ki. De lehet tévedek

Még valami... Egy soros portra hogy fűződ fel a sok eszközöd? Az rs232 nem tudja, az rs485 alkalmas rá.

Így igaz, nem fordulhat elő, esetemben nem is fordul elő.

Érdekes. Ez a vevő igaz?
Ha párhuzamosan tolod neki akkor is jó igy kábelen lógatva, mert most más az irányultsága, kisebb ?
Kis teljesítményen jó a NYÁK-on is? Mekkora távot kell áthidalni egyébként, lehet, hogy nagy teljesítményhez közel van?

Légy szíves, kód bevitelekor a hozzászólás író ablakban használd a "Kód" gombot!

> Urak, eddig csak 1 ember volt kedves segítséget nyújtani
Egyrészt türelem! Másrészt pedig ilyen ez a popszakma

> az atmega328p csip köré van építve a 2 panel.
Első kérdés az órajel? A serial nagyon érzékeny a pontos órajelre. Kvarccal stabilizált órával járnak a csipek? Ha nem, akkor általában működik, de a csip specifikációja szerint adott szórás szerint előfordulhat, hogy hibázik, ráadásul leginkább a hőmérséklettől függ.

Az általad használt eredeti protokoll megvalósítás hibája az, hogy ha egyetlen hiba is becsúszik, akkor hibaállapotba ragad a rendszered. Általánosságban minden protokollt úgy kell megvalósítani, hogy tranziens hibából fel tudjon állni a rendszer.

Én így szoktam:

* A vevő az első vett bitnél elindít egy timeoutot, és ha ez lejárt, akkor hibásnak veszi az adott kört. A bejövő puffert üríti, és várja a következő periódust.
* Az üzenetet CRC-vel (vagy egyéb ellenőrzőösszeggel) védeni kell. Ha nem jön ki az üzenet CRC-je, akkor szintén hibának jelöljük és eldobjuk az eredményt.

Keveset hibázó csatornán ennyi elég is, ha viszonylag ritka periódussal kommunikálunk. Ha növelni kell a jelsebességet hibázó csatornán, tehát önmagában a timeout+CRC nem elég, akkor önszinkronizáló protokollt lehet fejleszteni, illetve hibajavító kódolást alkalmazni. De ez bonyolultabb, és ide nem is kell.

Ahogy mások is írták többszáz métert 0-5V jelszinttel meghajtani nem éppen életbiztosítás. Én is csináltam már hasonlót ráadásul 1 vonalon busz rendszerben, de csak játszós projekten. És az is inkább 50m volt összesen, nem többszáz. Ha valaminek megbízhatónak kell lenni, akkor szerintem nem elfogadható, hogy már tesztüzemben is billeg, aztán ki tudja milyen zavarok jönnek később. Érdemes ránézni a jelre szkóppal: egy tesztprogramban írj olyat, ami teljesen periódikus kimenetet ad (0b01010101 vagy 0b10101010 bájt küldése ahogy a csövön kifér), erre szkóppal ránézve látod, hogy mennyire szögletes és mennyire kerek a jel a vételi oldalon, és ebből lehet következtetni, hogy van-e tartalék a rendszerben. A jelsebességet érdemes csökkenteni addig ameddig csak engedi a hardver, illetve az adatsebességed. (Vigyázat: ha órajel problémád van, azon nem segít a jelsebesség csökkentése!) De végsősoron rendes szabványosan összerakott buszt javasolnék én is, ahogy a többiek is írták.

Az optocsatolót én is jó gondolatnak tartom, mert nem akarod, hogy a vezetéken keresztül esetleg a riasztás előtt már meg lehessen ölni a központot! Persze az optocsatoló ehhez önmagában nem elég, a tápon keresztül nem lesz teljes galvanikus függetlenséged szerintem. De ezek már azok a részletek, amik miatt egy profi rendszert nagyon nehéz leutánozni házilag. Azokban rengeteg év tapasztalata benne van jó esetben.

Igazán szép az a megoldás talán, ha netkapcsolaton keresztül periodikus életjelet ad a rendszer egy máshol üzemeltetett szerverre, és ennek az életjelnek a megszűnte is riasztásnak számít. Ezzel viszont az a baj, hogy jó sok fals riasztásod lesz, mert a net azért szakadozni szokott...

Szerintem az I2C, SPI stb átállás nem segítene rajtad, hiszen itt is elvi hibás volt a program, ott is hasonló lenne. A problémát legtöbbször érdemes a megkezdett úton megoldani, de az RS485 meghajtót szerintem nem fogod tudni kispórolni.

Sziasztok

Visszatérve a régebbi kérdésemre ahol azt kérdeztem ,hogy "Egy nanó és egy 16x2 karakteres LCD-n gyakorlatozok de nem sikerül úgy szöveget görgetni , hogy pl 2. sor 10. karaktertől kezdje és csak 3 karakternyi helyen fusson a szöveg (11,12,13 karaktereken). " Most találtam egy módot LCD kijelző ahol leírják, hogy lehet karaktereket görgetni leftToRight() rightToLeft(), de azt nem, hogy hogyan. Ebbe tudna valaki segíteni?

Tudtommal görgetni csak egész sort lehet a kijelzőbe épített vezérlő segítségével, egyébként neked kell megoldani a dolgot, programból.

Egyébként nem olyan borzasztóan nehéz ám ez a görgetés! Én ezt csinálnám:
Kell egy sztring, ami a felvezető szóközöket tárolja (vagy bármit amit akarsz helyette), legyen start.
Kell a forrás sztringed amit görgetni akarsz. Kell egy számláló integer (mondjuk legyen i), amit nulláról indítasz, ő fog indexelni. Kell egy függvény, ami a megadott sztringből kimásol neked x karaktert (jelen esetben hármat), i pozícióból. Az eredeményt összefűzöd a start sztringeddel, és már mehet is ki az lcd-re. Következő iterációban megnöveled az i indexet, hogy a következő három karaktert kapd meg. Értelemszerűen ezt egy ciklusban érdemes. A ciklus addig megy amíg a forrás sztringed végére nem értél. Ekkor nullázod, mehet elölről. És ennyi. A járulékos igények bonyolíthatják el, maga a görgetés ennyiből megvan.

Sziasztok. Volna egy projectem amiben segítségeteket kérném:
Adott egy arduino nano, egy 100W-os Peltier modul, egy páratartalom szenzor, és egy 3. elem amit még majd itt fejtünk meg.
A project maga úgy nézne ki hogy kellene egy kicsi kamra amiben mind hőmérséklet mind páratartalom szabályozható lenne. (Csiperke-gomba törzs tenyésztéshez kellene).
Itt adódnak a gondok:
-A kamra hőmérsékletét egy értéken kellene tartani, esetleg x fázis időben jobban csökkenteni 4-5 fokkal.
-Páratartalom szabályozása, anélkül hogy felmelegítsem a bent lévő levegőt (érzékeny rá a gomba).
-És ugye friss levegő bejuttatása (ez csak akkor amikor már a termőtestek nagyobbak), mivel sok oxigénre van szüksége a gombának akkor már.

A főbb paraméterek amiket tudnia kellene: kb. 60-90% közötti páratartalom, külső hőtől független belső hőmérséklet szabályozása 15-25C között, szellőztetés, vagy akár majdnem hogy teljes légút elzárása (kezdeti fázisban).

Ebben a projectben kérném segítségeteket. Persze ha lehetőség van rá még egy 4x20 karakteres LCD-t is be lehet tenni az állapotok ellenőrzésére.

Érdekes projekt. A "kicsike kamra" mennyire kicsike? A páratartalmat mivel akarod állítani? A harmadik elemmel mire gondoltál? Milyen keret van rá? Mekkora a légköbméter (csak nagyságrendileg)?

A kamra kb 30L űrtartalmú.
A páratartalom az a harmadik elem ami még tervezés alatt van hogy hogyan tudnám megvalósítani (itt gondoltam vaporizálásra, piezoval történő hidegköd képzésre, párakapura...stb).
Egy max 20E ft környékén szánok rá, annyiból szerintem kényelemesen ki lehetne hozni.

És konkrétan miben kérsz segítséget? Eddig mit valósítottál meg? Miért akadtál el? Ha nem mondod, akkor rögtön belefutsz majd olyanba hogy "nem lehet", vagy hogy "tervezd át az egészet"

Amint megjön a páratartalom szenzor, megpróbálom összeállítani az alap kapcsolást kóddal, aztán már csak szabályozni kell valahogy minden értéket külön-külön.

De akkor mi a gond? Agyalásban kellene segíteni?

Legelőször is a ködképzésben kellene segítség hogy hogyan lehetne a legegyszerűbben és legjobban szabályozható módon megoldani.
Ami még lényegesebb lehet később a fogyasztás kérdése mivel ez kb 1,5 hónapon át fog éjjel-nappal menni.

60-90% elég tág tartomány ... ha csak annyi az elvárás, hogy ezen belül legyen akkor ahhoz kár ködképzésben gondolkodni. Elég egy kis perisztatikus szivattyú, ami a tartályban lévő itatós papírra pumpál egy kis vizet, ami onnan szépen elpárolog... ha meg magas a páratartalom akkor meg indulhat a szellőztető ventilátor (persze figyelni arra nehogy kint magasabb legyen a páratartalom mint amit bentre szeretnénk... ) ... Esetleg egy ejtőtartályos csepegtetős megoldás... óránként pár cseppre állítva, az estleges felesleg meg kiszellőztetve ...

Sziasztok.
Tud nekem valaki olyan kapcsolást amivel egy akkumulátor feszültségét tudom távolról monitorozni?

Keresgéltem de nem találtam csak nodemcu-val, de az is többet tud mint kéne.
Jó lenne ha egy nano elég lenne hozzá, persze ha egyáltalán elég erős hozzá és le tudja kezelni.

Vagy esetleg nem épített már valaki itt ilyet?

Maga a feladat kb. semmi. Egy feszültségosztóval az akksifeszt a uC által "fogyasztható" szintre osztod, azt pedig nézed ADC-vel az általad kívánt gyakorisággal, és elküldöd az általad kívánt csatornán. Ha az adott uC beépítettje nem felel meg, akkor használhatsz komolyabb ADC-t is, pl. ADS1115-tel szerelt modul Kínából "párszázas ajánlat", és 16 bites (amiből 15-öt használhatsz fel, mert előjeles).
A konkrét feladat ismerete nélkül nem tudom, hogy egy nano elég-e hozzá, adott esetben a nano is overkill, egy attiny25 is elég lehet.