- Apple Watch Sport - ez is csak egy okosóra
- Samsung Galaxy Watch7 - kötelező kör
- Ezek a OnePlus 12 és 12R európai árai
- Milyen okostelefont vegyek?
- Yettel topik
- One mobilszolgáltatások
- Xiaomi 15 - kicsi telefon nagy energiával
- Kézbe fogták az ultravékony Z Fold7-et
- Nem növel telepméretet a Galaxy S26 Ultra
- Átlépi végre az iPhone az 5000 mAh-t?
-
Mobilarena
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
-
ratkaics
senior tag
válasz
ekkold
#17154
üzenetére
Köszi!
Én is nézegettem az OpenEVSE dolgot. Szimpatikus is lenne, mert sajnos a hardware gyártásban sem szakértelmem, sem pedig rutinom nincs, szóval ez az "összeszerelős" dolog jó lenne. De ez sajnos 1 fázisú eszköz, biztosan meg lehetne oldani a 3 fázisú használatot, de egyenlőre nem találtam rá példát.
A másik amit találtam az a smartESVE. Ez már talán jobban megfelelne a céljaimnak, de azért ez is elég drága, meg a Modbus kommunikációs részét nem teljesen értem.
Én a HomeAssistant szerveremről szeretném a töltési teljesítményt dinamikusan vezérelni.
Van esetleg itthoni beszerezhető eszköz, ami hasonló funkciókkal bír, mint a smartEVSE? Esetleg el tudja valaki készíteni? -
And
veterán
válasz
ekkold
#16866
üzenetére
Használtuk régebben mindkét félét. Először persze nem voltunk tisztában vele, hogy egyáltalán többféle mechanikai osztással is létezik
. A megoldás az lett, hogy nem tettünk különbséget a kódban a rotary típusa szerint. Itt eleve többféle értelmezés is lehetséges, a korábban említett csupán két él figyelése szerintem például nem teljesen korrekt. A teljes és egyértelmű kapcsolási periódus mindenképp négy élből áll, csupán kettőt figyelembe véve félútról visszatekerhető az encoder, ami helyzettől és ízléstől függően furcsán hathat (mivel ekkor az általad 'dupla lépésesnek' nevezett kivitel anélkül ad egy-egy teljes oda-vissza jelzést, hogy akár egyszer is fix mechanikai állapotba lépett volna). A tapasztalat viszont az volt, hogy ha mind a 4 él meglétéhez kötöttünk egy lépést, akkor viszonylag gyakran hibázott, ezért kompromisszumként három éllel megelégedtünk. A hibázás (lépés kihagyása) ekkor elhanyagolható lett, és elmaradt a téves előre-hátra működés is. Persze hardverből is rásegítettünk, ahogy írtad, RC-szűrést (2,7k / 1nF) kialakítva. Gyári készülékeken sem mindig tökéletes a rotary, a mi megoldásunk sem lett annál rosszabb, egész nagy tekerési sebességig használható maradt. -
#16868
razorbenke92
őstag
ekkold
#16865
válasz
ekkold
#16865
üzenetére
Ebben az esetben beletennék a kódba egy flaget, és amíg az nincs igazra téve, addig a az enkóder süket.
Amíg a flag hamis, addig azt figyelném, hogy az 11 állapot fennáll e egy általad meghatározott ideig egy meghatározott időn belül.
Mivel az egyik enkóder stabil állapotban csak 00 lehet, ott ez biztos hogy nem fog előfordulni könnyen.
Indulás után vársz 2 másodpercet az egyik stabil állapotban, és utána elfordítod egyel, és ott is vársz 2 másodpercet. Ha egyikben sincs 11 állapot stabilan (a kettő között észre tudod venni hogy már megtörtént a mozgás) akkor tudod, hogy melyik tipus. -
válasz
ekkold
#16860
üzenetére
Ja, hogy ez mechanikailag stabil állapot?
Én pont fordítva fognék hozzá: szimpla lépésesként kezelném, aztán pár beolvasás után megnézném, hogy a stabil állapotok többsége páros szám, vagyis ha legtöbbször 2 lépésenként stabilizálódik, akkor dupla lépéses. Kell egy treshold, mondjuk 75% fölött egyik, alatta a másik, és ezt addig tologatod, amíg megbízhatóan nem tud jósolni az algoritmus.
De ezt nehéz így látatlanban megoldani, kéne tudni, mire használod. Pontosan milyen feladat az, ahol nem tudod előre, hogy melyik kerül az áramkörbe? -
#16861
razorbenke92
őstag
ekkold
#16860
válasz
ekkold
#16860
üzenetére
Ahogy értem, ez mind a kettő inkrementális AB enkóder.
A feldolgozási logika mindkettőnél ugyanaz, csak a mechanikája az egyiknek egyszeres felbontásra van stabilizálva, a másiknak pedig kétszeresre.
Az elsőnek az a logikája hogy az A jelre "rising" interruptot teszel. Tehát amikor a jel 0->1 átmeneten halad át, akkor hajtasz végre feladatot.
A feladat az, hogy ellenőrzöd B-t. Ha B=1, akkor pozitív irányba történt fordítás, ha B=0 akkor negatívba.
A másodiknak annyival bővül a logikája, hogy az A jelre "falling" interruptot is teszel (a kettő együtt "changing" interrupt).
A logika pedig:
- Ha A=1 és B=1 -> előre fordult
- Ha A=1 és B=0 -> vissza fordult
- Ha A=0 és B=0 -> előre fordult
- Ha A=0 és B=1 -> vissza fordulttovább egyszerűsítve akár a fentit, akár a lentit:
Ha az interrupt eseményben A és B értéke egyezik -> előre fordult, ellenkező esetben hátra.(négyszeres felbontás esetén pedig a B váltásait is lehet figyelni, és eljárni A értéke szerint)
-
Undoroid
őstag
válasz
ekkold
#16766
üzenetére
Erre az utasításra rá fogok keresni a világhálón, hátha találok róla valami példát honi nyelvezettel...addig vár a sok, finom Bejgli!
Azon gondolkoztam, hogy mi van akkor, ha nem az eltelt időt számolná a kontroller, hanem a lefutott ciklusok számát? Ha lefutott a megengedett 'számú' kód, akkor egyszerűen leállna! Mint annak idején a Basic programnyelvben az " IF - FOR - THEN - NEXT " parancssor alkalmazásánál?! (Ezeket az utasításokat kb. 30éve nem használtam, remélem jól írtam?)
Elküldök az általam ismert két eMail címe(i)dre egy linket! Ott láthatod a próbapanelos videót a működésről! Azon majd láthatod, hogy ha valamit túl lehet bonyolítani, azt így kell csinálni!
-
Undoroid
őstag
válasz
ekkold
#16761
üzenetére
Szia!
Ügyes megoldás!
Köszönöm a fáradozásaidat! A bajom azzal van, hogy nem csak különféle színeket villantok fel egyforma ideig, hanem elindulok pirossal, majd átúsztatom az elérhető összes szín érintésével, kb 15 másodperc alatt, majd villogtatok további színeket, majd ismét úsztatom a színeket, de félperces idő alatt megy el az elejétől a végéig. Ezért is használtam a color - delay párost és fix értékeket folyamatosan. A rendelkezésre álló tárhely majd' 1/5 részét el is foglaltam ezzel az igen buta és kezdetleges kóddal. A végeredmény viszont -szerintem- egész jól néz ki. Ettől függetlenül bontok egy NANO-t és arra feltöltve megnézem, hogy a szépen megírt kódodat, hogyan tudom teljesenelrontania saját ötleteim szerint kiegészíteni!? Ezért is hagynám ki az A és B átkapcsolásának lehetőségét...nincs rá szükség, mert elég hosszú, változatos effektusok kerültek a kódba. Mindössze a futási idő lekapcsolása lenne leginkább érdekes.
-
Undoroid
őstag
válasz
ekkold
#16680
üzenetére
Üdvözöllek!
" Saját célra készültek. " Ha mégis úgy alakulna a dolog, hogy lesz egy olyan példányod, amitől megválnál, akkor kérlek, hogy keress meg privátban!
********************************************************************************
Más...
Reggel jövök egy újabb kérdéssel a (nálam) gyakorlottabb kollégákhoz, mert amit az előbb megírtam, azt sikerült teljesen eltörölni és már nincs időm újra leírni.
-
-
-
Janos250
őstag
válasz
ekkold
#16588
üzenetére
Hogyan tudunk függvénybe bevinni előre meg nem határozott számú paramétert?
Közben csináltam mintapéldát, hogyan tudjuk belerakni containerbe, akármennyi van is, és a függvényben iteratorral annyit használunk fel, amennyi van./*
mintapelda elore meg nem hatarozott szamu parameter atadasa fuggvenybe iteratorral
Minden olyan container hasznalhato, aminek van .begin() es .end() iteratora
peldaul: vector, list, deque, map, set, stack, stb
*/
#include <iostream>
#include <vector>
#include <list>
#include <deque>
using namespace std;
//void parameterAtadasVectorral(auto parameter){ // ez csak C++14 -tol el
void parameterAtadasVectorral(vector <int> parameter){
Serial.println("\nfelhasznaljuk a vector elemeit:");
for (auto i = parameter.begin(); i != parameter.end(); ++i){
//vagy: for (vector<int>::iterator i = parameter.begin(); i != parameter.end(); ++i){
Serial.println(*i);
};
} ;
void parameterAtadasListaval(list <int> parameter){
Serial.println("\nfelhasznaljuk a lista elemeit:");
for (auto i = parameter.begin(); i != parameter.end(); ++i){
Serial.println(*i);
};
} ;
void parameterAtadasDequeSorral(std::deque <String> parameter){
Serial.println("\nfelhasznaljuk a deque elemeit:");
for (auto i = parameter.begin(); i != parameter.end(); ++i){
Serial.println(*i);
};
} ;
void setup() {
Serial.begin(115200);
delay(1000);
vector <int> enVectorom {10,115} ;
enVectorom.push_back(8); // a vegere betesz egy elemet
parameterAtadasVectorral(enVectorom) ;
std::list<int> enListam = { 9,7,3,29 };
enListam.push_back(50);
parameterAtadasListaval(enListam) ;
std::deque<String> enDqueueDuplaveguSorom= { "macska","kutya","lo" };
enDqueueDuplaveguSorom.push_front("kismalac"); // elejere teszi
enDqueueDuplaveguSorom.push_back("pipi"); // veger teszi
parameterAtadasDequeSorral(enDqueueDuplaveguSorom) ;
} ;
void loop() {
};
/*
Ezt irja ki:
felhasznaljuk a vector elemeit:
10
115
8
felhasznaljuk a lista elemeit:
9
7
3
29
50
felhasznaljuk a deque elemeit:
kismalac
macska
kutya
lo
pipi
*/ -
Janos250
őstag
válasz
ekkold
#16588
üzenetére
Na, csináltam egy memory refresht.
Így is lehet olyan függvényt írni, aminek változó számú paramétere van/*
mintapelda variadic function hasznalatara, azaz
hogyan lehet irni olyan fuggvényt, aminek valtozo szamu parametere van
*/
#include <iostream>
#include <cstdarg>
using namespace std;
void tobbParameter(int hanyParameter...){
va_list argumentumok;
//egyeb deklaraciok, ha kell
va_start(argumentumok,hanyParameter);
// az "argumentumok" lista inicializalasa
for (int i = 0; i < hanyParameter; i++){
int soronKovetkezoParameter = va_arg (argumentumok, int) ;
Serial.println(soronKovetkezoParameter);
};
va_end(argumentumok);
// az "argumentumok" lista bezarasa
} ;
void setup() {
Serial.begin(115200);
delay(1000);
tobbParameter(3,5,10,8);
// 3 parameter lesz meg a 3 utan, amit fel kell dolgozni
} ;
void loop() {
};
/*
ezt irja ki:
5
10
8
*/ -
válasz
ekkold
#16571
üzenetére
A Pascal nekem majdnem teljesen kimaradt, illetve egyszer, még az ősidőkben, telefonra akartam játékot írni, és a java-t túl bonyolultnak találva MIDletPascal-ban oldottam meg, ehhez megtanultam, majd teljesen el is felejtettem a Pascal nyelvet.
Én Basic-ben kezdtem C64-en, 6510 assembly-al folytattam, majd kb. 20 év kihagyás után PHP, kis Pascal, kis python (ezt meg a Symbian-on használtam, mert a Symbian-t is túl bonyolultnak találtam ). Az assembly-t valamiért nagyon megkedveltem, úgyhogy az AVR assembly-t is megtanultam (legalábbis egy részét). A C-t a LEGO Minestorms miatt kezdtem el, aztán PIC-el próbálkoztam, de szerencsére jött az Arduino meg a C++. -
Janos250
őstag
válasz
ekkold
#16566
üzenetére
"ha tudod mit csinálsz, akkor jól is fog működni."
Hát, ez az!
Sokkal könnyebb elbaltázni a programot C-ben, mit bármi másban.
De az Arduino az C++ , itt azért már van némi kontroll !
Én annak idején hagytam is a fenébe a C-t, és csak később a C++ -t használtam/használom, mert a C "mindent szabad" , "ha hülyeséget írsz, én megcsinálom a hülyeséget, nem figyelmeztetlek" szemléletétől feláll a szőr a hátamon.
Azért a pascalok fejlettebb verzióiban is sok mindent meg lehetett csinálni úgy, hogy komolyabb ellenőrzés is volt.x = 'A';
x += 2;Az ilyen megoldásokat én nem kedvelem. C++ esetén legalább jelezni kell átdefiniálással, hogy tényleg ezt akarom.
Persze mindezek ízlés kérdése. Kinek az egyik tetszik jobban, kinek a másik.
Viszont Arduino esetén javasoljuk mindenkinek a C++ használatát! -
Dißnäëß
nagyúr
válasz
ekkold
#16528
üzenetére
Köszönöm és az Előtted szóló 2 kollégának is !
Csöves erősítő bias-t (munkapontot) tartana a helyén, ami idővel is, meg bemelegedés után is - a kapcsolásból adódóan - hajlamos picikét elmászni, illetve figyelne a push-pull kimeneten az input csövek eltéréséből (gyártási szórás) adódó DC offset-t is, ez egy másik kézi trimpoti lenne, amivel néha ez itt megjelenő offset-et érdemes visszakorrigálni 0-ra.
Gondoltam, ilyeneket rábíznék valami "automatikára", ne nekem kelljen ezt az amúgy "fix bias"-ú megoldást kézzel tekergetnem X naponta. (Elvileg ritkábban, de csináljuk jól, pontosan).
-
Janos250
őstag
válasz
ekkold
#16450
üzenetére
Azt hiszem, mindketten ugyanarról beszélünk, csak más nyelven:
Idézet a netről:
Az egydimenziós tömbök (vektorok) és az egyszeres indirektségű („egycsillagos”) mutatók között teljes a tartalmi és a formai analógia.int *p;
p = &a[0]; vagy p = a;A legtöbb C++ fordító az a hivatkozásokat automatikusan *(a+i) alakúra alakítja, majd ezt a pointeres alakot lefordítja.
-
Janos250
őstag
válasz
ekkold
#16383
üzenetére
Egy ilyen szenzor 1200 Ft.
https://www.aliexpress.com/item/32334119287.html
Megéri ennyiért kínlódni egy erősítő kapcsolással, aztán mérni a feszültséget, majd korrigálni, és átszámítani fokra, amikor a meglévő MAX áramköre mindezt elvégzi, és digitálisan küldi az értéket szabványos, SPI protokoll szerint?
Persze, ha nem az élvezet a cél!![;]](//cdn.rios.hu/dl/s/v1.gif)
-
wakula778
csendes tag
válasz
ekkold
#16376
üzenetére
köszönöm a gyors reagálásokat.
1 szenzor lenne csak.
mikor feszkó alá helyezek mindent kb 23fokos szoba hőmérsékleten 40-50fok körül mér ha felraktam a tűzhelyre kb 90ig ment el. nem lenne egyébként baj azzal ha kb 20-30 fokot tévedne mert ahova tervezve van ott 700-900 körül lenne a maximum és ott belefér ennyi csúszás de a tűzhelyen már jóval több volt mint 90. lusta voltam lemenni a lézeres hőmérőért de ami már világit az nem 90fok
. tudnátok esetleg olyan szenzort ajánlani ami kompatibilis a max6675-el(K) és tuti hogy nem olvad le 1000fokon sem? feltéve ha nincs más lehetőségem -
Janos250
őstag
válasz
ekkold
#16260
üzenetére
Persze, de nekem erre a munkára, amit ő végez, nincs szükségem, ezért nem is akarok fizetni érte. Az ismert V... oldalon meg a hirdetők többnyire azt csinálják, hogy megrendelik ők is Kínából a Te nevedre, de kétszer annyit kérnek tőled, mint amit ők kifizetnek érte. Hozzájuk nem is kerül a csomag.
-
Janos250
őstag
válasz
ekkold
#16230
üzenetére
"Nem akartam saját könyvtárat írni erre"
Pedig szerintem az a legcélravezetőbb, nem egy bonyolult a bitek kivitele.
Én ESP32-re csináltam ugyanezt, mert akkor legalább tudom, hogy mit csinál.
Ha párszáz nano időzítési pontossággal tudsz kiírni, azzal már be lehet lőni.
Kíváncsiságból megcsináltam GPIO billegtetéssel (ESP32), és úgy is működött, bár az ESP32-n van erre célhardver (RMT) -
biker
nagyúr
-
biker
nagyúr
válasz
ekkold
#16060
üzenetére
Az a helyzet, némi teszt, számolgatás, és B+-olás után (hogy ..é nem olvastam el jobban a speckót) rájöttem, ez rohadtul alkalmatlan a feladatra.
Az ok, hogy az analóg bemenet 1023(1024) osztású, és 100A max méréssel az 0,1A felbontás, ami nekem jó. Igenám, de ez a szuper IC 2.5-3.5V közt (0.925V) skálázza a kimenetet, ami pont ötöde lesz így, közel 1A felbontás az kb 2A pontosság, ami már a kuka kategória kb.
Nézek mégis olyan áramváltót, ami nem 100/5A és 5A mérő kell elé, hanem eleve DC kimenetes. 0-5V -
biker
nagyúr
válasz
ekkold
#16053
üzenetére
ha van valami jobb tipped, meghallgatom.
Eddig annyit találtam, hogy a kondit kell hozzá nagyobbra cserélni, az csillapít kicsit, illetve gondolkodtam a kimeneet egy 10-100kohm-al testre hátha stabilizál valamit.Minden induláskor kalibrálom, 20.000-es ciklusban leátlagolom (kb 4mp) hogy mennyi épp a nullája, így ha gond van, csak terhelés lekapcsolás mellett reboot és újra nullázva van.
-
biker
nagyúr
válasz
ekkold
#16045
üzenetére
Köszi, de ezzel nem vagyok előrébb most
Az uno tetején terveztem 7 kis modult elhelyezni, és szendvicsben tök jól menne, minden megvan már. csak a köztes panel nincs, és gyártás előtt szerettem volna egy forrasztott tesztet.
Eddig ez áll legközelebb a keresett termékhez, de ebbe se kellene a beleforrasztott sorkapocs és társai -
#16038
tonermagus
aktív tag
ekkold
#16024
tonermagus
aktív tag
válasz
ekkold
#16024
üzenetére
Az LF50CV mellett döntöttem. Szimpatikus. 3 lábas megoldás.
Stabil tápról kapja feszültséget így elé nem nagyon szeretnék kondit rakni. Viszont a belső oldalra mekkora kondit kellene választanom?
Nekem nagyon szimpatikusak ezek a fóliakondik:
https://www.hestore.hu/prod_10040535.html -
válasz
ekkold
#15809
üzenetére
[link]
A rossz hír az, hogy nekem csak régebbi avrdude-dal működött a hack, azt hiszem az 1.6.xx-el csomagolt avrdude-dal még ment, de nem gond, mert az attiny85-höz az is pont megfelel, ha programozni kell. Az újabb avrdude-ból talán kivették már a támogatást.
Amúgy nagyon jó cucc, megéri elővenni, mert a saját programjával debugolni is lehet, serial monitorként is lehet használni meg ilyesmi. -
Undoroid
őstag
válasz
ekkold
#15771
üzenetére
Szia Gábor!
Valamikor SKYPE-n beszélgettünk. Az igényesen megépített Tesla tekercseidet rendszeresen nézegettem és ha jól emlékszem volt egy 12DC (vagy 24?) -ről működő (zselés akkuval) verziód is! Az nagyon tetszett!
Később teljesen eltűntél... ...mára már nem is látszol a listámon! 
" lehet, hogy a nano-nak pont valamelyik LCD-hez használt lábával van gond " Pont erre gondoltam Én is, amikor ezt [link] írtam. Mindjárt kipróbálom azt, amit Aryes javasolt [link]
********************************************************************************
Aryes [link] : Kipróbálom! Első körben a program második sorában lévő pineket fogom megváltoztatni úgy, ahogy javasoltad! A kód többi része eléggé ködös nekem, de kicsit emlékeztet a Basic programnyelvhez! Ha elakadok, akkor jövök kérdezni! " Van power bankod? "
Van, éppen töltődik! Újra megcsinálom az eredeti bekötést és meglesem. Ha ugyanaz az eredmény, akkor több lehetőségem is lenne:
1. Program átír, átcsatlakoztatás, élesztés...
2. Előkapom a másik 2x16-os LCD-kijelzőt, ami i2c-csatolóval rendelkezik...itt viszont alaposan át kell írni a kódot! Az ilyenkor használt bekötést ki tudom keresni, de a kód megfelelő átírása már necces lesz számomra!Itt kérdezted [link] , hogy mi lenne az a masina?! Ez egy speciális rádióvevő készülék, ami nemcsak a hagyományos már nem használt AM (középhullámú, Amplitudo-modulált) és FM (frekvenciamodulált) csatornákra tud csatlakozni, hanem akár a rádióamatőr sávok, repsávok, stb vételére is alkalmas! doberman biztosan annyira benne van a hibakeresésben, hogy elfelejtett válaszolni!
-
Undoroid
őstag
válasz
ekkold
#15745
üzenetére
Üdvözöllek!
Köszönöm az iránymutatást!
A válasz nagyon egyszerű: teljesen kezdő vagyok ebben a témában. Régebben láttam ezekről (Nano, Uno) a mikrovezérlőkkel épített ügyes kapcsolásokat. Megtetszett és szerettem volna kipróbálni őket...akkoriban (több évvel ezelőtt) még drágák voltak az induló csomagok/készletek így nem indultam el és maradtam a hagyományos panelgyártásoknál. Tavaly -év végén- láttam helyben egy kissé hiányos és használt készletet, amit gyorsan meg is vettem. Több dologgal voltak ugyan gondok*, de ezek az eladási árral voltak kompenzálva!
* Az LCD-kijelző panelja és az egyik Nano a csomagból rossz volt, mert túl 'bika' forrasztópákával- és túl kevés gyakorlattal próbálkozott az előző tulaj. Az LCD-t meg tudtam menteni annak ellenére, hogy már hiányzott több forrszem és vezetősáv róla!
A Nano-t odaadtam egy ismerősömnek, amit alkalmasint megjavíthat (szintén forrasztási hibás és itt-ott zárlatos forrszemek gyártódtak rá)Jelenleg a hozzá kapott példákkal kísérletezek (módosítom/próbálkozok) és azokhoz bőven elegendőek a zsengébb tudású modellek. Ha már több tapasztalatom lesz és az építeni kívánt vezérlés kívánja a komolyabb mikrovezérlőt, akkor mindenképpen ki fogom próbálni!
-
_q
addikt
válasz
ekkold
#15753
üzenetére
STM mx cube vagy cube siman a neve amivel regen lehetett a fuggvenyeket egyszerusiteni, volt hozza kulon fejleszto kornyezet is, de az arduino egyszerusege nekem jobban bejon, persze nem ezt hasznaljak a cegek tudtommal, de hobbira kenyelmesebb. Akkor ez jo hir, hogy STM-re is megoldott. Koszi.
-
Janos250
őstag
válasz
ekkold
#15749
üzenetére
Sokáig én is az STM32 alapúakat használtam, én is meg voltam velük elégedve. Az egyes perifériák regisztereinek cím alapján való elérése is kényelmes, jól dokumentált, így könnyen el tudtam intézni bármit, könyvtár használata nélkül.
Azért mindenre az ESP32-t használom, mert
1. a két mag más programozási logikát enged meg
2. a WiFi nálam gyakran kell, mert mindent úgy csinálok, hogy telefonról legyen vezérelhető IP alapon
3. ha már ezt használom, nem akarom keverni, mert abból csak káosz van.
4. igaz, hogy drágább, mint az STM32 (évekkel ezelőtt kb. 800 Ft-ért vettem az egyszerűbbeket STM32-ből, az ESP32 meg ma is 2000, vagy fölötte van, mióta az ÁFA bejött), de összességében nem ezen múlik a boldogság -
Janos250
őstag
válasz
ekkold
#15489
üzenetére
Akkor még néhány mondat a "logic level" FET-ekről.
IRL = Logic level gate (írja a gyártó), azaz logikai szintű Vgs-el vezérelhetők. A "teljes" nyitást többnyire 4.5 V-ra adják, de ha logikai szintre gyártják, elég jól kinyitnak ezek alacsonyabb Vgs-nél is.
Ilyen például az IRLB4030 is, ami IGENIS JÓL KINYIT 3.3V-nál. Miért pont ezt választottam? Részben a tokozása miatt, részben meg mert nekem most konkrétan 48V-ra kell, ezért nem jó például a "super logic level" IRLML6344, BSC046N02KS, stb. mert annak alacsonyabb a Vds, pedig az aztán tényleg alacsony Vgs-nél nyit.
https://www.infineon.com/dgdl/Infineon-BSC046N02KS-DS-v01_08-en.pdf?fileId=db3a3043163797a6011637c34414001c
Vgs= 2.5V, Tc=25 C esetén continuous drain current = 60 A, 37 mOhmAz, hogy nálam az IRLB4030-on 48V-nál néhány A áramnál Vgs=3.3V-nál a fűtőszálon 48V esik, a FET-en meg 0.007 V, ez a 0.007 V nekem nem okoz fejfájást.
A problémát nekem az okozta, hogy nem IRLB4030-at küldött a kis kínai. Ráírva se IRLB4030 van, hanem LB4030, az meg a fene tudja, micsoda, de a mérésem szerint biztosan nem IRLB4030.Összefoglalva a véleményem:
Bár pap és papné esete, de én azt mondom, hogy:
Igenis FET driver betervezése helyett inkább használjuk a korszerűbb, logikai szinttel vezérelhető FET-eket, hiszen arra gyártják őket! -
Janos250
őstag
válasz
ekkold
#15465
üzenetére
Én ezt nem teljesen így gondolom.
https://www.infineon.com/dgdl/irlb4030pbf.pdf?fileId=5546d462533600a4015356604640258d
FIG. 3[VGS, Gate-to-Source Voltage (V)] függvényében a [Drain-to-SourceCurrent(A)].
Ott úgy tűnik, hogy 3V-nál már elég nagy az áram.
"FET meghajtó" :
Ezekben az IRL.... típusokban épp az a jó, hogy "L", azaz TTL szintű VGS-el mennek, ez meg konkrétan 3.3V szinttel is.
Ami valódi, az kiválóan teljesíti is az elvárt paramétereket, amint írtam. -
Istv@n
aktív tag
-
válasz
ekkold
#15190
üzenetére
Ez a piezo-s lifehack nagyon eredeti ötlet, megjegyzem későbbre!
A hall szenzorhoz annyit tennék hozzá, hogy az esp32-ben beépített hall szenzor van (hogy milyen célból, arról fogalmam sincs), ha feltétel a vezetéknélküli működés, akkor egy ilyennel egymagában is meg lehet oldani.
-
válasz
ekkold
#14928
üzenetére
Szerintem a kódolást maga az IDE, a szövegszerkesztő szintjén kezeli, ezért a legegyszerűbb az lenne, hogy ezeket a szövegeket egy külön .h fájlban tartanád, amit egy olyan külső szövegszerkesztővel írsz és szerkesztesz, ami tud iso8859-2 kódolással menteni. Fordításkor nem fogja átkódolni utf-8-ra, byte-to-byte fogja a lefordított kódba másolni a string-eket. Úgy emlékszem volt már ezzel saját tapasztalatom.
-
kesztió
aktív tag
válasz
ekkold
#14640
üzenetére
azt a nagyjából állandó vízhőmérsékletet, ami a kívánt helyiség hőmérsékletet tudja tartani.
Én azért nem indulnék ki abból a feltételezésből, hogy minden szobában azonos hőmérsékletűre van állítva a termosztát. Mert a keringő víz hőmérséklete viszont mindenütt azonos, mármint olyan, amilyennek a hőszivattyúban be van állítva.
. A megoldás az lett, hogy nem tettünk különbséget a kódban a rotary típusa szerint. Itt eleve többféle értelmezés is lehetséges, a korábban említett csupán két él figyelése szerintem például nem teljesen korrekt. A teljes és egyértelmű kapcsolási periódus mindenképp négy élből áll, csupán kettőt figyelembe véve félútról visszatekerhető az encoder, ami helyzettől és ízléstől függően furcsán hathat (mivel ekkor az általad 'dupla lépésesnek' nevezett kivitel anélkül ad egy-egy teljes oda-vissza jelzést, hogy akár egyszer is fix mechanikai állapotba lépett volna). A tapasztalat viszont az volt, hogy ha mind a 4 él meglétéhez kötöttünk egy lépést, akkor viszonylag gyakran hibázott, ezért kompromisszumként három éllel megelégedtünk. A hibázás (lépés kihagyása) ekkor elhanyagolható lett, és elmaradt a téves előre-hátra működés is. Persze hardverből is rásegítettünk, ahogy írtad, RC-szűrést (2,7k / 1nF) kialakítva. Gyári készülékeken sem mindig tökéletes a rotary, a mi megoldásunk sem lett annál rosszabb, egész nagy tekerési sebességig használható maradt.
Köszönöm a fáradozásaidat! A bajom azzal van, hogy nem csak különféle színeket villantok fel egyforma ideig, hanem elindulok pirossal, majd átúsztatom az elérhető összes szín érintésével, kb 15 másodperc alatt, majd villogtatok további színeket, majd ismét úsztatom a színeket, de félperces idő alatt megy el az elejétől a végéig. Ezért is használtam a color - delay párost és fix értékeket folyamatosan. A rendelkezésre álló tárhely majd' 1/5 részét el is foglaltam ezzel az igen buta és kezdetleges kóddal. 
Ez aztán a szép munka! 
![;]](http://cdn.rios.hu/dl/s/v1.gif)
. tudnátok esetleg olyan szenzort ajánlani ami kompatibilis a max6675-el(K) és tuti hogy nem olvad le 1000fokon sem? feltéve ha nincs más lehetőségem 
Az uno tetején terveztem 7 kis modult elhelyezni, és szendvicsben tök jól menne, minden megvan már. csak a köztes panel nincs, és gyártás előtt szerettem volna egy forrasztott tesztet.
Új hozzászólás Aktív témák
Hirdetés
- Apple Watch Sport - ez is csak egy okosóra
- sziku69: Fűzzük össze a szavakat :)
- Kerékpárosok, bringások ide!
- NVIDIA GeForce RTX 5080 / 5090 (GB203 / 202)
- Linux kezdőknek
- NTFS, exFAT, FAT32 – Melyiket válaszd és miért?
- Milyen légkondit a lakásba?
- PlayStation 5
- Diablo IV
- Lakáshitel, lakásvásárlás
- További aktív témák...
- Azonnali készpénzes félkonfig / félgép felvásárlás személyesen / csomagküldéssel korrekt áron
- LG 65B4 - 65" OLED - 4K 120Hz 1ms - NVIDIA G-Sync - FreeSync Premium - HDMI 2.1 - PS5 és Xbox Ready
- Bomba ár! Lenovo IdeaPad 330S-15IKB - i5-8G I 8GB I 256SSD I 15,6" FHD I HDMI I Cam I W11 I Gari!
- Bomba ár! Lenovo ThinkPad T470 - i5-G6 I 8GB I 256GB SSD I 14" FHD I HDMI I Cam I W10 I Garancia!
- ÁRGARANCIA! Épített KomPhone Ryzen 5 7600X 32/64GB RAM RTX 5070 12GB GAMER PC termékbeszámítással
Állásajánlatok
Cég: CAMERA-PRO Hungary Kft
Város: Budapest
Cég: Promenade Publishing House Kft.
Város: Budapest