-
PROHARDVER!
Arduino hardverrel és szoftverrel foglakozó téma. Minden mikrovezérlő ami arduinoval programozható, és minden arduino program, board, és hardverrel kapcsolatos kérdések helye.
Új hozzászólás Aktív témák
-
-
agent_k
őstag
válasz
vargalex
#15857
üzenetére
Köszönöm! Nagy rajongód vagyok router témában. :) Köszönöm a hozzászólásodat. Körvonalazódott már, bennem is amit írsz. Ez egy dev board. Lehet játszani vele, de kvázi prod környezetre más megközítést kellene alkalmazni. De nem fogok. Napelem és 4056. Köszi srácok szerintem túl is beszéltük a témát
-
Tomika86
senior tag
válasz
vargalex
#15675
üzenetére
const byte PulsesPerRevolution = 2;
const unsigned long ZeroTimeout = 100000; // For high response time, a good value would be 100000.
// For reading very low RPM, a good value would be 300000.
// Calibration for smoothing RPM:
const byte numReadings = 2; // Number of samples for smoothing. The higher, the more smoothing, but it's going to
// react slower to changes. 1 = no smoothing. Default: 2.
/////////////
// Variables:
/////////////
volatile unsigned long LastTimeWeMeasured; // Stores the last time we measured a pulse so we can calculate the period.
volatile unsigned long PeriodBetweenPulses = ZeroTimeout+1000; // Stores the period between pulses in microseconds.
// It has a big number so it doesn't start with 0 which would be interpreted as a high frequency.
volatile unsigned long PeriodAverage = ZeroTimeout+1000; // Stores the period between pulses in microseconds in total, if we are taking multiple pulses.
// It has a big number so it doesn't start with 0 which would be interpreted as a high frequency.
unsigned long FrequencyRaw; // Calculated frequency, based on the period. This has a lot of extra decimals without the decimal point.
unsigned long FrequencyReal; // Frequency without decimals.
unsigned long RPM; // Raw RPM without any processing.
unsigned int PulseCounter = 1; // Counts the amount of pulse readings we took so we can average multiple pulses before calculating the period.
unsigned long PeriodSum; // Stores the summation of all the periods to do the average.
unsigned long LastTimeCycleMeasure = LastTimeWeMeasured;
unsigned long CurrentMicros = micros();
unsigned int AmountOfReadings = 1;
unsigned int ZeroDebouncingExtra; // Stores the extra value added to the ZeroTimeout to debounce it.
// The ZeroTimeout needs debouncing so when the value is close to the threshold it
// doesn't jump from 0 to the value. This extra value changes the threshold a little
// when we show a 0.
// Variables for smoothing tachometer:
unsigned long readings[numReadings]; // The input.
unsigned long readIndex; // The index of the current reading.
unsigned long total; // The running total.
unsigned long average; // The RPM value after applying the smoothing.Annyit szeretnék, hogy ami itt 3db const van, azokat az értékeket, kijelzőn keresztül szeretném módosítani. De nem működik.
Persze a const elhagyva, és itt van a Zerotimeoutnál a +1000 -
Janos250
őstag
válasz
vargalex
#15303
üzenetére
"Nincs is inicializálva a Serial"
"Abban soros porton megy ki az infó nem teló, hanem PC számára. De azzal se jutok előrébb."
Persze, de azt azért feltételeztem, hogy próba erejéig csak tett bele valami kiírást, nem anélkül várta hogy a serial monitoron megjelenjen valami.
"Az AP nevének meghatározása sem ördögtől való"
Igen, de ez AP, és ha be akarsz rá jelentkezni, meg kell keresned az SSID-t, hogy be tudj rá jelentkezni, míg ha te adsz egy SSID-t, akkor azt tudod. Egyik elegánsabb, másik kényelmesebb."az AP létrejön"
Persze, aboolean result = WiFi.softAP(AP_NameChar, "stargazing");
alapján kutya kötelessége létrehozni, ha csak nem valami idétlen
karaktersorozat van az SSID-ben (AP_NameChar), vagy nem rövidebb a PW ("stargazing") 8 karakternél.
Lehet épp azért nem látja, mert nem tudja, milyen néven keresse?
Vagy valami egyéb gond van, hogy az egész valami hardver ok miatt el se indul nála?
Mondjuk resetelve marad az ESP.Én egyébként az egészet kissé másként csinálnám. Nem szeretek minden app-ot felrakni a telefonra, inkább WEB-et használok.
Más, hogy én - mint írtam - mindig direktbe létre szoktam hozni az AP-, nem is próbáltam még anélkül soha.
-
válasz
vargalex
#15307
üzenetére
Azt írtad, hogy feltöltötted a kódot és nálad létrejön az AP, ezek szerint lehet, hogy nála valamelyik könyvtár nem stimmel. 🤔
Felmerül a kérdés, hogy Te régebbi könyvtárakat használsz, esetleg régebbi IDE-t, vagy mindent frissítve. Láttam már olyat, hogy egy régebbi kód csak régebbi IDE-ben, vagy egy library régebbi verziójával fordult csak le. -
Janos250
őstag
válasz
vargalex
#14922
üzenetére
Az este még nekiálltam egy kicsit tanulmányozni a javasciptet és az AJAX-ot, mert úgy láttam, hogy ezt nem úszom meg.
Kezdem kapisgálni, mi az, amit írtál. Tényleg meg lehet azt csinálni, hogy amikor a csuszkát elengedem, egy táblázatot szőröstül-bőröstül
újratöltsek anélkül, hogy az egész lapot újra kellene töltenem, és így nem villog a töltésnél. (Majd egyszer, ha lesz időm leírom összefoglalva, hogyan is kell az ilyesmit csinálni)
Egyébként megnéztem, a FF-nek nem okoz gondot, ha az AJAX-ra nem válaszolok, hanem csak feldolgozom az általa küldött értéket. A gondot az okozta, hogy ha nem válaszoltam rá, de a lapot egyből újratöltöttem. Akkor nem pontosan tudta, mitévő legyen.
Köszönöm neked is, és mindenkinek a segítséget, így a probléma tényleg megoldva, most már elboldogulok vele.
-
Janos250
őstag
válasz
vargalex
#14909
üzenetére
Na ez lenne a másik kérdésem, hogy ha beírom ezt a sort, akkor az ajax miért nem küldi el? Mert nem küldi el. Számomra ez érthetetlen.
Mellesleg a netet bogarászva találtam olyan utalást, hogy valahogy a # karakter használatával el lehet azt érni, hogy a lapnak csak egy részét frissítse, de semmi konkrétumot nem találtam arra, hogy ezt a WEB lapon milyen script utasítással lehet elérni, és hogy akkor a szerver mit válaszoljon rá. Jelenleg ugyan számomra nem létkérdés, mert az egész html szöveg 6 kbyte, de a kíváncsiság!
![;]](//cdn.rios.hu/dl/s/v1.gif)
Én azt hiszem, egyre többen fognak Arduino alapon netes vezérléseket csinálni, de semmi megfelelően összeszedett tutorialt nem találtam, ahol egyben le lennének írva a legfontosabbak.
-
-
Janos250
őstag
válasz
vargalex
#14871
üzenetére
Köszi mindkettőtöknek. Azért link, mert annak előzménye van, ezt tavaly mutattam, ahhoz akarnék kapcsolódni. Bár gondoltam, hogy mégis átállok buttonra, de a 14867-ban írt megoldás jól működik, az marad egyelőre.
Javascriptben intézném a hívást? Na, az nem megy, mert hülye vagyok a javascripthez.
Ezért nem boldogulok a 14863-ben leírt problémával se. Ott aXMLHttpRequesthelyett kellene valami javascriptes megoldás, de nem tudom mi. -
Janos250
őstag
válasz
vargalex
#14291
üzenetére
"Én leginkább a hagyományos C karakter tömböt használom"
Például a "raw string" használata nekem is nagyon jól jön néha.
Ide írom, mert szerintem többen nem ismerik:
Egyben lehet berakni egy karakter tömbbe szöveget.
Mindenfélét bambán, nyersen (raw) bemásol, nem kell például az idézőjelet (") hanyatt-törtvonallal (\) eldugni.
Most például egyben tudomclient.print(enSzovegem)-el
elküldeni a konstans szöveget, nem kell soronként kínlódnom vele.De mennek az alábbiak is:
Serial.println(enSzovegem);
printf(enSzovegem);
printf("Ez egy minta: %s \r\n",enSzovegem);const char enSzovegem[] PROGMEM = R"(HTTP/1.1 200 OKContent-type:text/htmlConnection: close<head>\r\n<meta charset="UTF-8">\r\n<title>WEB proba</title>\r\n</head>\r\n<body><h1>Ez az én próba szövegem</h1>)"; -
Janos250
őstag
válasz
vargalex
#14291
üzenetére
Helló!
BUÉK mindenkinek!
Ezt szerettem volna, de nem megy:
http://www.cplusplus.com/reference/string/string/find/
Magát a string osztályt lehet használni ESP32-n, de a find nem jól működik. Pedig sok minden van a string osztályban.
pl.:http://www.cplusplus.com/reference/string/
Vagy én ittam túl sokat. :-)
Az Arduino String osztályában ugyanennek nem find a neve, hanem iindexOf . Az jól működik, bár először azon is meglepődtem, mert az eredményt megkapó változót megszokásból előjel nélkülinek deklaráltam, és csodálkoztam, hogy ha nem talál, akkor 255-öt (=-1) ad vissza indexként. -
#14240
Drótszamár
őstag
vargalex
#14238
Drótszamár
őstag
válasz
vargalex
#14238
üzenetére
vargalex, gyapo11: Köszi, erről nem is tudtam.
Kipróbáltam, de sajnos nem működik. Lehet túl régiek vannak nekem. Az egyik 2015-ös gyártmány, a másik még régebbi. Az talán az első modell volt. 10400 mAh a kapacitása.
------------
Elektronikát mivel lehet megvédeni nedvességtől? A mostani több hetes ködös idő több terepen lévő hőmérséklet szenzoromat is megölte. A szenzorokat kimaszkolva körömlakkal kenjem le a nyákot? Van erre valami bevált módszer?
Pl az egyik szenzor modul ami egy tányéros árnyékolóban van.
-
Dißnäëß
nagyúr
válasz
vargalex
#13000
üzenetére
Sosem az az 1 dolog a lényeg, amiről szó van, hogy törhető-e vagy sem, látható-e vagy sem, hanem ezek kombinációja. Teljesen természetes dolog kellene, hogy legyen, hogy egy wifi router-t úgy setup-olunk fel, hogy csak a bele konfigolt MAC című eszközöket engedje fel, ez Pistikét távol tartja, miközben természetesen a WPA2 is aktiválva van, ami meg Jurijt és Szergejt is. És még AP isolation-el, meg routing-ban is lehet tovább cifrázni. Tökéletes védelem wifi-n nincs, az sosem lesz egy zárt lánccal egyenértékű (ezért is jó a wifi szegmenst a vezetékestől külön választani L2-ben, az eddig tárgyalt ARP poisoning így a wifi buborékon belül marad). De azt belátjuk, hogy Pistikéből rengeteg van, így MAC cím látás ide vagy oda, az első szűrő, amolyan nagyobb lyukú szita, megfogja a kosz 99%-át és már csak a maradék 1%-al kell mondjuk a további lépcsőkben foglalkozni, ha paranoidok vagyunk (hűtő és kávéfőző IoT esetében nem vagyok az, fűtés szó-szó, ott már inkább).
Sosem egy dolog jelent abszolút biztonságot (ha lehet ilyenről beszélni). Egy kezdő szöcske nem fog neki MAC-eket nézegetni, egy zombi eszköz talán (ugye a kártékony kód írójának leleményességétől függ annak hatékonysága), egy okosabb ember igen. És minél több lépcsőn kell keresztülmennie, hogy eljusson céljához, annál jobb a védőnek, annál inkább fogy az akarat, a gőz a támadóból, míg végül ha az ember jól csinál mindent, megakad egy olyan ponton, ahonnan már nagyon nagy az esélye annak, hogy ott megállni kényszerül és kész. Persze ha tartós kárt nem is, bénulást így is okozhat, attól függően, milyen mélyre ment. Lényegében - elméletben - minden törhető, gyakorlatban ennek vannak lépcsői és fokozatai, melyek különböző mennyiségű erőfeszítésbe kerülnek, kezdve Pistike hobbista "törjünk valamit" kedvétől odáig, hogy kvantum számítógép sem fejti meg 10 perc alatt a sztorit, ez a vonalzó másik vége.
Ha most körbenézek a telómon (társasház, földszint), perpill. 14 (!) SSID-t is szóró AP-t látok magam körül. A rájuk kötött okos eszközökkel és kliensekkel együtt ez nem túl megnyugtató, és bár - feltételezhetően - mindegyik Pistike, mi van, ha csak 1 közülük nem az.
Arról nem is beszélek, hogy éjszaka a fejem mögött a téglafal túloldalán vajon a szomszéd ágya van-e a fejrésszel szintén, vagy egy router, mert neki az a nappalija és egész idő alatt kapom a rádiót agyba. Ezt túlbeszéltük (szegény Arduino topic).
Mindent kell alkalmazni egy időben, ami kezünkben van. Ezért mondtam, hogy a wifihez képest a mobil netes SIM kártyás IoT ad nem kevés plussz biztonságot, de kitettséget is egyben. A biztonság az tiszta, a kitettség viszont azért, mert ha a mobilszolgáltató megmakkan, pl. kitör egy háború vagy a politika úgy dönt és bumm, akkor a kerti öntöző, locsoló és a többi, mondjuk alapvető élelmiszer-ellátásomat biztosító kis eszköz hirtelen elveszti a kapcsolatot a külvilággal és magára marad, meg a gyári is leáll. Az ő pici kódjában nem sok logika marad, bár ez is implementáció függő, de a bonyi dolgok általában külső agyba mennek, Pi, egyéb. Nem mintha egy háború vagy bármi hasonló esetén marhára érdekelne, mi megy, az ember fut inkább, de ez más téma.Ha most lenne egy 1-2 hektár területem, egy tanyám, ahol ilyenekkel foglalkoznék (ez a célom hamarosan), elagyalnék azon, wifi-re tenném-e az eszközöket, vagy mobilos netre. Valszeg az önállóság és függetlenség paraméterek mentén wifire szavaznék, pláne, ha a fizikai közelségbe kerülés esélye konvergál a nullához, akár még antennával is, mert olyan a terep. De ha mondjuk egy sűrűn lakott belvárosi kecóban kellene agyon IoT-zni mindent, a beléptetésen kívül szerintem mindent mobilnetes kütyükre bíznék wifi helyett, mert összehasonlíthatatlanul biztonságosabbak a kommunikáció alsóbb rétegei. Az más, hogy pont a kávéfőzőnek adni emelt biztonságot abszurd, de ha mondjuk egy műhelyről, kisebb telephelyről, gyárról, fontosabb dologról van szó, ahol azért még lehet bőven sniffelni wifit, jobb egy mobilszolgáltatóval menni.
Szerintem aki eddig wifire tette az eszközeit, most nagyon kezd elbizonytalanodni, ügyelt-e vajon mindenre kellőképpen és legalább a minimumot meglépte-e ezen a biztonsági teendők skálán.
Értelmezhető adat tekintetében a nagy átlagnak azért a WPA2 elég nagy lépcsőugrásnyi biztonsági szintet nyújt már a békés alváshoz. Egy darabig még. (Na itt lehet gond a korábban feszegetett 10+ éves életciklus).Szerk.: tökre egyetértek Veletek, ezt inkább csak úgy a nagy plénumnak leírtam..
-
-
-
Bogyo72
csendes tag
válasz
vargalex
#12146
üzenetére
Ez így van, de mégis valami nem ok vele. Az persze még hozzá tartozik, hogy a megjelenített számokat középre igazítva íratom ki, így a teljes kiírás elmozdul amikor egy 1-es kerül bele.
De majd csinálok egy konkrét példát pl.: 00 aztán 01-et felváltva kiírva, hogy egyértelmű legyen tényleg mindig rossz-e vagy teljesen véletlenszerű, bár egyik sem jobb.Vagy áttérek erre a libre: [link]
Elvileg ez is támogatja ezt a kijelzőt és tud fontsimítást is.
-
gyapo11
őstag
válasz
vargalex
#12068
üzenetére
74VHC123AFT akadt elsőre a kezembe, 4 μA standbyban. Mos fet szintén pár μA lehet. De nem is csak az arduino fogyaszt, mert mi van az rf modullal és a hőmérőkkel ha a táp rajtuk van, és még ott van a táp konverter modul alapárama is. Legyen mondjuk 10 μA, az 2000 mAh kapacitást feltételezve 240000 óra, ami 27 év készenlét. Persze ez se igaz, mert mérni kell az időt ami valami oszcillátorral meg számlálóval megy, szóval több lesz azért a fogyasztás.
-
hermit
tag
-
op9
aktív tag
válasz
vargalex
#11455
üzenetére
Sikerült haladnom a dologgal. Mivel mondtad, h ha nem lenne bootloader, akkor nem is lehetne USB-n feltolni a kódot, így rákerestem, hogy hogyan lehet upgrade-elni, mivel akkor kell rajta lennie.
Ennek a segítségével sikerült 1.5-ről 2.3-ra rakni, és most már ha újra rádugom az eszközt, akkor a korábban rátöltött villogás megy. Szóval így a jó, csak most "Unknown USB Device (Device Descriptor Request Failed)" lesz amint betölti a villogást.
Szóval köszi, így már előrébb jutottam! -
válasz
vargalex
#11273
üzenetére
Újraírtam csak az indexelést, így most tökéletesen megy: [link]
Leszámítva, hogy soros portra semmit nem ír ki.
Azt hiszem az volt a baja eddig, hogy amíg balra indexelek, addig a jobb oldalit le kell kapcsolni, plusz fordítva is. Nem volt lekezelve ez az ága a feltételnek. -
válasz
vargalex
#11232
üzenetére
Most látom, hogy írtál egy új megoldást. Köszönöm!
Annyiból összetett, hogy a csúszka, giroszkóp az elé teszi a csatorna nevét, stringet küld, a gombok meg nem, azok float/int adatot küldenek. De akkor azt lekezelem valahogy.
Egyébként nem nagyon értem a packetbuffert. Ha a buffer mérete 4 byte, akkor abba hány karakter fér? Nem 4 hanem 5? Miért 5, mert van 0. eleme is?
Konkrét példa: csatorna neve abc és utána a csúszka ad értéket 0-240 között. A változatlan kódom ekkor lecsapta az abc-t, és átjöttek a számok 0-99 között. De az már 5 karakter hossz.Még egy kérdésem van: a wifi ap nevét, jelszavát, csatorna számát miért nem módosítja, ha átírom a forrásban és újra feltöltöm? kb 20-ból 1x sikerült módosítani, akkor is a példatáras wifi ap programmal, nem ezzel amivel kísérletezek.
-
válasz
vargalex
#11226
üzenetére
Köszönöm!
Érdekes, hogy a LED_BUILTIN a flashelős ledet kapcsolgatja, a gpio14 meg az sck feliratost. Ez jó, mert egyszerre tudok akkor két gombot+adattovábbítást tesztelni. Este nem tűnt fel.
Még most jön a neheze, mert a motorokat is kéne távirányítani. Az biztos, hogy lesz egy dc motor, amivel előre-hátra fog menni a járgány, a kanyarodást még nem tudom. Van servo motorom is, meg van dc motorom is. A dc az pont beillik átépítés nélkül, a servo meg pontosabb ahogy nézem. Egyelőre folytatom a dc motor irányításával. Egy csúszkával akarom szabályozni a sebességét és az irányát. Min érték -255, max 255, 0-val pedig megáll.
Tehát az elképzelés: 3 byte-ot küldene a RoboRemo.
Értékek: -255 - 255 dc motor sebesség, 256 első+hátsó ledek, 257 és 258 index, és a telefon elfordításával kormányoznám, mondjuk 500-600 közötti értékekkel.
Az ingyenes Roboremo 5 funkciót enged, ennyi pont beleférne. -
válasz
vargalex
#11223
üzenetére
Köszönöm, igen, a stringgel volt baja. Ha átkonvertálom int-be akkor végre belemegy a feltételek vizsgálatába. Hát, nagyjából működik, most jönnek a 0-ák maguktól is, ezt még pontosítani kell
Bár most lehet azért jön 0, mert az Y tengelyt is küldi a roboremo, és azokat az értékeket veszi 0-nak. Meg végül is felesleges 8 byte, elég lesz 1-2 is.
Megadtam neki végül fixen a gpio 14-et is, mert a builtin nem megy valamiért.
forrás
Halad ez -
válasz
vargalex
#11213
üzenetére
Ok, aztán már leesett...
Most kezdem akkor onnan, hogy legyen a Wemos az AP, és legyen rajta sima egyszerű web szerver. Ez most úgy fest működik is: pastebin link
Kiírja soros monitorra amit kell.
Ha pingelem a laptopról, akkor nagyon sok a csomagvesztése. Ez miért lehet? Ennyit bír a lap? A reakcióidők is nagy szórást mutatnak. -
gyapo11
őstag
válasz
vargalex
#11174
üzenetére
A böngésző a NAT mögül kapcsolatot tud teremteni egy serverrel, aminek van netes IP címe. Ugyanígy egy másik NAT mögött levő gép is, ezután a server szerintem már kihagyható, és mindkét gép számára a másik lép a server helyére.
Arra gondoltam, hogy a teamviewer servert használni, de persze ha a protokoll nem ismert, akkor erős reverse engineering kellene hozzá.
Ott van a bittorrent, két NAT mögötti gép képes egymással adatot cserélni, kapcsolat felépítéséhez kell a server, de utána már nem. De voltak más ilyen peer to peer filecserélő programok is. -
gyapo11
őstag
válasz
vargalex
#11171
üzenetére
Nem arra gondoltam, hogy a kódot egy az egyben mikrovezérlőn futtatni, hanem a módszert követni, bejelentkezni egy serverre mind a kliens mind a server, és azon keresztül adatokat továbbítani. Azt nem tudom, hogy a teamviewer csak a bejelentkezés idejére használja a servert, és aztán már a két külső gép közvetlen kapcsolatban van, vagy minden a serveren keresztül megy, de utóbbi esetben elég nagy terhelése lenne.
A lényeg, hogy ha két pc tud kapcsolódni NAT mögül, akkor két mikrovezérlő vagy pc és mikrovezérlő is, csak kell hozzá a program. -
válasz
vargalex
#11163
üzenetére
Nem csak bizalom kérdése, nem vagyok biztonsági szakember, meg nem is szeretnék a kelleténél többet foglalkozni az otthoni hálózat biztonságával. Nekem kényelmes, hogy a NAS-on futó smb hálózat jelszó nélkül üzemel, hogy a raspberry a gyári ssh jelszóval nyitható stb. A torrentezés miatt az ip címem sem hadititok, így jól jön, hogy van egy plusz "tűzfal", ami véd. Ha kivennének a NAT mögül, ezeket a réseket mind be kéne tömnöm, és akkor még mindig ott van annak a lehetősége, hogy a routeren befoltozatlan biztonsági rés van. Jobban bízom a láthatatlanságban.
Jártam már úgy, hogy torrentezős gép egyik napról a másikra 250+ vírust szedett össze, mert csak a router és a windows tűzfala védte. De nem akarok offolni tovább. -
PHM
addikt
válasz
vargalex
#11066
üzenetére
Biztos.
Mit gondolsz, az akkupakkokban/powerbankokban talán mindig
válogatott, tökegyforma cellák vannak? Segítek: nem.
Párhuzamos kötésnél a töltő és a kisütő áramok is megoszlanak,
a cellák belső ellenállásának függvényében.
Neked is azt mondom, kicsit tájékozódj lítium akku ügyben. -
zsolti_20
senior tag
válasz
vargalex
#11059
üzenetére
Az a megoldas mennyire jatszik, hofy egy toltesvezerlore egy akkumulstort csatlakoztatok. 4db darab eseten 4 toltesvezerlot hasznalnek. Keresek egy toltot ami bir 2A amper kerul es szerkesztek egy tolto kabwlt hozza aminek egyik vege usb masik pedig 4 mini usb. Igy egy konektorbol vagy egy toltocsatlakozobol tudnek tolteni 4aksit.
-
-
válasz
vargalex
#11059
üzenetére
A másik pedig, hogy a töltő az áramfelvétel csökkenése alapján figyeli a töltöttséget, és több akkunál, még ha történetesen egyformán is veszik fel a töltést, annyifelé oszlik ez az áram, ahány akksi össze van kötve. Így könnyen túl lehet tölteni a cellákat, mert nem áll le a töltés időben.
-
Teasüti
nagyúr
válasz
vargalex
#10179
üzenetére
Vagy ha úgy érted, hogy a Motionapps20 header fájlból van-e több példány is, akkor igen. Van egy módosítatlan a könyvtárban és a módosított meg a program mellett. De nem gondolom, hogy ez probléma lenne. Ha nem a program mellettit töltené be, akkor nem az osztályra dobna hibát, hanem sok másra.
Meg a példában simán lefordul így. -
tvamos
nagyúr
válasz
vargalex
#9672
üzenetére
Tegnap kaptam egy döglött 84 cellás ebike akupakkot. Piszok kemény. Olyan akku összekötô lemezek vannak benne, hogy nem viszi el a kínai dremel.
Nektek mi a beszt prektiszetek leszedegetni az aksiról az összekötô lemezt?
Nem akarom teljeszen szétrobbantani, a 4. parallel csoportban döglött meg valamelyik cella, ott akarom elcsapni. Ami alatta van, azt bontanám, de nem akar engedni. -
_q
addikt
válasz
vargalex
#9503
üzenetére
Közben gondolkoztam, hogy oké 170mA meg a dropout is kicsi, de nem kellene inkább egy step up converter? Tehát step up az aksi feszültségét 5 V-ra, majd azt LDO-val 3.3V-ra és ez menne ESP-re?
Az aksi kb. 2.8-4.2 V között használható biztonsággal. Adatlap szerint ESP8266 2.5 - 3.6 V, ESP32 2.3-3.6 V között működik. Ha Wifi is van, gondolom akkor legalább 3 V kellene.
Ha figyelembe vesszük mondjuk, hogy a dropout 300 mV és meglegyen a 3V táp az ESP-nek, akkor 3.3 V kimeneti feszültség kellene az aksi felül. Azaz 4.2-3.3 V között lehet kihasználni az aksit. Ellenben ha kap egy step up convertert, akkor mehetne 4.2-2.8V között, +0.5V pedig deep sleep esetén akár heteket jelentene.Ha jó a gondolatmenet, akkor step up hasznosabb lenne szerintem. Mit gondoltok?
(#9508) Janos250
A schematic-on van egy 22uF párhuzamosan 100nF-al az LDO kimeneten, ESP mellett pedig 100uF tantál VCC-GND között. Sajnos többet nem igazán tudok hozzátenni, nincs túl nagy tapasztalatom, így többnyire már meglévő részekből dolgozok. -
_q
addikt
válasz
vargalex
#9506
üzenetére
Az a nyugalmi áramot jelenti, gondolom, ha nincs rajta terhelés. Ha már ott egy ESP, meg még pár kisebb alkatrész, akkor szerintem ez nem igaz. Current consumption meg nincs benne.
(#9505) Janos250
Úgy tudom 5 V legalább ajánlott, főleg mivel a kínai alkatrészek jobban szórhatnak mint egy "bevizsgáltabb" darab.
100nF-ot hogy érted kerámia tantál? Egybe a kettő hogyan? Én egy doit shematicot használok, az alapján csinálom a nyákot. Ott 100uF 6.3V-os tantál van jelölve, semmi más. -
_q
addikt
válasz
vargalex
#9484
üzenetére
Köszi. Néztem ezt is csak a 250 mA-es max kimeneti áramot kevésnek tartom.
(#9488) Janos250
Köszi ez kellett igen. Ez alapján tudja amit szeretnék.(#9489) Tankblock
Köszi, akkor ez lesz a befutó. Egyébként csináltál hozzá nyákot amire mondjuk rádugtad tüskesorral vagy próbapanelen forrasztgattad össze? -
ZTE_luky
aktív tag
válasz
vargalex
#9170
üzenetére
nem nem ti értettétek félre, ne haragudjatok, én nem voltam egyértelmű. szóval ez egy fa keretbe megy bele, és a portokat szépen be szeretném faragni hogy stílusos legyen. A rajz nem a mostani bekötést ábrázolja, csak a szerintem helyeset. sokkal szebb lenne ha csak egy port lenne a fából kifele, azaz csak a mini usb-ről kapná az áramot az egész. viszont a képen egy olyan megoldás van ábrázolva hogy egy dc csatit is befaragok, és egy mobil töltőről bemegy egy dc csatin keresztü la GND 5V-ra az áram, és külön a szalagra egy Y toldással. de akkro meg is válaszoltátok, kelleni fog a külön port, a mini-t eg majd csak programozásra hazsnálom
xboy89
igen sajnos a szalagban van valami gyárilag amitől alap 5V,GND ellátás miatt mindig felvillan, ezért a powerbanket alapból mellőzöm szerintem, főleg hogy az általad linkelt oldal pár napot jósolt meg neki
ha jól értelek, köthetném úgy, hogy arduino usb-n kapná meg az áramot, és ugyanúgy az usb portra forrasszam rá a ledeket is? Tehát ne az arduino 5V GND tüsiére, hanem ahogyan az általam készített képen is látszik? és akkor nem lenne gond a stabilítással.
Igen nekem is ezt mondták, hogy ha kisebb teljesítményű tápra rakok valamit tönkre nem megymax nem működik jól. ergő igaz hogy normál esetben 6-8A kéne nekem, de mivel nagyo ntakarékon működi ka 2A is elég, és ha jól működik és elviszi rendesen, nem lesz baj.
Bocsi mégegyszer a kétértelműség miatt, meg netán ha hülyék a kérdések
a problémát én bonyolítottam túl. egy képpel egyszerűsíteni szeretném. a mostani kérdésem csupán csak az hogy egy usb kábelen/porton átmegy annyi áramerősség ami ehhez nekem kelleni fog, vagy "szépen" forrasztgassak "rendes" vezetékeket az egységekhez?
-
válasz
vargalex
#8993
üzenetére
Azért írta xboy89 a fettel vezérelt feszültségmérést, mert így csak a mérés ideje alatt fogyasztanak az ellenállások.
Mondjuk ha jól számolok, 3,6V névleges akkufeszültség mellett 2db 10k ellenálláson 0,2mA folyik el, kapcsolgatás nélkül. Az esp deep sleep alatt mennyit fogyaszt? És a boost-buck konverter? -
_q
addikt
válasz
vargalex
#8974
üzenetére
Rosszul fogalmaztam, igen a kívülről történő elérésre gondoltam, hogy még nem tudom kelleni fog-e. Ha thingspeak-re szeretnék valamit feltenni oda gondolom nem kell. Más mondjuk nem jut eszembe hogyan tudnám megoldani az adatok megjelenítését grafikonon.
(#8975) Teasüti
Igazad van hogy jó lenne olvasni, csak jelenleg nem sok fogalmam van arról, hogy mit is olvassak. Azt tudom mit szeretnék elérni és rá tudnék keresni virágnyelven, de az kevés ahhoz, valahogyan szakmaibban kellene keresgéljek. Viszont most már pár szakmai kifejezés szóba jött, ezek menték keresgélek. Csak megint előrébb járok fejben, mint gyakorlatban -
_q
addikt
válasz
vargalex
#8972
üzenetére
Nagyon köszönöm, keveredtek bennem a fogalmak.
Remélem a türelmed nem fogyasztottam el teljesen Első körben nem akarom kifelé az adatokat küldeni, ha majd mégis szeretném akkor a korábban szóba került módon meg tudom tenni (digit felhívom és megkérem intézkedjenek, vagy nyitok egy portot kifelé a routeren).
Erre majd még visszajövök kérdezni ha eljutok oda. -
_q
addikt
-
AcCEsS
senior tag
válasz
vargalex
#8942
üzenetére
Érdekes volt a topic amit linkeltél, sok hasznos infóról lehetett olvasni benne, köszönöm! Hasonló okosságokat találtam ezen az oldalon a deepsleep és a power save témáiban közzétett tapasztalatokról/javaslatokról. Egyiket-másikat a tegnapi napon beépítettem a saját projektembe, és - jelenleg úgy néz ki - sikerült komolyabb előrelépést elérnem az energiatakarékosság szempontjából. Pl. a szenzorok által mért értékeket RTC User memóriába tárolom (az tényleg max 512 byte?), majd a kövi mérést összevetem a tárolttal, és csak akkor húzom fel a wifit és küldöm be az infókat a Domoticz számára, ha volt bármiféle változás a mért értékekben. A túl gyakori - és nem igazán hasznos - változásokat a mért érték minimális kerekítésével küszöböltem ki (pl. a lux értéket 10-re kerekítve használom, a hőmérsékletet meg 1 tizedesre), mert minden elsuhanó felhő változtatott a percenkénti adatokon, pl. 1723 ról 1724 luxra módosult a mérés, és csak emiatt indult be a wifi. Kb. 20 órája megy az új algoritmus, de a fogyasztás nagyjából megfeleződött, mert volt olyan időszak éjszaka, amikor 73 percen át nem változott a mért érték, nem kellett wifi-n keresztül beküldeni az adatokat. Ébredés után Wifi nélkül és a delay sorokkal együtt 28 milliszekundum alatt lefut ez értékek begyűjtése és tárolása a szenzoroktól, majd jöhet a várva-várt szundi. Wifi-vel ez kb. 1600-1700ms, de csakis BSSID, meg fix wifi csatorna és statikus IP cím használatával! Képes voltam #ifdef-el megcsinálni a teszt és az éles változat fordítását, hogy még a serial.print() meg a többi fejlesztést segítő csacskaság se vegyen el plusz időt és energiát a végleges változatban.
Eccerűen ráfüggtem a témára, de nagyon! 
-
_q
addikt
válasz
vargalex
#8944
üzenetére
Elhiszem én is, de nem látom hogy tényleg jól írtam-e meg a kódot addig, amíg aksiról nem megy hosszabb ideig.
Másik kérdés mindenki felé.
ESPnow tényleg nem megy WIFI-re csatlakozással együtt? Adott 2 db ESP, egyik mér, küld adatot a másiknak, aki netről fogad/küld adatot. Ha nem ESPnow, akkor mivel lenne érdemes a két eszköz közötti küldést megoldani, hogy WIFI-re is tudjon az egyik csatlakozni? -
AcCEsS
senior tag
-
tibi-d
tag
válasz
vargalex
#8882
üzenetére
A PLC-k úgy működnek, hogy a ciklus elején a fizikai "Input" területet bemásolják egy virtuális memória területre. Ezzel a memóriával dolgoznak a ciklus végéig. A ciklus végén a belső memóriaterület kiíródik a fizikai kimenetre.
Minden bemenet megtatrja állapotát a következő ciklus elejéig, az összes kimenet megtartja állapotát a következő ciklus végéig. Az arduinónál akár programsoronként ki-be tudom kapcsolgatni a kimeneteket, vagy soronként be tudom olvasni a bemenetet. -
Janos250
őstag
válasz
vargalex
#8807
üzenetére
Bocs, ez Xboynak ment volna, de már nem írom át.
Elméletben a szolgáltató a saját routerén engedélyezhet port átirányítást a belső IP-re. Mondom, csak elméletben, mert nincs tapasztalatom vele, fogalmam sincs, hajlandó-e rá a Digi. Mint ahogy azt se tudom, mennyi pénzt kér saját fix IP címért, vagy ingyen megteszi. Rémlett, hogy valahol azt írták, hogy igen. Rákerestem:
"Digi internet esetén hívjuk fel a 1272-es telefonszámot és a NAT kikapcsolását kérjük a hibabejelentő menü kiválasztása után. A mai napig működő megoldás még."
[link] -
Tankblock
aktív tag
válasz
vargalex
#8764
üzenetére
én meg ESP-01 et ehhez a projecthez meg AtTiny13A-t.
A beépített linear DC-DC miatt - ezek sohasem lesznek jók másra, mint kipróbálni hogy működik e - ha azt lecserélnék egy sokkal hatékonyabbra akkor talán...
van 2 Wemos board de nem nyűgözött le, maradok a saját tervezésű boardoknál, igaz lassabban jutok el a project végére, mert több idő, több hibalehetőség, és több füst :-P
-
Teasüti
nagyúr
válasz
vargalex
#8629
üzenetére
Úgy tűnik éppen ez a hiba forrása.
Nem tudom mi történik pontosan mikor a j átfordul nullán, de olybá tűnik felülír vhol vmit, amit nem kéne.
Ezt alátámasztandó a hiba elhárul ha az elemek számát 255-re emelem vagy megakadályozom, hogy átforduljon.
Ahogy tanulmányozgattam a C string-eket, ezek csak pointerek és nincs megkötve az elemek száma. Ezért is nem panaszkodott, mikor a data[8]-ba beraktam vagy háromszor annyi elemet.
ESP32-nél talán azért nem jött elő, mert szimplán mocskosul sok memóriája van az Uno-hoz képest. -
Teasüti
nagyúr
válasz
vargalex
#8629
üzenetére
Igen, azt már átrágtam párszor. Fordított sorrendben rakja ki a kijelzőre azt a 4 bájtot, amire a j számláló hivatkozik. Tehát max 4-ről indul - buff[4] - és eltárolja csökkenő sorrendben a következő 4 karaktert (vagy hát amíg kifut a számláló az értelmezhető tartományon - a nulladik elem az meg úgyis felül lesz írva később, 255-ről átfordulva meg már nem érdekes) amit kirak a kijelzőre.
Kicsit baltával faragott módszer, de így nem kell külön tükrözni a tömböt.
És a cikluson belül csak ez a sor lépteti a j változót a következő számjegyre, de csak ha nem pontot kap a bemeneten, amit speciálisan kell címezni az MSB-vel a bájtsorrendben.Nálad produkálja a hibákat?
-
Teasüti
nagyúr
válasz
vargalex
#8621
üzenetére
Épp a Serial.print parancsokkal küzdök, ugyanis rendre megváltoztatják az adatot és teljesen kiszámíthatatlan hibákat okoz.
Van vmi ötlet miként lehet ennek a végére járni?
Megkérhetlek benneteket, ha van egy kis szabadidőtök, hogy lefuttatjátok ezt a programot?
A könyvtár elvileg bugmentes, azt csinálja amit szeretnék, stb.
Eredeti Uno R3-ason futtatom. (Mondjuk lehet ki kéne próbálnom másik lapon is.)
A setup()-ban a for ciklussal játszadozok most és teljesen inkonzisztens eredményeket ad nekem.
1. ha nem ismétlem a sprintf parancsot, akkor már a második alkalommal korrupt adatokat ad át a függvénynek.
2. A Serial.print(data) hibásan működik.
3. Ha a ciklus paramétereiben a temp változóhoz hozzáadok egy számot - hogy tovább fusson -, akkor az első pár ismétlés után egyszercsak azt írja ki a konzolra, hogy a ciklusszámláló értéke 132 és kilép a ciklusból.
Bárkinek bármi ötlete mi az ördög folyik itt?
3+ Ez esetben ha a temp változót volatile-nak deklarálom, akkor nem akad ki 132-vel.
Én ebből semmit nem értek. -
ngabor2
nagyúr
válasz
vargalex
#8320
üzenetére
Köszi szépen, valószínűleg ez volt a hiba. Holnap kiderül...
Amúgy a relén korábban egy relé modult értettem, tehát nem az arduino lapnak kell táplálnia.
Teasüti: nem akarok műveleteket végezni az idővel, mindössze arra voltam kíváncsi, hogy számként, vagy BCD-ben van tárolva. De számként van.
-
ngabor2
nagyúr
válasz
vargalex
#8311
üzenetére
Nem méretm, hanem kipróbáltam. 3 másodpercenként váltogattam a HIGH és a LOW állást, kapcsolgatott.
Viszont valamit nem értek. A korábbi kódot módosítottam egy kicsit, különvettem a kapcsolást és az idő ellenőrzését. Hogy lássam, mit csinál, ideiglenesen 16 órát állítottam be. A módosult kódrész:
ora = t.hour();
Serial.println(ora, DEC);
if (ora > 5 && ora < 16 ){
p2 = 1;
}
else{
p2 = 0;
}
if (p2 = 1){
digitalWrite(2, LOW);
}
else{
digitalWrite(2, HIGH);
}
Serial.println(p2, DEC);A kimenete:
2018/3/26 (Monday) 16:34:1
16
1
2018/3/26 (Monday) 16:34:4
16
1Tehát hiába 16 az ora értéke, ami nem kisebb, mint 16, tehát az első if() értéke hamis, a p2 mégis 1 marad. Az időt számként tárolja, mivel próbaként műveleteket végeztem vele és ment, illetve az ora és a p2 int típusú.
![;]](http://cdn.rios.hu/dl/s/v1.gif)
Mindent kell alkalmazni egy időben, ami kezünkben van. Ezért mondtam, hogy a wifihez képest a mobil netes SIM kártyás IoT ad nem kevés plussz biztonságot, de kitettséget is egyben. A biztonság az tiszta, a kitettség viszont azért, mert ha a mobilszolgáltató megmakkan, pl. kitör egy háború vagy a politika úgy dönt és bumm, akkor a kerti öntöző, locsoló és a többi, mondjuk alapvető élelmiszer-ellátásomat biztosító kis eszköz hirtelen elveszti a kapcsolatot a külvilággal és magára marad, meg a gyári is leáll. Az ő pici kódjában nem sok logika marad, bár ez is implementáció függő, de a bonyi dolgok általában külső agyba mennek, Pi, egyéb. Nem mintha egy háború vagy bármi hasonló esetén marhára érdekelne, mi megy, az ember fut inkább, de ez más téma.
Akár pár sörért cserébe.
Eccerűen ráfüggtem a témára, de nagyon! 
Új hozzászólás Aktív témák
Hirdetés
ekkold
- Asztali PC , i7 11700KF , RTX 3070 Ti , 32GB DDR4 , 512GB NVME , 2TB HDD
- Asztali PC , R5 5500 , RX 5700 XT , 16GB RAM , 256GB NVME , 1TB HDD
- ASUS TUF Gaming F15 gamer laptop
- X1 Yoga 8th 2-in-1 14" FHD+ IPS érintő i5-1335U 16GB 256GB NVMe ujjolv IR kam aktív toll gar
- Lenovo / SK Hynix 512GB M.2 NVME SSD 0 perces
- 2db Dell PowerEdge R740 2U Rack Szerver és 3db Netapp FAS2040 NAS
- Telefon felvásárlás!! Samsung Galaxy A16, Samsung Galaxy A26, Samsung Galaxy A36, Samsung Galaxy A56
- ÁRGARANCIA!Épített KomPhone i5 13400F 16/32/64GB RAM RTX 5070 12GB GAMER PC termékbeszámítással
- Bomba ár! Fujitsu LifeBook U757 - i3-7GEN I 16GB I 256SSD I 15,6" FHD I HDMI I Cam I W11 I Garancia!
- HP 200W (19.5V 10.3A) kis kék, kerek, 4.5x3.0mm töltők + tápkábel, 928429-002
Állásajánlatok
Cég: Promenade Publishing House Kft.
Város: Budapest
Cég: PC Trade Systems Kft.
Város: Szeged