Keresés

Részletes keresés

Törölt nick Creative Commons License 2015.02.03 0 0 805

A pro mininél tapasztaltam a lábak jelölésével kapcsolatban a feliratozás nem mindig korrekt, de figyelmetlen is voltam, eleve keresztezni kell a tx rx vezetékeket az rs232 szabvány szerint.

Viszont nem működik az oldalsó lábakon.

Előzmény: granov (804)
granov Creative Commons License 2015.02.02 0 0 804

Én most épp az esp8266-os wifi modulokkal kínlódok.

Nagyon nem találok normális libraryt hozzá. Mert még a lábkiosztás sem konzekvens a neten.

TX-et tx-re köt az egyik, a másik meg rx-hez. A programban CH_PIN-t reset paraméterrel jelöl...

Pedig csak simán egy logot szeretnék feltenni valahova.

Ha van tippetek....

Előzmény: x20fan (803)
x20fan Creative Commons License 2015.02.02 0 0 803

Én még előtte vagyok, de majd figyelek. Már amit eddig olvastam fórumokat látszik, hogy nem mindig az első library működik, amit talált az ember. Talán itt is a csoport tapasztalata a legjobb, ami már több embernél bevált, annak jó esélye van nálam is, ha ugyanolyan modulokat használunk. Ez is előnye a nem saját fejlesztésnek, hogy mások kínlódásának eredményét felhasználhatom.

Előzmény: Vargham (801)
x20fan Creative Commons License 2015.02.02 0 0 802

Szerintem ha megszakad a kapcsolat, az még jobb, mintha téves/sérült adat jön, bár utóbbit crc-vel lehet detektálni.

A vezetéknek előnye még a táp vihetősége, egy szenzornak meg egy nanonak nem kell olyan sok áram, bármilyen vezetéken elmegy.

Előzmény: John Zero (800)
Vargham Creative Commons License 2015.02.02 0 0 801

> Megvan hozzájuk a software library, ami szintén nem kevés munka és nem kis bizonytalanság, ha nekem kell megírnom.

> Valószínűleg nálam jobb programozók írták, tesztelték, javították.

