Sajnos nem sok rálátásom van a követelményekre, előírásokra amit elvártak, elektronika rész nem hozzám tartozik, én a mérés - kiértékeléssel foglalkoztam. Gyorsulás érzékelővel álló helyzetben tiltás körül 50-80 g körülieket mértünk Z irányban, de X és Y-ban is voltak azért nagy kimozdulások. A mértékére nem emlékszek mekkora volt, csak hogy van csavarodása a NYÁK-nak. Nem mondom hogy mm-es, de pont elég volt ami az elég érzékeny gyorsulás szenzort egy olyan frekvencián rázta, ahol érzékeny az érzékeny volt és ez a mérés miatt nem volt szerencsés. de csavarodása volt a panelnek ez biztos. Az se volt mindegy hogy a gyorsulás érzékelő hol helyezkedik el a panelen, milyen ragasztóval van beragasztva a NYÁK, mert nem csavarozva volt. Tehát minden apróság amit nem is gondolnánk számít. Egyébként ez céges projekt, szóval túl sok mindent nem is tudok mondani hivatalosan, lehet ez is több mint amit szabadna

ESP32 nem sokkal nagyobb mint egy ESP-01. ESP32-vel van tapasztalatom, illetve abból van is modul/development board, ezért ebben az irányban indultam el. Ez az egész projekt a tiédhez képest jóval egyszerűbb, maga az analóg óra részét nem is akartam túlbonyolítani, így ott egyszerűbb a helyzet. Lehet kapni kész mechanikát: [link]. Lesz egy fa lap abba bele lesz marva a mechanikának és a kijelzőnek + elektronikának a helye. ESP32 órában és egy kinti egységben, mind a kettő méri a hőmérsékletet, páratartalmat, Real time clock modul kiírja a dátumot. A két ESP32 kommunikál egymással, az órában lévő pedig még pluszban küldi egy honlapra az adatokat, ahol látszódna grafikonon az adat. Múltkor szóba került a kívülről való belső hálózat elérése, na most emiatt még nem tudom hogy belső hálózaton legyen az egész vagy külsőn. Esetleg thingspeak-re menjen az adat. De valami ilyen lenne az elképzelés.
Az se hülyeség amit írtál, léptetőmotor óra szerkezet, de oda akkor kellene áttétel a kismutató-nagymutató miatt, nem tudom a pontos mechanikai megvalósítás mennyire lenne komplikált, így ezt a részét inkább a profi "kínai mechanikára" bíznám

[ Szerkesztve ]

Na várj csak, ez nem is vezérelt mechanika! Legalábbis semmi jelét nem látom, hogy bármihez kapcsolódna egy elemen kívül.
Azt hittem motoros mutatókat tervezel, amit természetesen az mcu vezérelne.
Akkor ez egy időjárás állomás lesz, kínai analóg órába építve?

Ami a hálózatot illeti, kifelé egyszerűbb a helyzet, mert a router ezt megoldja alapból.
Külső kérés a belső hálózatra nem működik publikus IP cím nélkül.
De nem látom semmi okát mi értelme volna közvetlenül az órára kapcsolódni, ha egyszer amúgy is az már tölti fel az adatokat vhova. Szóval ez a része szvsz tárgytalan. Én tuti szerverre küldeném ki, ahhoz nincs szükség közvetlen hálózati kapcsolatra az óra és a felhasználó között.

[ Szerkesztve ]

Igen, így van ez egy sokkal egyszerűbb megoldás amit én szeretnék. Órát nem akartam újra feltalálni még akkor se ha érdekes feladat lenne . Mindenképpen kellene egy fali óra, ezért gondoltam, hogy vigyünk bele valami pluszt amitől kicsit egyedibb lesz. Igen ez inkább egy időjárás állomás lesz ESP oldalról, csak a körítés másabb.
Egyelőre még nagyon az elején vagyok az egésznek. Hobbinak és érdekességnek jó ilyennel foglalkozni ezért kezdtem ezt. Kicsit bele kevertem a külső hálózatról történő belső hálózat elérését. Tényleg jóval egyszerűbb kiküldeni szerverre. Ezt a részét még átgondolom, ha oda érek. Most minden funkciót beletenné legszívesebben, de annak meg nem sok értelme van

[ Szerkesztve ]

Hogyan fogod használni a DMP-t? Van hozzá library-d? Ugye a gyro szenzorban lévő DMP-ről van szó?

