- Hivatalos a OnePlus 13 startdátuma
- Samsung Galaxy S23 és S23+ - ami belül van, az számít igazán
- Android szakmai topik
- Milyen okostelefont vegyek?
- iPhone topik
- Apple Watch
- A hagyományos (nem okos-) telefonok jelene és jövője
- Samsung Galaxy S25 Ultra - titán keret, acélos teljesítmény
- Fotók, videók mobillal
- Samsung Galaxy Watch (Tizen és Wear OS) ingyenes számlapok, kupon kódok
-
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
-
ekkold
Topikgazda
válasz
Postas99
#23659
üzenetére
Ilyen irányú tapasztalatom nem sok van, de van pár eszközöm amiben ESP8266 vagy ESP32 van. Mikrotik Routert ill AP-ket használok, a wifi nem egy sebességbajnok ezekben, viszont stabil, és nagyon széleskörűen konfigurálható - egy próbát biztosan megér.
Próbára néznék egy régebbi típust, akár használtan, amiben erős wifi van pl. RB951G-2HnD. Régen egy szálloda wifi hálózatában használtunk ilyeneket, és volt olyan eszköz amin 40...50 user csatlakozott egyszerre wifivel. -
ekkold
Topikgazda
válasz
Dißnäëß
#23636
üzenetére
[link - LM317 adatlap]
Ha megnézed több különféle applikáció, ill. rajz is van az adatlapon. Van amelyiken polarizálatlan kondi van rajta (pl. 100nF), és van ahol elkó. Ez alapján feltételezem, hogy az LM317 nem túl érzékeny rá, hogy milyen kondi van rajta.
A 78xx és 79xx sorozatú stabkockák eléggé gerjedékenyek, ezért a ki- és bemeneti oldalára erősen ajánlott 100nF közvetlenül az IC mellett, és esetleg elkó is! Az elkóknak sokkal nagyobb az ekvivalens soros veszteségi ellenállása (ESR) azonban gerjedésre hajlamos áramkörökben, ez a veszteség segít a parazita rezgőkörök jóságát lecsökkenteni olyan szintre, hogy ne gerjedjen az áramkör.
Léteznek olyan stabilizátorok (kapcsolóüzeműben is) amelyek nem stabilak kerámia/fólia kondikkal, hanem elkó kell rá. Némely típus adatlapján pedig külön kiemelik, hogy ez a típus stabil kerámiakondikkal is! -
ekkold
Topikgazda
válasz
Dißnäëß
#23621
üzenetére
A szuperkondival több gond is lehet:
- vannak olyan típusok amelyek csak kicsi árammal használhatók (amit linkeltél az is ilyen). Ha nagy árammal töltöd-kisütöd akkor hamar tönkremegy, ill. a rel nagy ESR-je miatt a funkcióját sem látja el.
- A gyors feltöltéséhez nagy áram kell, és kb. közel zárlattal indul emiatt a stabilizátor, amit esetleg nem szeret hosszabb távon. Ha kisebb árammal töltöd akkor viszont sokáig fog tartani.Szóval ha már szoftver, akkor úgy kell megírni, hogy ha csökken a táp, akkor azonnal kapcsoljon ki minden olyan funkciót, ami áramot fogyaszt (pl. wifi), és mentsen.
Jó esetben ehhez akár n* 10ms is elegendő lehet, az 1 másodpercnek pedig bőségesen elegendőnek kell lennie.A stab előtti pufferfeszt kellene figyelni, így veheted észre a leghamarabb, ha elkezd csökkenni.
-
ekkold
Topikgazda
válasz
Dißnäëß
#23615
üzenetére
...nincs a neten mikrofarád <-> milliamperóra kalkulátor...
Akkor segítek:
Farád = As/V (amperszekundum per volt)
47000uF = 0,047F
Ha a puffer kondi mondjuk 9V-ra van feltöltve, és a rendszer akkor áll le, amikor 6,5V-ra csökken a feszültsége (mert ugye a stabkockán is marad valamennyi), akkor deltaU = 2,5V
2,5V * 0,047F = 0,1175As = 117,5mAs
Tehát jelen példában 117mA terhelés esetén 1 másodpercre elég a kondiban tárolt töltés.
Ha a kondi nagyobb feszültségről indul, vagy nagyobb kapacitású, vagy kisebb az áramfelvétel akkor hosszabb ideig bírja.
Ha a stabilizátor kapcsolóüzemű (tehát jobb hatásfokú) azzal is lehet némi időt nyerni. -
#23598
ekkold
Topikgazda
JulianSinulf
#23597
ekkold
Topikgazda
válasz
JulianSinulf
#23597
üzenetére
Köszi!
Igazából még csak nem is off, hiszen arduinoval készült az STM proci programja
-
ekkold
Topikgazda
válasz
JóGéza
#23592
üzenetére
Az évek során kb. 50db panelt adtam el hozzá, és ha nem is készült el még mindenkinél mindegyik, azért az elmondható, hogy elég sok példányban lett utánépítve. Nyilván az alkatrészek ára sem jelentéktelen manapság, (amikor készült kb harmad annyiból kijött mint most), de még mindig sokkal olcsóbb mint egy eredeti JBC állomás.
-
ekkold
Topikgazda
válasz
ViZion
#23507
üzenetére
Másik támában szóba került a nemsokára megszűnő skype. Majdnem a kezdetektől használtam, akkor még p2p alapon működött, akár helyik hálózatban is a külső szerverek elérése nélkül is! Az amcsik elsősorban azért támadták, mert semmilyen módon nem lehetett lehallgatni - ott (és amúgy nálunk is) kötelező lehetőséget biztosítani az állambiztonság számára ilyen funkció használatára. Aztán megvásárolta a M$ 8500 millió dollárért! Nem elírás! dollármilliárdokat fizettek a skype-ért, és az akkora már 100 milliós nagyságrendűre növekedett felhasználótábor adataiért... Bárki szerint elképzelhető az, hogy ez egy reálisan megtérülő üzlet volt, a fizetős felhasználóktól származó bevételből?? Biztos, hogy nem csak az adatok és a lehallgatás lehetősége kellett, ill. az ért meg ennyire sok pénzt? Biztos, hogy nem állami támogatás volt ennek a pénznek valamekkora része, valamilyen ellenszolgáltatásért cserébe?
Kína nem méginkább így működik? De. Akkor? Az lenne a furcsa ha valamiben nem lenne. Persze attól még ez nem feltétlenül jelent közvetlen veszélyt (és nem is mindenkire), de ugyanakkor azért számítani kell rá, hogy itt-ott lehet "alvó ügynök", és semmilyen eszközben nem szabad 100%-ig megbízni.
Érdemes megnézni pl. mikrotik routerekben mi is az a Calea csomag, és miért aktív alalpból az amerikai verziókon, de az európaiban nem... de ugye itt is telepíthető... -
ekkold
Topikgazda
válasz
ViZion
#23507
üzenetére
Nem tartom lehetetlennek, hogy a ESP-n keresztül meghekkeljenek valakit. Egyrészt a wifi csatlakozáshoz el tudok képzelni "univerzális kulcsot ill. jelszót" amivel mindenképpen rá lehet csatlakozni. A benne megvalósított TCP protokoll (amit csak használni kell) is tartalmazhat extrákat (gépi kódban akár néhány bájton is!), és pl. gyűjthet kisebb adatokat, pl. egy-egy kódolatlanul küldött jelszó a LAN-on...
Persze nyilván nem egyszerű, de sose becsüld le a távolkeleti fejlesztőket (és a többieket se)... -
ekkold
Topikgazda
válasz
Janos250
#23195
üzenetére
Nekem a win10 csinálta ugyanezt régen. Azért van, mert a CP2102 chipek 90%-a nem eredeti. A gyártó pedig kiadott pár újabb drájvert, amivel csak az eredeti chip megy (a windows pedig ezeket erőlteti). Nálam egy régi drájver levadászása megoldotta annak idején a problémát. Itthon Win7-et használok, azon nincs vele gond.
Ujabb windowsokban le kell tiltani valahol, hogy magától frissítse a drájvert (különben lecseréli a működő drájvert is a nem működőra - és nem is szól) Utána pedig fel kell tenni egy régit amivel működik. Talán megvan valahol amit win10-en használtam - kérdés, hogy a win11-be bele lehet-e erőltetni. -
#22988
ekkold
Topikgazda
JulianSinulf
#22985
ekkold
Topikgazda
válasz
JulianSinulf
#22985
üzenetére
Van néhány logikai probléma a programodban. A legdurvábbak:
- Avegallas_fent(); és a vegallas_lent();függvényedet egymás után hívod, tehát az első függvény teljesen mindegy, hogy mire állítja a v változódat, mert a második függvény felülírja a v értékét.
- A másik probléma, hogy ugyanazokat az információkat többször értékeled ki. Tehát a v függ a végálláskapcsolók állásától, de azután újra vizsgálod ezeket. Tehát a két vizsgálat közül az egyik vizsgálat felesleges, a másikat meg jobban át kellene gondolni.
A javaslatom, hogy ne ezeket foltozgasd, hanem -> kuka, majd gondolt át mit szeretnél elérni, és írj új függvényeket rá. -
ekkold
Topikgazda
válasz
ratkaics
#22966
üzenetére
Ha van benne generátor, akkor a generátor valamelyik tekercsén a frekvenciát lehet mérni (egyenesen arányos a fordulatszámmal). A haladási sebesség hez vahgy kell egy szerzor/jeladó valamelyik kerékre ill. tegnelyre, vagy GPS-el is meghatározható a sebesség.
A GPS-el csak annyi a baj, hogy lassabban frissül, de a sebbég és a forduzlatszám alapján meghatározható az áttétel (váltó sebességfokozata), és a GPS frissülései között, a fokozat ismeretében (a fordulatszám alapján) is frissíthető a sebesség.
Vagy ha a váltón is van valamilyen jeladó, akkor a fokozat + fordulatszám alapján is kalkulálható sebesség. -
ekkold
Topikgazda
Változó, hogy mikor melyik a jobb (#define vagy pl. const int).
Van amikor csak az egyik jó, pl. vannak olyan függvények amelyeknek csak változó lehet a paramétere, simán egy beírt szám nem. Ilyenkor a #define-al megadott érték nem lesz jó paraméterként használva.
Aztán itt van pl. ez:
#define ERR_MSG1 "Megszakadt a kapcsolat!";
const char* err_msg1 "Megszakadt a kapcsolat!";Ha a programban több helyen írjuk ki ezt az üzenetet, akkor az első esetben (#def..), a program több különböző helyén is fog tárolódni a szöveg, annyi példányban ahányszor kiírjuk. A második esetben viszont csak a stringre mutató pointer lesz többször felhasználva, a szöveg csak egyszer tárolódik el.
Az fordító optimalizálójára szerintem nem illik túlságosan támaszkodni, mert nem biztos, hogy mindig ugyanúgy fog viselkedni, és a működése attól is függ, hogy mi az optimalizálás célja (mert az is állítható: kódméret, sebesség, memóriahasználat, stb...), valamint sok esetben az is állítható, hogy mennyire legyen "agresszív" az optimalizálás. Utóbbi esetben sokkal hatékonyabb lehet, de előfordulhat, hogy olyasmit is kiszed amit nem kellene, és összeomlik a program... Tudom sokan már nem így programoznak, de én még azt tanultam, hogy igyekezzünk eleve hatékony kódot összehozni...
-
ekkold
Topikgazda
1, Több nyomógomb kezelése esetén is probléma mentes a GND -re húzás. Viszont az egyes áramkörök VDD feszültsége (logkai H szintje) lehet különböző (1,8V - 3,3V - 5V - 12V), ami hibás csatlakoztatás, ill. a gombok elcserélése esetén komoly problémát okozhat, ha a gombok H szintre kapcsolnának. Viszont a GND az mindig 0V...
2, A mikrokontrollerek bemenetén többnyire van szoftveresen bekapcsolható felhúzó ellenállás, így esetleg megspórolható egy külső alkatrész. Lehúzó ellenállás viszont nem minden mikrovezérlőben van, így ha a gombok H szintre kapcsolnak, ahhoz a legtöbb esetben kell külső ellenállás is. (de pl. STM procikban van választható felhúzó vagy lehúzó ellenállás is)
-
#22754
ekkold
Topikgazda
JulianSinulf
#22753
ekkold
Topikgazda
válasz
JulianSinulf
#22753
üzenetére
Ne offoljunk légyszi itt ezzel, biztosan van megfeleő pl. HiFi-s téma erre is. Maradjunk a dolog arduino-t érintő részénél.
-
ekkold
Topikgazda
Pár éve volt szó egy olyan technológiáról, hogy az ultrahangot modulálják egy hallható hanggal, és nagy teljesítménnyel, irányítottan megcéloznak vele. A fül nem hallja ezt a frekvenciát,de a nagy amplitúdó miatt torzítások keletkeznek, ami bizonyos mértékben demodulálja a jelet. Emiatt a célba vett illető, belül fejében hallja a hangot, azt hiszi hallucinál és fura belső hangokat hall. Adott esetben "a hang" biztatja valamire, vagy éppen lebeszéli valamiről... Állítólag pl. titkosszolgálatok sikerrel alkalmaznak ilyen eszközöket.
20kHz felett hangot gyakorlatilag senki sem hall, de ha modulálva van, és elég hangos is, akkor lehet hogy hallunk valamit (de az valójában nem a 20kHz feletti frekvencia). -
ekkold
Topikgazda
válasz
5150head
#22540
üzenetére
- Sokféle megoldás elképzelhető, akár potis is.
- De a nyomógombokhoz is írható olyan program, hogy ha a "FEL" gombot nyomogatod, akkor minden gombnyomás növel egy kicsit a sebességen, ha pedig a "LE" gombot, akkor minden gombnyomás csökkent egy kicsit a sebességen.
- Vagy használhatsz akár rotációs enkódert is a poti helyett. -
ekkold
Topikgazda
válasz
5150head
#22536
üzenetére
A loop elején mindíg újra 10-re állítod a sebességet, helyette inkább:
Kell egy változó a sebességnek, és azt növeled vagy csökkented, és ha kell, akkor hívod a függvényt ami végrehajtja. pl:
void loop() {
static int16_t sp=10;
// Set the speed in steps per second:
stepper.setSpeed(sp);
// Step the motor with a constant speed as set by setSpeed():
stepper.runSpeed();
if(digitalRead(uppin) == LOW) {
sp =30
}
if(digitalRead(downpin) == LOW) {
sp = 1;
}
} -
ekkold
Topikgazda
válasz
Arabiata
#22486
üzenetére
Amit tudnod kell: igen nagy fába vágtad a fejszét (ez nem baj, csak tudd). Ez egy külön szakma, több év tanulás kellhet az alapokhoz is. Majd folyamatos tanulás, ahogy fejlődik a technika - ahhoz, hogy szinten tartsd a tudásod.
Ahol kezdhetsz: [ebben a témában - link] nyisd meg az összefoglalót. Itt találhatsz linkeket tananyagokra, és elektronikával foglalkozó weboldalakra is. Ha kb. mindet alaposan átrágod, akkor eljuthatsz egy olyan szintre, hogy tudsz majd úgy kérdezni, hogy utána van esélyed érteni a kapott választ. -
-
ekkold
Topikgazda
Egy ilyen példát találtam a neten:
// Set-up hardware PWM on the Arduino UNO/Pro Micro at 2kHz on digital pins D9 and D10void setup() {pinMode(9, OUTPUT); // Set digital pin 9 (D9) to an outputpinMode(10, OUTPUT); // Set digital pin 10 (D10) to an outputTCCR1A = _BV(COM1A1) | _BV(COM1B1) | _BV(WGM11); // Enable PWM outputs for OC1A and OC1B on digital pins 9, 10TCCR1B = _BV(WGM13) | _BV(WGM12) | _BV(CS11); // Set fast PWM and prescaler of 8 on timer 1ICR1 = 999; // Set the PWM frequency to 2kHz (16MHz / (8 * (999 + 1)))OCR1A = 500; // Set duty-cycle to 50% on D9OCR1B = 250; // Set duty-cycle to 25% on D10}void loop() {}
Ahogy nézem itt 1000 lépéses PWM-et állít be, 2kHz-en, de ez több is lehetne, utána kellene nézni pontosan, hogy melyik regiszter mit állít be. -
#22401
ekkold
Topikgazda
JulianSinulf
#22400
ekkold
Topikgazda
válasz
JulianSinulf
#22400
üzenetére
A biztosítékot nem tudja lemérni.
A kábel csatlakozófejben van egy ellenállás, ennek az értékével specifikálják a kábel terhelhetőségét, amit a töltésvezérlőnek figyelnie kell (nem terhelheti túl a kábelt).
A sima háztartási villásdugó max 10A-t visel el, egyes ipari(bb) verziói 16A-t. Nagyobb áramra ipari csatlakozók kellenek, vagy fix bekötésű eszköz.
Tehát további limit lehet a töltésvezérlőbe is építve, pl. a sima, konnektorba dugható eszközök nem szoktak 10A-nál többet engedni.
-
ekkold
Topikgazda
Annyit néznék meg, hogy a töltésvezérlőben levő MCU mekkora tápról jár (3,3V esetleg 5V), és ehhez igazítanám a PWM szűrőt. A vezérlő bemenete gondolom az MCU egy A/D bemenete lehet. Tehát ha mondjuk 3V-os, akkor egy kis feszültségű, Rail-to-Rail Input/Output, opampot használnék, a szűrőhöz, ami szimpla 3V-ról jár. A kívánt PWM értékeket meg simán ki is lehet kísérletezni, és egy táblázatba fel lehet venni. De akár tanítható, vagy öntanuló is lehetne az eszköz - pl. a saját MCU-d is mérheti a szűrő kimenetét, a belső A/D konverterével (de szerintem még erre sem lesz szükség).
-
ekkold
Topikgazda
Értem. Arra próbáltam célozni, hogy ha már MCU-t meg PWM-et kell használni, akkor az EVSE akár ki is hagyható, mert közvetlenül elláthatja ezt a funkciót is a cucc.
Viszont akár hogy is lesz, ehhez nem kell hatalmas felbontás, mert az autó úgysem fogja tizedes pontossággal tartani az áramot, csak úgy kb. azt amit kell. Meg nem is szereti ha hirtelen változnak a beállítások, legalábbis mikor teszteltük, akkor volt amelyik autó letiltotta a töltést, ha túl gyorsan akartuk az áramot változtatni, tehát célszerű ha eleve lassan változik. Ennélfogva azt mondanám, hogy PWM + szűrő, kellően jó megoldás lehet. -
ekkold
Topikgazda
Természetesen az is teljes körű megoldás volt, figyelte a feszültségszinteket, a fázisonkénti áramfelvételt, és az ÉV hibaáramot is mérte. A kábel csatlakozófejben levő ellenállást (ami a kábel terhelhetőségét jelzi) szintén mérte, és figyelembe is vette.
Az MCU vezérelt verziónak sok további egyéb funkciója is volt.... -
ekkold
Topikgazda
Eddig úgy tudtam, hogy az elektromos autónak egy 1kHz-es, ±12V-os PWM jel kitöltési tényezőjével lehet "megmondani", hogy mekkora áramot vehet fel maximum. Ilyen töltésvezérlőket fejlesztettem is jónéhány évvel ezelőtt, volt MCU-ra épülő verzió, és volt "diszkrét" MCU nélküli megoldás is (filléres alkatrészekkel, pl. komparátorokkal stb. megoldva).
-
ekkold
Topikgazda
Mondjuk kezdd ezzel: [link]
- Ha a feszültség hullámossága nem elég kicsi, akkor akár több fokozat is egymás után köthető.
- Precízebb megoldásba referencia forrás is kellhet (azt kell kapcsolgatni a PWM-el)
- A szűrés tulajdonságai digitális módszerekkel is nagy mértékben javíthatók, de az tovább bonyolítja az áramkört.Ez utóbbi megoldással terveztem már áramkört, viszont ez már igen sok alkatrész, de cserébe 50ms alatt, jóval 1µV alatti értékre beáll a hullámossága (a pontosság sajna valamivel kisebb). De mivel neked kevésbé kihegyezettek az igények, egy egyszerű, és jól méretezett szűrő is simán megoldás lehet.
-
ekkold
Topikgazda
válasz
Janos250
#22316
üzenetére
Sajnos a mechanikus kontaktusokkal felépített rotary enkóderek, tapasztalatom szerint prelleznek mint a fene, ami csak elvileg nem gond, gyakorlatilag viszont olyan gyorsan is prellezhet, hogy kimarad megszakítás, mert hamarabb jön az újabb impulzus, mint ahogy az irq lefut. Emiatt volt nekem hatékonyabb a pollozás, mint a szintváltásra induló irq. Ha viszont van hardveres szűrés is (pl. sima RC-tag) akkor nem tud túl sűrűn új megszakítást indítani, és simán van idő mindenre a szoftverben.
-
ekkold
Topikgazda
Ennek így nem látom át a működését. Az interrupt eleve akkor hívódik meg amikor változik a láb állapota. Megnézed, hogy eltelt-e bizonyos idő, és tényleg változott-e a láb állapota, és ha igen akkor növeled az értéket.
Mi történik prellezéskor, és mikor fog csökkenni az érték?Mi történik ha a prellezés éppen hamarabb befejeződik mint az interval? Akkor mi fogja a függvényt meghívni?
-
ekkold
Topikgazda
Ezt a prellmentesítést hogyan oldottad meg?
Ami megoldást láttam eddig ott a megszakításban kivárta a prellezés végét, ami akár 1ms is lehet - hát az nem túl szép. Vagy rá lehet nézni a loop-ból, hogy abbahagyta-e már a prellezést, vagy timer megszakításból is, de akkor meg majdnem ugyanott vagyunk mintha eleve így kezelnénk pollozással...De hátha tudsz valami jobb megoldást... ?
-
ekkold
Topikgazda
Meg lehet azt jól is csinálni. A forrasztóállomásomban [link] pl. a loop-ból kezelem a gombokat és/vagy az enkódert is, ráadásul úgy, hogy nincs hardveres prellmentesítés, hanem azt is szoftverből oldottam meg (hibátlanul működik). Persze ehhez olyan program felépítés kell, ahol a loop nagyon gyorsan fut (de igyekszem mindig ilyen elven programozni).
Most egy másik projektben gombokat és egy forgó kereket, amit két optokapu figyel (enkóderhez hasonlóan kell kezelni) egy 40µs-os timer megszakításból kezelem. Azért így mert a kijelző multiplexelését is szoftveresen kellett megoldani.
[link-video] [link-video]
Baloldalt a fordulatok számát - jobb oldalon a másodpercenkénti fordulatszámot mutatja.Lehetne persze az input lábakkal indítani megszakítást, de így sokkal nehezebb a prellezést szoftveresen kezelni (akkor kellene pl. RC tag a bemenetre, hogy ne tudjon túl sűrűn megszakítást indítani).
-
ekkold
Topikgazda
válasz
Janos250
#22248
üzenetére
Lényegében egy pointert hoztál létre, amit utána úgy indexeltél egy változóval, mintha egy tömb lenne. Ezt megteheted, de tudni kell, hogy ilyenkor nem történik memória foglalás, mint egy tömb vagy sima változó esetén (csak a pointer számára foglal memóriát), tehát ha nem jó címre írsz, elszállhat a programod.
Ezt megteheted sima változó esetén is, foglalhatsz memóriát dinamikusan, vagy létrehozhatsz konstans pointert is.
uint32_t * kodszam = ((uint32_t *)(0x3FF03000));
*kodszam = 0 //az adott fenti címre beírja a nullát
kodszam[0] = 0 //ez ugyanezt csinálja -
ekkold
Topikgazda
Az lenne a kérésem, hogy a forrasztás témával menjünk át (aki még folytatni szeretné) a Hobbielektronika témába, mert ez itt az Arduino témában eléggé OFF, itt pedig maradjunk meg az Arduinoval kapcsolatos témáknál.
-
#22088
ekkold
Topikgazda
JulianSinulf
#22087
ekkold
Topikgazda
válasz
JulianSinulf
#22087
üzenetére
Ez csak közvetett ok. Magyarul nem közvetlenül a műhold miatt került bele az ólom, hanem azért, mert a sima ónból készült forrasztásokkal gondok voltak, úgy általában minden olyan elektronikában, amit kicsit hosszabb távra terveztek. A műhold, vagy az atomerőmű csak egy-egy példa arra, hogy a gyakorlatban is előfordultak és problémákat is okoztak ezek a jelenségek, tehát nem csak egy elméleti dologról van szó. Sajnálom ha ez nem így jött át.
Komolyabb eszközökben ma is használnak ólomtartalmú forraszanyagot (pl. orvosi műszerek elektronikái, repülőgépek).Az ón átkristályosodása miatt kialakuló ónpestissel úgy emlékszem 10C fok alatt kell számolni, de itt még lassú a folyamat. Az ólommentes forraszanyagok egyéb ötvözői (réz, ezüst, antimon, bizmut, stb..) ezt a folyamatot is (és az ónbajusz képződést is) lassítják, de a lehetséges ötvözők közül az ólom a leghatékonyabb.
Általánosságban az ólommentes forraszanyagokkal magasabb hőmérsékleten is kell forrasztani, mint az ólmossal, ami szerintem megintcsak inkább hátrány, mint előny.De felőlem mindenki azzal dolgozik amivel szeretne, vagy amire lehetősége van. Az otthoni hobbi használat szerintem nem akkora mennyiség, hogy környezetvédelmi vagy egészségügyi szempontból bármilyen jelentősége lenne.
-
#22065
ekkold
Topikgazda
JulianSinulf
#22063
ekkold
Topikgazda
válasz
JulianSinulf
#22063
üzenetére
....A Galaxy IV egy távközlési műhold volt, amelyet 1998-ban ónbajuszok okozta rövidzárlatok miatt letiltottak és elvesztek.....
....2005. április 17-én a Connecticut államban működő malomkői atomerőművet leállították egy "téves riasztás" miatt, amely a reaktor gőzrendszerében a nem biztonságos nyomásesést jelezte, amikor a gőznyomás ténylegesen névleges volt. A téves riasztást egy ónbajusz okozta, amely rövidre zárta az erőműben a gőznyomás vezetékeinek felügyeletéért felelős logikai kártyát...
[link] -
#22062
ekkold
Topikgazda
mindenes24
#22059
ekkold
Topikgazda
válasz
mindenes24
#22059
üzenetére
Általános célra furatszerelt alkatrészekhez 0,7mm, esetleg 0,8mm-es ón-ólom ötvözetet használok, ezzel gyorsan és optimálisan lehet haladni. SMD-hez ennél vékonyabbat: 0,3...0,5mm-es ónt használok.
Az ólommentes ónokkal készült forrasztások élettartama rövidebb, rosszabbul tűrik a rezgéseket és a mechanikai igénybevételt. Hajlamosabbak megrepedni a forrasztások, bizonyos körülmények között előfordul az "ónpestis"-nek nevezett jelenség, vagy az "ónbajusz" képződés. Annak idején emiatt műholdak is mentek tönkre. Ennek a kiküszöbölésére került be az ólom ötvöző anyagként. A 60%-40% ötvözet úgynevezett eutektikummá alakul, ennek az olvadáspontja mindkét ötvőző fémnél alacsonyabb.
Amúgy az ólom mérgezősége nagyban függ attól, hogy milyen formában találkozunk vele. A fémes ólom nem oldódik, nem szokott mérgezést okozni. Sok helyen a mai napig ólomcsőből van a vízvezeték, mégsem hallani tömeges ólommérgezésről. Az ólom akkor válik veszélyessé, amikor oldott formában találkozunk vele (pl. ólomakkumulátor esetében, az akkumulátorsavban oldott ólom) ilyenkor már kis mennyiség is komoly mérgezést okozhat - de a forraszanyag nem ez a kategória.
Még pár további infó: [link] számodra a második bekezdéstől lehet érdekes. -
#22000
ekkold
Topikgazda
JulianSinulf
#21999
ekkold
Topikgazda
válasz
JulianSinulf
#21999
üzenetére
Azért az igen "vicces" lenne ha egy 10km-es kábelt csak cserével lehetne javítani.
-
-
ekkold
Topikgazda
válasz
Postas99
#21991
üzenetére
Attól függ milyen műszerek vannak a hibakereséshez. Egységugrás jelre adott reflexióból elég pontosan megmondható hogy mekkora távolságra lehet a hiba... Ez egyetlen mérés.
Programozói logikával meg: bináris keresés a megoldás, de az több mérés.... (megnézzük félúton, majd annak a felénél, stb...)
Józan paraszti ésszel meg: látjuk hol ásta fel a vízművek a földet: 99% hogy ők vágták el a vezetéket ásás közben.Akkor már kérdezek én is:
Rákapcsolok egy kábel egyik végére 25V-ot, a másik végére meg egy 230V/100W-os izzót. Az izzó teljes fényerõvel kezd világítani! Semmilyen csalás nincs a dologban, de akkor hogy lehet ez?
Bocsánat most nézem, hogy nem az elektronika témában vagyok... -
ekkold
Topikgazda
válasz
#99235328
#21385
üzenetére
Az említett MIC azért jó, mert a dropout áramfüggő, azaz 300mA-nél 160mV, de az STM 40mA körül fogyaszt, ezzel mindössze 21,3mV a mardékfesz elég a stabilizátor működéséhez.
A mA mérés teljesen elfogadható eredményt fog adni, minimális hibával. Akár több darab LDO is használható pl. külön az MCU-nak, külön a kijelzőnek, stb... de lehet, hogy ebből egy is elegendő a teljes áramkörhöz.
Hasonló megfontolásból válaszottam én is, ezt az LDO-t (hogy 1db Li celláról működhessen az MCU), és az akksit sem muszáj 3,3V alá kisütni.... Ezen kívül a 3.3V-os LDO sem áll le ez alatt, csak ilyenkor a kimeneti feszütsége együtt csökken a bemenővel (minusz a dropout - ami nem sok). Ha megfelelő referenciát használsz akkor ez sem probléma. -
ekkold
Topikgazda
válasz
#99235328
#21378
üzenetére
- Az STM32 adatlap szerint 2V - 3,6V között működik. Tehát akár 2V-ról is lehet használni.
- Én pl. egy apró filléres LDO-t használok: MIC5501-3.3 az STM-hez, ez 300mA-nél 160mV feszültségeséssel dolgozik, de mivel itt közel sincs ekkora fogyasztás 30...40mV maradékfeszültség is elegendő. A Li cellát amúgy sem illik 3V alá meríteni, é smég ilyenkor is lesz az LDO kimenetén 2,95V (és ugye akár2V-ról is megy a proci - próbáltam)
Annak idején készítettem BluePill-el lábkompatibilis kis paneleket, amit WhitePill-nek neveztem el (mert fehér panelt akartam - bár néhány zöld lett), íme:
[link] [link]
Ezeken is ilyen LDO van. Ennek azaz egyedüli hátránya, hogy max. 5,5V-ot bír el a bemenete, tehát nem kaphat ennél nagyobb feszültséget.Ha végig stabil feszültséget szeretnél akkor 3,0V-os verziójú LDO-t használj, és csak 3,1V-ig hagyd merülni az aksit.
[MIC5501 PDF] [MIC5501 - Chipcad] [MIC5501 - TME]
Persze kereshetsz más tipust is, elég sokféle létezik -
ekkold
Topikgazda
Nagy terhelésnél, és nem túl hosszú üzemidőnél, ez valóban nem indokolt. Igazából lehet, hogy csak átsiklottam felette, de a szóban forgó projekt többi részét nem ismerem. Van amikor 0,1µA is számít, van amikor meg néhány mA sem lényeges. Amúgy egy ilyen említett opamp sem árban, sem méretben nem jelentős - nálam meg előfordul, hogy egy-egy projektbe átveszem, az esetlegesen korábban már megoldott részfeladatok megoldásait. Pl. ez a megoldás esetleg kibővülhet később azzal, hogy egy LDO (aminek van EN lába, és szintén elhanyagolható a saját fogyasztása) adja a tápot az MCU-nak, az MCU pedig mindent (is) le tud kapcsolni ezt használva.
Amúgy meg vitatkozhatsz nyugodtan, senki sem tévedhetetlen, Te sem, és Én sem, és a fórum erre (is) való.
-
-
ekkold
Topikgazda
válasz
#99235328
#21355
üzenetére
Ennek a feladtnak (az egyik) korrekt megoldása:
Ellenállás osztó pl. 2db 10MΩ (vagy nagyobb ellenállásból). Azért célszerű két egyforma ellenállást választani, mert ezeknek valószínűleg a hőfokfüggése is hasonló lesz - ezért jó eséllyel mindíg a felére osztja a feszültséget. Nagy ellenállást választva rajta hagyható lesz az akkun, mert az akksi önkisüléséhez képest elhanyagolható áram fog átfolyni rajta (< 0,2µA).
Persze mivel ez az osztó nem terhelhető érdemes egy kicsi cmos opampot betenni követő erősítőként az osztó, és az A/D bemenet közé. Több olyan opamp típus is létezik, amelyiknek a saját fogyasztása a nA-es tartományban van, és táptól-tápig tud dolgozni (Itáp <= 0,1µA), ha ilyet használunk akkor ez sem meríti az akkut számottevő mértékben.
Ilyen módszerrel elvileg a a táp kétszereséig lehet mérni (tehát 3,3V esetén 6,6V-ig), de sokszoros túlfesz esetén, a nagy ellenállások miatt oz osztó árama akkor is olyan kicsi marad, hogy nem károsítja az opamp bemenetét.
Zener használata védelemként azért nem lenne szerencsés, mert linearitás hibát okoz a mérésben.
Az A/D bemenet impedanciája nem túl nagy, ezért önmagában nagy ellenállású osztóval nem túl jó használni. Ha mindenképpen meg akarjuk spórolni az opampot, akkor 100k....1M nagyságrendű ellenállásosztót használhatunk, de az osztó kimenetére érdemes egy néhány µF-os kerámia kondit kapcsolni.
Az A/D méréskor nem tudja számottevően kisütni ezt a kondit, ezért a mérési hiba kicsi tud maradni - viszont ennek az az ára, hogy nem lehet túl sűrűn mérni, mert minél sűrűbben mérünk, annál nagyobb lesz a mérési hiba (mert annál jobban kisül a kondi az A/D bemenő impedanciája miatt). Ugyanis a legtöbb MCU esetében, az A/D bemeneti impedanciája csak a mérés közben terheli az osztót. -
ekkold
Topikgazda
Eléggé körbejártam a témát, egyértelműen proci hiba. Volt amelyik lapon próbaképpen lecseréltük a procit, természetesen jó is lett. Amúgy az USB hibás proci is használható - szinte minden olyan projekthez amihez nem kell az USB. Ja, és hőmérő sincs ezekben a procikban (az eredetiben van - és kiolvasható).
Még egy érdekesség: A saját WhitePill lapokra STM32F101 proci került (mert olcsón tudtam venni egy pár darabot). Ez elvileg USB nélküli, 36MHz-es proci. Gyakorlatilag viszont mindegyiken működik az USB, és akár 150MHz-en is mennek. Feltételezhetően a gyártó így feliratozta, mert éppen 101-es procira volt igény... vagy csak nem ment át valamilyen teszten - de nem tudom min, mert a kinai 103-as prociknál ezek sokkal jobbak. -
ekkold
Topikgazda
Még egy érdekesség STM32 ügyben: Sok olyan BluePill van a piacon amibe, hamis vagy éppen selejtes proci kerül. A hibák közül az egyik leggyakoribb, hogy az USB-hez tartozó portlábak nem működnek rajta (és ezért az USB sem működik). Ennek tesztelésére összedobtam egy próbapanelt amelyen minden I/O láb kapott egy-egy ledet, és egy egyszerű futófény programmal pillanatok alatt letesztelhetők a lábak. Azért is kellett ez, mert készítettem saját BuePill paneleket (WhitePill néven) és ezzel teszteltem, hogy jól sikerült-e a proci beforrasztása.
[link - video - USB-OK]
[link - video - USB-ERR]
[link - WhitePill - Saját-2021.07.23] -
ekkold
Topikgazda
válasz
Postas99
#21233
üzenetére
A BlackPill-t lehet arduino-val programozni? Mit kell telepíteni ill. milyen alaplapot kell hozzá beállítani?
A BluePill-eket annak idején kipróbáltam meddig lehet felhúzni. A kínai hamis procik 104MHz-en még működtek. Eredeti procival 128Mhz-en simán ment a BluePill, utána próbaképpen kicseréltem a (8MHz-es) kvarcot. 10MHz-es, és 11,1MHz kvarccal próbáltam. Alaphelyzetben 9-es szorzóval megy, és a szorzót növelve 150MHz- környékén volt a max. ahol még működött. Vagyis, ha egy hangyányival mégtöbb sebesség kell 80...88MHz-re, esetleg 104 MHz-re még mondhatni biztonsággal fel lehet húzni (kvarc cserével, vagy a szorzó átállításával). Bár érzése nekem az STM proci 72MHz-en is jóval gyorsabbnak tűnik, mint pl. az ESP8266 80MHz-es procija. -
ekkold
Topikgazda
47L04 EERAM-al kapcsolatban kérdezném (aki már használt ilyet). Elvileg ugye ha elfogy a tápja, és aktív az automatikus mentés, akkor menti az SRAM tartalmát az EEPROM-ba, bekapcsoláskor pedig visszatölti.
Hogyan kezeli, ill mi történik ha mondjuk éppen egy 32 bites változót, vagy egy nagyobb struktúrát frissítek, és közben fogy el a táp? Tehát ilyenkor lehetnek félig megírt adatok, és ezt tudni kell kezelni szoftverből, avagy ezt is kezeli valahogyan? Tehát mi történik ilyenkor (pufferel, kihagyja a mentést ha éppen írás közben fogy el a táp, vagy egy korábbi, az aktuális írás előtti állapot mentődik)? -
ekkold
Topikgazda
Ha sima konstansokkal akarod feltölteni, akor az ugyanannyi helyet foglal mintha két tömböt készíteniél, tehát ez esetben két tömböt kell készíteni. A használatakor pedig pl. pointert használsz amibe az egyik vagy a másik (vagy több is lehet) tömb címét töltöd bele.
int xy[3][3] = {.....
int zy[3][3] = {.....
int * py;py = xy;
py[0][1] = .....
.....
py = zy;
py[0][1] = .....
.....
Ha nem akarsz pointerezni, akkor a memcpy() függvénnyel másolható a tömb egyikből a másikba.
memcpy(xy, zy, sizeof(xy))Ha nem akarod, hogy a zy tömb is foglaljon memóriát, akkor progmem konstansként kell definiálni, de ilyenkor csak olvasható lesz, de arra pl. továbbra is jó, hogy az xy tömbbe belemásold. Tehát:
const int PROGMEM zy[3][3] = {..... -
ekkold
Topikgazda
válasz
Gergosz2
#20749
üzenetére
Nyilván egy nagyobb tudású A/D nem lesz olcsó, de azért hozzátenném, hogy a bitszélesség csak egy paraméter a sok közül, pl. a sebesség is lehet fontos szempont. Sok (töbnnyire külső) A/D tartalmaz olyan szűrőket (pl. 50/60Hz lyukszűrő) ami lehetővé teszi hogy "ne billegjen" a kapott digitális érték.
-
ekkold
Topikgazda
válasz
Ton-ton
#20746
üzenetére
Nagyjából mindegyik MCU-nak rosszabb a belső ADC-je, mint egy küldő A/D konverter. A többihez képest pedig szerintem nem rosszabb az sem ami az STM32-ben van. Használtam már néhány dologra BluePill panelt (STM32F103) és szerintem az A/D jobb mint ami általában az arduino (pl. nano) paneleken van. Ráadásul a nano 10bites A/D konverteréhez képest ez 12 bites, és még gyors is.
-
ekkold
Topikgazda
válasz
Dißnäëß
#20639
üzenetére
Nem igazán arduino-s, de ilyesmire olyan cucc kell(ene) ami másnak is van, különben kivel fogsz kommunikálni? Ez pedig a 27MHz-es CB rádió, abszolúte szabálytan, és a szlengben csak "utánégető"-nek hívott végfokkal. Némelyik török kamionosnak anno kW-os végfok volt a kamionban, és simán hazaszólt az asszonynak innen is, igaz akkor addig mindenki csak őt hallotta... Sokaknak volt un. szelektív hivója, azaz a vevő zajzárral ment, és egy DTMF kód oldotta fel a zajzárat, így csak azt halotta a vevő aki neki szóló adást küldött. Az az érzésem, hogy egy lehetséges "zombi apokalipszisre" tekintettel még sokan vannak olyanok, akik megtartották az efféle készülékeiket... Sajnos én nem CB-ztem soha, de ha lett volna akkor most is meglenne (és az utánégető is
). -
#20090
ekkold
Topikgazda
its_grandpa
#20089
ekkold
Topikgazda
válasz
its_grandpa
#20089
üzenetére
Szerintem az elsőre jobb megoldás a #define használata, mert nem foglal plusz memóriát (a változóval ellentétben)
#define Gas_sensor A0
#define Gas_pin 2
....
....
analogRead(Gas_sensor);
....
....
digitalRead(Gas_pin);
....
....
Nekem sok programom eleve egy csomó #define-al kezdődik, ha pedig nagyon sok akkor kirakom mondjuk egy hwconfig.h fájlba. -
ekkold
Topikgazda
Pergésmentesítésre sokféle megoldás van.
- Hardveres megoldás: külső felhúzó ellenállás a gombon, majd RC szűrő
- Megszakításból: állapotváltásra le kell tiltani a további megszakítást kb. 1...2msec-re, amíg a prellezés lezajlik.
- 0.1...1ms-os timer megszakításból: azt kell figyelni, hogy a gomb állapota néhány megszakításon át változatlan-e, ha igen akkor van vége a prellezésnek, és felhasználható az új állapot.
- loop()-ban: az állapotváltás időpontját menteni kell (millis() vagy micros() függvény), ha az utolsó változás óta eltelt több mint 1...2msec, akkor már nem prelleg, felhasználható az aktuális állapot.Én a legutóbbit haszánlom leggyakrabban, mert ehhez nem kell megszakítás, és ha a loop() nem katasztrofálisan lassú akkor stabil és jó megoldás. (még enkóder is kezelhető így, gyakorlatilag hibamentesen). Arra pedig mindíg érdemes törekedni, hogy a loop a lehető leggyorsabb legyen, (azaz pl. amennyire csak lehet kerüljük a delay()-t, és az egyéb lassú függvényeket).
-
ekkold
Topikgazda
válasz
Janos250
#19861
üzenetére
Sokszor hasznos a pointerek használata, ugyanis (ha jól van megírva a program) akkor hatékonyabb kódot fordít belőle a fordító. Pl. nem ugyanúgy fordul le ha a ciklusváltozóval indexelsz egy tömböt, vagy helyette egy pointert növelsz a ciklusban. Bár az újabb fordítók (beállítástól függően) olyan mértékben is tudnak optimalizálni, hogy ha szándékosan rosszul írom meg a kódot, akkor is ugyanaz fordul belőle, mint egy hatékonyabb forráskódból. Néha viszont a túlzott optimalizálás elrontja a kódot. Ha viszont erre is MI-t használunk majd egyszer, ami értelmezi, hogy "mi a fenét akart a költő", akkor onnantól ez az egész elveszti a jelentőségét (tartok tőle, hogy ez nincs is olyan messze).
-
ekkold
Topikgazda
-
#19561
ekkold
Topikgazda
Harcipocok84
#19559
ekkold
Topikgazda
válasz
Harcipocok84
#19559
üzenetére
Nem mondanám, hogy rutinos vagyok PID -ben, de a forrasztóállomásomban leprogramoztam a PID szabályzást - és egész jól sikerült.
-
ekkold
Topikgazda
Igen lehet ilyen "trükkökkel" gyorsítani egy programot, de ez processzor függő is.
Pl. a BluePill (STM32F103) a legtöbb utasítást egyetlen órjel alatt végrahajtja, tehát a feltétel kiértékelés, vagy éppen egy változó ellenőrzése ugyanúgy egyetlen órajel idejéig tart (14 nanosec).Csak érdekességképpen az ESP procik lassabban olvassák a flash-t mint az STM (és a programkód a flas-ból fut), emiatt ez utóbbi annak ellenére gyorsabb, hogy alacsonyabb az órajele. Amikor elkezdtem használni a BluePill-t, meg is lepett, hogy mennyire gyors (főleg egy arduino-hoz képest). Ráadásul hardveres szozó/osztó modulja van így az esetek nagy részében az is egyetlen órajel. Ez anyit jelent, hogy a kódban pl. szorzás helyett bitléptetést használva (vagy fordítva) ugyanolyan sebességgel fut a program. De mondjuk Atmega proci esetén (pl. arduino nano) hatalmas sebességkülönbség van a két módszer között. Ez utobbi esetében a szorzás/osztás esetén gyakorlatilag egy ciklusnak kell lefutnia a prociban.
-
ekkold
Topikgazda
válasz
tibi-d
#19360
üzenetére
Ha a feltételek egymást kizáró relációban vannak, akkor kérdés a gyorsaság
Ebből a szempontból nézve is a második verzió a gyorsabb.
Viszont akkor lehetne if()....else.... ágat létrehozni, hogy a harmadik feltételt ne is vizsgálja ha a második teljesült. Ez még egy hajszálnyit jelenthet sebességben. -
#19349
ekkold
Topikgazda
razorbenke92
#19347
ekkold
Topikgazda
válasz
razorbenke92
#19347
üzenetére
Amúgy szerepel a 18650-es akksik adatlapján, hogy meddig lehet kisütni, károsodás nélkül?
Pl. fehér lehet üzemeltetek 18650-es celláról ami kb 3V-ig tudja kisütni, utána meredeken csökken a fényerő. Eddig úgy gondoltam, hogy ez így rendben is van - vagy mégsem? -
#19331
ekkold
Topikgazda
Harcipocok84
#19330
ekkold
Topikgazda
válasz
Harcipocok84
#19330
üzenetére
Az EEPROM kb. 10^6 irást bír ki (egymillió). Az olvasás nem számít, akárhányszor olvasható. Megsérülni akkor tud a tartalma, ha írás közben fogy el a táp.
Ha reprodukálható a hiba, akkor azért a szoftverhiba is esélyes. Az EEPROM-ba mentéshez szoktam definiálni egy struktúrát a mentendő adatok számára, ezt használva gyakorlatilag nem lehet elrontani a címzést sem.
-
ekkold
Topikgazda
Még annyit, hogy az ajax tulajdonképpen nem más mint egy javascript-ből indított fájl lekérdezés vagy letöltés. Tulajdonképpen mindenféle könyvtár nélkül sem bonyolult használni.
Meg aztán manapság a websocket talán elegánsabb megoldás, csak ahhoz szerveroldalon kell többlet (websocket szerver, ami amúgy van ESP-re is). -
ekkold
Topikgazda
Amikor készült, éppen hiánycikk volt a BluePill, nekem meg volt egy jópár eredeti STM32F101 procim, ami elvileg gyengébb mint az STM32F103 - de a gyakorlatban kiderült, hogy valójában ugyanaz a proci csak más típusjellel adták el (néha csinál ilyet gyártó). Ezek a procik egy annyira szerencsés szériából voltak, hogy még "húzatók is". 3,3V-ról, még 128MHz-en is vígan működött mindegyik amelyiket próbáltam. Ráadásul Elvileg 64K flash van bennük (ezt "mondja magáról" a proci), de szoftverből 128k-ig tartó területre is tudtam írni, és vissza is olvashatók az adatok. Így aztán terveztem hozzá nyákot, amit kínában legyárttattunk, aztán megtanultam beforrasztani (mikroszkóp latt) a procikat. Anyagilag persze nem igazán éri meg a ráfordított munkaidő miatt, de hobbi projektnek nagyon jó volt, mert szépen működnek, és tanultam is belőle.
Amúgy kíváncsiságból kínából rendelt BluePill-eket is próbáltam kicsit húzni, nagyjából 104MHz-en még mentek, felette fagyás.... (a névleges órajel 72MHz)
-
ekkold
Topikgazda
Ha jobban megnézed az adatlapot, a Vin-el összekötés csak egy lehetőség, amúgy az EN láb 1,2V felett bekapcsolja az LDO-t.
Ezt úgy érdemes, hogy pl. egy kondi vagy RC tag felhúzza egy időre az enable lábat, amikor a Vin megjelenik, majd az MCU elindul és bekapcsolva tartja, pl. egy diódán keresztül. Ha az MCU később L szintre állítja az adott lábat, akkor kikapcsol az egész áramkör.
Az indításkor használt kondi egy gombbal kisüthető - ez lehet pl. egy bekapcsoló gomb, de olyan áramkör is készíthető ami mondjuk adott feszültség felett bekapcsolja. -
-
ekkold
Topikgazda
Lényegében egy spéci "stabkocka", csak tud pár extrát.
Pl. van engedélyező bemenete, ha kikapcsolod, akkor közel nulla lesz a fogyasztása.
"A 3,3V verzió azt jelenti, hogy ha rákötök egy Li-ion cellát, 4,2V-tól 3,3V-ig leadja a 3,3V-ot, ha a cella 3,3V alá merül, akkor a kimeneti feszültség is megy vele?"
Igen, majdnem pontosan így, de 3,3V alatt esik rajta egy kicsi (áramfüggő) feszültség. A bemenő feszültsége 2,5V - 5,5V közötti lehet.
Az engedélyező láb használható akár akksi mélykisütés védelemhez, pl. ha mondjuk az MCU-val vezérled, és az méri az akksi feszültségét. -
ekkold
Topikgazda
válasz
ReFleXx
#18352
üzenetére
MIC5501 - többféle feszültségű és tokozású verzió létezik.
Nem tudom belefér-e: 38uA fogyasztása van
300mA-nél 160mV feszültségesés rajta, de mivel FET a szabályozóelem benne, ezért kisebb áram esetén arányosan kisebb a maradékfesz.
STM32-höz használtam 3,3V-os verziót, annak 40mA körüli a max fogysztása, így 21mV körüli maradékfesszel is elműködik.
[link]
Összességében nekem bevált.
_Completa.gif)
Új hozzászólás Aktív témák
Hirdetés
- Hivatalos a OnePlus 13 startdátuma
- Veszprém és környéke adok-veszek-beszélgetek
- Kerékpárosok, bringások ide!
- A fociról könnyedén, egy baráti társaságban
- TV antenna és jelerősítés
- Samsung Galaxy S23 és S23+ - ami belül van, az számít igazán
- Anime filmek és sorozatok
- Anglia - élmények, tapasztalatok
- AliExpress tapasztalatok
- Fogyjunk le!
- További aktív témák...
- ÁRGARANCIA!Épített KomPhone i5 12400F 16/32/64GB RAM RTX 4060 Ti 8GB GAMER PC termékbeszámítással
- Telefon felvásárlás!! iPhone X/iPhone Xs/iPhone XR/iPhone Xs Max
- ÁRGARANCIA!Épített KomPhone Ryzen 5 7600X 16/32/64GB RAM RTX 4060Ti 8GB GAMER PC termékbeszámítással
- Bomba ár! Dell Latitude E6520 - i7-2760QM I 8GB I 256SSD I Nvidia I HDMI I 15,6" HD+ I W10 I Gari!
- 3DKRAFT.HU - 3D NYOMTATÁS - AZONNALI ÁRAJÁNLAT - GYORS KIVITELEZÉS - 480+ POZITÍV ÉRTÉKELÉS
Állásajánlatok
Cég: Promenade Publishing House Kft.
Város: Budapest
Cég: CAMERA-PRO Hungary Kft
Város: Budapest