Többen, többször is abba a hibába estünk, hogy így gondoltuk. De nem. Nincsenek jól megírva. :-(

Előzmény: x20fan (799)
John Zero Creative Commons License 2015.02.02 0 0 800

A rádiós megoldás szerintem nem rossz, én az NRF24L01+ (modulokat) használtam és nekem jól megy. az NRF ráadásul csomagokat küld, kényelmes.

 

Azt kell végiggondold, hogy mi a következménye annak, ha szakadás vagy kiesés van a rádiókapcsolatban? (Pl. valami zavar van.) Ha katasztrófális, akkor mindenképpen drótos kapcsolat kell, de ha nem kritikus. Bár én nem tapasztaltam ilyet, a legrosszabb ami volt, hogy van olyan hely a házban (kívül) ahová nem megy el rendesen a jel, de ezt egy ismétlős rendszerrel meg lehet oldani.

 

Előzmény: x20fan (792)
x20fan Creative Commons License 2015.02.02 0 0 799

Ez a communication link nagyon jó, még sokat kell nézegetnem az arduino.cc oldalt.

 

Tkp. nem találtam ki előre a protokollt. A feladatot találtam ki, azt is csak nagy vonalakban, mégpedig a viszonylag sok szenzort viszonylag nagy távolságban. Ezzel kilőttem a kis lokális megoldásokat, pár méterre jól működő beolvasásokat, amikkel az asztalon lehet játszani. Nekem akkor érdekes az arduino, ha tudom használni ilyen célra, kint vannak a mérendő dolgok, valahol fedett, árammal rendelkező helyen a feldolgozás, és az adatoknak el kell jutni a feldolgozás helyéhez. Persze nem csak szenzorok, hanem beavatkozó egységek, motorok, fényforrás, hangjelzés stb. is, csak ott ugye ellenkező irányú az adatközlés.

Tetszik az ethernet, a rádiós vezeték nélküli és az rs485. A konkrét feladat határozza meg, hogy melyiket érdemes használni. Ezeket meg fogom nézni közelebbről, kipróbálom, mert a gyakorlatban is szeretném látni, hogy belefér a program, megfelelő a sebesség és biztonságos az átvitel, fogyasztások hogy alakulnak, zavarvédettség milyen.

 

Abban igazad van, hogy a legegyszerűbb megoldásban van a legkevesebb hibalehetőség, de a szenzor nem kommunikál (mondjuk egy fotoellenállás vagy thermisztor), viszont analóg mennyiséget mér. Analóg jelet nem akarok vinni, lehetne próbálkozni a 4-20 mA árammal, de sokkal jobban tetszik a digitális átvitel, vagyis processzor kell. Lehetne csupasz mikrovezérlő, de akkor ahhoz board, programozó, és nyernék 300 ft-ot az arduinohoz képest. És arduinora már ki van dolgozva sokféle protokoll. Hogy mennyire stabil folyamatos üzemben azt nem tudom. A chip adott, az csupaszon se lenne stabilabb, a bootloader és az áttöltött sketch megbízhatóságáról nem tudok semmit, ezt tesztelni fogom. A nanon alig van alkatrész, elko egy se, az usb-ttl átalakító nem fog működni programáttöltés után, gyakorlatilag nagyon közel van ahhoz, mintha a csupasz chipet használnám a minimálisan szükséges alkatrészekkel. Lehetne találni valami kis 8 lábú mikrovezérlőt, ami szintén olvasni tudná a szenzort és át tudná fütyülni a buszon, de én ezzel a megtakarítható összeg kicsinysége és az általam belevitt bizonytalanság (saját nyák fejlesztés, saját forrasztás, felhasznált alkatrészek minősége) miatt nem foglalkoznék. Ráadásul ha én veszek egy chipet vagy a kínai 1 milliót, egész más áron kapjuk, lehet nem tudnék olcsóbb lenni az egyedi nyákommal és alkatrészeimmel.

 

A tesztelés OK, nem breadboardon fogom, hanem a valódihoz közelebbi konfiggal, kiviszek az udvar végébe egy nanot, kihúzom a madzagot, lehetőleg forrasztott, toldott, összesodrott, szigszalagozottat, és ha azon bejön meg kimegy jól az adat, akkor az jó. Ez az rs485-re vonatkozik, az ethernethez cat5 kell, a rádióshoz meg semmi.

 

Az egyedi fejlesztésről már írtam, valahogy az nekem nem tetszik. A sokféle kapható perifériát már sokan tesztelték, azok már bizonyítottak, csak a minőségre kell figyelni, hogy a kínai milyen szutyok alkatrészekből rakta össze milyen szutyok forrasztógéppel. Ebben van bizonytalanság. Megvan hozzájuk a software library, ami szintén nem kevés munka és nem kis bizonytalanság, ha nekem kell megírnom. Valószínűleg nálam jobb programozók írták, tesztelték, javították. Nekem csak a feldolgozást kell megírnom, hogy azt csinálja amit szeretnék. Tehát én most mindenképpen a kész modulokkal fogok indulni, még a szenzoroknál is, bár ott sokhoz nem is kell protokoll, egyszerűen digitalizálni kell az analóg mennyiséget. Ha viszonylag közel van pár szenzor, azt még egy arduino is le tudja kezelni, és olyan programot kap, ami mindegyik rákötött szenzor megszólításakor válaszol a megfelelő értékkel.

Előzmény: Prof (796)
x20fan Creative Commons License 2015.02.02 0 0 798

Igen az ár azért nem lényegtelen, egyrészt nem ipari cuccról van szó, hanem hobby szint, másrészt éppen a sok érzékelős kiépítés a cél, ha csak 1-2 szenzor van, akkor egyszerűbb a feladat. 4900-ért látok az ebayen can shieldet, mellé még az uno egy ezres. Biztos jó, de ennél az rs485 sokkal olcsóbb (244 Ft), és az 32 egység 1200 m-en atombiztos átvitellel. És jó mellé egy mini pro vagy nano is. Elkezdem jobban megnézni az rs485-ös műszaki adatokat, ez már eléggé ipari is, egyszerű vezetéken megy, zavarérzéketlen, valószínűéeg a software kezelése sem túl bonyolult.

Előzmény: Prof (795)
x20fan Creative Commons License 2015.02.02 0 0 797

Ez a rádiós modul egész korrektnek néz ki. Nem annyira olcsó, és szinte már bonyibb mint az arduino. Eltettem a libraryt, látom már külön gyűjtemény lesz ezekből.

Előzmény: Vargham (793)
Prof Creative Commons License 2015.01.31 0 0 796

Jónak gondolom a meglátásaidat (ettől még nem biztos, hogy valóban azok, de egyeznek az én gondolataimmal).

http://playground.arduino.cc/Main/InterfacingWithHardware#Communication

Itt az Arduino és Arduino, illetve Arduino és perifériák közötti kommunikációs lehetőségek vannak csokorra szedve.

 

Én mindenekelőtt a következő elvet követném: a szenzorok mellett lehetőleg az elképzelhető legkevesebb, legnagyobb üzembiztonságot nyújtó alkatrész legyen. Egy szimpla érzékelőhöz (akár analóg, akár digitális) egy 328P mikrokontroller plusz egy shield többé-kevésbé az ágyúval verébre kategória. Csak itt van a 22-es csapdája, mert olyan mikrokontroller, amely képes az önálló adatfeldolgozásra, kicsi, nem ágyuval verébre és nem utolsó sorban lehetőleg eleve tudja azt a kommunikációs protokollt (vagy inkább csatolófelületet), amit a projektre kitaláltál, gyors keresés után nem találtam. A CAN bus elegáns lenne, de ez is kicsit több a kelleténél. Munkás ugyan, de többé-kevésbé úgy állnék neki, hogy alap alkatrészekből (128P-alapú alap DIY arduino) + CAN bus vezérlő (vagy más, amit választasz), teleraknék 4 breadboard-ot, plusz egy nagyobb, későbbi adatfeldolgozásra alkalmas kártyát. Aztán tesztelnék feszt.

A kész kiépítés meg vagy egyedileg gyártott nyákokon vagy forrasztós próbapaneleken menne ki, szintén minimálkonfigurációba (ami nem kell, azt nem bekötni stb.). Az egyes adatgyűjtőket pedig az adott szenszornak megfelelően tudod felprogramozni (ICSP vagy soros, irreleváns), és jöhet a telepítés.

Előzmény: x20fan (792)
Prof Creative Commons License 2015.01.31 0 0 795

A CAN csak shielddel érhető el Arduinon.

Plusz egy eszköz. Ilyen projektek esetén én a minimálkonfigurációt javasolnám, már csak azért is, mert a minőségi +40 usd vagy az óccókínai 17 dolláros ár érzékelőnként (vagy néhány érzékelőnként) azért jelentős többletköltség.

Előzmény: Vargham (793)
Vargham Creative Commons License 2015.01.31 0 0 794

Gyártó linkje helyesen: Hope RF

Előzmény: Vargham (793)
Vargham Creative Commons License 2015.01.31 0 0 793

Ha vezetékes, akkor: CAN bus.

Ha rádiós, akkor: http://www.hestore.hu/prod_10032132.html

Kínából lehet rendelni olcsóbban is, van belőle többféle kivitel. Csak adó, csak vevő, adó-vevő, valamint többféle MHz.

Itt a gyártó: http://www.hoperf.com/search.asp

Van hozzá Arduino library: https://github.com/jcw/jeelib

 

A rádiót lehet broadcast üzemmódban is használni, de lehet csoportokba is rendezni őket, és csoporton belül még csatornát is lehet rendelni hozzájuk. Nem fogják zavarni egymást.

x20fan Creative Commons License 2015.01.31 0 0 792

Nem elég csak a hőmérséklet, akármi más is lehet szükséges. Fotoellenállás/dióda/tranzisztor fényt mér, folyadékba vagy földbe merülő fémpálcapár szintet vagy nedvességet mér, mikrofon hangszintet, potméter szellőzőzsaluk nyitottságát, de lehet mágneses térerő, közelség és még soksokféle mennyiség, ami analóg. Nincs mindenre 1wire szenzor, amit csak rá kell dugni a többi meg tisztán program. Millió féle szenzor van, és újakat is ki lehet találni, a mért értéket pedig el kell vinni a feldolgozó egységhez, a központi arduinohoz. Ez egy mindennapos probléma, erre kell megoldásnak lenni, különben az arduino meg a mérési adatok nem találkoznak.

Egyelőre eljutottam a gondolatkísérletben oda, hogy digitalizált adatokat kell továbbítani, buszon kell továbbítani (bár a cat5+router pont nem az, hanem csillag), ezért processzálni kell a szenzornál, amire olcsó és jó megoldás egy arduino. Milyen busz legyen? Amit a központi feldolgozó arduino és a szenzorok melletti arduinok összekötésére lehet használni. Az a jó, ha nem kell megírni hozzá a protokollt, hanem kész libraryt lehet használni. Lehet 1wire, csak tud-e a sok arduino úgy beszélgetni, mint ahogy sok ds hőmérő tud? Lehet soros, csak meg kell oldani a címzést, hogy ne legyen ütközés. Lehet egyedi, de akkor meg kell írni mindent, ami nem feltétlenül extra bolnyolult, hiszen pár bit a cím, majd beszél a szenzor, és ez ismétlődik. Viszont ehhez kell valami saját hw is, hogy kis impedancián menjenek a bitek elnyomva a zavarokat. Két pinnel megoldható, egyen kifelé küldi a központi egység a címet, a másikon befelé jönnek az adatbitek openkollektoros vonalon valami jól követhető sebességgel. Mivel a mérési eredmények 10 bitesek az arduino analóg bemenetével mérve, ha 10 ms egy bit, akkor is tizedmásodperc alatt bejön egy mérés, de lehet gyorsabb is, még nem jöttek meg az arduinok, nem tudok sebességet mérni. Igazából nem annyira kritikus a sebesség, inkább a zavarmentesség.

 

Javasolnám is, hogy akinek van már gyakorlata pl. ethernettel, írja meg hogy is nézne ez ki pl. két szenzorral és egy központi egységgel. Hogyan kapja meg a központi egység a két mérési adatot, ami 0-tól 1023-ig egy szám.

 

Illetve ha az egyedi megoldást nézzük, hogyan célszerű a mondjuk 4 címbitet kiírni, és a 10 adat bitet beolvasni?

Pl. legyen a fél bitidő L, és az utána következő fél bitidőben az adatbit H vagy L. Ezzel az a baj, hogy ha minden adatbit L, akkor végig L-ben lesz a busz.

Akkor legyen egy harmad bitidő H, harmad bitidő L és harmad bitidőben az adatbit. De más bevált megoldás is lehet, a lényeg, hogy ne legyen túl bonyolult megírni hozzá a programot, és biztonsággal olvashatók legyenek az adatbitek.

Előzmény: vfp (790)
x20fan Creative Commons License 2015.01.31 0 0 791

A cat5 kábel jó, elég olcsó és 4 csavart érpár van benne. Ethernet+arduino már 1500.- Ft/mérőhely, de sokkal jobban megbíznék az átjött adatban, mint egy analóg jelben röbbtíz m távolból. Teljesen szabványos, router vagy switch olcsó, semmit nem kell barkácsolni.

Előzmény: granov (789)
vfp Creative Commons License 2015.01.31 0 0 790

Ha hőmérséklet érzékelőket akarsz üzemeltetni, ott a DALLAS 1-Wire rendszere (pl.: Ds18b20) egyszerű és sokat fel lehet fűzni a buszra. (mivel magának az érzékelőnek van egydi címe) 1db digitális portot visz el, és nálam 30-40m síma 4-eres telefon vezetéken megy, több helyen szabványos RJ-11-es aljzatokat raktap bele, így kialaítva a leágazásokat. UTP-n még messzebre is mehet. De lehet két, vagy több buszt kialakítani, ha a busz hossza vagy iránya gondot jelent.

Nem kell különleges kliens-szerver szoftvert írni hozzá, egy egyszerű könyvtár és már lehet is címezgetni az érzékelőket.

 

Ha meg magas hőmérsékletet akarsz mérni (120C fölött), akkor már a MAX6675+K type páros, és nincs gond a torzuló jellel.

 

Az sebességre hivatkoztok itt, de miért is?

Az érzékelők lekérdezése kb. 1mp. Ezek mellett szerintem érdektelen, hogy az I2C 100KHz, vagy az SPI 400KHz. Tudtommal ezeket a protokolokat elsősorban eszközön belüli komunikációra találtak ki, tehet néhány 10cm. Tudom elmennek nagyobb távolságra is, de minek.

Mi a célja a mérésnek? Ha csak hőmérséklet naplózás, akkor a mérési intervallumok 30mp-1perc közöttiek (extrém esetben 10mp). Aztán csinálsz belőle 5 perces átlagokat és azt jeleníted meg grafikonon.

 

Én kb. így látom, várom más véleményét ezzel kapcsolatban.

Előzmény: x20fan (786)
granov Creative Commons License 2015.01.31 0 0 789

Hamár mindenhova arduino

nano/micro/mini +enc28j60 + egy nagyon olcsó switch (vagy használt router uszkve egy ezres).

CAT5 elég messze megy, sokkal több dolgot tudsz rajta átvinni. Szabvényos  és müxik.

 

Előzmény: x20fan (788)
x20fan Creative Commons License 2015.01.31 0 0 788

Az analóg jel továbbításával az a baj, hogy torzul, zavarokat szed föl, hacsak nem nagyon kis ellenálláson/nagy árammal történik. Ez viszont külön erősítőt igényel. És nehéz buszra szervezni, tehát ha 7 analóg jelet mérnék, akkor a 6 arduino bemenet nem elég, míg ha digitalizálom, és úgy akarom begyűjteni, az sokkal egyszerűbb. Habár most egyből nem tudnám megmondani, hogyan is kapcsolgatnék a buszra adatot. Könnyen lehet, hogy nem lehet megúszni az intelligens jeladót, ami pl. egy arduino nano vagy mini pro, és ezeket minden szenzor mellé kitenni, majd nem a szenzorokkal kommunikálni, hanem az arduinokkal. Egy vezérlőkóddal kezdeni a vételt, kiküldeni egy sorszámot, ezt minden arduino veszi, és az szólal meg a mért értékkel, amelyiket megcímeztem.
Az rs232 és rs485-nél nem tudom hogyan megy a buszra szervezés. Ezeket könnyű megcsinálni hosszú vezetékkel hibamentesre. Meghajtás kell, az arduino kimenet önmagában nem elég, meg a védelem miatt is.
A címzés miatt igazából a kézfogós protokollok nem jók, mert először csak hallgatni kell, amíg kimegy a cím, hogy kinek kell beszélni, aztán meg csak beszélni kell, és mindenki más hallgat. Már emiatt is a buta eszközök, mint pl. shiftregiszter nehezen elképzelhetőek. Ha meg a központi egységnél akarnám multiplexelni a távoli szenzorokat, akkor millió vezeték kellene, mindegyikhez vinni kellene a saját vezetékét, az nyilván nem jó.
Vezeték nélkül a BT-t kihagynám, 50 m-re nem érzem elég stabilnak, már a wifi is kérdéses, a 433 MHz-es modulok viszont kellően olcsók, és azt hiszem 100 m-t írnak rálátással. Csak nem tudom mi van, ha viszonylag közel vannak a szenzorok, szét kellene hangolni őket más-más frekvenciára, de nem hiszem hogy van ilyen lehetőség rajtuk. Ha nincs, akkor kiesett ez is.

Előzmény: Prof (787)
Prof Creative Commons License 2015.01.30 0 0 787

Ha nagyon nagy idiótaságot írok, majd legfeljebb valaki pontosít.

Ami nagy vonalakban a lényeg:
Alapvetően az Arduino analóg bemenetei erre a célra vannak, magát a jelet (ha az analóg jellegű, tehát alapvetően egy feszültség/áram viszony változó ellenálláson át való megváltoztatását jelenti), különösebb nehézség nélkül (elvben legalábbis) végtelen távolságra lehet szállítani. Itt csak a kábel minőségét, ellenállását, kapacitását kell figyelembe venni, illetve azt, hogy a jel mennyire érzékeny külső tényezőkre (környéken futó nagy feszültségű elektromos vezeték, telefonkábel, internetkábel stb.).
Amikor valamilyen buszt használsz, akkor egy meglévő analóg jelet alakítasz át digitális jellé, amelyet aztán valamilyen módon továbbítasz. Az egyes szabványok nagyjából determinálják az átvitel formáját és módját is, de pl. TCP/IP mehet soros kábeltől elkezdve wifin át BT-ig (meg még ugye kis millió más módon is). Minél komplexebb a továbbítandó adat (mérési sűrűség, mérési pontosság, hibahatár stb.), annál megbízhatóbb módot kell választani. A DS18B20 One Wire buszt használ, nem kell hozzá semmilyen további elem az érzékelő oldalán, a tápfeszültség alapján létrehozza és a busz-csatornán küldi a jeleket, akár elég jelentős távolságra (megfelelő minőségű kábelen persze). A megoldás előnye egyben a hátránya is: van kábel. Biztonságosnak tekinthető, nincs gond a tápellátással, cserébe telepíteni kell.

A kábeltelen megoldások közül mindegyiknek három fontos tulajdonsága van. Egyrészt a távolsággal arányosan veszít (rendszerint) a megbízhatóságából, mindenképp kell hozzá egy komplett jelfeldolgozó rendszer az érzékelő oldalán (igen, ez lehet akár egy arduino is, bár nem feltétlen kell), végül meg kell oldani a tápellátást valahogy (ami kábelezést igényel).

Az i2c elvileg alaplai kommunikációra lett kitalálva, elég érzékeny a rádiófrekvenciás zavarokra, bár én ezt annyira (eddig) nem tapasztaltam, igaz, hogy Arduino viszonyban ez azért elég alacsony órajelet jelent.

Az SPI egy klasszissal gyorsabb bír lenni (pláne, ha meghajtja valaki), tehát érzékenyebb valamivel, cserébe a kétirányúsága folytán megbízhatóbb.

E kettő inkább a klasszikus "szerver--kliens" vagy "master--slave" felállás szerint üzemelnek, tehát van egy központi (vezérlő) elem és egy külső, perifériális elem (pl. adatgyűjtő vagy kimenet).

Az RS485 -- ha jól emlékszem -- erősítés nélkül 100 métert kibír CAT5 kábelen, ami azért elég baráti (bár a One Wire is).

RS232 inkább szükségmegoldás szerintem, bár pokoli olcsó és egyszerű.

E kettő többé-kevésbé azonos "erősségű" berendezések közötti strukturált adatforgalmat tud megvalósítani (bár Master asszem így is kell hozzájuk). Okos ház tervezéshez ezek működőképes megoldások.

Előzmény: x20fan (786)
x20fan Creative Commons License 2015.01.30 0 0 786

Nagyobb távolságra milyen buszra érdemes érzékelőket kötni? Gondolok itt fényérzékelőre, vízszintre, tehát analóg mennyiségek digitalizált adatát kell átvinni 20-50 m távolságból. Soros port, rs485, vagy valami egyéb busz, i2c, spi, esetleg rf adó-vevő, BT, wifi? És mi legyen az érzékelő mellett? Egy másik arduino? Ha egy buszon vannak, akkor sorszámozni kell, van-e erre kész megoldás?

Prof Creative Commons License 2015.01.29 0 0 785

Nohát.

MAX7221 probléma „megoldva”. Nem stimmelnek a logikai szintek, úgyhogy valami csatoló kell... Gondolkodom, tanulok, aztán majd... A többivel nem volt időm foglalkozni.

Előzmény: Prof (739)
Prof Creative Commons License 2015.01.29 0 0 784

Úgy fest, pedig Rigoltól Agilentig volt rajta pár tétel. Csak tudott volna választani... :-)