Igen, az MPU-6050 library példaprogramja ami a Process-nek küldi ki merre áll az 3 poligonból álló repülő, az éppen DMP-t használ.

ESP32-re való portolás jelenleg itt tart.

[ Szerkesztve ]

Ez jó, én is ezzel csinálom a légegér projektemet.
Egy baja van csak: inicializálás után vagy másfél perc kell neki, hogy abbahagyja a pörgést (yaw/z tengely körül) és beálljon egy fix irányba, addig igazából használhatatlan. Ezzel vannak tapasztalataid? X/Y tengely mentén elég stabil az elejétől kezdve, de ott igazából az acc. szenzor adatait használja.
Ha ezt egy motoron fogod használni, az azt jelenti, hogy gyújtás után másfél percig elég véletlenszerű adatokat fogsz kapni.
Ehhez hozzájön, hogy kis hőmérséklet változásokra is vadul elkezd kúszni a Z tengely, ami motoron a motor hője/napsütés hatására is előfordulhat.

[ Szerkesztve ]

A Z tengely körüli kúszás/forgás engem nem érdekel (Amúgy miért nem használsz 9 tengelyes szenzort? Az iránytűvel szerintem a yaw is korrigálható.). Az X és Y tengely kell csak a dőléshez és az egykerekezéshez.
Nekem ehhez elég a Teapot demo program, négy értéket használok csak amiből kettő nyers adat (X gforce, temp), kettőt pedig a DMP számol (roll, pitch). Alvó üzemmódban meg bármilyen tengelyen bármilyen gyorsulás felébreszti a vezérlőt.

Amúgy nem, nem igazán van vele tapasztalatom. Úgy 2 éve szórakoztam ezzel utoljára. Azóta várja jobb sorsát. Amúgy fura, hogy még mindig nincs "hivatalos" library a DMP-hez, amikor már 2012-ben kiadták hozzá a dokumentációt.

[ Szerkesztve ]

9 tengelyest használok, de a dmp nem használja az iránytű adatait a számoláshoz. Próbáltam már az említett lib 6axis és 9axis .h fájljával is, és ugyanúgy kúszik az elején. A 9axis talán előbb megáll és később pontosabb is, de teszteltem mágnessel és egyáltalán nincs hatással a dmp-re.
Csak gondoltam hátha mára fejlődött a tudomány, kb. egy éve játszottam vele utoljára.

Biztos hogy meghalt?

Van rajta egy szép Dióda pont ezért. Nem lehet hogy max csaak azt kellene cserélni? Nekem a töltésvezérlő szállt el fordított polarítás végett, de cseréltem, és működik mint előtte.

Ha még nem dobtad ki küld el nekem :-P

Release the Beast....

Egy ismerősömnek van elfekvőben egy arduino robotautós szettje, amit még sosem használt és kölcsön tudja adni, kedvcsinálónak jó lehet. Van távolság mérő szenzor, motor shield, 2 kis motor, meg kerekek, enkóder, váz stb, de vezetékek se tápkábel nincsenek.

A kérdésem az,hogy ha usb-re kötöm az arduino-t, akkor úgy is mindent működésre lehet bírni, vagy mindenképpen szükségem volna egy külön tápellátásra is?

És rohansz utána a laptoppal?
Működésre lehet bírni természetesen, de a motoroknak kevés lesz az 500mA, amit az usb-ről tud szívni. Illetve az usb-nek lesz sok a motor áramfelvétele, le fog oldani a polyfuse, ami a portot védi. Az ultrahang szenzort fogod tudni tesztelni. A motoroknak szerezz egy 4 ceruzaelemes elemtartót, vagy egy 2S lipo akksit.

[ Szerkesztve ]

Nem tudom, vmelyik melegszik a három közül (dióda, ch340g, ldo), nem érzem melyik. Gépre kötve a Windows meg nem reagál rá.
Lehet javítható, ha csak a dióda vagy az LDO. Ha az usb vezérlő ment ki, azt az isten nem cseréli ki ezzel a QFN tokozással.
Esetleg az LDO-t még bevállalom, lehet ki is próbálom 3v3-ról betáplálni hátha úgy még megy.
Ruggedunio-ból kiindulva mind az LDO, mint a mikrovezérlő megdöglik, ha GND felől jön a ménykű.

[ Szerkesztve ]

