Sziasztok, hosszú utat jártam be, sok részmegoldást, vagy forrasztással összeépíthető lehetőséggel találkoztam, és most itt vagyok, hogy megoldást találjak erre:
- összesen akár 30, legalább 10 azonos I2C / SPI szenzort tudjak olvasni, hogy ne legyen I2C ID ütközés
- el tudjam vezetni akár 30 méterig, kábelen (WiFi-s és más kábel nélküli megoldás érdektelen számomra)
- csillagpontosan kiépített 8 eres (UTP és/vagy S/FTP)kábelen is működjön az átvitel a helyiségek és a központ között
- lehetőleg egy helyiségbe elég legyen 1 kábelt vinni, és oda több szenzort tudjak bekötni, több különbözőt
- a helyiségekben, ami maximum 30 méterre van, ne kelljen Raspberry Pi vagy más SBC, hanem lehetőleg csak maga a szenzor és a szenzor adatainak továbbításához szükséges hardver legyen ott
- működjön POE-vel, vagy távolról lehessen az áram ellátást megoldani, hogy ne kelljen ott helyben tápegységet vagy erősáramot használni
- hogy milyen buszon mennek az adatok és hogyan, az nincs megkötve, lényeg, hogy szabványos, a célnak megfelelő legyen
- legyenek olyan kész hardver modulok, amiből össze lehet legózni az egészet, és maximum kábelezni kelljen, minimális forrasztással, hogy később könnyen, olcsón karbantartható legyen az egész meghibásodás vagy bővítés esetén
- előny lenne, ha SBC / Raspberry Pi jellegű 1 darab központi egységgel meg lehetne oldani az összes szenzor olvasását, vagy minél kevesebb SBC-vel
- a helyiségenként 1-1 "SBC UTP/RJ45-ön és rajta a szenzorok" útnál kevesebbet fogyasztó alternatívát keresek
Ennek a témának az elődje, sok jó és hasznos és olcsón kivitelezhető javaslattal, azonban nem kész modulokból összerakva: CAN busz (+SPI converter) és Raspberry Pi topológia, működés, kiépítés Ha rutinosabb lennék forrasztásban, mikrokontrollerek programozásában, készítésében, akkor már a linkelt témában felvetett megoldásokkal meg tudtam volna oldani. Köszönöm ezúton is mindenkinek, aki ott hozzászólt, mert sokat segített.
Még nem találtam meg biztosan a megoldást, most itt tartok a tervezésben, megvalósítási javaslat ábrája V0.2.1:
Felhasznált eszközök:
Vezérlő, szenzor lekérdező SBC:
SeeedStudio BeagleBone Green
https://beagleboard.org/green
I2C busz csatlakozás 4 eres csatlakozóval, bár ez GPIO-ra kötve az I2C-t elhagyható lenne:
Grove Base Cape for Beaglebone v2.0
https://www.seeedstudio.com/Grove-Base-Cape-for-Beaglebone-v2-0-p-2644…
Megoldás, hogy ne legyen I2C ID ütközés:
I2C Hub 1 to 6 Expansion Unit (TCA9548A)
https://m5stack.com/products/pahub-unit
(vagy a 8 csatornás változata, hogy ne legyen I2C ID ütközés: )
SparkFun Qwiic Mux Breakout - 8 Channel (TCA9548A)
https://www.sparkfun.com/products/14685
I2C-ből RJ45, max 30 méter kábel, majd újra egy ilyen átalakító és újra I2C:
SparkFun Differential I2C Breakout - PCA9615 (Qwiic)
https://www.sparkfun.com/products/14589
I2C elosztó, hogy ne kelljen forrasztani, csak beledugni a kész kábelt és szenzorokat:
Grove - I2C Hub
http://wiki.seeedstudio.com/Grove-I2C_Hub/
Kábel:
Grove - Universal 4 Pin Buckled 20cm Cable (5 PCs pack)
https://www.seeedstudio.com/Grove-Universal-4-Pin-Buckled-20cm-Cable-5-…
Példa szenzor 1:
Grove - Temperature, Humidity, Pressure and Gas Sensor (BME680)
https://www.seeedstudio.com/Grove-Temperature-Humidity-Pressure-and-Gas…
Példa szenzor 2:
Grove - Light Sensor v1.2
https://www.seeedstudio.com/Grove-Light-Sensor-v1-2.html
UTP / S/FTP kábelek RJ45-ös csatlakozóval
Van bármi észrevételetek, hogy ez így megfelelően működne-e?
Melyik részét csinálnátok máshogy? (úgy, hogy a téma elején részletezett igények teljesüljenek)
Köszönöm.
Hozzászólások
Szia!
Úgy látom ezt elég szépen összelegóztad. Ez a differenciális konverter külön tetszik.
Ugyanakkor háromszor meggondolnám, hogy I2C-ből ekkora rendszert építsek-e? Egyszerűen magát a buszt nem erre találták ki.
Engem lejobban ezek a differenciális konverterek aggasztanak: az I2C kétirányúvá alakítása ritkán problémamentes, főleg nagy kiterjedésű rendszereknél, elsősorban a szórt kapacitás miatt.
Ez az I2C HUB (valójában inkább switch) nagy ötlet, ezzel még akár működhet is.
Az UTP-hez miért ragaszkodsz? Később ethernet upgrade vagy az ár miatt?
Én magam ennél kicsit konzervatívabban álltam neki a saját megoldásomnak, de nálam mások voltak a szempontok. Sajnos én még eszközöket nem tettem fel, csak a kábelezést csináltam meg.
Én RS-485-höz húztam be 4 eres árnyékolt csavart érpárat, busz kialakításban. 2 éren megy majd az adat, másik kettőn 24 V.
Szia, köszönöm a válaszod és külön jó, hogy le merted írni az aggályaidat, mert neked több a tapasztalatod biztosan az I2C-vel, mint nekem.
"Ugyanakkor háromszor meggondolnám, hogy I2C-ből ekkora rendszert építsek-e?"
Én nagyon sokat gondolkoztam rajta, a CAN busz jellegű vagy az Ethernet jobban tetszene, de nem találtam olyan összelegózható megoldást, aminél:
- Ethernet-en POE-n van egy mini adapter / modul, amire rákötöm az 1-3 I2C vagy SPI szenzorom, és lekérdezhető RPI-ről simán.
- CAN BUS / ModBus-hoz sem találtam olyan kész modulokat, amiből RPI-n tudnám könnyen a szenzorokat kezelni, I2C ID ütközést is kezelve. Nem szeretnék úgy összeforrasztani valamit, hogy nem teljesen értem az egész működését. Meg tudnám csinálni, de nem szeretném.
Ez a téma is még a további lehetőségek keresése miatt jött létre.
Nem akarnék helyiségenként egy RPI jellegű gépet oda rakni, nekem overkill-nek tűnik egy 4 core / 512-1024 MB memóriás, operációs rendszeres miniszámítógépet fenntartani 1-3 szenzor 1 percenkénti lekérdezésére. Egyszerűen elvből zavar, hogy egy ilyen SBC-re nagyon sok komoly feladatot rá lehetne bízni, és ott fog működni 0.02-es load-dal, üresjáratban, talán még az 1 core-t sem használja ki teljesen, csak a Linux-ok szükséges működése: log-ok írása, file rendszer kezelése, a millió mindenre alkalmas kernel alig valamire használata. Tudom, bővíthető, stb, de akkor is.
Annyit tudtam egyszerűsíteni, hogy a közeli helyiségekben lesz 1 RPI, és úgy 1-3 helyiség szenzorai lesznek megoldva. Oda végülis ezek az extenderek jók lehetnek, mert összesen 3-6 szenzor lesz csak, távol csak pár darab, nem 30.
Tehát ezt a fajta működést pár szenzorra javasolnád, vagy arra sem találnád alkalmasnak?
Írok konkrét példát, kérlek erre mondj szerinted reális működési megbízhatóságot:
RPI jellegű SBC-re kötök, aminek van 2 I2C busza:
- 2-3 méterre 1-2 szenzort (I2C busz #1)
- 3-4 méterre 1-2 szenzort (I2C busz #1)
- 2-3 méterre 1-2 szenzort (I2C busz #2)
- 4-6 méterre 1-2 szenzort (I2C busz #2)
Ha kell, I2C buszonként az 1-2 szenzorhoz rakok ilyet, ami messzebb van, a közelebbihez nem:
2x SparkFun Differential I2C Breakout - PCA9615 (Qwiic)
https://www.sparkfun.com/products/14589
SPI-n te hány méterre vinnél el 1-2 szenzort?
Ez így működhet szerinted megbízhatóan?
Jön a szokásos hardver keresésem, hátha jó lesz bármelyik ide:
Ethernet LAN Module ENC28J60 Network RJ45 SPI Arduino UNNA003O 2560 AVR ARM PIC - NA052
https://rees52.com/wireless-and-iot/11-na052
ENC28J60 hálózati modul bővítőkártya Arduino Internet a dolgok SPI RJ45
https://azsiacenter.com/elektronika/enc28j60-halozati-modul-bovitokarty…
diymore ENC28J60 Ethernet Shield for Arduino Nano V3.0 RJ45 Webserver Module 51 AVR SPI PIC STM32 LPC
https://www.amazon.co.uk/diymore-ENC28J60-Ethernet-Arduino-Webserver/dp…
https://www.tweaking4all.com/hardware/arduino/arduino-enc28j60-ethernet/
"Az UTP-hez miért ragaszkodsz? Később ethernet upgrade vagy az ár miatt?"
Mert CAT6A / CAT7A van kiépítve jelenleg csillagpontosan, több is, helyiségenként a szükséges hálózati kapcsolaton felül, ilyen célra.
Tehát a kész kábelezéshez keresek észszerű megoldást a szenzorok olvasásához. Továbbá lesz RPI alapon multiroom audio is pár helyiségben, de az az egyszerűbb része, csak gondolkozom, hogy mennyire kombináljam azt, hogy az 60w-os erősítős RPI-t 0/24-ben járatom, az ütemezett bekapcsolás, zene, majd kikapcsolás helyett.
"Én RS-485-höz húztam be 4 eres árnyékolt csavart érpárat, busz kialakításban. 2 éren megy majd az adat, másik kettőn 24 V."
Igen, többen ezt javasolják, csak nem találtam olyan megoldást, ahol kész modulokból össze tudnám rakni ezt a fenti dolgot.
Miért 24V? A szenzoroknak hány V fog kelleni, és milyen módon fognak ezen az érpáron kommunikálni?
Sakk-matt,
KaTT :)
"Tehát a kész kábelezéshez keresek észszerű megoldást a szenzorok olvasásához."
Vagyis gombhoz a kabátot.
"Miért 24V? A szenzoroknak hány V fog kelleni,"
Azért, mert a drótnak, a szoftverrel ellentétben fizikai tulajdonságai vannak. Jelen esetben ellenállása.
Ha adott teljesítményt akarsz elvinni távolra, akkor nem szeretnéd, hogy a villanyod a drótot fűtse.
Nagyobb tápfeszültséggel indulva kisebb áramok lesznek a dróton, tehát a konstans ellenállásán kevesebb veszteséged lesz. (De ezt tanultad általánosban fizikából.)
A kérdésed második fele jó. Bármekkora is a szenzorok feszültsége (5 V vagy 3.3 V), azt ott helyben állítod elő, kapcsolóüzemű táppal, annak meg mindegy, hogy 10 V-ot kap vagy 22-t.
"Vagyis gombhoz a kabátot."
Eldöntöttem, hogy ilyen gombokat akarok, néztem hozzá sok színt, amivel jó, és igen, a gombok megvétele után var(rat)om meg kabátot.
Kértem több cégtől okos otthonra árajánlatot régebben, és ők azt mondták, hogy vagy körben húznak ki egy kábelt busznak vagy még jobb, ha csillagpontosan van a helyiségekben plusz UTP. Én az utóbbit választottam és azt valósítottam meg.
Tehát a leginkább ajánlott megoldáshoz való kábelezést valósítottam meg, de ettől még ha akarnám a helyiségenként körbe buszt is ki tudnám vitelezni, de nem akarom.
Tetszik a csillagpontos rendszernek a hibatűrése.
"Azért, mert a drótnak, a szoftverrel ellentétben fizikai tulajdonságai vannak. Jelen esetben ellenállása.
Ha adott teljesítményt akarsz elvinni távolra, akkor nem szeretnéd, hogy a villanyod a drótot fűtse.
Nagyobb tápfeszültséggel indulva kisebb áramok lesznek a dróton, tehát a konstans ellenállásán kevesebb veszteséged lesz. (De ezt tanultad általánosban fizikából.)"
Igen, erre tippeltem én is, hogy ezért, amit leírtál.
Ugyanez van a 12V és a 24V LED-es világításnál, ledszalagoknál, hogy egy nagyobb helyiségben jelenősen jobb a hatásfok a 24V miatt, mintha 12V lenne. 12V esetén több wattot fogyaszt, és annál többet, minél hosszabbak a 12V-os kábelek.
Sakk-matt,
KaTT :)
Az én tapasztalatom az, hogy az igazság a két megoldás között van. Van, amit központba kell kötni, van, amit nem. A mi házunkban rengeteg kábel lett, ha ismét építkeznénk, nem így csinálnám (legalábbis sok kérdést átbeszélnék normális/nyitott/agilis villamos tervezővel). De akkor még nem tudtam, ráhagytam arra, aki elvileg ért hozzá.
Egy-egy konkrét problémát meg lehet oldani egyedi barkács megoldással, de a dolog nagyját én biztosan "dobozos" megoldásból raknám össze.
Azaz, konkrétan mit? :)
Sakk-matt,
KaTT :)
Amire van "gyári" megoldás, azt gyári megoldással csinálnám, minél kevesebb vezeték és kütyü kelljen. Annál kevesebb időd megy el rá, probléma esetén annál hatékonyabb a javítása. Néhány év múlva (mikor benned sem lesz friss az információ) neked is problémás lesz hiba esetén megoldást találni. Arról nem beszélve, hogy adott esetben megfelelő kütyüt is elő kell kotorni valahonnan.
Ami a topológiát illeti: minden lámpát nem vezetnék be a központba, (nagy részüket) helyi aktorokkal kapcsolnám. Rengeteg kábelt meg lehet spórolni + ahova nem terveztél csillár kapcsolós dolgot, később oda is tudsz ilyet tenni. De ez csak egy példa és sok minden függ az alaprajztól is, az igényekről nem is beszélve. Vezetéket stb. nyilván méretezni kell, tehát villanyász közreműködés mindenképpen szükséges (én legalábbis nem értek hozzá eléggé és nem is akarok).
Megfeledkeztél a 24kW teljesítményű, folyamatos üzemű dízelgenerátorról. ;)
Nyilvánvalóan az aktív állapotban mA alatti áramfelvételű 3,3V/5V-os szenzoroknak iszonytató fogyasztása lesz a több percenként történő lekérdezés végett. :-D
Itt a legnagyobb fogyasztó a busz, ahol a meghajtók "végsebessége" 30mA. Egy ág fogyasztása kb. 3,3V/7-8 mA. Azok is csak a lekérdezés ideje alatt mennek, és egyszerre csak egy vonal. Ilyenkor csúcsban megduplázódhat a teljesítményfelvétel.
Szóval erőmű!
Kapcsolóüzem ilyen kis fogyasztásnál nem gazdaságos. Helyette pl. söntstabilizátort érdemes alkalmazni.
az I2C kétirányúvá alakítása
Az már eleve kétirányú. :)
tr '[:lower:]' '[:upper:]' <<<locsemegeLOCSEMEGE
Engem lejobban ezek a differenciális konverterek aggasztanak: az I2C kétirányúvá alakítása ritkán problémamentes, főleg nagy kiterjedésű rendszereknél, elsősorban a szórt kapacitás miatt.
Ő legalább értette miről ír. ;) Bár a problémát nem a driver differenciális volta okozza, hanem a három "logikai szint". Ha a driver két oldalán nem hasonló a slew rate, akkor a driver visszapofázik. Azaz nem lesz kétirányú. :)
Szóval egy 3m kábelre tervezett Fm+ drivert a 20m kábel meghajtásához megfelelően le kell lassítani.
majd szépen megveszed ezeket, összerakod az asztalon, ebben a kapcsolásban annyi SW munka lesz, hogy megőrülsz, instabil lesz, aztán beépiteni nemtudod, mert sedoboz, semmi, ha meg bekokecolod majd jól nem fog működni. az i2c NEM ERRE VALÓ. ezek az összeparintós grove szarok asztalra valók, aztán meg a fiokba. kidobott pénz meg idő egy hőmérsékleté, amit kész bóti eszközökkel is lehet mérni. Páratartalmat mérni egy szobába meg majd rájössz két nap után, hogy felesleges.
az is érdekes, hogy egy darabos szarnál mindenki erőlködik az rpivel, időt nem kímélve az igénytelen és lassu python scriptekkel, mert olyan munkát én ki nem adnék a kezemből, mikor ott vannak x86os sbc-k, igaz picit drágább, de ipari, atomstabil, msatával, gyors mint a zállat. aztán rs485...
az ilyen technologia, ha megveszed, majd a kukába/fiókba/doboz alján végzi, mert lehetetlen belőle jót csinálni. arra van kitalálva, hogy asztalon szórakozz.
egy házba sokévre betenni ostobaság.
------------------------
uint8_t *data; // tipussal megszorozzuk az adatot. wtf?
istenemre mondom, felgyorsítom a projectet, és megcsinálom a kapcsolodobozba szánt stm32-es rs485-ös ötletemet, amit szabadon programozhatsz.
------------------------
uint8_t *data; // tipussal megszorozzuk az adatot. wtf?
Köszönöm a lehetőséget, most megint triviálisnak tűnő kérdéseket fogok feltenni, amiből nyilvánvaló lesz, hogy nem értem a pontos működési folyamatot ezzel:
Veszek X darab ilyet, 5 ezer Ft / darab áron:
STM32 Industrial Development Board STM32F103VET6 CAN RS485 Minimum system ARM L
https://www.ebay.com/itm/STM32-Industrial-Development-Board-STM32F103VE…
vagy ilyet:
NUCLEO-L452RE-P - Development Board, Nucleo, STM32 MCUS, Arduino Uno Compatible, On-Board Programmer
https://hu.farnell.com/stmicroelectronics/nucleo-l452re-p/dev-board-nuc…
Vagy inkább itt még olcsóbb, pár száz forintos áron:
stm32f103c8t6
https://www.aliexpress.com/w/wholesale-stm32f103c8t6.html?switch_new_ap…
Leírás hozzá:
http://digipak.org/product/stm32f4-discovery-arm-cortex-m4-processor-ki…
És végre egy adatlap:
http://www.st.com/web/en/resource/technical/document/datasheet/CD001615…
Tehát erre illeszted az RS485-öt... és aztán?
Hogy, milyen módon fogom látni RPI-n ezt a kis ARM-ot?
Milyen nyelven és módon kell megoldanom a rádugott I2C vagy SPI-s szenzorok támogatását ARM-on?
Konfigurálni kell? Programozni ARM-on? Hogy töltöm rá a frissítést?
Le fogom tudni kérdezni az ARM-ot, vagy lekérdezi a szenzort X időnként és elküldi valahogy valahova?
RPI-n bekapcsolom az I2C/SPI adatbuszt (ha még nem volt), letöltöm a gyártó által javasolt példa Python vagy más kódot, és le is tudom kérdezni a szenzort, a kimenetét pedig bármibe be tudom tölteni. Van sok tool amivel az adatbuszokat tudom nézni, lekérdezni.
Vagy RPI-n a Home Assistant config-ban bemásolok 5-15 sornyi paramétert (beállítom a szenzor I2C ID-t például), és már támogatja is a szenzort I2C/SPI-n, kész.
RPI-n ennyi a támogatott szenzor szoftveres része, pár tíz perc maximum, teszteléssel.
Mennyi időre tippelnéd, ha elkészül az STM32+RS485 hardvered, hogy a rá kötött 3 szenzort látni fogom Home Assistant-ban I2C-n vagy SPI-n vagy bármilyen más támogatott módon, mert be tudtam mindent állítani/programozni?
Sakk-matt,
KaTT :)
"majd szépen megveszed ezeket, összerakod az asztalon, ebben a kapcsolásban annyi SW munka lesz, hogy megőrülsz, instabil lesz, aztán beépiteni nemtudod, mert sedoboz, semmi, ha meg bekokecolod majd jól nem fog működni. az i2c NEM ERRE VALÓ. ezek az összeparintós grove szarok asztalra valók, aztán meg a fiokba"
Köszi hogy ezeket leírod. Mivel én jelenleg az asztalon játszom ezekkel, és látom bennük a potenciált, a célt, így MÉG nem tudom, hogy 0/24-ben hogy működne. Nyilván igazad lehet, mert biztos nem viccből írod.
"kidobott pénz meg idő egy hőmérsékleté, amit kész bóti eszközökkel is lehet mérni. Páratartalmat mérni egy szobába meg majd rájössz két nap után, hogy felesleges"
Ezzel nem értek egyet, máshogy működünk. Nekem erre van igényem, és meg akarom valósítani. Az más, hogy később lehet, hogy én is arra jutok, amire te, de lehet, hogy nem.
"az is érdekes, hogy egy darabos szarnál mindenki erőlködik az rpivel, időt nem kímélve az igénytelen és lassu python scriptekkel, mert olyan munkát én ki nem adnék a kezemből, mikor ott vannak x86os sbc-k, igaz picit drágább, de ipari, atomstabil, msatával, gyors mint a zállat. aztán rs485..."
Rendben.
Kérlek akkor írj konkrét terméket, te erre a célra ipari x86 alapon hogy oldanád meg.
Moxa szintű ipari PC-re gondoltál? Például:
https://moxa.hu/termekek/2119/-V2403-sorozat
https://www.moxa.com/en/products/industrial-computing/x86-computers/v24…
https://www.moxa.com/en/products/industrial-computing/x86-computers
vagy másra?
Ha ennyire nem jó szerinted az én megoldásom, kérlek írjad le konkrét termékekkel, hogy lenne jó szerinted:
1 - milyen fő szervert javasolsz pontosan
2 - milyen OS-t javasolsz a fő szerverre, azt mennyi idő beállítani
3 - hogy oldod meg a csillagpontosan kiépített CAT6A/CAT7A kábelekkel, hogy milyen eret mire használsz, vagy legyen RJ45 UTP és aztán?
4 - mit raksz a helyiségekbe behúzott CAT6A/CAT7A kábelekre
5 - milyen szenzorokat tudok használni, kombinálni, kerek URL-t a terméklistáról
6 - hogy kell bekötni ezeket a szenzorokat? lesz bármilyen szenzor ID ütközés?
7 - milyen szoftverrel, hogyan tudom elérni a szenzor adatokat
8 - hogy, milyen nyelven kell konfigurálni / programozni
9 - te kb mennyi idő alatt raknád össze készre a hardver részét, és mennyi kb idő alatt a szoftver részét, 8 helyiség, 24 szenzor esetén?
Ezek után jobban fogom látni, hogy miről is beszélsz, de jelenleg csak mutogatsz egy nagy homályos, sötét lyukba... :)
Sakk-matt,
KaTT :)
jelképes 10e ft/óra+áfa (min 3óra) díjért megosztom veled 7 évnyi ipari mérés/adatgyűjtésben/process control szerzett tapasztalatomat. :) annyit elárulok, hogy pythont sose/sehol nem használtunk, de c-t viszont annál inkább. meg tudunk irni device treet/kernel modult embeddedhez(beaglebone black), hogy kernel szinten legyen pwm hardware motorhoz, amit sysfs-en kereszül akár bashból 8GB python nélkül is lehet kapcsolni. pl így:
/ {
motor1 {
compatible = "pwmoutput";
pwms = <&ehrpwm1 0 200000 1>;
pwm-names = "default";
enabled = <1>;
duty = <100000>;
status = "okay";
pinctrl-names = "default";
pinctrl-0 = <&P9_14_pwm_pin>;
};
motor2 {
compatible = "pwmoutput";
pwms = <&ehrpwm2 0 200000 1>;
pwm-names = "default";
enabled = <1>;
duty = <100000>;
status = "okay";
pinctrl-names = "default";
pinctrl-0 = <&P8_19_pwm_pin>;
};
};
a pwmoutput kernel modul 300 sor.
de ugyaingy van impulzus számláló kernel modul, amit szintén sysfs-en keresztül érsz el sima cat paranccsal.
flowmeter{
status = "okay";
compatible = "pulse_counter";
pinctrl-names = "default";
pinctrl-0 = <&P8_17_default_pin>;
gpio = <&gpio0 27 GPIO_ACTIVE_HIGH>;
unit = <1 1 3600000>; /* 1 impulus 1 liter 3600000 msra számold, vagy 2 impulzus 1 liter */
stopafter = <180000>;
};
egyszerű, gyors. vannak hasonló dolgok ADC-hez, stb....
szóval ilyen szinten ilyeneket tudok veled megosztani :)
szenzor meg bármilyen van, csak pénzl egyen. nem a 400ftos vacakon múlik hidd el.
------------------------
uint8_t *data; // tipussal megszorozzuk az adatot. wtf?
Szervusz!
Én ezt kicsit máshogy csinálnám. ha van ethernet akkor minden hejségbe tennék egy arduinót és ethernet mosullal szolgálnám ki az rpi-t. Ez nálam remekül bevált. Az enc chip egyépként kíváló modul ha tudod használni. A tápelátást én pasiv poe módszerrel oldottam meg. Ha ezt az utat választod két oldalról is megoldhatod a lekérdezést. Szenzort leolvassa az arduino és figyeli az időt. Ezesetben beküldi az adatot akár a szerverne hogy miként azt te döntöd ell. Másik eset mikor a szerver kérdezi le az állapotokat. Ha jól értem a fényszenzor esetén akkor neked az lenne az irdomos ha veleki felkapcsolja a villanyt akkor erre az eseményre ő beküldi az új státuszt. És még plussz jó hogy azt kötsz a mikro kontrollrthrz amit csak akarsz és a távolság is kevésbé problémás. Pér infó: OneWire én hóztam el 200m re is igaz két megszakítással ds18b20 szenzort és működik stabilan többéve... I2C problémásabb szűrővel eddig maxumum 20m volt a stabil... Igaz tovább nem is akartam. SPI én 10m nél tovább sosem akartam vinni. Egébb lehetőség ha az ethernet nem jó akkor az arduinoval lehet késziteni saját I2C eszközt akár master-slave vagy master-master módban. Nem egy leányálom de működik. Bárki bármit mond az avr ezenbelül az arduinó igen is képes akár az iparban is helyt állni. Központak nekem elég volt egy OrangePi Zero is teljes veb font-end el. Igaz nem loggolok bár ezis könnyen megoldható lenne.
Remélem tudtam segíteni merre indulj!
Sok sikert!!!
Szia,
szóval veszek:
GENUINO ZERO
https://store.arduino.cc/genuino-zero
ARDUINO ETHERNET SHIELD 2
https://store.arduino.cc/arduino-ethernet-shield-2
Nincs benne POE, ezért veszek hozzá POE modult:
POE MODULE 12V
https://store.arduino.cc/poe-module-12v
Ráforrasztom a POE-t az ARDUINO ETHERNET SHIELD 2-re, így lesz POE.
POE switch-nek:
TP-Link 5 Port Gigabit PoE Switch
https://www.amazon.com/TP-Link-TL-SG1005P-Gigabit-Ethernet-compliant/dp…
Majd a GENUINO ZERO-ra rakom az I2C / SPI szenzorokat.
"Ha ezt az utat választod két oldalról is megoldhatod a lekérdezést. Szenzort leolvassa az arduino és figyeli az időt. Ezesetben beküldi az adatot akár a szerverne hogy miként azt te döntöd ell. Másik eset mikor a szerver kérdezi le az állapotokat. Ha jól értem a fényszenzor esetén akkor neked az lenne az irdomos ha veleki felkapcsolja a villanyt akkor erre az eseményre ő beküldi az új státuszt. "
Tehát ahogy leírtam, így helyiségenként meg van oldva a szenzor leolvasás?
Arduino esetén hogy kell megoldani az I2C ID ütközést, ha több azonos I2C azonosítójú szenzort akarok 1 I2C buszon? Vagy rakjak külön Arduinót, és kész? Esetleg I2C-re 2 azonos szenzor (2 id-je lehetséges) és a harmadikat SPI-re, és úgy? Mert 3 azonos szenzor elég lenne egy pontra.
Sakk-matt,
KaTT :)
"Arduino esetén hogy kell megoldani az I2C ID ütközést, ha több azonos I2C azonosítójú szenzort akarok 1 I2C buszon? "
Ha egy buszon akarod, akkor ugyanúgy, ahogy PI-nél: megfelelő cél IC, amit már többször is linkeltél.
De ha nem ragaszkodsz az egyetlen buszhoz, hanem mindegyikhez másik buszt építesz, akkor megoldod szoftverből. :)
https://playground.arduino.cc/Main/SoftwareI2CLibrary/
http://wiki.seeedstudio.com/Arduino_Software_I2C_user_guide/
A Zero meg az Ethernet shield összekötésekor azért fontold meg, lehet-e gond abból, hogy a shield 5 V-os, a Zero meg 3.3 V-os.
Miért pont a 32 bites Zerot választottad, miért nem jó a mezei Uno?
Köszönöm a segítséget, a 3,3V-ra nem figyeltem.
Akkor a Zero helyett már 5V-os:
ARDUINO MEGA 2560 REV3
https://store.arduino.cc/mega-2560-r3
Olyasmi fél információt olvastam, hogy ha a csak 2 KB SRAM esetén a TCP csomagok feldolgozásával lehetnek gondok, és egyszerűen csak több SRAM-mal rendelkezőt kerestem. De a MEGA akkor az jó lesz, 8K óriási mennyiségű SRAM, és a tetejére több Shield-et is lehet még rakni, ha kell, az Etherneten felül.
Ezzel végül is teljesül, hogy alacsony fogyasztású lesz. Az más, hogy több időt kell rászánnom, mint egy RPI esetén.
Sakk-matt,
KaTT :)
Ertem en, hogy zavar, hogy mi mindenre kepes az RPi, de nem lenne megis jobb megfontolni valamelyik kb. 25$ vagy alatti RPi-ket a bohom draga Arduinok helyett?
Ismertem kollegat, aki az RPi-t csak arra hasznalta, hogy ethernetre kosse az arduino-jat, mert olcsobb volt venni egy rpi-t, mint meg az arduinora ethernet shieldet.
Aztan meg sw-ben, ha ugyis magad raksz ossze mindent kezmuves jelleggel, akkor fogsz valami szoftveres message busz architekturat (amq, rabbit, ...) azok raadasul meg tudnak elosztottan is mukodni.
Meg irsz helyben valami sajat sw-t ami az eszkozok meg a message bus kozott kozvetit. (Akar python-ban is, nem tudom miert huztak le annyira, hogy helyette lehet C-zni is... persze lehet... csak ido-raforditasban nem ugyanott vagy, es ahogy magad is irtad: a feladathoz kepest hatartalan mennyisegu eroforrast tol alad a raspi)
Meg irsz valami szep designos kontrol layert az egesz fole, ami meg a message busodon keresztul tartja a kapcsolatot a node-okkal.
Nem tunik oriasi, kivitelezhetetlen feladatnak.
" Nem tunik oriasi, kivitelezhetetlen feladatnak."
Persze, hogy nem az, azért vágtam bele. Ha apró alkatrészenként én forrasztgatnám össze nyákra az összes alkatrészt, és hozz az egyedi szoftvert, az úgy már túl sok idő lenne, hogy összerakjam.
Az igazi tapasztalat a 0-24-ben működés lesz majd, hogy bírja és meddig.
Sakk-matt,
KaTT :)
Szia!
Bocsánat hogy sokára válaszolok de kicsit azaz nagyon elhavazódtam.
Több lehetőség is van ezesetven is. pl az emlitett software i2c. De több szenzornak lehet a cimét általában kis cinpönyel modosítani. Én a tápot a kék/kék-fehéren és a barna/barna-fehéren szoktam eljutatni. A te esetedben ha 12V a táp és van szerelhető csatid akkor egyszerően ráteszed a betápot a beépített dc-dc konverterre. Én az enc28j60 ict preferálom egy dht22 vel nekem évekóta remekül elkalapál. Jó vannak mokoláseok meg ugye az uipEthernet könyvtárat hastználom de nem is real time a rendszrem. A mega ezek után meg a végtelenség netovábja :D . Én továbbá nem szorakoztam minden helység kapott egy arduino nano-t. meg egy hozzá való ethernet shildet végül ha nagyon kényelmes vagy akkor egy csavaros teminalt.
Nano
Ethernet modul
DC és io csavaros
Tegyük hozzá én sokat használom az Atmel alapú dolgokat szóval áll itt hogy a kardiológus mindent a szivnél keres az urologus meg ....
Köszönöm a válaszodat!
Jó olcsó ez a nano klón! :)
Ja POE Ethernet-en akarnám a nano-t üzemeltetni, elvileg a TL-SG1005P 5-Portos gigabites asztali switch 4 PoE porttal eszköz 48V-ot ad ki. Ilyen esetben, ha erre raknád a nano-t, mi kellhet még, a szenzorokon kívül?
Sakk-matt,
KaTT :)
Arduino esetén hogy kell megoldani az I2C ID ütközést, ha több azonos I2C azonosítójú szenzort akarok 1 I2C buszon?
Hasznalj ilyesmiket: PCA9546A, PCA9548A. E ketto rendre egy 4 illetve 8-csatornas I2C-kapcsolo es/vagy multiplexer. Illetve ezek egyben level translatorok is, szoval ha 5V <-> 3.3V <-> 2.7V <-> ... szintek kozott kell illesztened akkor az is megoldhato.
Köszi a javaslatokat.
Sakk-matt,
KaTT :)
Talán érdemes megnézni az esp32+poe+eth modulokat is.
Pl.:
https://www.olimex.com/Products/IoT/ESP32/ESP32-POE-ISO/open-source-har…
Szia, sajnos az ESP32-ről sem tudok sokkal többet mint az Arduinóról, így nehéz összehasonlítanom, hogy melyiket válasszam.
Az Arduinóról nagyobb dokumentációt látok, így az tűnik eddig a reálisabb útnak.
Miért az ESP32-t választanád az Arduinóval szemben?
Sakk-matt,
KaTT :)
én arduino mega-t vennék, kínait. abból is vannak jók, én a geekcreit-ot ajánlom. (sokkal olcsóbb mint az eredeti arduino). pár szenzort leolvasni bőségesen elég.
Nincs benne POE, ezért veszek hozzá POE modult:
nem kell oda POE modul, se poe switch. veszel sima cctv poe injector kábeleket olcsó pénzért ( https://www.aliexpress.com/item/32822534899.html?spm=a2g0o.productlist… )
az arduino pedig megcsinálja magának a feszültségeket a 12V-ból
én inkább elszórnék pár arduinót a házban és csak ethernet kábelem lenne, ami a kommunikációt és a tápot is megoldja. a rengeteg kábel is pénzbe meg energiába kerül.
Arduino esetén hogy kell megoldani az I2C ID ütközést, ha több azonos I2C azonosítójú szenzort akarok 1 I2C buszon? Vagy rakjak külön Arduinót, és kész? Esetleg
I2C-re 2 azonos szenzor (2 id-je lehetséges) és a harmadikat SPI-re, és úgy? Mert 3 azonos szenzor elég lenne egy pontra.
lehet használni pl. software i2c lib-et, külön pineken. az arduino megának nagyon sok pinje van.
Szia, köszönöm az infókat.
Szerinted milyen hátránya lenne, ha mégis POE lenne, például ilyen TL-SG1005P POE switch használattal, ami elvileg 48 voltot tud?
Tehát veszek egy Geekcreit® Arduino Compatible UNO R3-at, hozzá:
Ethernet Shield W5100 R3 Support PoE For Arduino UNO Mega 2560 Nano
Ez menne 48V esetén is, amit POE-n kapna: "Input voltage range 36V to 57V"
Érdekes, hogy most sehol nem találtam az Ethernet shield-hez POE module-t. Ahol volt, ott már nem gyártják, és már nincs.
Mi lehet az oka ennek?
Az hogy lehet, hogy nem gyártanak ilyen Arduino Mega / Uno jellegű hardvert alapból Ethernet + POE-vel? Mi az oka?
Azért tetszene jobban, ha 48V + POE lenne, vagy legalább 24V, hogy kevesebb áram veszne el az alacsonyabb V miatt, tehát ha csak 12V vagy 5V-ot vinnék a kábelen, előnyösebb 24V vagy 48V-ot vinni, az más, hogy mivel tudom átalakítani a megfelelő voltra.
Arduino alapon ezt hogy szokták megoldani? A linkelt CCTV POE injektor maximum 12V-on működik.
Mert TP-LINK eszközökkel például meg lehetne oldani, 48V-os POE injektor:
https://www.tp-link.com/hu/business-networking/accessory/tl-poe150s/#sp…
POE splitter / elosztó:
https://www.tp-link.com/hu/business-networking/accessory/tl-poe10r/#spe…
"én inkább elszórnék pár arduinót a házban és csak ethernet kábelem lenne, ami a kommunikációt és a tápot is megoldja. a rengeteg kábel is pénzbe meg energiába kerül."
A rengeteg kábel már adott, csillagpontosan.
Helyiségenként vagy 1-2-3 helyiségenként lenne 1 arduino, és ha a fenti splitter + inkektorral vinném oda a 48V-ot, majd 5V-ot adnék a splitterből az Arduinónak az úgy jó? A POE nélküli Ethernet meg menne az Ethernet shield-be.
Árban már ott van ez az Arduino + Ethernet shield, mint egy Orange Pi Zero jellegű gép, azonban az elméletben a szimpatikusabb az Arduino irányban, hogy ha csak 1 percenként kérdezném le a szenzorokat, akkor jóval kisebb fogyasztása lenne, mint az RPI-nek, ami folyamatosan menne.
Ezen felül jóval több idő lesz beállítani az Arduino-t a szenzorokkal, mert még nem csináltam ilyet, mint RPI-n beállítani, azt már értem és csináltam.
Szóval ez a 2 irány az, amin gondolkozom, a nyitva hagyott akár KNX jellegű, kész eszközökből való kiépítésen át, a még nem ismert utat sem kizárva... :-)
Sakk-matt,
KaTT :)
Érdekes, hogy most sehol nem találtam az Ethernet shield-hez POE module-t. Ahol volt, ott már nem gyártják, és már nincs.
ha nem lehet kapni, az elég nyomós ok kihagyni a tervből :)
Azért tetszene jobban, ha 48V + POE lenne, vagy legalább 24V, hogy kevesebb áram veszne el az alacsonyabb V miatt
azért nem olyan veszélyes az a veszteség... pl. ha az arduinodnak kell mondjuk 5 watt (ennyi nem kell, de whatever), az 12V-on ugye 0.42A. Az ethernet kábelben a drót keresztmetszete kb. 0.205 mm2, réz, az 100 méteren kb. 8.4ohm ( http://hyperphysics.phy-astr.gsu.edu/hbase/Tables/wirega.html ). Tehát neked kb. lenne 0.42^2*8.4=1.48 watt... (azt hiszem összesen 4 drót van felhasználva, de ugye a 100 méter kábel az oda vissza 200).
szóval ez a másfél watt (és ez 100 méteren) egy év alatt neked megeszik kb. 13kwh-t, ami mondjuk kb. 6xx HUF (mondom kb.).
A tp-linkes injektorod + splittered emag.hu-n: 4100 + 6500=10600HUF, tehát ebből a pénzből mehet a hőveszteséged bő tizenévig :)
De... ezzel is kisebb a fűtésszámla :)
Ami a kütyüket illeti, szvsz sokkal robusztusabb egy mikrokontroller, mint egy linuxot futtató board. Sokkal könnyebb a szenzorok timing-jait betartani, immunisabb a külső hatásokra, ha lefagyna, ott van a watchdog, sokkal gyorsabb a reboot, nem megy tönkre az sd kártya, nagyságrendekkel egyszerűbb a szoftver, nem kell kínlódni kernel/userspace mindenféle dolgokkal...
Sejtettem, hogy nem jelentős a fogyasztás különbség a 48V és a 12V között, de mondjuk 20-30 szenzor esetén, 1 km kábel esetén már... valami :)
Ez nálam inkább ilyen elvi kérdés lenne, hogy ne melegedjen az, aminél megoldható relatíve nem túl drágán, hogy ne melegedjen.
"Ami a kütyüket illeti, szvsz sokkal robusztusabb egy mikrokontroller, mint egy linuxot futtató board. "
Ez igaz. Ezért "erőltetem" ezt az irányt, csak nincs benne tapasztalatom sajnos.
"Sokkal könnyebb a szenzorok timing-jait betartani, immunisabb a külső hatásokra, ha lefagyna, ott van a watchdog, sokkal gyorsabb a reboot"
Ezek nem jelentős szempontok jelenleg.
"nem megy tönkre az sd kártya"
Ez sem, NFS-en fog működni az összes RPI.
"nagyságrendekkel egyszerűbb a szoftver, nem kell kínlódni kernel/userspace mindenféle dolgokkal..."
Hát nekem az utóbbival van sok tapasztalatom, és kb nulla az arduino / esp32 irányban.
Ezért mennék erre... :)
Sakk-matt,
KaTT :)
> Sejtettem, hogy nem jelentős a fogyasztás különbség a 48V és a 12V között, de mondjuk 20-30 szenzor esetén, 1 km kábel esetén már... valami :)
Ha a 48V->5V konvertert a mikrovezérlőhöz nem elég hatékony, akkor simán lehet, hogy végsősoron ugyanott leszel, mint 12V->5V-tal elveszted a réven, amit nyertél a vámon.
Amire kijön, hogy nem lényeges szempont, azzal érdemes úgy tervezni, hogy az egyszerűbb megoldást választjuk.
Tehát te is azt javaslod, hogy használjak egyszerű RJ45 splitter/injector-t az RPI táplálására, még akkor is, ha 5,1V/2,5A RPI tápot dugok rá, és 20-30 métert is vinni kell a POE-t? Hogy nem sokkal rosszabb, mintha a 20-30 métert 48V teszi meg, és az RPI mellett 20 cm-re alakítom le 5V-ra?
Sakk-matt,
KaTT :)
> nem megy tönkre az sd kártya
Apropó SD kártya: olyan rendszert tervezgetek éppen, hogy az RPI SD kártyája read only. Így nem öregszik.
Illetve van rajta egy logging partíció, de oda blokkonként RAW módon loggolunk, tehát nem írunk egyetlen blokkot sem sokszor felül.
Csinált már valaki ilyet?
f2fs-nek hívják szerintem.
tr '[:lower:]' '[:upper:]' <<<locsemegeLOCSEMEGE
olyan rendszert tervezgetek éppen, hogy az RPI SD kártyája read only. Így nem öregszik
Helyes! Sot, ennek kene az alapertelmezettnek lennie. Pont par honapja csinaltam meg en is ugyanezt, megy is rendesen ahogy kell.
Overlayfs-re teszed a /var-t, ahol az rw filerendszer tmpfs?
tr '[:lower:]' '[:upper:]' <<<locsemegeLOCSEMEGE
A /var is readonly, a /var/log meg a /var/run az pedig tmpfs. Ez nekunk tokeletesen eleg.
Mas, raspberry-izeknel komolyabb rendszereknel (PCengines/Alix/APU) kiegeszitettuk a rendszert FRAM-alapu blockdev-ekkel. Azt meg annyiszor es ugy irom ahogy akarom :) Viszont cserebe nem nagy (nehanyszor 100k, attol fugg mekkora modult teszunk bele). Ha barmi kritikus, alkalmazas-fuggo folyamatos loggolasra van szukseg akkor az arra megy.
Ha READ ONLY lesz az SD kártya, amiről csak BOOT van, majd NFS-ről húzza be az OS-t és NFS-re ír mindent (ami alatt RAID 1 mirror + offsite backup van), ennél van jobb javaslatod, hogy máshogyan legyen, ha adott a NAS, amiről mennek így az RPI-k?
Azon kívül, hogy SD / USB boot nélkül is meg lehet oldani a hálózati boot-ot PXE-n, TFTP + NFS használattal.
Sakk-matt,
KaTT :)
Miert ne lehetne az operacios rendszer is a vegytisztan readonly-ra felcsatolt SD-kartyan? :) Ugye tradicionalisan csak /var-ban lehetnek iras alatt levo dolgok (lasd itt: https://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard). De jobb a bekesseg es az is legyen readonly. A debian-alapu voyage rendszerekben vagy egy `remountrw` meg `remountro` parancs, ehhez hasonlot barmikor tudsz csinalni RPi-hez is. Egy klasszik deszktop rendszebren is altalaban csak a /var/log meg a /var/run van iras alatt, ha tisztan az op. rendszer dolgait nezed.
Na, es ha ezzel megvagy akkor persze NFS-t is fel tudsz huzni. De en nem tennem az operendszert oda egy ilyen esetben - hacsak valami egyeb dolog nem indokolja (pl olyan clustert szeretnel csinalni, ahol az alaprendszer is gyakran frissul/modosul/fejlesztodik).
Egyebkent meg alternativa lehet egy masodlagos SD kartya is. Amin nem a rendszer van, hanem adat(ok). Ha az leserul barmi miatt akkor a rendszered meg uzemkepes marad. Mi is csinaltunk hasonlo dolgot, konkretan RPi CM3 alapokon (dual SD card). Ez a compute module egyebkent joval stabilabb hardver mint a "klasszik" RPi boardok, vsz azert mert az USB erosen redukalt.
+1 mehet az egész readonly-ba... nekem a raspbian 8-asom teljesen readonly-ban van, a /tmp és a /var/log tmpfs, ennyi.
> Miert ne lehetne az operacios rendszer is a vegytisztan readonly-ra felcsatolt SD-kartyan? :)
Mert draga, es semmi pozitivumot nem hoz?
Egyreszt frissiteni hogy fogod? Kihuzod a kartyakat?
Mi van ha nem bootol az uj rendszerrol, kihuzod a kartyat?
Minek 2000+ ft-ot rakolteni?
En csak negativumot latok itten.
---
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....
Mert ha nem SD-n van akkor mire teszed ebben a rendszerben? Oke, vannak eMMC chipek is, amik pontosan ugyanolyan kartyakent jelennek meg az operendszer fele.
Nem az a lenyeg es/vagy hangsulyos hogy milyen mediakokon van a rendszer hanem hogy folyamatosan readonly-ban van, _kiveve_ persze ha explicit irni akarsz ra. Pl frissited, ahogy mondod :) En pl igy szoktam ezeket:
# remountrw
# dpkg --clear-avail && dselect update && apt-get dselect-upgrade
# remountro
Es akkor nem tortenhet baj, kiveve akkor ha pont menetkozben jon aramszunet. De a lenyeg hogy normalis esetben nem serulhet le a filerendszer barmilyen leallasnal is. Ami egy beagyazott rendszernel azert mas mint egy deszktop/laptop/szerver/stb esetben.
Nemtudom, nekunk jobban megerte ez a megoldas nagysagrendileg ~30 beagyazott vegyes szirszarnal (ahol aramszunet, lekapcs-felkapcs, kikapcs-visszakapcs teljesen mindennapos), mint az hogy nehanapjan egyikmasik filerendszere azt mondja hogy csutortok es aztan se kep se hang. Mert epp' manual fsck-t ker boot kozben.
nfs, network boot, rpi sorozatszam alapjan kapja az oprendszert, igy verziozva lehet fejleszteni, es kulonbozo taszkra kulonbozo oprendszer.
Egyebkent poe, igy nincs az, hogy a dobozt szet kell szedni, es sd kartyaval kell szarakodni, amit a helyszinen akar forditva is be tudjak dugni, es akkor az rpi kuka...
---
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....
"nfs, network boot, rpi sorozatszam alapjan kapja az oprendszert"
Ezt hogy, hogy rpi sorozatszámhoz mappát?
TFTP szerver sem kell?
Sakk-matt,
KaTT :)
erre nem is valaszoltam.
A tftp addig kell, amig a kernel parametert atadja.
Azaz pont a tftp mondja meg, hogy melyik nfs mappa ami kell, es itt a sorozatszam<=>nfs mappa osszerendeles.
En olyat akartam egyebkent, hogy full elosztott, barmelyik lehessen a master (aki az elso). De ez kifogott rajtam. Az egesz dhcp/tftp egyetemi oktatoszobara vagy iskolai szamitogepteremre lett kitalalva.
---
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....
Én a RAID 1-es NAS-omról akarom indítani az RPI-t, hogy arról fusson, amiről van backup. És az összes RPI-k egy helyről mennek (multiroom audio RPIk és szenzoros RPIk, aztán később lehet nem RPIk lesznek a szenzor kezelők).
Tehát több RPI esetén nem olyan egyszerű megoldani, hogy különböző mappából menjenek?
Sakk-matt,
KaTT :)
Felreertettel.
Azt nem egyszeru megoldani, hogy ki legyen a fonok, ahol fut a tftp szerver, nfs szerver, dhcp szerver.
En nalam van (most) 46 raspberry pi, de sajnos a fonokot ki kellett jelolni, pedig hardware-ben teljesen azonos a tobbivel. En olyat akartam, hogy mindegyik elindul (akar egyszerre), es aki az elso az lesz a dhcp szerver, tftp szerver, nfs szerver.
A tobbi felismeri, hogy nem nyert, es ujrainditja magat, mostmar tftp-n keresztul nfs-rol bootolva.
De az egesz nfs bootolas egy kib*szott nagy kokanyolas. Pl. ha billentyuzet be van dugva, akkor nem megy az nfs boot, mert "could not enumerate usb device" vagy valami ilyesmi. Ahol kell usb, ott most bootolas utan relevel "csatlakozik" az usb (van kulon egy rele-nyak csinalva az usb-nek).
Pedig az usb hasznos. Van csak numpad, de meg akar labpedal is, vagy speci billentyuzet, pl:
https://www.poscope.com/product/ponet-kbd48cnc/
Szoval en redundanciat akartam, kb. kinyirhatatlan setupot (ahol mondjuk egy targonca atmegy az egyiken, attol ne halljon le a masik 45, mert pl. o volt epp a master).
---
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....
Értem, köszönöm az infót. Nekem várhatóan 8-10 RPI lesz csak, abból 3-5 lesz, ami ideiglenesen fog menni a multiroom audio miatt.
"De az egesz nfs bootolas egy kib*szott nagy kokanyolas. Pl. ha billentyuzet be van dugva, akkor nem megy az nfs boot"
Nekem nem lesz semmi USB rádugva az RPI-re, headness fog menni + RJ45 kapcsolat.
Sakk-matt,
KaTT :)
"headness fog menni"
Az nálad alap.
De miert bantod a holgyet? Mi csipodott be?
---
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....
pölö az aláírása
Na jo, jo, de nem biztos hogy minden regularis felhasznalasi mod azt jelenti hogy van is internet :) Valamelyik RPi-CM3-as elektronikat peldaul ballonon tervezzuk reptetni. Na, ott viszonylag keves az NFS-felmountolasi lehetoseg. Ellenben nem baj ha barmifele brownout/reboot utan ugy be tud bootolni hogy garantalt hogy a rendszer egyben marad.
Jó, azért a ballonon reptetés nem egy átlagos felhasználás... :)
Bár néha úgy érzem, hogy UTP kábelen lévő eszközökről szenzorokat olvasni hasonló kihívás, mint a ballonon reptetés... :)
Sakk-matt,
KaTT :)
Te választottad ezt a megvalósítást.
Tudom, és nagyon izgatott vagyok változatlanul, hogy mennyire, hogy fog működni az egész. Köszönöm neked is a sok észrevételt, mert nem kérdés, hogy jogosak.
Ha egy álom lenne ez az egész, akkor a te hozzászólásaid szimbolizálnák az "árnyék" szerepét, ami nagyon fontos tud lenni, hogy legyen és létezzen. C.G. Jung - Az ember és szimbólumai című művére utalok ezzel.
Érkezik lassan 2 ilyen I2C - RJ45 átalakító, tesztelni fogom, több szenzorral, több kábellel, hogy miként működik 0-24-ben, és megírom majd.
Sakk-matt,
KaTT :)
Azt mesélted, a kábelezésed csillagpontos.
Felteszem, egyetlen csillagpontba fut be az összes.
Akkor ezzel azt éred el, hogy kábel végéről annak a pár, ráköthető szenzornak a jelét beviszed a csillagpontba.
És?
Ott mit kezdesz a 20 szenzor jelével? Milyen cucc fog szenvedni az egyforma címek kibogozásával?
Szia, gyorsan a lényeg: a csillagpont vége, a kábelek ott vannak minden helyiségben, viszont példaként ha az egyik helyiség falán felül az álmennyezetben van az SBC, akkor kb 1-1,5 méterre ott a másik helyiség is (a fal túloldalán), így nem használom a csillagpontosan kihúzott kábelt erre, hanem másra lesz használva, ha az előző helyiség csillagpontosan kihúzott kábele elegendő rá. És ha 3 helyiség sarkában van az SBC, akkor 3-ba be tudom húzni hasonlóan 1,5-2 méter kábellel és a másik 2 csillagpontosan kihúzott kábel nem erre lesz használva. Így kevesebb SBC is elég. Ez miatt tesztelem az I2C-RJ45 átalakítót, hogy akkor az egyik I2C interfészen lesz az extender, a másik I2C interfészen pedig a 2-3 közeli szenzor. Hamarosan kipróbálom a gyakorlatban, hogy mennyire stabil így 0-24-ben, olyan hosszú kábelekkel, ahogy élesben is lenne. Írok, ha van valami tapasztalat. Előbb érjen ide minden alkatrész... :)
Sakk-matt,
KaTT :)
Jó, és mi van kábelek másik végén, a csillagpontban?
Végül is a kastély összes helyiségének szenzorait oda végződteted, nem 24, csak 6 kábelen. :Đ
A csillagpont közepén egy vezérlő RPI van (TFTP + NFS-en boot, és NAS/SAN-on van minden adat + backup), ami gyűjti az adatokat, a lekérdező RPI node-ok a terv szerint nem tárolják az adatokat, hanem egyből továbbküldik. Ha később kevés lesz az RPI, akkor lesz valami iparibb PC, ami lehet, hogy x86 lesz, ki tudja. Mert azért 4 gépről pár byte adatot percenként feldolgozni, és 1-2 kliens általi weblapot kiszolgálni, mint vezérlő, azért komoly erőforrás igény... :-)
Nem kastélyba készül, de azért köszönöm a tippet... :-)
Sakk-matt,
KaTT :)
Tehát akkor a csillag közepén is PI, a végeken is PI.
A végső PI-ken lesz az I2C-RJ45 átalakító, azok így találkoznak a szenzorokkal.
Tehát a központi PI már egy (négy) megcsócsált, előfeldolgozott adatot kap etherneten, valami saját protokollal.
Lássuk el munkával a PI-gyártókat.
Hát igen.
Megfelelően meghajtott drótok + szenzorok + multiplexer + központi mcu/rpi helyett (amin néhány betűt kell csak írni-olvasni), több protokollal rendelkező számítógép hálózatot kiépíteni az tényleg egyszerűbb és kesebb fogyasztású és megbízhatóbb.
Erre csak azt tudom mondani, amit a villamosmérnök + digitális hangmérnök + orgonakonstruktőr barátom egy brit hifi újság tesztjére - ahol csillagászati árú, optikai digitális hangkábeleket teszteltek olyan módon, hogy hajtogatták és közben figyelték a hangminőség változását: Eldobom a diplomám!
" több protokollal rendelkező számítógép hálózatot kiépíteni az tényleg egyszerűbb és kesebb fogyasztású és megbízhatóbb."
Akkor miért ezt választod?
Vagy nem ide, vagy nem olvastad. ;)
Vagy csak szmáli nélkül nem érted az iróniát.
félrement, ja
bocs
Igen, mert azt tesztelték, amit a hozzá nem értő embert érdekel, hogy ilyenkor mi van. Empatikusan nézve ez érthető teszt. Bevallom, engem az érdekelne, hogy egy jobb minőségű hangkábel mellett van egy erősáramú kábel, amin mondjuk van 230V/2000 watt terhelés, hogy ez okoz-e a hangzásban bármit? Vagy a másik teszt, ami érdekelne, hogy egy legolcsóbb CAT5E kábel esetén viszünk 40 méterre gigabitet, akkor ha egy mellette lévő kábelen is viszünk ugyanígy gigabitet, járatjuk full duplexen max sávszélességen, okoz-e bármit? Vagy ha még harmadiknak és negyediknek melléjük csapunk, a biztonság kedvéért 10 cm-enként kábelkötegelővel erősen rögzített 230V/2000 watt terhelést, akkor mi fog történni? Minden UTP csomag odaér? TCP-t hányszor kell újraküldeni? És még rakjunk oda, ha volt packet loss a CAT5E-nél CAT6A, CAT7A, CAT8 kábeleken, vigyünk maximum sávszélességet. Ha tudsz ilyen real life tesztet, érdekelne.
Sakk-matt,
KaTT :)
Ez a teszt olyan, mint a víz szárazságanak a tesztelése. Hiába nem vegyész és nem atomfizikus valaki, akkor is ostobaság.
A 2000 Wattos kábel jó esetben nem zavarja a hangkábelt, rossz esetben enyhe brummot mérhetsz. Ez a hangzást nem zavarja. Sokkal valószínűbb a Kossuth Rádió beszivárgása, de jó árnyékolásnál nem fog az sem zavarni.
A hálózati kábel mérését magad is elvégezheted a driver számlálóinak segítségével. Több kábelt is vezethetsz egymás mellett, az sem okoz zavart.
A 230V meg csak adott távolságra vezthető a csavart érpártól. Nyilvánvalóan ott sem az 50Hz, hanem a nagyfrekvanciás zavarok okozhatnak a megengedettnél nagyobb közösdmódusú jelet.
Köszönöm az infót. Tehát szerinted egy 4 eres + árnyékolt YSLCY-JZ 4G1 mm2 300/500V 184095/34 kábelen, amit eredetileg 2x sztereó hang továbbítására húztam be, és a 6 eres riasztó kábelen kívül CAT 6A S/FTP és CAT 7A dupla árnyékolt kábelekkel együtt van húzva (azok mellett), ezen akár vezethetek 230V-ot maximum 90W-os RPI+erősítő tápjához erősáramot, és nem fog zavarni semmit? Vagy a riasztó kábel esetén ez gond lesz, hiába kívül árnyékolt ez a kábel, amin vezetném a 230V-ot. Tudom, külön kellett volna vezetni, és nyilván a konnektor, stb az külön van ezektől, villanyszerelő által, csak van helyiségenként ilyen kábelem is és gondolkozom, hogy mire használjam. Nyilván meg tudom még oldani, hogy vezetek szépen elkülönítve megfelelő erősáramú kábelt, ha ez nem jó erre. A 90W is névlegesen magas, majd megmérem, hogy maximum hangerőn mennyi áramot vesz fel, érdekességből.
Sakk-matt,
KaTT :)
nem huzhatsz erosaramot gyengearam melle egy kabelcsatornaban. Ez a szabvany.
Erre van pl. kitalalva az osztott (rekeszes) kabelcsatorna, hogyha egy nyomvonalon kell vinni.
---
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....
Nemcsak melléhúzza: hozzá is köti, nehogy kicsússzon :Đ
"Vagy ha még harmadiknak és negyediknek melléjük csapunk, a biztonság kedvéért 10 cm-enként kábelkötegelővel erősen rögzített 230V/2000 watt terhelést, "
"Vagy ha még harmadiknak és negyediknek melléjük csapunk, a biztonság kedvéért 10 cm-enként kábelkötegelővel erősen rögzített 230V/2000 watt terhelést, "
Igen, ez egy elméleti út lett volna, hogy egy külön kábelcsatornát hozzá rögzítek (vagy x cm-re mellette vezetek, ezt úgyis villanyszerelő csinálja majd, ha szükséges), és abban egy árnyékolt erősáramú kábel megy. Jobbnak tűnik a csak 24V, az egyik kábel esetén már biztosan csak 19,5V-ot vezetni a nem rég emlegetett 4 eres + árnyékolt kábelen.
Sakk-matt,
KaTT :)
A 230V vezetésére - ahogy írják - külön csatornát ill. megfelelő távolságot kell alkalmazni. (0,5-1")
Ennek ellenére kipróbálhatod, mivel árnyékolt a kábel. Ebben az esetben a 230V árnyékolását mindkét végét földelni kell!
Ettől kezdeve jó kérdés, hogy milyen hurkok keletkeznek és mit hova fog szórni.
Alapvetően az elektronikai ökölszabályok között van olyan, hogy a zavar mértékét csak becsülni lehet. A végeredményt mindig a mérés adja. A gyakorlatban minden zavarforrást fel kell mérni, és a szakszerű zavarcsökkentést alkalmazni. Ha ez nem bizonyul elegendőnek, akkor további vizsgálat után további zavarcsökkentő elem beépítése szükséges.
Mint látod, itt a nesze semmi fogd meg jól! De az élet már csak ilyen. ;)
A 230V túl közeli vezetésénél a szűretlen hálózaton érkező nagyferkvenciás zavarokra (összefoglaló néven: Kossuth Rádió ;)) és a fogyasztók kapcsolgatásánál keletkező impulzusokra lehet számítani. Ezek a zavarok azért veszélyesek, mert a megengedettnél nagyobb feszültség kerülhet az alacsonyszintű jeleket fogadó áramkör bemenetére. A másik esetben ugyanezekre a bemenetekre a kelleténél magasabb nagyfrekvenciás komponens kerülhet, ami megzavarja a normál működést.
No, most már mindent tudsz!
Igen, köszönöm a segítséget, és az eredeti "józan paraszti ész" tervnél maradva, ahogy az eredeti irány is: nem vezetek erősáramot a gyengeáramú kábelekkel, még ha technikailag lenne esély, hogy működne is. Viszont akkor ezen a 4 ér + földeléses kábelen 24V-ot (vagy most éppen: 19,5V-ot) has jól sejtem, vezethetek "szabványosan", és az árnyékolás mindkét végét földelhetem, ha szükséges. Így az itt összerakott erősítős RPI-hez a mostani 230V 3V - 4,5V külső tápot akkor 24V - 3V átalakítóra cserélem majd, és akkor egy forrásból megy minden. Ez így jobb, ugye? És akkor a 24V-ot relével kapcsolom ki/be.
Sakk-matt,
KaTT :)
és az árnyékolás mindkét végét földelhetem
Na ez az, amit baromira nem akarsz. Ez a biztos módja annak, hogy a Kossuth Rádió megjelenjen az árnyékoláson.
Az attól függ.
Eredetileg a 230V-os kábelről volt szó. Amin jön a Kossuth Rádió. Rosszabb esetben - pl. frekvenciaváltó - az előírt árnyékolás: acélcső mindkét végén földelve.
Persze a Kossuth Rádió a föld és a "levegő" között ad, így sugárzás útján is érkezhet.
Ha jelvezetékről van szó (pl. usb2.0), akkor nem biztos, hogy az árnyékolás a föld is. Egy laptop nincs is földelve. Ekkor inkább testelésről meg készülékházról beszélünk. Azért, hogy a DC a neki kijelölt úton közlekedjen, az árnyékolás a számítógépnél össze van kötve a testtel, a kliens oldalon is, de ott megszakítják egy kondenzátorral. Nagyfrekvenciásan a két test össze van kötve.
A fenti esetben, ha nincs készülékház, akkor a kondenzátor a 0V vagy jelföldre csatlakozik. A tápvezetékeken érkező zavarokat meg az előírt soros ferritgyöngy csillapítja.
Hasonló lehet egy (két) desktop összekötése. Ott a tápegységnél egy kis kondenzátorral összekötik a földet a készülékházzal. Sajnos ezt gyakran összekötik a 0V vagy jelfölddel is. Ebben az esetben a Kossuth Rádió szempontjából az árnyékolás mindkét vége földelt.
"és az árnyékolás mindkét végét földelhetem"
Tehát akkor nem földelem.
Ez a fenti 4 eres kábel akkor jó lehet ez a 24V / 80w átvitelre, nem gond, hogy S/FTP / UTP és riasztó kábel megy mellette?
Vagy inkább csak relé kapcsolásra használjam ezt a vezetéket (és ott helyben legyen a tápegység), ne a 24V átvitelre?
Sakk-matt,
KaTT :)
Csattogtassál csak jó sok relét, az a biztos, akkor lesznek rendes zavarok. Egy sima DC legfeljebb melegíteni fog, ha rosszul méretezted.
Miért lesz zavar, ha relével kapcsolok jelen esetben egy 24V-os tápegységet?
Tudom nem függ össze, de ha egy jóval nagyobb ampert is kezelni tudó relét veszek, akkor nem biztonságosabb lesz a működés, mintha kb pont olyat vennék, ami a célra elég?
Például ilyet:
https://www.ebay.com/itm/IACS-1-Channel-25A-30A-240V-Relay-Board-SPDT-A…?
Aminek ha adok 12V-ot, akkor:
"5V, 9V, 12V, 24V - we recommend 12V or 24V DC input.
This voltage range powers the board and does not interact with the switching ability e.g. a 12V DC board can switch anything up to 250V AC or 30V DC for this model."
Vagy a másik, aminek nem kell extra táp:
https://www.ebay.com/itm/3-3V-5V-30A-Relay-Module-for-Arduino-Nano-Due-…
A 2 közül melyiket javasolnátok, melyik tűnik jobb minőségnek?
Az első az komolyabbnak tűnik, mint az utóbbi.
Sakk-matt,
KaTT :)
Nem biztos, hogy jol ertem kisbetut, de szerintem arra gondolt, hogy minden releben van egy tekercs, amit
ha meghuz, akkor zaj keletkezik.
Szoval nem biztos, hogy audio kabel mellett kellene vinni olyan kabelt, amit "rangatsz" elektromosan.
En az egesz szenvedest nem ertem igazabol. Eros arammal egyutt ne vigyel gyengearamot.
Francba a zajjal, ennek eletvedelmi oka van.
Egyreszt serulhet kabel, es akkor hopsz ott a 230 a gyenge oldalon,
masreszt aki gyengearammal dolgozik, az nem szamit ra, hogy van ott 230 is.
---
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....
Az, hogy erősáramot viszek a gyengeáram mellett, az egy elméleti kérdés volt, de nem úgy lesz.
Most már az a kérdés, hogy ez a (YSLCY-JZ 4G1 mm2) 4 eres + árnyékolt kábelen vigyek-e 24V-ot, ami elvileg max 80 wattot vehet fel, vagy ne.
Sakk-matt,
KaTT :)
A földelésnél - árnyékolásnál csak a körvonalakat írtam le. Elsődlegesen a szabványokat kell ismerni hozzá. Pl. ne találj ki az usb 2.0-hoz valami egyedit, mert a szabvány és az azzal dolgozó gyártók ajánlásai már régen is beváltak.
Láttál már számítógépbe relét? Természetesen nem ez ebay-n árult relé panelre gondolok. For Arduino. ;)
Tehát a következő lecke: MOSFET, analóg kapcsoló, optikailag leválasztott analóg kapcsoló - ez utóbbit szerintem tévesen néha SSR-ekhez sorolják.
Ja, a táp az lehetne az erősítő mellett. Sőt, igen közel.
Köszönöm az iránymutatást újra és újra! :)
MOFSET:
http://www.tavir.hu/egyszeru-elektronika-mosfet
https://hu.fmuser.net/content/?1958.html
https://wiki.ham.hu/index.php?title=MOSFET
Az analóg kapcsoló, optikailag leválasztott analóg kapcsolóra tudnál 1-1 linket induláshoz?
Nem akarok USB2 esetén sem valami egyedit csinálni. A látszat ellenére szeretem a szabványokat és betartani a szabályokat, amiket a gyártók javasolnak. Például annyi voltot adok az erősítőnek, amit a gyártó javasol az adott ohmhoz.
Sakk-matt,
KaTT :)
Azhtung! Ezek csak példák lesznek.
Ezen az oldalon láthatsz néhány példát.
A "MOSFET Current Switch" egy db N-FET-ből áll. Ehhez 5-10V vezérlő feszültség kell, és csak a GND felé kapcsol.
Az "IRF540 MOSFET Switch Module" már erősítőt is tartalmaz, így 3,3V-os is lehet a meghajás. De ez is csak a GND felé kapcsol.
Ez a szerkezet már optikailag leválasztott. Szintén csak a GND felé kapcsol, és legalább 12V kell a kapcsolt oldalon a meghajtásához.
Egyenáramú kapcsoló (SSR). Ez optikailag leválasztott 60V/4A és legfeljebb 0,09 Ohm ellenálású kapcsoló. A vezérlő oldalon egy LED-et kell meghajtani kb. 10mA árammal. Ezzel már a felső ágat is lehet kapcsolni.
A párja az AQZ202, ami már két szembe fordított FET-et tartalmaz, így váltóáram kapcsolására is használható. Cserében az ellenállása is a duplája, terhelhetősége a fele, mert mindkét FET melegszik.
Kisebb áramok kapcsolására AQY211EHA is elegendő: 30V AC/1A 0,25 Ohm.
A +24V kapcsolását olcsóbban megoldhatod egy kisebb elenállású P-FET és némi meghajtással - leválasztva, vagy anélkül.
És még: https://www.pololu.com/product/2814/specs
"Megfelelően meghajtott drótok + szenzorok + multiplexer + központi mcu/rpi helyett (amin néhány betűt kell csak írni-olvasni), több protokollal rendelkező számítógép hálózatot kiépíteni az tényleg egyszerűbb és kesebb fogyasztású és megbízhatóbb."
Nem mondtam, hogy megbízhatóbb. Elméletben, a külön erre gyártott hardver és egy komplexebb, több funkcióval rendelkező hardver esetén matematikailag nagyobb az esély a meghibásodásra a komplexebb, több alkatrészt tartalmazó esetén.
Fogyasztása is több lesz.
Viszont nekem beállítani biztosan egyszerűbb és érthetőbb.
Sakk-matt,
KaTT :)
" A végső PI-ken lesz az I2C-RJ45 átalakító, azok így találkoznak a szenzorokkal."
Igazából 2 I2C-RJ45 átalakító lesz:
RPI - (kábel az RPI I2C busz és az adapter I2C csatlakozója közé)- I2C-RJ45 - (UTP kábel RJ45 csatlakozással mindkét végén) - RJ45-I2C (ugyanaz, mint a másik, csak így szimbolikusan csatlakozik az RJ45-re) - (kábel az adapter I2C csatlakozója és a szenzor közé) - I2C-t támogató szenzor, például BME680
Ezt fogom nézni, hogy hány méteresek kábellel tudom lekérdezni, hogy még vannak más szenzorok is az azonos I2C adatbuszon.
"Tehát a központi PI már egy (négy) megcsócsált, előfeldolgozott adatot kap etherneten, valami saját protokollal."
Hát, lehet csalódás lesz, de nem lesz még saját protokoll sem. Etherneten a 2 RPI között TCP/IP-n, IPV4 + TCP-n lesz a kommunikáció, lehet fájlokat küldök és feldolgozom, vagy MQTT vagy egyéb módon küldöm az adatokat, ami készen van.
RPI-nél meg I2C és SPI lesz a szenzorokhoz, mert annak van meg a támogatása készen.
"Lássuk el munkával a PI-gyártókat."
Hidd el, ha választhatok, hogy a PI gyártókat látom el munkával (és azzal oldom meg, amikor lehetne célhardverrel is), vagy téged kérdezgetlek még ezerszer, mikor hardvert próbálok gyártani (és mindig egy triviális lépésnél akadok meg, amit ha értenék igazán hozzá, tudnék), hogy a PI gyártókat kíméljem, akkor egy idő után te javasolnád, hogy jó lesz nekem az a PI! :-)
Sakk-matt,
KaTT :)
" lehet fájlokat küldök és feldolgozom, vagy MQTT vagy egyéb módon küldöm az adatokat, ami készen van."
Ezt hívom saját protokollnak. Készen van, de másnál, máshogyan. Nálad implementálni kell, éleszteni, tesztelni.
Hát ez gáz! Az én hőmérőim "munin protokollt" beszélnek. Azt is implementálni kell.
Persze a legbonyolultabb az I2C-RJ45 protokoll konverziója lesz! ;)
"
az I2C-RJ45 protokoll konverziója"Szándékosan beszélsz zöldséget?
Az I2C egy protokoll, az RJ45 egy közeg. A "konverziót" a megvett és beledugott IC-k végzik. Ha tápot kapnak. A "kábel" egyik végén betolod az I2C-t, a másik végén kijön ugyanaz az I2C.
Szándékosan. Ott a szmájli.
Mindössze KaTT barátunk világosan kifejezett és pontatlan terminus technicus használatára utaltam. Ha megfigyeled, folyamatosan I2C-RJ45 átalakítóról ír.
((Nem ugyanaz az I2C jön ki, mert a gyártó (NXP=Philips) dI2C-nek hívja. A PCA9615 a 3mA képességű I2C buszt konvertálja 30mA képességű differrenciális Fm+ meghajtássá.))
A fentihez hasonlóan nem sikerült megkülönböztetni a CAN, rs485 stb. drivert (hardvert) a protokolltól.
Szóval cinikusan arra céloztam, hogy aki ilyen egyszerű dolgokon nem igazodik el - és utána sem képes nézni - annak biztosan lesznek még problémái. Pedig azért lenne érdemes megismerkedni az alapokkal, mert aztán a büdös életben nem fogja kideríteni melyik szinten működik hibásan valami.
Sajnos egy kábel meghajtását nem lehet szoftver úton megoldani. Pár éve pont a PCA9615 okozott egy olyan hibát, hogy a differenciális oldalon hiányzó kábel miatt visszapofázott. És erre is csak akkor jöttem rá, amikor pontosan kimértem szkóppal. Egyes esetekben túl gyors ez az áramkör, tehát lassítani kell.
Ezen felül a modul nem az UTP kábelhez van illesztve, de ahhoz már forrasztani kellene.
Aztán a végén jön a "de szar ez a digitális technika". ;)
csak egy gondolat.
Tavaly kiirtam egy sd kartyat amirol fut a rendszer. Majd csinaltam rola ket mentest 1-1 sd kartyara (adata, kingston).
Iden elovettem az egyik mentest (kingston), bootolas kozben kernel panic valamilyen sectort nem er el.
Az adata mukodik. Egy evig egy aluminium csvaros dobozban pihentek egy nomal sd kartya adapterben, egy helyen (egymason).
Van egy hardkerneles mmc-sd kartyam.
Az is birja, de neha razkodastol a csatlakozonal szetesik.
A legrosszabb az sd kartyanal, hogy nincs egy konkret tool ami egyertelmuen megmondja, hogy szar.
Van egy mobilban meghalt sd kartya. Teljesen jol mukodik (latszolag), olvasni lehet, csak egyik irasi muvelet se hajtodik vegre (usd kartya).
Szoval nem tudom, hogy milyen sd kartyaval probalkoznek ballonos reptetesnel, ahol a suly is szamit.
---
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....
Szerintem ez nem meglepő. Ezek a flash eszközök jellemzően egy FET-ben 2, de inkább 3 bitet tárolnak. Teszik ezt úgy, hogy a gate-csatorna kapacitásba 8 különböző feszültségértéket tárolhatnak, így a source-drain ellenállás 8 különböző tartományba eshet, amelyet A/D konverterrel vizsgálnak, s kapják vissza a 3 bitet. Ha sokáig áll a kártya, a lassan elszivárgó töltés másik feszültségsávba tolja majd az A/D konverter bemenetét, s egyből 3 bit sérült, nem csak egy. Vannak ugyan hibajavító kódok, redundás tárolás, így ha használják a kártyát, van esély a helyes érték visszaírására, de ha sokáig áll, akkor túl sok bit sérülhet, amelyből már nem lehet az eredeti információt visszaállítani.
tr '[:lower:]' '[:upper:]' <<<locsemegeLOCSEMEGE
Szep ez a "mese", csak a kerdes adodik:
Most akkor szar a kartya vagy sem?
Hol egy tool, ami bitenkent atnyalazza es megmondja hogy milyen allapotu? Kb. mint a memtest a memoriara.
---
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....
Biztosat nem tudok mondani, de szerintem formázd meg újra, s használd.
tr '[:lower:]' '[:upper:]' <<<locsemegeLOCSEMEGE
Az a tapasztalatom, hogy régebbi fényképezőgépek nagyon minimalista módon írogatnak. Egy idő után egyes területek olvasása bizonytalan vagy lehetetlen lesz. Iyen hiba okostelefonnal is előfordult már. Természetesen az álldogálásba belefáradt kártyával is találkoztam.
A "javításhoz" többszöri felülírás kell. A pattern mindegy.
Win alatt a HD Tune Pro-val szoktam írni. Tud olvasási tesztet is.
Linuxon akár dd-vel is csinálhatod.
Wearing level jellegű infó tool-t én sem tudok SD kártyához, mivel egyszerűbb annál, hogy ilyen tároljon.
Én csak olyan "koptató" módszert tudok tesztelésre, ami megmondja, hogy éppen jó volt-e a teszt alatt, de nincs garancia, hogy később is jó lesz-e.
Ha bytera pontosan akkora random file-t generálsz, mint az SD kártya mérete file rendszer nélkül, csinálsz valamilyen HASH-t a file-ból, például SHA3-512, majd ráírod dd-vel vagy bármivel a memóriakártyára, és utána visszaolvasod file-ba. (Közben lesz egy írás/olvasási adatod is mellékesen.) A visszaolvasott file-ról csinálsz újra HASH-t, és ha egyezik, akkor tudod, hogy az írás idején még biztosan jó volt... :)
Az USB-s pendrive is hajlamos 1-2-3 év után elfelejteni adatokat, márkától függetlenül tapasztaltam, hogy fiókban állt.
Sakk-matt,
KaTT :)
No, akkor ezt megbeszéltük. ;)
Mivel a fenti eszközök nem ilyen célra valók, inkább ipari ssd-t használok. Esetleg DOM vagy CF kártya is jobb lehet.
Az ipari ssd nem az Industrial grade pendrive! ;)
HASH, alkoss, gyarapíccs! ;) Sokkal egyszerűbben csinálnám, mert nem memóriát tesztelünk. Ha nincs hiba, akkor nem kell két egyforma file. Ha van hiba, akkor legfeljebb a darabszáma érdekel.
De ez csak különvélemény.
Igen, jogos, biztos lehet egyszerűbben is.
CF-et én is jobban szerettem mindig is mint az SD-t, mégis az MMC/SD lett az elterjedtebb. Főként azért szerettem jobban a CF-et, mert masszívabb, a vezérlő a CF-ben van, így bármilyen ősrégi eszköz tudja kezelni a legújabb CF-et is, ami azonos szabványú. Ez MMC/SD esetén ugye az eszközben van a vezérlő és előfordul, hogy nagyobb az SD mint ami az eszköben lévő vezérlő ismer és címezni tud, így hiába rakom a slot-ba, nem látja. Meg az SD sokkal sérülékenyebb, de hát ez viszi előre a gazdaságot, hogy mennek tönkre, sérülnek meg. Ahogy a Blu-ray esetén is gyengébb a védő réteg, mint a CD/DVD esetén, jobban sérül.
Sakk-matt,
KaTT :)
"Az hogy lehet, hogy nem gyártanak ilyen Arduino Mega / Uno jellegű hardvert alapból Ethernet + POE-vel? Mi az oka?"
Még így sem egyben, de könnyen összerakhatóan egy másik platform, I2C-vel, stb:
WRTnode - Open Source and Mini OpenWRT Dev Board
https://www.seeedstudio.com/WRTnode-Open-Source-and-Mini-OpenWRT-Dev-Bo…
WRTnode Standard Shield
https://www.seeedstudio.com/WRTnode-Standard-Shield-p-2388.html
Sakk-matt,
KaTT :)
infó: OneWire én hóztam el 200m re is igaz két megszakítással ds18b20 szenzort és működik stabilan többéve...
Mi ez a két megszakítás? Valami repeater-t lehet a OneWire-re tenni? Érdekelne.
feliratkozom
Személyes weboldalam
'Everybody loves LEDs'
Szerintem RS485-tel csináld. Olyan egyszerű a kommunikáció, hogy akár teljesen software-esen, a bitek időzítésével is meg lehet csinálni, még UART sem kell feltétlenül. Viszont UART ma már szinte minden mikrokontrollerben van, így még hardware-es támogatást is kapsz hozzá. Az I2C-t nagyon nem erre találták ki. Jó, a szimmetrikus átvitel sokat hozna a dolgon, de én biztosan fáznék tőle. Aztán az is lehet, hogy megcsinálod, beválik, s minden kétkedőre vidáman mosolyogsz majd.
tr '[:lower:]' '[:upper:]' <<<locsemegeLOCSEMEGE
Szia, az a helyzet, hogy nincs releváns tapasztalatom RS485 jellegű eszközökkel. Most fogom beforrasztani az hangkártyának a 3 lábas infra vevőjét, sima ügy, le van írva, hogy melyiket hova és a többi része eleve kész a hangkártyán, a szoftver támogatása is adott.
Azonban bár technikailag meg tudnám ezeket forrasztgatni, ha bármi van vele, nem tudnám segítség nélkül kijavítani, mert nem pontosan értem, hogy mik lehetnek a bajok.
Jelenleg most ott tartok, hogy Arduino MEGA alapon csinálnám meg, lásd fentebb: rá egy POE + Ethernet shield, rá a szenzorokat aztán szoftveresen behúzom a kész kódokat a leolvashatósághoz vagy továbbküldéshez, amit találok. Mert itt még kb jobban értem, hogy mi mit csinál.
Infóim szerint az Arduino-nak megadhatóak sleep-ek, tehát például alszik 1 percig, felébred, leolvassa a szenzorokat és küldi például MQTT-n az RPI-nek, és újra alszik 1 percig. Így teljesülne a koncepcióm, hogy keveset fogyaszt, és nincsen feleslegesen menő operációs rendszer, ami még ezer mást is csinálhatna.
Amit most összeraktam RPI 3B+ + DAC + AMP 8 ohm 2x55w nagyon jól szól egy 2 utas Magnat Symbol Pro 160-on. Van mély, közép, magas, dinamika, nekem ez elég. Messze jobb, mint amit vártam egy RPI-re rakott kis DAC+AMP-tól. 24V-os tápról megy az RPI-is, visszatáplálva. Néma csendben kapcsolódik be, nem pattan semmi, tökéletes, hogy így nem kell mindig mennie. Kb 1 perc alatt boot-ol be és áll készen.
Sakk-matt,
KaTT :)
Már meg ne haragudjál, de ez még tréfának is baromság!
Ha az rs485-tel nincs releváns tapasztalatod, akkor az összes idelinkelt marhasággal meg van?
Az rs485 csak egy "erősítő". Összekötöd rx-rx, tx-tx, a-a, b-b, és egy gpio az irány vezérléséhez. Az a/b pontok között van a csavart érpár, a két végén meg 100Ohm. Ha a soros portra küldesz egy karaktert, azt mindenki veszi, ha más küld, akkor is. Aki ad, az átkapcsolja az irányt. (A vevő helyett az adó fog működni.)
Egy modul kb. 200Ft. Ha magad forrasztod, akkor kell egy ic-30Ft, egy kondenzátor meg feltételesen 1-3 ellenállás-20Ft, meg nyák.
Ennek ellenére a pca9615 jó ötlet, de maga az ic is drága. Ennél egyszerűbb és olcsóbb az i2c busz "hatótávolságának" kiterjesztése. Mivel bármilyen szenzort kapsz i2c felülettel, minden további fejlesztés drágítja, bonyolítja a kiépítést. És ezzel együtt a megbízhatóságát is csökkenti! Ha 10-15W-nál nagyobb a fogyasztás, akkor is biztos lehetsz benne, hogy feleslegesen költötted a pénzt és bonyolult a rendszer.
Hagyd, bent van nala a grep -v 485!
Eddig kb. 10 topicot inditott a temaban, altalaban a top commentben ott van, hogy csinalja RS485-tel (esetleg alternativanak megemlitve, hogy 1 wire vagy egyeb hasonlo), es meg mindig ezen szenved. Pedig konkret ic tipusszamot is kapott mar.
Probalkozott CAN-nel, modbussal, talan meg ethercat is elojott, most itt ez az i2c nyujts, de valamiert nagyon nem akarja.
--
When you tear out a man's tongue, you are not proving him a liar, you're only telling the world that you fear what he might say. -George R.R. Martin
Szia, nem, nem ignorálom a 485-öt, csak én a kész megoldás jellegű utat keresem, ahol jó esetben kész hardvert UTP-re / RJ45-re dugok, a hardverbe a szenzorokat, és már csak szoftveresen kell megoldani a távoli lekérdezést.
Az RS485 irányban ennél sokkal több forrasztási, hardveres feladatot látok. És még egyszer: nem azzal van a bajom, hogy egyszer megforrasztom, hanem hogy nem pontosan értem jelenleg, hogy mit csinálnék meg, ezért keresek kész célhardvert, ami kb arra van, hogy 1-3 szenzort rá csatlakoztatva és szoftveresen megtámogatva lekérdezhető lesz a szenzor. Az Arduino kb ilyennek tűnik, csak kihagytam volna a hardver programozást. Raspberry Pi esetében össze tudom legózni a megoldást, csak zavar a fogyasztás, hogy van feleslegesen egy operációs rendszer, mint overhead.
Tehát ott tartok, hogy már RPI + szenzorok módon meg tudnám oldani, de kisebb fogyasztású megoldást keresek, kész eszközökből összerakhatóan lehetőleg. Az Arduino szinte ez, mert kis fogyasztás, csak még a szoftveres részét meg kell oldani. Szóval eddig ez a nyerő, de még keresem, ami ennél is egyszerűbb. Még egyszer leírom, hogy az RS485 komplexebb, időigényesebb megoldásnak tűnik.
Sakk-matt,
KaTT :)
Az UART (soros) protokoll ket eszkoz kozt annyibol all, hogy van 2 jelszint (magas es alacsony, egyszeruseg kedveert legyen 1 es 0). Van egy jelvaltasi sebesseg, mondjuk bit per second, legyen 9600 most, ebbol kijon egy ido, amennyi ideig egy-egy bit atmegy (9600-nal kicsit tobb, mint 1ms, legyen most t). Az atvitelnel a vonal alapbol 1-ben van. Amikor a kuldo ki akar kuldeni egy byte-ot, akkor 0-ba huzza t ideig. Aztan (attol fuggoen, hogy hany bitunk van, az esetek donto tobbsegeben 8) atmegy az adat, a legkisebb bittol kezdve. Szoval ha az adat adott bitje 0, akkor logikai alacsony, ha 1, akkor magas ertekre allitja. Opcionalisan itt johet egy paritasbit, utana meg jon egy stopjel, ami logikai 1-es, es legalabb t ideig kell tartania (beallitastol fuggoen lehet 1.5t vagy 2t is). Kb. ennyi az UART leirasa.
A "logikai magast" es "alacsonyt" altalaban feszultsegszintekkel szoktak reprezentalni (lehetne aramhurok is, vagy pl. lezerfeny vagy akarmi). Ha a mikrokontrollerednel van UART, akkor ott a 0 0V-ot, a magas meg a tap szintjet (5V TTL vagy 3.3V) szokta jelenteni, ennyi megy ki belole a TX labon. UART fogadasa az RX-en szinten (bar van 5V tolerans 3.3V-os mikrokontroller, meg 3.3V-as UARTot is fogadhat biztonsagosan egy 5V-os). Ha ketiranyu kommunikaciot akarsz, akkor az eszkozok TX-RX labait keresztbe osszekotod, teljesen ertelemszeruen.
Ha nagyobb tavolsagra megy, akkor jon az RS232, aminel a logikai magas mondjuk -12V, az alacsony meg +12V. A magasabb feszultsegszint messzebbre viheto, kevesbe zavarerzekeny (ugyanakkora zavar aranyaiban kevesbe befolyasolja). Ez ugy szokott menni, hogy fogod a mikrokontroller, amibol kijon a TTL szintu UART, bekuldod egy jelszintilleszto IC-be, onnan a hosszu droton a masik eszkoz jelszintillesztojebe, es jon a masik uC. Visszafele ugyanigy (altalaban egy IC oda-vissza megoldja mindkettot).
Ha ez sem eleg, akkor ott az RS422, itt szimmetrikus jelatvitel van, ami csavart erparon nagyon messzire elmegy (a zavaras a ket erre ugyanugy hat, es kb. kiejti), hatranya, hogy a korabbi 1-1 drot helyett 2-2 kell, mert az egyik es masik iranyba is erpar megy a szimmetria miatt.
Az RS485 egy sima UART, annyi, hogy az elozoekhez hasonloan nem TTL (vagy akarmilyen mas) jelszint van benne, hanem a 422-hoz hasonloan 2 vezeteken szimmetrikusan megy az adat, es a jelszintilleszto IC-nek van egy plusz laba, ami megmondja, hogy azt a 2 vezeteket most olvasasra hasznalja, vagy irasra (o kuldjon adatot). A SW protokoll meg ugy szokott lenni, hogy minden eszkoznek van egy-egy cime, es amikor megszolitjak, akkor valaszol. Mondjuk van egy master, es egy csomo slave, a master meg kerdezgeti a slave-eket. Persze a drot fizikai tulajdonsagai (visszaverodes) miatt kell lezaroellenallas, de ez nem csak itt van.
Egyebkent a CAN is hasonlo, szimmetrikus atvitelt hasznal.
---
En itt a kovetkezot tennem a helyedben: veszel egy (vagy ketto) arduino nanot ($1.4-2.5 korul vannak a klonjai) az ismerkedes kedveert, azon van USB atalakito, szoval a gepre radugva rogton megy. Ezt a fejleszteshez ajanlom, jobban latod, mi tortenik. Ezen kivul arduino mini (pro) fog kelleni a kinti eszkozokhoz, es valamilyen szintilleszto IC is, SN75176, MAX485, vagy valami hasonlo, egy par passziv alkatresszel egyutt (attol fugg, mint hasznalsz, pl. lezaroellenallas biztos kelleni fog, a szintilleszto engedelyezojere is tennek egyet). Az arduino tx-rx vonalait rakotod a szintillesztore, valamelyik tetszoleges labat az iranyra, es megirod a programjat. Az egyszeruseg kedveert en a fomodulhoz tennem az egyik nanot, es a Pi-nek valami emesztheto formaban adnam az adatot. (es SW sorossal menne az eszkozok fele), igy nagyon hasonlo tud lenni a kod a masteren es a slave-eken.
Extrem esetben meg az is megoldhato, hogy mondjuk egy atmega8 legyen a modulokon arduino helyett (ugyanugy Arduinokent is programozhato), meg extremebb esetben kvarc nelkul (bar soros atvitelhez ez nem ajanlott).
--
When you tear out a man's tongue, you are not proving him a liar, you're only telling the world that you fear what he might say. -George R.R. Martin
Egy apró javítás:
1/(9600 Hz) = 104.17 µs
tr '[:lower:]' '[:upper:]' <<<locsemegeLOCSEMEGE
Teljesen jogos.
--
When you tear out a man's tongue, you are not proving him a liar, you're only telling the world that you fear what he might say. -George R.R. Martin
Szia, nem, nem ignorálom a 485-öt, csak én a kész megoldás jellegű utat keresem
Oké, segítek:
Egy központi, okosabb SBC, plusz valami olcsóbb, egyszerűbb Linuxos SBC minden helyre, ahova szenzort akarsz rakni, Ethernet közéjük, szabványos PoE switch, kész PoE PD táp adapter (ami a PoE tápból csinál olyat, ami az SBC-knek kell: vagy valami rádugható szar, vagy egy külső dobozka - a PoE injektor párja), az SBC seggére meg a max. 0.5-1m távolságban levő szenzorok direktben rákötve.
Ez a kész megoldás jellegű út, amin "csak" az SBC-re kell SW-t írni, meg a szenzorokat valahogy ráhekkelni. Minden mással szopni fogsz, pláne amikor 8-bites Arduinóval akarsz Ethernetet kezelni...
Igen, köszönöm a megerősítést.
Itt nem sokkal lentebb: https://hup.hu/node/165101#comment-2370325
Én is, mint 8. megoldás erre jutottam, amit javasoltál:
"
* Megoldás 8, meg tudnám építeni, talán működhetne: Orange Pi PC Plus POE Ethernet-en, 2-3 helyiség szenzorait kezelve I2C-n vagy más módon
+ Előny: értem, POE, Ethernet alapú, könnyen bővíthető, könnyen rárakhatóak a szenzorok, könnyen beüzemelhető, üzemeltethető, ha megy, akár harmada a fogyasztás, mert a környező helyiségekben csak szenzorok vannak valahogyan odavezetve, I2C-n vagy bármi máson
- Hátrány: folyamatos nagy fogyasztás, az Arduino / ESP32-höz képest, 0/24 üzem az RPI-nek feleslegesen, nem kész eszközök, ha megáll, akkor 2-3 helyiség mérése esik ki
"
Miért nem vinnéd messzebb 1 méternél a szenzorokat?
Sakk-matt,
KaTT :)
- Hátrány: folyamatos nagy fogyasztás, az Arduino / ESP32-höz képest, 0/24 üzem az RPI-nek feleslegesen, nem kész eszközök, ha megáll, akkor 2-3 helyiség mérése esik ki
Nem vagyok meggyőződve, hogy ennyire nagy a különbség fogyasztásban. Nyilván az Ethernet végpontonkénti 1W-ját nem nagyon tudod megspórolni, de az technológiai kérdés alapvetően. Viszont ha leclockolsz egy SBC-t mondjuk 1GHz-ről 250-300MHz-re (ahol még mindig röhögve elviszi a Linux, amit kell), akkor az alap 3-5W-os fogyasztása simán lemehet a töredékére. És ezt szerintem mindegyik ilyen cucc tudja. Az izgalmas kérdés inkább az, hogy a PoE implementáció mekkora overheaddel dolgozik - ezt meg semmilyen adatlapon nem fogod megtalálni, max. kimérheted.
Miért nem vinnéd messzebb 1 méternél a szenzorokat?
Mert az alkalmazott technológiák nem erre vannak kitalálva (az SPI-t is, de az I2C-t meg főleg panelen belüli megoldásnak tervezték, tehát még az 1m is sok lehet), ergó erőlködni kell, ha mást akarsz. Ezt lehet ugyan, de azt meg nem fogod készen, modulként megvenni, ehhez már sajnos elektronikai tudás kell, meg forrasztópáka. És még hozzáértéssel is nagyon hamar ki tud derülni valamiről, hogy már alkatrészek szintjén is drágább, mint az általános megoldás, és akkor a belefeccölt időt és energiát nem is számoltuk (pl. ezek a random I2C "kihosszabbító" integrált áramkörök, amikből kiskerben szökőévente eladnak 12 db-ot Európaszerte, ezért az áruk több, mint egy random SBC, amit meg tonnaszám gyártanak a kínaiak).
Ez alapján:
TP-Link TL-POE10R non-isolated example
https://www.youtube.com/watch?v=TYd3RtooFxY
Ha én is ilyennel akarom megoldani az RPI POE ellátását, akkor nekem is kell ilyen?
TracoPower TEL 5-1211 DC/DC converter (print) 12 Vdc 5 Vdc 1 A 6 W No. of outputs: 1 x
https://www.conrad.com/p/tracopower-tel-5-1211-dcdc-converter-print-12-…
Hogy ezen keresztül adjak áramot az RPI-nek?
https://www.actpower.com/educational/isolated-vs-non-isolated-power-sup…
Az SBC élettartamot mennyire növeli meg, ha izoláltan kapja az áramot, mintha nem? Főleg, ha az áram forrás eleve szinuszos szünetmentesen át fog jönni.
Sakk-matt,
KaTT :)
" izoláltan kapja az áramot"
Mit csinálsz a micsodával?
Tanár Úr, Ön biztosan érti, hogy mit akartam mondani. Ha trafóval, akkor izolált (rosszabb hatásfokkal, de megbízhatóbban, kevesebb ingadozással), ha chip-ből konvertált, jobb hatásfokkal (viszont nagyobb ingadozással és kevésbé biztonságosan talán), akkor izolálatlan, és itt az utóbbi. Legalábbis ezt olvastam több helyen és láttam a legutóbbi videóban is.
Sakk-matt,
KaTT :)
Tehát a galvanikusan leválasztott tápegységet írtad itten körbe, ismét szakszerűen.
CSAK GALVANIKUSAN LEVÁLASZTOTT tápegységet szabad használni. Ez a saját - ezek szerint még nem felfogott - érdeked.
Rendben, akkor ilyen irányt keresek.
Az külön izgalmas, hogy tudom ezt kideríteni egy termékről, hogy milyen, ha nem látom a nyákot. Bár ha látok egy trafót, az galvanikusan leválasztott tápegységre utalhat akár. (Próbálok biztonságosan fogalmazni, mert hátha van 1 kivétel, és újra beszólsz! :-) )
Sakk-matt,
KaTT :)
A galvanikus leválasztás hiánya egy multiméterrel elég jól tesztelhető (a sípolós dióda-ellenőrző mód az ideális funkció), ha a két oldal között van sípolás bármilyen irányban, akkor az ott nem leválasztott.
Egyébként a szabvány szerint a PSE oldalon is, és a PD oldalon is kellene lennie leválasztásnak az Ethernet vezeték, és minden ember által érinthető alkatrész között (beleértve a készülékházat is). Ha a PD oldal nem egy konkrét berendezés része, hanem önálló termékként árulják, akkor ugye nem lehet feltételezni, hogy a mögé kötött berendezésben nem lesz érinthető felület, ergó kötelező ott megvalósítani a leválasztást. Ha a PD oldal bele van építve a készülékbe, és lehet tudni, hogy nincs érinthető része a készüléknek (és vezetékek sem jönnek ki belőle), akkor ott elvileg ki lehetne ezt spórolni.
Ergó a fenti videóban levő TP-Link switch és splitter egyike sem felel meg a PoE szabványnak.
Pedig a TP-Link terméke egy populáris, kommersz terméknek tűnik, ráadásul egy nagy (low cost) gyártó. A gyártó oldalán nagyon szépen dobálóznak mindenféle szabvánnyal.
Mit keressek akkor helyette, ha nem ezeket a termékeket? :)
Sakk-matt,
KaTT :)
Egy nagyon gyors keresés:
poe isolated splitter
https://blog.adafruit.com/2018/06/08/new-product-poe-splitter-with-micr…
Ha kicsit is kérdéses a szállító (pl. aliexpress), akkor kell rendelni egyet, kimérni, esetleg szétbontani és megnézni, aztán csak akkor venni többet belőle, ha jó a cucc.
A switch oldal kevésbé fájdalmas, mint a PD oldal amúgy. Persze a switchnél is gond lehet, ha
- több port egymással galvanikus kapcsolatban van, mert ha az egyik port vezetékeit rövidre zárod, simán lekapcsolhat a táp, és megy a többi port is,
- ha nincs leválasztás a switch bele és az Ethernet vonal között, akkor meg egy ESD esemény vagy egy szekunder villámcsapás simán viheti a switch belét is, ami valószínűleg gazdasági totálkár a switchnek.
Köszi, ezeket én is nézegettem.
https://www.adafruit.com/category/144
Itt csak a jobb cuccok nincsenek raktáron :)
"Ha kicsit is kérdéses a szállító (pl. aliexpress), akkor kell rendelni egyet, kimérni, esetleg szétbontani és megnézni, aztán csak akkor venni többet belőle, ha jó a cucc."
Aztán izgulni, hogy ugyanabból a hamisított szállítmányból kapok-e, vagy a másikból :)
Itt mondjuk van ez a termék:
PoE Splitter with MicroUSB Plug - Isolated 12W - 5V 2.4 Amp [ADA3785]
https://thepihut.com/products/adafruit-poe-splitter-with-microusb-plug-…
Tehát ez 48V-ból csinál 5V-ot, pont ilyen kell.
Ezt akkor merhetem rárakni erre a 4+1 portos TP-Link POE-s switch-re?
TL-SG1005P
https://www.amazon.com/TP-Link-TL-SG1005P-Gigabit-Ethernet-compliant/dp…
Sakk-matt,
KaTT :)
"Aztán izgulni, hogy ugyanabból a hamisított szállítmányból kapok-e"
Nem kell kicsit sem izgulni: ugyanabból kapsz.
Itt mondjuk van:
PoE Splitter with MicroUSB Plug - Isolated 12W - 5V 2.4 Amp [ADA3785]
https://thepihut.com/products/adafruit-poe-splitter-with-microusb-plug-…
Tehát ez 48V-ból csinál 5V-ot, pont ilyen kell.
Ez szerintem ugyanaz a termék, csak kicsit drágábban - az a vicc jut az eszembe, amikor a boltost kérdezik, hogy miért adja drágábban ugyanazt a terméket, mint a szemben levő boltos - ahol amúgy éppen nincs az adott termék, és az a konklúziója, hogy "ja, amikor nálam éppen nincs, akkor nálam is olcsóbb"...
Hogy ez a PoE switch mit tud, az ennyiből nem egyértelmű, viszont elég olcsó ahhoz, hogy az ember kísérletezzen vele. Én speciel nem vennék nem menedzselt eszközt már semmire se, de az én vagyok, meg egy menedzselt PoE switch 3x ennyibe kerül.
Köszi a tippeket, ki fog derülni, hogy mit tud a cucc. Nekem fizikailag külön hálózaton lesznek a szenzorok, nem lesz netjük sem, szóval nem használnám ki a menedzserelésből adódó előnyöket.
Sakk-matt,
KaTT :)
Ez egy jarhato ut, hogy teszel egy levalaszto tapegyseget utana, en is igy csinaltam.
- Az 5V/1A nem eleg
- levalaszto tapegysegtol nem fogja tovabb birni az rpi
- ha valaminek kell a normalis feszultseg, azt eszre fogod venni
Itt mindosszesen annyi tortenik hogy az rpi -42V es -47V-rol megy. Megkapja az 5V-jat.
---
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....
Emlékszem egyébként hogy jópár éve én is pont erről álmodoztam, hogy ilyen CAN vagy I2C busszal építek szenzorhálózatot a házamba. Végül nem építettem semmivel, de legalább ma már én is RS485-tel csinálnám, ha nekiállnék :-)
Az UART-ot már szinte szeretem debuggolni is, és még értem is. A topiknyitónak is üzenem, hogy ez a legegyszerűbb, és teljesen alkalmas a feladatra. Ami vezélrőhöz nem illeszthető, az úgysem jó semmire.
En valami ilyemsi tablazat alapjan valasztanek madzagolast meg protokollt meg kommunikaciot:
Annak fuggvenyeben tertmeszetesen hogy mit akarok es/vagy mi a celom :) Az implementation complexity az csak valami szubjektiv, igy a korabbi tapasztalatok alapjan irtam bele szamokat... es inkabb a szoftveres oldalon levo komplexitast tukrozi, nem az osszeforrasztas nehezseget...
Az SPI full duplex, de a valosagban inkabb half duplexkent hasznaljak. A - jelen esetben - egyik legfontosabb szempontot viszont kihagytad: hogy esszeruen mekkora lehet a halozat fizikai merete. Ja, es az EtherCAT meg 1-wire kimaradt. Meg ha az Ethernet fole UDP/IP-t (vagy meg inkabb: TCP/IP-t) is akarsz, az az eroforrasigenyt meg a komplexitast is megdobja.
--
When you tear out a man's tongue, you are not proving him a liar, you're only telling the world that you fear what he might say. -George R.R. Martin
Az SPI full duplex, de a valosagban inkabb half duplexkent hasznaljak
Igen, ez igaz. Mondjuk akkor hozzavehetjuk a simplex uzemmodot is -- azaz amikor csak SCK+MISO-t hasznalsz. Ennek szinten vannak elonyei, pl nincs clock skew, es igy akar sokszaz megabitig is siman fel lehet vinni a savszelt. Foleg ha LVDS transcievereken keresztul viszed el messzire a jelet.
Ja, es az EtherCAT meg 1-wire kimaradt
Persze, absz nem teljes a tablazat. Inkabb csak azokat irtam bele amikkel mar van valamennyire relevans tapasztalatom. Bar az EtherCAT az az ethernetnek a reszhalmaza.
Jó kezdemény, de van még rengeteg szempont.
Elsősorban nem szabad összekeverni a "protokoll" és a "médium" fogalmát.
Igen gyakori, hogy az eredetileg néhányszor 10 cm hosszú i2c buszt olcsó rs485 vagy egyéb hardverrel toldják meg. Így a twisted besorolás csak az alap koncepcióra igaz. Ugyanúgy, mint az ethernet és az üvegszál esetén.
További fontos szempontok:
- Átviteli sebesség és gyakoriság.
- Teljesítményfelvétel.
- Környezeti zavarok és zavarérzékenység.
- Latency.
- Csatlakozás.
- Az eszközök (szenzorok) tipikus illesztése.
- Nem utolsó sorban a költség.
A fentiekből általában az jön ki, hogy rj45 esetleg rj11, twisted, rs485 és i2c proto.
I2C-t lehet RS485-re tenni? Erre nem is gondoltam. Pedig kézenfekvő.
Az ugy nem fog menni mert az i2c az pull-down, az rs485 meg push-pull rendszeru fizikai illesztes (lasd: arbitration). De i2c-t kihajthatsz CAN transciever-rel, kis trukkozessel (kell plusz egy tranzisztor meg egy ellenallas, de majd lerajzolom, ugy jobban latom). Vsz abban a fenti rajzon levo PCA9615-alapu megoldasban is hasonlo logika van.
Mielőtt lerajzolnád, nem árt megnézni egy P82B96 adatlap első ábráját. ;)
Ettől kezdve az RX-TX vonalakat két irányba egy-egy vonali adóval és vevővel ellátva 4 csavart érpáron kész a duplex összeköttetés.
A "logika" egy kb. +/-30mV hiszterézisű áramkör, amelyik eldönti, hogy melyik irányból szóltak először. Ennek a működését a PCA9615 adatlapban található szkóp felvételeken tanulmányozhatod.
Igen, teljesen jogosak a szempontok. De az is igaz, es azert is irtam most csak ezeket a szempontokat mert mar igy ezekkel nezve sincs ket egyforma parameterekkel rendelkezo megoldas :)
Hja, a fogyasztas is jogos, egy eth phy elegge tud melegedni. De sok CAN/RS485 is sokra mehet mert azert az a 120 ohm 5 volton is mar eldisszipal 0.2 wattot. Azaz a CAN-nal full savszel mellett atlagosan 0.1 wattot, de RS485-nel 0.2-t. Ket lezaro ellenallassal pedig 0.2-t vagy 0.4-et mar...
A tobbi meg mar tenyleg messzire vezet :)
120 ohm helyett 1k es 10n vagy 100n
------------------------
uint8_t *data; // tipussal megszorozzuk az adatot. wtf?
Ezzel a kábel szépen átmegy illesztetlen állapotba. Igaz, a slew rate a futásidő sokszorosára növekszik, a sávszélesség meg töredéke lesz. Legjobb esetben <1..10kHz.
Ez egy járható út, de sok esetben elkerülném a ráköttött eszközök - ilyen paraméterek melletti - helyes működésének ellenőrzését.
https://e2e.ti.com/blogs_/b/analogwire/archive/2016/07/28/rs-485-basics…
------------------------
uint8_t *data; // tipussal megszorozzuk az adatot. wtf?
mellesleg nem elég 4800 bps? vagy 1200. el lehetne huzni a drótot a hódig.
------------------------
uint8_t *data; // tipussal megszorozzuk az adatot. wtf?
Hja, max 8b/10b vagy mas dc-balanced kodolasnal csinalnek ilyet, de inkabb ugy sem. Ez egy trade-off. Sokat fogyaszt nagy tavon es nagy savszelnel. Ez van :)
Az ethernet kb. 1W - a sebességért ez az ár.
Viszont az ethernet csak pont-pont kapcsolatot tud, míg az rs485 fogyasztása nem nő lényegesen, ha 32-128 állomást kapcsolsz rá. Így aztán a végpontonkénti fogyasztás már elenyésző lehet.
Aztán a 120 Ohmra sem kerül a teljes 5V csak 1,5 ... egyre jobb a helyzet. ;)
Az i2c is hasonló, mert az eszközöktől függetlenül elég az egész buszra 1-2 ellenállás.
Nagyon szépen kiveséztetek minden lehetőséget. Talán még egyet nem láttam, a 230V -os hálózati kommunikációt (Power Line Communication) régebben sok ilyet csináltak, de az utóbbi időkben (szerintem az olcsó kis adó-vevő modulok miatt) eltűntek.
Az RS-485 az optimális megoldás - a riasztók zöme mind ezt használja, hasonló követelmények mellett.
A tűzjelzőkben vannak ennél érdekesebb kommunikációs eljárások, elképesztő távolságokra viszik a tápot és a jelet (több száz méter), viszont nagyon lassú.
Az RS-485 -höz is vannak kész modulok, de valójában a kommunikációt mindösszesen egy az UIART -ra chip intézi. A tápláláshoz, eszközönként 50mA a 12V elégséges, de azért jól nézz körül a step-down avagy buck modulok között mert nem mindnek a jó hatásfoka.
* Én egy indián vagyok. Minden indián hazudik.
OP elore behuzta az UTP kabeleket, es azon akar kommunikalni, innentol a power line kiesett (meg a radios is).
Bucko (legalabbis asszem o) valamelyik korabbi topicban mar kifejtette, hogy ha kis fogyasztasu eszkozoket hajt meg, a DC-DC uresjarati fogyasztasa nagyobb lesz, mint egy LDO elfutott energiaja.
--
When you tear out a man's tongue, you are not proving him a liar, you're only telling the world that you fear what he might say. -George R.R. Martin
Bizony, behozhatatlan előnnye jár, ha el lehet olvasni az adatlapot még a rendszer összerakása előtt. ;)
Az elektronika a gyakorlatban anyagismeret és egy csomó ökölszabály. Ezt akkor sem szabad elfelejteni, ha modult vásárolsz az ebay-n! Számtalan esetben találkoztam olyannal, hogy a modul az adatlapon szereplő mintakapcsolás volt, csak hibásan kivitelezve. Ezt aztán magyarázd el egy amatőrnek, akinek "működik"!
Egyébként nem LDO-t írtam, hanem söntöt. Azért, mert biztonságosabb és kisebb lehet a zaja.
Jártam már úgy, hogy meg voltam győződve róla, hogy csodaalkatrész van a modulon. Csak aztán kiderült, hogy inkább csodaszar. Csak éppen az adatlapról hibásan másolták át a modul lapjára a számokat.
> OP elore behuzta az UTP kabeleket, es azon akar kommunikalni,
Mondjuk nem egy elhanyagolhato szempont, hogy utp kabelert a sarki villanyszerelo boltba is leugorhatsz 15 ev mulva.
Egy speci 12 eres riaszto kabelre multkor 60napot vartam.
---
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....
Szia, igen, a 2 ér Ethernet / UTP / S/FTP adott / helyiség csillagpontosan, amiből elvben 1 kábelt használnék erre, kivéve, ha indokolt a másik is.
A hálózati kommunikációt (Power Line Communication) kihagynám itt.
Már sok RS485 jellegű lehetőséget végig néztem, ahol nyilvánvalóan többen javasoltatok megvalósítható megoldást, csak éppen sajnos nem tökéletesen értem a működést és a kivitelezést. Továbbá a minél inkább összelegózható megoldást keresek, minél kevesebb forrasztással.
Összefoglalom gyorsan, mi van éppen a fejemben erről:
% ===================================================================
* Megoldás 1, meg tudnám építeni: Orange Pi Zero helyiségenként POE Ethernet-en.
+ Előny: értem, POE, Ethernet alapú, könnyen bővíthető, könnyen rárakhatóak a szenzorok, könnyen beüzemelhető, üzemeltethető, ha megy
- Hátrány: folyamatos nagy fogyasztás, az Arduino / ESP32-höz képest, 0/24 üzem az RPI-nek feleslegesen, nem kész eszközök
% ===================================================================
* Megoldás 2, meg tudnám hardveresen építeni, de szoftveresen kihívás: Arduino helyiségenként POE Ethernet-en vagy splitterrel
+ Előny: alacsony fogyasztás, "alszik", a lekérdezések között, várhatóan nagyobb élettartam
- Hátrány: nincs Arduino fejlesztési tapasztalatom, több forrasztás, hiányosabb alapismeretek, nem teljesen értem minden részét, nehezebben üzemeltethető ezért, nem kész eszközök
% ===================================================================
* Megoldás 3, meg tudnám hardveresen építeni, de nem tudom, hogy működne-e: RPI + I2C expansion, a témanyitó hozzászólásban az infók
+ Előny: I2C-n minden, 1-2 RPI-vel meg van oldva az egész
- Hátrány: lehet, hogy nem működne a gyakorlatban, nem tudom. Folyamatos nagy fogyasztás, az Arduino / ESP32-höz képest, 0/24 üzem az RPI-nek feleslegesen, nem kész eszközök
% ===================================================================
* Megoldás 4, meg tudnám hardveresen építeni, de nem tudom, hogy működne-e: CAN és/vagy ModBus alapú kommunikációval + RS485 + ami még kell
+ Előny: alacsony fogyasztás, cél eszköz, kevés felesleges funkció
- Hátrány: lehet, hogy nem működne a gyakorlatban, nem tudom. Nincs ilyen fejlesztési tapasztalatom, több forrasztás, hiányosabb alapismeretek, nem teljesen értem a működést, nehezebben üzemeltethető ezért, nem kész eszközök, ebben van a legtöbb fekete lyuk, amit nem értem, hogy miért úgy van.
% ===================================================================
* Megoldás 5, meg tudnám hardveresen építeni, de nem tudom, hogy működne-e: ESP32 + POE alapon
+ Előny: alacsony fogyasztás, cél eszköz, kevés felesleges funkció
- Hátrány: lehet, hogy nem működne a gyakorlatban, nem tudom. Nincs ESP fejlesztési tapasztalatom, több forrasztás, hiányosabb alapismeretek, nem teljesen értem minden részét, nehezebben üzemeltethető ezért, nem kész eszközök
% ===================================================================
* Megoldás 6, meg tudnám hardveresen építeni, működne elvileg: Kész kábel alapú modulokból megépíteni, például KNX
+ Előny: dokumentáltabb, értékállóbb, kész eszközökből
- Hátrány: Még senki nem tudott mutatni olyan konkrét megvalósítást, amire szükségem lenne, drágább ár a kész modulok miatt, a kész modulok miatt limitáltabb fejleszthetőség talán
% ===================================================================
* Megoldás 7, meg tudnám hardveresen építeni, működne elvileg: Kész kábel alapú modulokból megépíteni, például Ethercat kompatibilis eszközökből
+ Előny: dokumentáltabb, értékállóbb, kész eszközökből, Ethernet alapú
- Hátrány: Még senki nem tudott mutatni olyan konkrét megvalósítást, amire szükségem lenne, drágább ár a kész modulok miatt, a kész modulok miatt limitáltabb fejleszthetőség talán
% ===================================================================
* Megoldás 8, meg tudnám építeni, talán működhetne: Orange Pi PC Plus POE Ethernet-en, 2-3 helyiség szenzorait kezelve I2C-n vagy más módon
+ Előny: értem, POE, Ethernet alapú, könnyen bővíthető, könnyen rárakhatóak a szenzorok, könnyen beüzemelhető, üzemeltethető, ha megy, akár harmada a fogyasztás, mert a környező helyiségekben csak szenzorok vannak valahogyan odavezetve, I2C-n vagy bármi máson
- Hátrány: folyamatos nagy fogyasztás, az Arduino / ESP32-höz képest, 0/24 üzem az RPI-nek feleslegesen, nem kész eszközök, ha megáll, akkor 2-3 helyiség mérése esik ki
% ===================================================================
* Megoldás 9: WiFi alapon
+ Előny: Sok a kész eszköz, amiből összerakható
- Hátrány: Nekem ki van építve a kábelezés már, WiFi alapű működés, amit nem szeretnék, a kész eszközöket nem tudom frissíteni/megvédeni OS/firmware szinten, sok igényel internetet, stb, ez a megoldás KIZÁRT, csak mint elméleti lehetőség hagyom itt
% ===================================================================
* Megoldás 10: amire nem gondoltam még...
Azt gondolhatod, hogy túltolom ezt az egészet. Ha nem ismered a helyzetemet, akkor jogosan hiheted ezt, azonban van időm eldönteni a jó megoldást, és inkább többszörösen átgondolom, hogy készítem el és hogy üzemeltetem, mint hogy gyorsan elkészítve jövök rá, hogy eleve rossz irányba indultam el. Nem tétlenkedem, több darab RPI-vel most tesztelem, hogy hány I2C / SPI szenzort tudok lekérdezni, és nézem, hogy változik, ha távolabbra viszem a szenzort, stb. Írok majd erről, ha érdemben jutottam valamire. Ettől függetlenül hamarosan eldöntöm, hogy hova milyen szenzor kell, és nézem a helyiségek közötti kapcsolatokat, hogy hova lenne érdemes elhelyezni az RPI-t, amin több helyiség szenzorja lehet. Aztán lehet, hogy később nem RPI lesz, hanem ESP32/ Arduino, mire beépítésre kerül a sor.
Jelenleg a 8-as (POE + Orange Pi PC Plus több helyiséget átfogóan) megoldás tűnik a leginkább jó ráfordított idő / érték / karbantarthatóság mutatóval, és a 2 (Arduino) és 5 (ESP) irányokat vizsgálom, hogy mi legyen, továbbá az I2C extender és egyéb lehetőségeket sem vetem el, hogy bizonyos esetben kellhet.
Sakk-matt,
KaTT :)
aztán feltételezed, hogy a összeklikkelt vasak jól működnek a fielden, és nem fog olyan történni, hogy az i2c eldobja magát, vagy az spi, azon mindig valid adat jön, és nem egy beragadt 32.3.
------------------------
uint8_t *data; // tipussal megszorozzuk az adatot. wtf?
Hát, a szenzor hiba, érintkezési hiba, kábel hiba, konverziós hiba, adapter hiba, modul hiba, RPI működési hiba, tápegység hiba, stb... része a folyamatnak, csak próbálom ezt detektálni és a hibás alkatrészt cserélni.
Ki fog derülni, hogy mi mennyire tartós, a gyakorlatban. Vagy vehetek mindent készen, és akkor van 1-2 év garanciám jó esetben.
cadmagician: amúgy írtam üzenet a rendszeren keresztül, majd várom a választ! :) Miért van a neved végén, hogy cadmagi-CIÁN? :)
Sakk-matt,
KaTT :)
En meg valaszoltam ra mailben
------------------------
uint8_t *data; // tipussal megszorozzuk az adatot. wtf?
RS485 nem bonyolult. Buta nagyon, mert csak a fizikai réteg van meg, fölötte a te dolgod, mit csinálsz. Van egy szimmetrikus érpár, egy eszköz ad, mindenki más fülel. Azaz half duplex. A bitek meg úgy jönnek, hogy van egy 0-s start bit, utána D0, D1, D2, D3, D4, D5, D6, D7, majd egy 1-es stop bit. Feltételeztem a 8N1 átvitelt. Aszinkron a kommunikáció, így minden eszköznek azonos sebességgel kell kommunikálnia. A karakterben lehet paritás bit is. De nem fontos, átviteli blokkonként valamilyen CRC-t számolsz, aztán azzal próbálod védeni az adat sértetlenségét.
tr '[:lower:]' '[:upper:]' <<<locsemegeLOCSEMEGE
Ezt így elméletben értem, köszönöm, csak gyakorlatban ezzel még így nem foglalkoztam, de egyre inkább közeledek ezekhez. I2C / SPI-vel sem, de ezeknek a működését már részben értem legalább, és látom a gyakorlatban. Abban tudnál segíteni, hogy olyan kész hardvert mutatsz, ami ilyen, és meg van csinálva hozzá a teljes szoftver támogatás, tehát a modulra, mikroszámítógépre, vagy bármire szenzort rakok, és lekérdezhető lesz, a célra alkalmas, kábelen.
Mert jelenleg még mindig bár overhead árán, de ez az én szintemen a legjobb út, ahol ráfordított idő/eredmény/használhatóság oké:
Orange Pi PC Plus POE Ethernet-en, 2-3 helyiség szenzorait kezelve I2C-n vagy más módon
+ Előny: értem, POE, Ethernet alapú, könnyen bővíthető, könnyen rárakhatóak a szenzorok, könnyen beüzemelhető, üzemeltethető, ha megy, akár harmada a fogyasztás, mert a környező helyiségekben csak szenzorok vannak valahogyan odavezetve, I2C-n vagy bármi máson
- Hátrány: folyamatos nagy fogyasztás, az Arduino / ESP32-höz képest, 0/24 üzem az RPI-nek feleslegesen, nem kész eszközök, ha megáll, akkor 2-3 helyiség mérése esik ki
Tehát az a rossz benne, hogy többet fogyaszt, mint az Arduino vagy ESP32, és hogy hamarabb megállhat, de kb ennyi. A többi csak előny elméletben.
Ha meg nekifogok RS485-öt fejleszteni, nem tudom megtippelni, hogy hány tíz óra után leszek ott, hogy RPI-ről le tudom olvasni a szenzor adatokat, mert most sem látom tisztán, hogy milyen akadályok fognak jönni, amikben hiányosságaim vannak és amit meg kell, hogy értsek.
RPI + I2C szenzorok is új, de már látom, hogy működik, és gyűlik a tapasztalatom.
LOCSEMEGE: Neked (és itt sokaknak még szerencsére), akinek komoly tapasztalatod van ezekben, nem érted igazán, mit tökölök, miért nem rakom pik-pakk össze az egészet: csak egy kis RS485, egy kis CAN vagy ModBus, ilyen modul, olyan ellenállás, pár kábel így és úgy kötve, C-ben csak ezt kell ráfordítani az ESP32-re vagy Arduinóra, meg ezt beállítom és kész is! Nem is értem, mi itt ebben a kihívás... :-)
Sakk-matt,
KaTT :)
Sokat toporogsz egy helyben. Kísérletezz, rakd össze fél méter kábellel, mérj, tapasztalj, gondolkozz, úgy könnyebb lesz. Nehogy bevásárolj sok százezer forintért, aztán nem tudod majd életre kelteni!
tr '[:lower:]' '[:upper:]' <<<locsemegeLOCSEMEGE
Jogos, köszönöm, azt csinálom. Most RPI alapon rakom össze az egészet (van több szenzorom), és közben próbálom megérteni, hogy milyen valódi előnyökkel járna, ha Arduino lenne az RPI helyett vagy ESP32, stb.
Sakk-matt,
KaTT :)
Arduino az RPI helyett? Mire gondolsz, DUE?
Csak ajánlom a figyelmedbe:
8 bit akkor ott az STM8S103F3P6 (20 pin) ck. 300,- Ft darabja az eBay -en. Nem risc de extended utasítás készlete van. Az égetése ugyan azzal az STLink -el működik és minden ott van ami az Arduinóban kivéve hogy az olcsóbb lapokon nincs kvarc. Annyira igénytelen, hogy felcsaphatod egy smd-DIP protko NYÁK -ra az RS485 meghajtóval együtt.
32 bit akkor az STM32F030F4P6 ARM Cortex M0 (szintén 20 pin)- nem kell gondolom bemutatni. A hw kivitel lehet azonos.
Egyébként a NYÁK lehet érdemes tervezni, ha jól értem több tucat is kellhet.
A táp lehet egy kis step down, szintén kapsz <300,- Ft eBay. Az egész "konstrukció" alig nagyobb egy szokványos pendrive, akár USB csatlakozót is használhatsz (2 ér táp, 2 ér adat).
OFF: Valahol halottam, hogy a korral a kreativitás nem csökken csak sokkal kevesebb dolgot tudsz kipróbálni. Arról is halottam, hogy az időé4rzkünk 10 évente négyzetgyök 2 -vel nő - azaz egyre gyorsabban múlik a szubjektív időnk.
A szakma "öregjei" türelmetlenek.
* Én egy indián vagyok. Minden indián hazudik.
Persze, hogy türelmetlen vagyok. Mire megcsinálja, és olvasnám, hova jutott, már lehet, hogy csak az érdekel, mikor tesz tisztába a nővérke. ;) Szóval igyekezzen ezzel a motyóval! :D
tr '[:lower:]' '[:upper:]' <<<locsemegeLOCSEMEGE
+1
Igen, jogos. Várhatóan hamarosan egyeztetek cadmagician Úrral, aztán akkor el fog dőlni a végleges irány... tervezés, beszerzés, összerakás, és remélhetőleg nagy öröm, vagy újrapróbálkozás... :-)
Sakk-matt,
KaTT :)
Velem az szokott lenni, hogy mire nekiállnék valaminek, addigra már rájövök, hogy másképpen kellene csinálni :-).
Szerk.: nem csodálkoznék, ha KaTT kartárs is így járna.
Egyrészt fejlődik az ember, ez természetes. Másrészt nem szabad semmit sem elkapkodni, mert abból kellemetlenségek adódnak majd. Harmadrészt a túl sokáig tartó döntésképtelenség nem azonos a megfontolt döntéssel, sokkal inkább amolyan mozgó célpontra lövésnek tűnik, s megöli a cselekvést. Egy kompromisszumos, elég jó, de nem optimális döntés is jobb, mint egy meg nem hozott döntés, mert nem mindegy, hogy valami záros határidőn belül elkészül, vagy sohasem készül el.
tr '[:lower:]' '[:upper:]' <<<locsemegeLOCSEMEGE
A hobbiprojektekkel az a baj, hogy álmodozni pár percet mindig van idő, de órákra beülni a dolgozószobába forrasztani már más tészta. Nem csoda, hogy a legtöbbje ötletelés szinten esik kútba. De nem csüggedek, örülök annak, ami elkészült.
Azért, ha ritkán nekiülök valaminek, azt végigcsinálom. Az más kérdés, hogy nem látok olyan feladatot, amit megcsinálnék. Ezt a fajta vergődést piaci termékeken is érzékelem. Lehet olyan asztali lámpát kapni, amely fehér LED-del világít, a talpában van egy RGB LED - tehát valójában 3 LED -, és egy kapacítív szenzorral lehet állítani, milyen színben pompázzon a lámpa talpának eleje. Nyilván PWM-mel csinálják. Aztán amikor ezt látom, azon tűnődöm, hogyan tudtam én eddig egy ilyen nélkül élni. De most komolyan: ettől nagyobb lesz a boltban az M-es tojás? Kevesebb lesz a rákos megbetegedés?
Ami meg esetleg valóban hasznos volna, az túl nagy falat egy fejlesztőnek, nagyon sok pénz és idő. Egyszerű hardware-rel, olcsón nem nagyon tud az ember értelmes okosságot kitalálni. Valóban értelmes okosság meg olyan, hogy bele sem kezd az ember, mert túl sok munka lenne. Ezen felül lényegében minden igény le van fedve a piacon, ami egyébként a kapitalista verseny velejárója.
tr '[:lower:]' '[:upper:]' <<<locsemegeLOCSEMEGE
Nyilvánvalóan az élet, a fejlesztés és a siker a bluetooth villanykörténél kezdődik, amelyet mobilappról tudsz irányítani! :-D
Ezzel szembeállítanám a MKKP fejlesztését (más jellegű), ami egy "hol lehet pisilni" app. Ez tényleg hiánypótló!
A második bekezdéssel nem értek teljesen egyet. Válasszuk le a jól fizető, parasztvakító piaci szegmenst! Ekkor maradhat olyan termék, ami hiányzik a palettáról, értelme is van. Talán nem lehet az egész világon eladni, de mégis szükség lehet rá.
Nemrégiben készítettem, illetve még folyamatban van a fejlesztés: Egyszerű IP hőmérő.
Van ilyen a piacon, de csillagászati áron. Ki lehet hozni olcsóbban is, de akkor meg KaTT barátunk nem lesz rá vevő, mert nem elég csak összedugni. Ennek ellenére még nem tartom a szerkezetet kiforrottnak. Az igazi megoldás az rs485, i2c vagy subGHz kapcsolat lenne. Eddig az az eredmény, hogy 20-25 darabos sorozatnál már megéri.
Hasonló hiány egy távolról leolvasható teljesítménymérő is. A Conrad típusok amatőr felhasználásra készülnek. Gondolom létezik ipari kivitel, de az annak megfelelő árszínvonalon.
Engem talajnedvesség mérőben érdekelne valami hasonló... :-)
(rádiós)
Pl: van egy "bázis", ami vezetékkel illeszthető valamilyen rendszerre (legyen rs485), és oda küldik valamilyen frekvencián az értéket a kertben elhelyezett érzékelők. Az automatizálási központ a bázison keresztül értesül/tudja lekérdezni az érzékelőket.
Eddig csak erősen ipari/mezőgazdasági léptekben találtam hasonlót, illetve érzékelő is kellene, amit nem darál le a fűnyíró (akár kellően lapos, akár úgy, hogy az antennás rész arrébb van, ahol már nem jár a fűnyíró).
Van sok kész talajnedvesség szenzor RPI-hez, I2C/SPI-sek. Ha rádobod egy RPI-re, egyből megy pár config beállítás után. Tudom túlzás erre egy RPI,de egyrészt több szenzort is rá tudsz tenni, egyszerűbb hardverrel ezt kivitelezni pedig mint látszik, nem tudok tanácsot adni... :-)
Soil Moisture Sensor (Raspberry Pi)
https://www.instructables.com/id/Soil-Moisture-Sensor-Raspberry-Pi/
Tutorial – Using Capacitive Soil Moisture Sensors on the Raspberry Pi
https://www.switchdoc.com/2018/11/tutorial-capacitive-moisture-sensor-g…
Vagy Arduinóra:
Kuman for Arduino Raspberry pi, 5PCS Soil Moisture Sensor Module and 5 PCS Temperature Humidity Sensor
https://www.amazon.com/Arduino-Raspberry-Moisture-Temperature-Humidity/…
Sakk-matt,
KaTT :)
Köszi, de ezek nem jók: alacsony fogyasztású rádiós kell, amit be tudok ásni a földbe. Ha lehet, bírjon ki egy szezont (bár lassan 365 napos egy szezon).
Ilyet nem kerestem, és nem is botlottam bele konkrétan ilyen kész megoldásba. Amit olvastam csak érdekességből is ilyenekből, hogy építettek Arduino / ESP32 vagy akár RPI alapokon, akkuval és akár napenergiás töltővel, majd x időnként lekérdezték RJ45/WiFi/BT-on. De ez kb mind ilyen hobbi projekt volt, nem kész termék.
Sakk-matt,
KaTT :)
Ha sikerül kidolgozni a föld alatti antennát, a helyedben eladnám az izraeli hadseregnek. ;)
"akár kellően lapos, akár úgy, hogy az antennás rész arrébb van, ahol már nem jár a fűnyíró"
Nem kell eladni, mar valoszinuleg tudnak rola, hogy lehet.
A lenyeg, hogy a frekvencia novelesevel a behatolasi melyseg csokken (ezt a mikrosutonel is tapasztalhattad, a kaja belsejet kevesbe eri). Ha a masik iranyba mesz, akkor meg no.
Igy szoktak tengeralattjarokkal is kommunikalni.
--
When you tear out a man's tongue, you are not proving him a liar, you're only telling the world that you fear what he might say. -George R.R. Martin
A poént meg nem fogtad, pedig leírtad. ;)
Miért ne lehetne egyszerűen a földbe fektetett párhuzamos vezetéket felhasználni a nedvesség érzékelésére. Persze nagyfrekvenciával meghajtva.
A másik oldalon meg nem fogsz az aliról olyan rádiós modult beszerezni, ami a föld alól ad. Avagy ki a rosseb akar elásni egy tengeralattjárót a telkén? ;)
Tehát a topográfia a következő:
Elásunk pár-jópár nedvességérzékelőt. Olyan mélyre, ahol a nedvességet ismerni szeretnénk.
Keresünk egy fát, kerítést, kutyaólat, amit nem érint a fűnyírás.
Az elásott szenzorokat elkábelezzük az objektumig.
A kimért kábeleket is beássuk a földbe, olyan mélyre, hogy egy esetleges talajművelet ne tegyen bennük kárt. Ezt megelőzendő, természetesen elásás közben jelölőszalagot is teszünk föléjük.
Odakábelezzük a 230-at is az objektumhoz, szintén megjelölt útvonalon.
Felszereljük a jelfeldolgozót és az adót (hiszen elég ugye egy adó) az objektumra.
És kész. Mi ebben az űrtechnika?
:Đ
Semmi űrtechnika. Csak elnéztem a linkelt "talajnedvesség szenzor RPI" és a "for Arduino" kategóriás divályszokat. No, azok sem űrtechnika. Valójában egy cserép virág nedvességét sem bíznám rájuk. :-)
A 230-at még a kert közelébe sem kábelezném, így nincs baleset. A kérdés rádióról szólt...
Eldöntendő, hogy a fenti szenzorokat, tengeralattjárót, vagy két vezetéket ásunk el. Az utóbbit javasoltam. Ehhez már csak egy nagyfrekvenciás driver, mcu és sub GHz adó kell, ami lelfeljebb 5 percenként, rövid ideig működik. A tápláláshoz egy évre elég egy kisebb elem. (a kutyaól mellett)
Hasonló, csak 230 nélkül, mert az bonyolítja a dolgokat.
Ez kb az, amit leírtál, 230 nélkül: http://www.caipos.com/products/caipowave/, ipari megoldás
Ez még egyszerűbben, nyilván más lépték, de sajnos nem valósult meg: https://www.indiegogo.com/projects/doodlebug-a-smart-wireless-soil-mois…
Ilyen is van oda, ahova nem kell "sok" és nem baj, ha kilóg a földből: https://www.amazon.com/Decker-PCS10-PlantSmart-Digital-Sensor/dp/B003Z4…
Ez is hasonló: https://xiaomi-mi.com/sockets-and-sensors/xiaomi-huahuacaocao-flower-ca…
> Engem talajnedvesség mérőben érdekelne valami hasonló... :-)
En ott megakadtam, hogy honnan veszel normalis talajnedvessegmerot ami kibir legalabb 3 evet?
Ezek az ebayes sz*rok eloxidalodnak seccperc alatt.
En magamnak gipszbol ontok, de maceras meg kalibralni kell.
---
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....
Pont ilyen hőmérőt keresek én is, ami elemmel megy legalább 1 évet, és rádión küldi 1-5 percenként az értéket. ATTiny alapon One Wire hőmérővel és rádiós modullal meg tudnám csinálni, és egész olcsó is lenne, de dolgozni kell vele :-(
Sajnos ez pont nem ilyen.
Kifejezetten szervertermi üzemre készült, munin-hoz. Az IP/wifi modul nagy fogyasztása miatt dugasztáppal.
Van benne két 5-12V-os relé meghajtó is, de csak a nem rádiós verzióban.
Szenzorok: MCP9801, BME280, AM2320 (kínai csoda)
Ezekből elvileg 1-8db köthető rá, de csak egyet használunk.
Az mcu pic18f14k22.
Itt egy kép - "fejlesztés alatt." ;)
Nonprofit projekt - mint a Luca széke.
A továbbfejlesztés rs485 lehet, ami az utp kábelről kap táplálást.
Az rs485 helyett lehetne uart interfészű rádió is, vagy mcu csere esetén akámi.
Amiket írtál megoldásokat, ezek készen, egyben összerakva megvásárolhatóak? Ha megépíteném, hogy kellene kommunikálni ezekkel, milyen módon, hány eres kábelen?
Még nem gyártottam ilyeneket, és azért keresnék kész elemeket, amiket csak össze kell rakni, hogy könnyebben üzemeltethető, karbantartható legyen.
Biztosan jó megoldás amit mondtál, csak nem csináltam még ilyet.
" A táp lehet egy kis step down, szintén kapsz <300,- Ft eBay. Az egész "konstrukció" alig nagyobb egy szokványos pendrive, akár USB csatlakozót is használhatsz (2 ér táp, 2 ér adat)."
Ha elkészül, amit javasoltál, USB csatlakozó lesz 2+2 érpáron, akkor hány métert tudom elvinni, hány V-ot kell adni neki?
Sakk-matt,
KaTT :)
Nemide
------------------------
uint8_t *data; // tipussal megszorozzuk az adatot. wtf?
Szia!
Most sikerült bevásárolnom grove cuccokból. Amit elsőre talán nem derül ki: szoftveres támogatottsága durván eltér platformonként. Én buta fejjel azt gondoltam hogyha kapható egy grove modul akkor minden (arduino,rpi,beaglebone) platformhoz van driver. Pont beaglebone-nal kezdtem, de így gyakorlatilag a kapható modulok 80%-hoz (!!!) NINCS szoftveres támogatottság. Írj magadnak saját drivert... vagy válassz olyan platformot amihez van. Van olyan 8-as reléjük amihez csak kizárólag arduino driver van és szevasz. Úgyhogy épp rpi-re váltok, ott cserébe az 5V/3.3V kérdéskörre kell figyelni.
Köszi a tippeket, én csak olyan grove-ot vettem, amihez elvileg van RPI támogatás, megnéztem a drivereket vásárlás előtt, hogy van-e. Mire fogod használni? 0-24-ben fogod járatni?
Sakk-matt,
KaTT :)
Nem 24órás projekt, egy gépet kéne vele vezérelni és IP adatot lehívni a gépről, napi 8-16 órában. A fogyasztás érdektelen, a stabil működés fontosabb. A szükséges cuccok többsége aruinos vagy rpis, így váltanom kell...
En ugy latom itt mindenki a sajat maganak tetszot ajanlja.
A nyito poszt egyik agat (i2c differencialis meghajto x2, 2 erzekelo meg egy rpi) 10eFtbol megvan.
Ennyiert nincs ember/ceg aki erdemben tanacsot adna.
Szerintem kezd el a projektedet. Valamire ugyis szorni kell a penzt.
Nem is latok itt kidobott penzt, mivel barmerre is indulsz el az erzekelok jo resze ugyis i2c.
---
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....
Szia, így van, rakom össze RPI alapon jelenleg az egészet, és tesztelni fogom az I2C-n a szenzorokat, hogy milyen kábelen hány métert mennek stabilan. Kezdésnek dupla árnyékolt CAT7A S/FTP kábelen nézem várhatóan. Aztán lehet, hozzácsapok egy ilyen i2c extendert.
Közben a helyiségek alapján átgondoltam a működést, és úgy, hogy egy RPI-vel 4 helyiség szenzorjait fogom olvasni, olyan hosszú kábeleken, amilyen oda kell, úgy fogom vizsgálni, mint prototípus a működést, stabilitást 0/24-ben. Tehát RPI-re 2 I2C busz kell, mert a szenzort maximum 2 féle I2C ID-vel tudom használni.
Ha akarnám, lehetne 3. I2C busz is HDMI-ből (mert headness módban mennek úgyis a szenzort olvasó RPI-k), de nincs rá szükség, és nem is akarnék kernelt patch-elni ez miatt.
http://blog.koalo.de/2013/11/i2c-over-hdmi.html
További infó, másik témához kapcsolódó hardver:
PCF8574 PCF8574T Support Cascading Extended Module Expansion Board High Low Level For Arduino I/O For I2C IIC Port Interface
https://www.aliexpress.com/item/32918268437.html?spm=a2g0o.productlist…
Sakk-matt,
KaTT :)
A sparkfun pca9615-t vegulis honnan vetted meg? En perpill csak a mousernel latok.
---
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....
Szia, itt:
https://coolcomponents.co.uk/products/sparkfun-differential-i2c-breakou…
Még 6 van nekik most épp. Én kettőt vettem, tesztnek.
Hozzá még Qwiic Adapter (DEV-14495) és 2 darab Qwiic Cable - 500mm (PRT-14429) kábelt.
Tudom, fillérekből ennél jobbat is forraszthatnék, tudom... :)
Sakk-matt,
KaTT :)
futok mouserrel egy kort, lenyegesen olcsobb.
Koszi.
---
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....
subscribe