Előzmény: Törölt nick (782)
Törölt nick Creative Commons License 2015.01.29 0 0 783

Így keress rá:

 

i2c port expander

 

fogsz pár találatot fogni....

Előzmény: x20fan (747)
Törölt nick Creative Commons License 2015.01.29 0 0 782

Én úgy tudom, nemrég volt karácsony :-).

 

Eltévedt felétek a Jézuska? ;-)

 

 

Előzmény: Prof (770)
Törölt nick Creative Commons License 2015.01.29 0 0 781

Kifejezetten olcsó távol keleti relékkel már volt olyan szívásom, hogy soha többet....

 

Persze tudom, minden ott készült, de ezek az olcsó minősítetlen jelfogók valamim katasztrófák, szó szerint életveszély. Amikor a névleges áram töredékétől összeolvad, szétég, avgy áthúz egy nyítottnak vélt érintkezőn, stb.

 

Valóban nem feltétlen tréfa állapotot tud eredményezni.

Előzmény: John Zero (778)
halaloszto Creative Commons License 2015.01.29 0 0 780

a meghalas egy dolog, kinemszarjale. magadnak azt csinalsz amit akarsz

 

melobol meg sem kell haljon senki ahhoz hogy a szabvanyoknak megnemfeleles miatt komoly fizetnivalod keletkezzen.

 