Nem, ez megdöglött. Piros Led folyamatosan villog rajta, kivéve USB-re kötve.
Se 3V3-ról, se 5V-ról nem megy. Az UART0 nem válaszol se boot-oláskor a Serial monitoron, se a program feltöltésnél nem kapcsolódik (EN és IO0 vagyis a Reset és Boot gombok lenyomva előtte). Jah és melegszik az ESP modul maga is USB-ről. Ez kuka.

Amúgy nem értem miért, a DevkitC tervrajzán rajta van a védődióda a Vbus-on ( D3 1N5819), így elvileg nem kellett volna tönkremennie. Hacsak a kínai nem spórolta le róla. Nem igazán tudom visszakövetni a vezetősávokat a panelen. NYÁK tervet meg nem találok róla.

[ Szerkesztve ]

Ti hallottatok már erről a Propeller-ről?

Elültetted a bogarat a fülembe:
Azt nézem, hogy a wroom32-höz tényleg nem kell semmi külső hardver a működéshez. A gombok is csak a programfeltöltéshez max.
A devkit-en lévő rakás kondi és ellenállás is mind a táphoz van és az usb-ttl chip-hez.
Hmmm, készítek egy barebone nyáktervet is, úgy is tervben van egy levegős forrasztóállomás, azzal szépen be lehet ültetni mindenféle IC-t.
Mondjuk a modul alján lévő hűtőpadot nem tudom hogy lehetne reflow kemence nélkül, te azt hogy fogod megoldani? Lehet egy bazi nagy via-t kéne odarakni és "felforrasztani" a lyukat.

[ Szerkesztve ]

Jó lesz az én mondjuk a DOIT development board alapján csinálom, ott van egy 100 nF-os kondi a wroom32 mellett, amúgy tényleg csak max a gomb és hozzá ellenállás, kondi kell. Ez meg kiváltható esetleg tüskével, amit GND-re húzol programozásnál. Valószínű én maradok a gomb megoldása mellett az első panelnél.

Még egyelőre adatlapozok, nem gondolkoztam még beültetésen. Illetve nem is figyeltem a hűtőpadot. Nem tudom ezeknél a kínai paneleknél vajon be van forrasztva?

Esetleg valami hasonlóan?

[ Szerkesztve ]

100u lesz az inkább, 0,1u-ból a modulon belül is van egy maréknyi.
Én ezen a programozón gondolkozom még, ehhez elég csak kivezetni tüskére azt a 6 lábat, nem kell se gomb, se semmi. Egyedül az EN-re a felhúzó és egy bypass kondi az üzemszerű működéshez.
Mondjuk sebességben csak 115200-at tud, ami elég karcsú: a devkit-en lévő chip 8x ekkora sebességet biztosít.
Ha generic FTDI csatolót használok, ahhoz meg kellenek a gombok is. Bár lehet ez a programozó meg jó lenne más 3,3V-os chipekhez is, mint pl a 8266.

A második részében azért elég vicces miket bénázik. Nem egy idegbeteg állat. Én már kivágtam volna az ablakon. Erre lesz jó a forró levegős forrasztás, ez az egész megvan vele 2 perc alatt sokkal szebben.
Én már próbáltam pákával alulról beforrasztani hűtőpadot, nekem nem működött a dolog. Az a fránya ón sehogy se akart felszívódni a másik oldalra. Mondjuk nálam 0,7 mm-es via-k voltak, nem tudom amúgy mekkora átmérőnél életképes a dolog. Én mondjuk tuti ezzel kezdtem volna a többi láb előtt, ha sikerül akkor erősen megtartja a chip-et, ha meg nem sikerül akkor könnyen le lehet szedni. A kontinuitás vizsgálat nem elég, ahhoz néha még forrasztani sem kell.

[ Szerkesztve ]

Ja igazad van a gombokhoz ajánlott a 100nF, kicsit belekeveredtem már . Nem tudom ez a programozó mennyivel jobb mint egy FTDI vagy CP2102-es USB-TTL konverter. Én az utóbbival tervezem használni. Ha jól tudom 8266-nál is soros vonalon lehet programozni. Így oda ez is szintén használható. RESET gombot érdemes használni, akkor már csak max a boot gomb-ellenállás-kondi 3-as a plusz alkatrész.
Sőt egy FTDI vagy CP2102 esetén csak RX, TX, VCC és GND kell. Bár ahogy nézem amit linkeltél is ugyan az lenne, csak kicsit drágább eszköz.
Egyébként arra a hűtőfelületre nem tudom tényleg mennyire lehet szükség. Persze ha melegszik akkor jó dolog, de egyébként nem vagyok biztos benne, hogy azt tovább muszáj forrasztani még, már mint az hűti alapból az ESP32-es IC-t. Az hogy ezt még egy további panel részhez forrasztod olyannak tűnik nekem, mint ha egy CPU-n lévő hűtőbordára még egy másik hűtőbordát tennénk, esetleg ventilátort. Az alap hűtőbordával is jó a többi már csak plusz lenne ami ha kivitelezhető jó, de nem biztos hogy kell is használni.