Vajk

Előzmény: Vargham (779)
Vargham Creative Commons License 2015.01.29 0 0 779

> Plusz ami nem hobbicélra megy, ott duplán meggondolandó, hogy pl. szép a relé-board, csak épp nincs meg rajta a biztonsági légrés.

Hobbiból is könnyű meghalni a nem megfelelő érintésvédelemtől...

Előzmény: John Zero (778)
John Zero Creative Commons License 2015.01.29 0 0 778

"Nekünk azonnal kellett 10 db. Másnapra itt volt. Ennyi előnye volt a magyar webshopnak."

 

Ahogy mondják: az idő pénz :-)

Amúgy az eBay-es tapasztalataim vegyesek, általában az jön ami kell, de vannak olyan dolgok (sokszor), ahol az olcsóság az igénytelenséget is jelent. Plusz ami nem hobbicélra megy, ott duplán meggondolandó, hogy pl. szép a relé-board, csak épp nincs meg rajta a biztonsági légrés.

Előzmény: Vargham (767)
Prof Creative Commons License 2015.01.29 0 0 777

:-D

Epic...

Előzmény: Törölt nick (776)
Törölt nick Creative Commons License 2015.01.28 0 0 776

Megoldódott a programmer not responding hiba.

Nem a kvarc, nem a forrasztások voltak hibásak.

A kicsi kínai egyszerűen felcserélte az Rx Tx feliratot a Arduino Pro Mini alaplapon.

A project mehet tovább.....

Előzmény: Törölt nick (712)

Ha kedveled azért, ha nem azért nyomj egy lájkot a Fórumért!