Nem tudom ez a programozó mennyivel jobb mint egy FTDI
Ha megfigyeled az ESP32 programozót, akkor azon rajta van az auto letöltéshez szükséges két tranyó is, ami lehúzza az EN és IO0 lábakat. Gyakorlatilag a Devkit áramköre egy az egyben CH340g-vel. Így mint írtam volt megspórolható még a két gomb is a NYÁK-ról.
Ezzel konkrétan nem kell semmi kiegészítő a modul mellé az EN felhúzó ellenállásán kívül. Kivezeted 6 tüskére a Vcc, GND, RX, TX, EN, OI0 lábakat, rá erre a programozóra és uccu neki!
Mondjuk a CP2102-es programozó szimpatikusabb lenne, ilyen van a devkit-en is, de az mellé kell egy auto-program áramkör még pluszban vagy a NYÁK-ra, vagy vhova (vagy hát különben nyomogatod a gombokat).
Talán az volna a legideálisabb, ha gyorsan összeraknék magamnak egy ilyen programozót a fenti mintájára CP2102-vel.

szerk: hmm ami azt illeti nem is kell saját, találtam hozzá "eredeti" devkit programozót!

(#8925) tvamos
Nem lehet, hogy a fura program nyelv miatt?
Állítólag nem rég jött hozzá ki egy C fordító.
8 független mag azért elgondolkodtató.
De tényleg nincs elterjedve egyáltalán. Teljesen véletlenül találtam rá.

[ Szerkesztve ]

Tényleg már látom. A reset gomb mindig jól jöhet mondjuk a panelen szerintem, ha nem akarsz aksit/elemet vagy hálózati resetet.

Ezen a devkit panelen ahogy nézem ki van hagyva a forrasztási helye az ESP32 wroom modulnak. Ha nem akarod ráforrasztani akkor nem látom még hogyan lehetne programozni.

(#8927) DopeBob
ESP32 Gateway. Ezen van ethernet.

[ Szerkesztve ]

ESP32 WROOM32 adatlap 14. oldal 7-es fejezet, oldal közepe:
"Note:
Soldering Pad 39 to the Ground of the base board is not necessary for a satisfactory thermal performance. If users do want to solder it, they need to ensure that the correct quantity of soldering paste is applied"

Solder pad alatt szerintem arra gondol, amiről mi is beszéltünk. Ha megnézed az adatlap 14. oldalán a schematic-ot, akkor látszik hogy jobb oldalon a GND3 fölött van a P_GND. Ha ezt összehasonlítod a PCB-vel, akkor látszik, hogy a P_GND nincs a GND3 fölött. Tehát ezek szerint a P_GND, ami a 39-es láb, illetve a megjegyzés az adatlapban engedményt ad arra, hogy nem muszáj beforrasztani, habár a schematic úgy mutatja még is. Tehát a felhasználótól függ be akarja-e forrasztani. Én szerintem hagyni fogom.

[ Szerkesztve ]

Nálam nem gond, egy egyszerű áramtalanítás megteszi reset-nek.
A devkit panellel meg a NYÁK-ra ültetett modult gondoltam programozni.
Nem kell a devkit-re beültetni semmit, csak a megfelelő tüskéit rákötni a NYÁK-on lévő modulra és voilá: éppen úgy programozod, mintha devkit-re lenne beültetve. Talán még eddig ez a legideálisabb megoldás - automatikus letöltés és nagy sebesség -, ha nem is a legpraktikusabb.

[ Szerkesztve ]

Nem biztos, de ennek a programozó panelnek nem ugyan az a kiosztása mint a development panaleknek, amire rá van forrasztva az ESP32? Mert akkor lehetne azt is használni.

De, ugyanaz a kiosztás. Csak nyilván olyan panelt nem használhatsz külső modulhoz, amin már rajta van egy.
Az UART busz hülyét kap, ha két modult kötsz rá.

(#8934) Janos250
A linkelt programozón nincs rajta az a két tranyó, ami kell az invertált logikához. Így az auto letöltés bukta.
Valamint ránézésre a 3,3 voltot valszeg feszültségosztóval állítja elő egyéb hijján, ami meg hááát...
Azok a 0603-as ellenállások nem úgy néznek ki, amire szívesen rákötnék akár csak 100 mA-t.
Az 1/10W-os korlátjukba legfeljebb 68 mA fér bele 1,7V-os drop-nál, ezzel meg nem biztos, hogy meg lehet hajtani egy ESP32-t. (Nem jártam utána.)
Szóval az UART kommunikáción kívül konkrétan semmire nem jó.
A devkit panelje meg semmivel nem kerül többe, vagy talán még olcsóbb is mint egy tisztességes FTDI programozó. És szerintem bekötni is ugyanannyi, mint egy FTDI programozót: usb az egyik végén, dupoint a másik végén.

[ Szerkesztve ]

WOW, ez tök jó!!
Gondolom ugyanúgy ki van vezetve rajta minden tüskére is mint a devkit-en, szóval a beültetett modulhoz is jó kettő az egyben.
Annyi, hogy ezen sincs rajta az auto program áramkör. Vagy nem látom sehol. Nyomni kell a gombot feltöltéshez?
Köszönöm a tippet!

[ Szerkesztve ]

Nem kell nyomni semmit.

Ezen csinálom a IR Remote projectemet egy ideje (már ha lenne rá időm...)

Igaz nem pogo pin de jó. Kivenni betenni nagyon okés, 100-as batchet nem ezzel csinálnám....

10-20 még ok, fejleszteni tökéletes.

Most nézem h a képhez képest az enyémen van még 1 6 lábas SMD ic. Nem tudom leolvasni, lehet h dual package MOSFET és akkor itt van a kutya elásva. pedig a linket a rendelésemből vettem ki.

[ Szerkesztve ]

Release the Beast....

Sziasztok!

[link] Tudtok ebben segíteni?

Ha az ESP8266 WAKE_RF_DISABLED beállítással lett deepsleep-be altatva, akkor a következő feléledési ciklusban van bármiféle lehetőség az RF modul bekapcsolására? Vagy csak a WAKE_RF_DEFAULT paraméterrel történő altatás utáni ébredés során fog működni ismét?

[ Szerkesztve ]

AcCEsS (https://www.metalenciklopedia.hu)

Ha jól tudom, csak egy újabb deepSleep hívással oldható meg. Viszont, ha WAKE_RF_DEFAULT-al altatod, akkor kódból te már kapcsolgathatod a wifi-t.

Itt pont ezt tárgyalják.

Alex

Hogy ellenőrizhető a kód, hogy valóban deep sleep-ben van az ESP? uA-es műszerem nincs hozzá.

Vannak, akik rendelkeznek ilyen műszerrel, ők mérték. Youtube-on is lehet róla videót találni. Nekem sincs, így én elhiszem. És természetesen a lényeg, hogy deepSleep hívás után ne húzd semmivel LOW-ra az RST lábat. Majd a timer lejártakor a GPIO16 LOW-ra állításával reset-eli a boardot.

Tuti működik, hiszen a percenként hőmérsékletet mérő cucc 1 Li-Ion cellával (notebookból bontott) elmegy 90+ napot.

[ Szerkesztve ]

Alex

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?

[ Szerkesztve ]

[link]

Itt azt mondja hogy ESP32 esetén ha a csatorna a ESPNow és a Wifi kapcsolatra ugyanaz akkor tud csak működni.

Ennyi kapcsolat esetén nem biztos hogy megéri. Tedd fel az egészet a MQTT re és rakd fel Wifire.

Release the Beast....

MQTT értelemzésnek többzör nekifutottam már, de kicsit bonyolult volt nekem. Esetleg egy jó leírást tudsz javasolni hozzá?

Alternatív megoldásnak esp32 socket server ami még jó. Ettől független annyi helyen olvasni MQTT-ről hogy érdekelne az a verzió is, hogy mi ez, mire jó, miért érdemes használni stb.

É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!

[ Szerkesztve ]

AcCEsS (https://www.metalenciklopedia.hu)

Igen, a deepSleep érdekes téma, rá tud kattanni az ember, hogy minél optimálisabb megoldást találjon.

Az elérhető memória valóban 512 byte, de ha csak mért értékeket akarsz tárolni, bőven elég.

Alex