- iPhone topik
- Motorola Edge 50 Neo - az egyensúly gyengesége
- Google Pixel topik
- Profi EKG-s óra lett a Watch Fitből
- Magyarított Android alkalmazások
- Mobil flották
- One mobilszolgáltatások
- Magisk
- Samsung Galaxy Watch5 Pro - kerek, de nem tekerek
- Samsung Galaxy S23 és S23+ - ami belül van, az számít igazán
-
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
-
_q
addikt
válasz
Teasüti
#9097
üzenetére
Igen beszéltük, hogy ugyan azon a csatornán kell legyen mindent. Előtte minden a kettesen volt, router + mind a kettő ESP, de az nem jó. Tehát ugyan azon a csatornára csatlakozás kevés, kimondottan az 1-es csatornán megy csak.
Igen pipa, úgy néz ki, de azért még tesztelem, hogy mennyire stabil és tényleg megy-e. Ezt leszámítva már csak kijelzőre kell küldeni az információt, illetve PCB-t tervezni hozzá. Köszönöm a segítséget mindenkinek
(Plusz opció: lehetne olyat, hogy a mért adatokat thingspeekre küldeni vagy más módon monitorozni, még meglátom.)
-
Teasüti
nagyúr
A megoldás az volt, hogy nem elég a két ESP-t 1-es csatornára tenni, hanem még a routert is 1-es csatornára kellett állítani. Más kombinációval sajnos nem működött.
Igen, azt hittem ezt már megbeszéltük korábban. ESPNow adhoc hálózatának és a WLAN-nak is egyazon csatornán kell lennie!
Így akkor ez most jó? Működik? Kipipálva ez a rész?Kíváncsi lennék egy BLE vs ESP-Now összehasonlításra, melyik lehet az energiatakarékosabb vajon.
-
_q
addikt
válasz
Janos250
#9095
üzenetére
Sajnálom, ha nem voltam követhető
Lényeg, hogy működik ESPnow + wifin keresztül routerre csatlakozás, onnan adat lekérés. A megoldás az volt, hogy nem elég a két ESP-t 1-es csatornára tenni, hanem még a routert is 1-es csatornára kellett állítani. Más kombinációval sajnos nem működött.
Jó a webserver-kliens is, ha nem kellene fix IP címmel dolgozni, ahol már UDP is szóba jön, legalább is NTP adat lekérésnél kell UDP is. Onnantól, hogy fix IP cím van és UDP függvényeknél is megjelenik az
IPAddressosztály, onnantól nem működik sajnos az NTP. Legalább is nekem nem sikerült megoldani. -
Janos250
őstag
Én már rég elvesztettem a fonalat, csak egyetlen megjegyzésem lenne:
Saját tapasztalat alapján az ESP32 8 (nyolc) clientet tud párhuzamosan kezelni.
Mondom ezt anélkül, hogy valaha is lementem volna a socket programozás szintjére. Én maradtam a WiFiServer, WiFiClient szintjén, oldják meg ők a socketek kezelését. -
_q
addikt
válasz
Teasüti
#9093
üzenetére
Jaa értelek már, akkor 3 db ESP32 kellene
viszont ez így már jónak kellene legyen, csak nagy helyet foglalna el a panelen.Akkor ezért nem nagyon találok Wifi+Bluetooth példákat, mert nem nagyon megy együtt a kettő
. Akkor ez is kilőve pedig szép és jó lenne ,ha menne együtt. Kezdem érezni az ESP korlátokat, pedig olyan jól hangzik, hogy mennyi mindent tud, viszont nagyon sok esetben ott van egy képzeletbeli vagy valóságos apró betűs rész, hogy "kivétel ebben és ebben az esetben nem tudja".ESNow esetén egyik eszköz STA másik AP módban van. Az STA esetemben a külső ESP lenne, ami alszik és 15 percenként felébred, adatot küld AP, benti ESP-nek majd visszaalszik. A router mint AP eszköz, arra csak az STA eszköz tudna csatlakozni, de ő meg egyszerre két helyre nem képes vagy a "szerverre" vagy a routerre csatlakozik. Legalábbis kommentek alapján, illetve próbálkozásaim alatt erre jutottam, hogy ez lehet az oka. Egy példát találtam, ahol MQTT szervernek küld adatot egy ESPnow eszköz. Lehet, hogy csak Channel 1-en működik ? A routerem 2-es csatornán kommunikál. Megnézem majd mi van, ha átteszem azt is 1-re. Igaz tesztelni NTP klienssel tudom csak, amúgy is az lenne a lényeges nekem.
Ahogy nézem akármilyen vezeték nélküli eszközt választanék, nem úszom meg olcsón, akár RF, BT vagy egy 3. ESP32 is legyen az. Lehet jobban járnék az RTC modullal.
(Vicces mert az elején úgy indultam el, hogy valami összetettebb feladatot szeretnék, ne végezzek vele 2 hét alatt. Erre jött ez a hőmérő-óra projekt, gondolván nincs más jó lesz ez, nem baj ha hamar végzek vele. Erre....a legegyszerűbb dolgok tartanak legtovább Persze nem haszontalan amiket próbáltam, azokat is jobban ismerem legalább most már, de nem számítottam rá, hogy ennyi fejtörést okoz 2 ESP32 közötti kommunikáció.) -
Teasüti
nagyúr
Úgy értettem, hogy egy ESP32 duóval megoldani a gateway-t. Szenzor alatt meg a vezetéknélküli másik ESP-t értettem. Vagy használhatsz egy külső BT modult a gateway-en, pofon egyszerű programozni sima UART-vel kommunikál. A belső wifi-t meg netre ráállítani. Így nincs RAM limit se, mivel sima UART használat van csak, nem kell betölteni a BT könyvtárat. Igaz ez már nem BLE, hanem classic BT.
(Ha meg BLE modult használsz, annak meg lesz saját könyvtára amit megint csak be kell tölteni és vagy befér a ram-ba, vagy nem.)
Passz. BLE+Wifi ram korlátba ütközik, ez nem működik még natívan sem jelenleg.
ESPNow+Wifi viszont érdekes, annak elvileg mennie kéne. -
_q
addikt
válasz
Teasüti
#9085
üzenetére
Mindenképpen 2 db ESP32-t akarok használni. Egyik kinti hőmérséklet mérésre, másik benti mérésre + kijelzésre. Sajnos a vezetékes kommunikáció ezért nem lehetséges. Ha nem akarnék NTP időadat alapján dátumot, akkor nem lenne gond egyik megoldással se amit eddig próbáltam (socket szerver, ESPnow), de nem szeretnék RTC modult pluszban, ha megoldható az NTP adat lekérése is. Így jelenleg a bluetooth maradt amit javasoltál, megpróbálom így. (RF modul vagy külső BT modul lehetne még opció, de ott is plusz elektronika kellene,. Ha már az ESP tudja a bluetooth wifi kombót, jó lenne ki is használni
). -
-
#9088
DrojDtroll
veterán
DrojDtroll
veterán
Lehet valahogyan egy virtuális arduino mikrokontrollert programozni? Léteznek emulátorok?
Fontos lenne, hogy soros porton elérjem a virtuális eszközt.
-
Teasüti
nagyúr
válasz
Tankblock
#9080
üzenetére
Nem figyeltem erre, viszont úgy veszem észre lassan a beágyazott rendszereknél is kezdődik, hogy egyre olcsóbbá válik az erőforrás, ami a programozás rovására megy. Pl egy Uno esetén a 32KB Rom-ot és 2KB Ram-ot alaposan be kellett osztani, viszont egy ESP32-nél azért a 4MB flash-nél és az 512KB Ram-nál annyira mindegy szerintem, hogy használunk-e String-eket, vagy sem.
-
_q
addikt
Teasüti javaslata alapján utána néztem az ESPNow-nak. Sajnos nem tud egyszerre két eszköz kommunikálni + még netre is csatlakozni. Külön 2 eszköz kommunkációja ment. AP+STA mód kellene, de azt írták, hogy az ESP32-be egy rádió adó van, tehát ugyan azon a frekvencián tudja szórni az AP és STA jelet is. Ezért is SoftAP a neve annak amire képes. AP+STA mód estén, ha van egy router akkor STA módba lesz konfigurálva és úgy megy, ha nincs akkor pedig AP módban. Esetleg menet közben lehetne AP és STA között váltogatni, de azt nem próbáltam.
Megpróbálkozok még a bluetooth wifi kombóval hát ha megy. -
JozsBiker
aktív tag
Sziasztok !
Szeretném logolni egy búvárszivattyú működését, amihez áramérzékelőt használnék. Alapvetően kétfélét találtam: Hall érzékelőset ( ACS712 ) és tekercseset ( ZMCT103C ). Ez utóbbi szimpatikusabb volna üzembiztonság szempontjából, mert a szivattyú tápját nem kellene a panelen megjáratni, csak átvezetni a tekercs közepén. Viszont érdekes módon erről az érzékelő típusról gyakorlatilag semmi konkrétumot nem találni a neten. Pl. azt sem tudom miért van 4 kivezetése. Esetleg valakinek infója ? Köszi.
-
Janos250
őstag
válasz
Teasüti
#9076
üzenetére
"Ti tudtátok, hogy a Stream osztályban ilyen függvények vannak, hogy readStringUntil(), parseInt(), stb?"
A HardwareSerial.cpp-ben ez van:
HardwareSerial Serial(0);
Vagyis a HardwareSerial típusú Serial objektum tőlünk függetlenül "automatikusan" létrehozásra kerül.A HardwareSerial.h-ban viszont ez van:
class HardwareSerial: public Stream
Vagyis a HardwareSerial osztály örökli a Stream osztály public és protected tagfüggvényeit, adattagjait.A Stream.h-ban viszont ez van:
class Stream: public Print
Vagyis a Stream osztály meg örököl a Print osztálytól, így közvetve a HardwareSerial is örökol a Print osztályból. Ezért lehet pl. Serial.print() és még egy csomó.A readStringUntil az a Stream osztályból öröklődik, szintén egy csomó egyébbel együtt.
Célszerű végigbogarászni a
HardwareSerial.h
Stream.h
Print.h
fájlokat, kincseket lehet bennük találni.Ezért értelmesek pl. az alábbiak:
Serial.available();
Serial.read();
Serial.peek();
Serial.flush();
Serial.setTimeout(1000);
Serial.find("vege");
Serial.find(10);
Serial.find("vege",10);
char c ;
Serial.find(c);
char charBuffer[20];
Serial.readBytesUntil(c,charBuffer,10);
uint8_t uint8_tBuffer[20];
Serial.readBytesUntil(c,uint8_tBuffer,10);
String str1;
str1 = Serial.readString();
str1 = Serial.readStringUntil(c); -
Tankblock
aktív tag
válasz
Teasüti
#9079
üzenetére
nem a
stream(stream)programkód azt jelenti hogy amikor inicializálod akkor a bejövő cím értékét bemásolja a class stream nevű változójába.
[Member initialization in constructors]
Sztem a stream object nincs definálva, hol lehet megnézni a könyvtárat?
-
Tankblock
aktív tag
-
Teasüti
nagyúr
Tudnátok segíteni kicsit, hogy library írásnál, hogy tudnék átadni egy Stream osztályt paraméterként?
Megnézve egy példát ezt látom, de nem tudom értelmezni. Nem láttam még ilyen szemantikát:class TinyGsmSim808: public TinyGsmSim800
{
public:
TinyGsmSim808(Stream& stream)
: TinyGsmSim800(stream)
{}Ez most mit jelent?
A TinyGsmSim808 osztályban a TinyGsmSim808 konstruktor alatt mi az a kettőspont és utána a TinyGsmSim800 függvény? A függvény meghívást nem a kapcsos zárójelek közé kéne tenni?Aztán tovább menve arra a függvényre ezt látom:
public:
TinyGsmSim800(Stream& stream)
: stream(stream)
{
Olyan függvény viszont nincs sehol definiálva, hogy stream().
Ez az egyetlen előfordulása így ebben a formában.Viszont nem értem mi történik itt pontosan a stream objektummal, amit egymásnak adogatnak át a függvények.
Ugyanitt lejebb a library függvényeiben viszont már ilyeneket látok, hstream.readStringUntil(',')Nem látom illetve nem értem hogy jutottunk el a konstruktortól odáig, hogy már hivatkozunk a konstruktornak átadott objektumra.
Szóval hol kerül definiálásra a "stream" objektum, amit a függvénymeghíváskor használunk? Vagy amikor lefut a konstruktor és a benne lévő (Stream& stream), akkor ezzel már definiálva is van? Nem kellene vmi parancsot használni külön a kapcsos zárójelben? A (Stream& stream) nem egy helyi változóként működik? Elérhető marad a teljes library-ben? -
Teasüti
nagyúr
Ahogy nézem már írnak ezekről a Serial osztályban is. Hmm, meg mernék esküdni rá régen nem volt ennyi függvény ebben. Viszont üdvözítő újítások! Ha már úgyis Stream osztályt kell használni String-ekkel, akkor legalább natívan oldja meg a feladatot, ne kelljen külön ramot foglalni a saját függvényekhez!
-
_q
addikt
válasz
Teasüti
#9075
üzenetére
Igen valami ilyesmi, pontos szakszavakkal leírt megfogalmazást én se tudok.
(#9076) Teasüti
Igaz nem stream, hanem socket client esetén hasonlóan jártam, char-ba olvassák ki a fogadott adatot. Először én is a nehezebb úton indultam el, mire megtaláltam a readStringUntil('\n') opciót, ami string-ben olvas be. Érdemben sajnos nem tudok a stream-hez hozzá szólni. -
Teasüti
nagyúr
Ti tudtátok, hogy a Stream osztályban ilyen függvények vannak, hogy readStringUntil(), parseInt(), stb?
Én meg egészen idáig char változóba olvastam ki mindent és magamnak szenvedtem össze ciklusos függvényeket az adatok értelmezésére amikor az egészet le lehet rendezni pl. ennyivel:stream.readStringUntil('\n').toInt();. Timeout meg astream.setTimeout()-tal állítható. Mondjuk azt nem tudom ez kód blokkolja-e a futtatást.
Bezzeg a Stream osztállyal eddig egyetlen egy Arduinós példa megoldást sem láttam, mindenki csak aSerial.available()ésread()függvényeket használja vmilyen char változóval az adatfogadásra.
-
Janos250
őstag
"Akik minimum 2 db ESP32-t használnak és ezek egymással kommunikálnak (hogyan teszik, Bluetooth, ESPNow, más?), plusz netre is akartak csatlakozni esetleg, ők milyen lehetőséget tudtak használni? "
Mint már többször írtam, nekem neten lóg egy szerver, ahova be lehet jelentkezni az egyik porton, és egy másik porton megy a http lekérdezés, hogy kiféle, miféle van épp bejelentkezve. Ez nem javaslat, csak infó.
-
_q
addikt
válasz
Tankblock
#9072
üzenetére
Arduino alatt is lehet használni az idf függvényeket, miért jobb szerinted ha arduino teljesen ki van hagyva? Az IDE sajnos nem a legszélesebb körben használható program. Azt sajnálom én is hogy egy STM32-es Kiel-hez vagy AVR studiohoz képest "butább" program. Sok hasznos funkciót elbírna még, de valószínű annyira hobbistáknak van kitalálva, hogy egy komolyan fejlesztőkörnyezet adta lehetőséget aki hobbi szinten programozik, ők nem hiányolják. Igaz én is hobbi szinten vagyok még is hiányolok sok funkciót
(#9068) Teasüti
Nézegettem a bluetooth + wifi használatot. Erre is azt írják githubos kommentek, hogy sajnos nem nagyon megy együtt, mert elfogy a RAM.
Valamit ki kell találjak, mert jelenleg a socket szerver még se lesz jó. NTP szerveren keresztül akartam dátumot lekérni, ami UDP-n keresztül kommunikál. Ha a socket szervernek statikus IP-t adok, akkor arra jutottam, hogy bezavarhat az UDP-nek, mert nem frissül az idő adat. Ha nem statikus IP-t használok akkor jó, viszont a socket kliens ki tudja mikor gondol egyet és nem tud csatlakozni. Jelenleg fix IP-t adok a szervernek, a kliensbe beírom erre csatlakozzon és megy is. Ha kihagyom ezt a fix IP dolgot, félek bármikor előjön egy csatlakozási probléma, amikor nem tudja a kliens hova csatlakozzon. Nem gondoltam, hogy ennyi problémás lesz.Akik minimum 2 db ESP32-t használnak és ezek egymással kommunikálnak (hogyan teszik, Bluetooth, ESPNow, más?), plusz netre is akartak csatlakozni esetleg, ők milyen lehetőséget tudtak használni? Nem gondolnám, hogy én vagyok az első aki ilyet szeretne csinálni.
-
Tankblock
aktív tag
Hello,
nem örültem meg, még,
esp-idf használom és néha megyek a development pathra néha meg a latest release pathra. Van róla rendes guide meg How to.... Nem oly ördöngős. Gitről meg lehet vadászni eléggé jó könyvtárakat is hozzá.
De igen volt rá példa h nem volt driver és hát nem maradt más hátra csak a technical reference....
Amúgy annyira nem kínai, sztem még az aurduino core is belerakható. Van kódkiegészítés, C++ hoz függvényekhez support. Refraktorálahtod a kódot. Megmuattaja hány helyen használod. Próbál írási időben segíteni.... (csak nem nekem :-P)
Az arduino ide-nek itt még van hova fejlődnie. -
_q
addikt
válasz
Teasüti
#9068
üzenetére
Itt írnak róla. Van ahol azt írják ugyan azon a csatornán kell legyen ESPnow és a wifi csatlakozás, de a kommentek nagy része arról számol be, hogy nem megy együtt a kettő. Én nem próbálkoztam, így saját tapasztalatom nincs. Lehet egy próbát megérne. A bluetooth-t nem tudtam mennyire működőképes jelenleg önmagában, illetve wifivel együtt. Tehát ezt a kettőt meg lehetne próbálni még, azért a socket server-client irányba mentem, mert ehhez egyből volt minta kód mindenféle negatív komment nélkül és biztosra akartam menni.
(#9069) Tankblock
Bizony arduino core, illetve idf függvényekkel néha kiegészítve![;]](//cdn.rios.hu/dl/s/v1.gif)
Eclipse alatt regiszter szinten programozod?Köszi a tapasztalatot,úgy látom érdemes áttennem másik csatornára a routert, de akkor be kell látni, hogy sok wifi között előfordulhat veszteség.
-
Teasüti
nagyúr
válasz
Tankblock
#9069
üzenetére
Szerintem itt te vagy az egyetlen, aki natívan programozza az ESP-t.
Annó én is csak azért akartam megpróbálni, mert akkoriban az Arduino Core-ban még nem volt benne, ami nekem kellett. Viszont én már megakadtam a programozó környezet beállításánál. Arduino IDE után egy Eclipse nekem kínai. Hobbi szinten nem is tartok rá igényt. Persze gondolom más lenne a helyzet, ha lenne IT végzettségem. -
Tankblock
aktív tag
válasz
Teasüti
#9068
üzenetére
ugye nem az arduino esp32 core-t használjátok?
Én azt csak feltettem hogy éegyen, de 1 példánál többnél nem töltöttem vele időt. Inkább eclipse alatt küzdök.
nekem ment minden a 0 magra , akkor sem volt problémám....
Van egy elméletem, hogy az arduino implementációban van valami kehe.....A kapcsolat sosem lesz tökéletes ezzel együtt kell élni, és kezelni kell. Azt a design során kell eldönteni, hogy az adat fontos-e annyira h újrküldjük vagy sem. Ha igen akkor azt tárolni kell, amíg ki nem ment.
A BlueFi implementáció még nem tudom milyen formában van. Én a MESH networköt várom mint a messiást és a MQTT brokert, ha 1 implementációba bekerül és kapunk még 1 gateway nodot is akkor mindenre gombot vartunk......
Addig marad a BLuetooth mesh akinek nagyon kell NRF chippekkel.....
az említett hálózati túltelítettség végett nálam a router is a gyenge láncszemek közé tartozik, hajlamos eldobni az összes Wifi kapcsolatot és reportálni h minden jó. A wirelessben meg 0 becsatlakozott elem van.......
-
Teasüti
nagyúr
ESPNow miért nem jó? Úgy olvastam, ha ugyanazon a csatornán megy, mint a normál wifi, akkor tud párhuzamosan mindkettőn kommunikálni.
Amúgy BLE-re nem gondoltál még? Sztem adja magát, gyakorlatilag erre van kitalálva, hogy szenzor adatokat küldözgessünk vele elemes kis fogyasztású eszközöknél. Mondjuk azt nem tudom, hogy a BT és a Wifi együtt működik-e. Wifi-s projektem még nem volt.Amúgy Core 0-s hibákat nálam a nagyobb delay() oldotta meg, de újabban inkább csak olyan műveleteket indítok azon a magon, ami egy meghívásra csak egyszer fut le. Minden ciklikus folyamat az 1-es magon van.
-
_q
addikt
válasz
Tankblock
#9066
üzenetére
Van esetleg javaslatod, ami stabilabb kapcsolatot tud vagy ez nem a websocet miatt van? 2 eszköz lenne, a szerver lekér NTP adatot netről, mér, kijelez. A másik eszköz a kliens, aki csak mér és küldi a szervernek az adatot. ESPNow sajnos nem jó a szükséges netről adat letöltés (később lehet adat feltöltés) miatt. Vagy törődjek bele, hogy ez nem lesz olyan stabil, mint egy SPI vagy I2C kommunikáció és inkább jobban járok, ha lekezelem az említett kommunikációs problémát egy adat újraküldéssel mondjuk?
-
-
_q
addikt
válasz
Janos250
#9064
üzenetére
Megpróbálom majd a delay-t magasabbra tenni. Nem AP módban hozom létre a szervert, hanem fix ip és router beállításokat használva (socket server kiegészítve fix IP-vel), így szerintem a linkelt függvényt nem tudom használni. Ha jól sejtem, akkor wifi socket szerver-kliens esetben a routeren tudom átállítani a csatornát, mivel jelen esetben az az AP.
"Nálam az egyik projekt egy erősen "zajos" wifi környezetben gyakran hibázik, de kisebb forgalmú helyeken hibátlan. "
A zajos környezet jelentheti azt, hogy kb. 9-10 elérhető wifi hálózat van körülöttem? Megnézem majd hogyan alakulnak a wifi csatornák, lehet az ESP pont egy sokak által használt csatornán kommunikál és ebből adódik időközönként a kommunikációs probléma. -
Janos250
őstag
"Ezt úgy érted, hogy mindegy hogy én a bemásolt task-ot core 0 vagy core 1-re teszem, a wifi fogadása mindenképpen a core 0-án, a háttérben történik? Tehát ha én egy client.read vagy client.readStringUntil meghívást csinálok, akkor már nem a klienstől fog olvasni, hanem egy már háttérben beolvasott bufferből szedi ki az adatot? "
Igen, én így tudom.
"a core 0-ra nem tehetek semmit?"
Én szoktam, ez csak egy ötlet volt, hátha..
Vagy szintén csak ötlet, a delay(10) megnagyobbítása mondjuk 100-ra. Tudod, kísérletes tudományKözben itt töprengek.
Ha jól emlékszem, az ESP az 1-es csatornán forgalmaz. Esetleg más csatornán? Úgy rémlik, valahol azt is meg lehet adni, de nem emlékszem pontosan, hol.
Nálam az egyik projekt egy erősen "zajos" wifi környezetben gyakran hibázik, de kisebb forgalmú helyeken hibátlan. Tudod, csak ötletek, kellő kritikával fogadd!Közben megtaláltam:
bool softAP(const char* ssid, const char* passphrase = NULL, int channel = 1, int ssid_hidden = 0, int max_connection = 4); -
_q
addikt
válasz
Janos250
#9062
üzenetére
0-ás magra raktam a wifi kliens fogadás taskot 0-ás prioritással. Semmi más nem fut rajta, legalább is általam nem, max a háttérben amiről korábban írtál 6-7 task a rendszer által futhat esetleg. A kód elkészültével a végén csak 5-10 percenként akarom hogy hőmérséklet adatot küldjön a kliens (jelenleg 2-10 másodpercekkel teszteltem), de elkerülve, hogy pont akkor történjen más művelet, mikor pont jönne a klienstől adat, minden mást a core 1-re tettem. Az hogy leterhelném a cpu-t nem gondolnám, a fogadáson kívül 1-2 konverziót csinálok csak, de azért bemásolom ide is:
void wificlientTask( void * parameter)
{
unsigned long CLIENT_TIMEOUT = 0;
int idxBatLevel = 0;
int idxTemp = 0;
int i = 0;
while(1)
{
WiFiClient client = wifiServer.available();
if (client) {
CLIENT_TIMEOUT = millis();
while (client.available() == 0) { //itt jon a hiba, timeout-al valtozo idokozonkent
if((millis() - CLIENT_TIMEOUT) > 10000) {
Serial.println(">>> Client Timeout !");
client.stop();
break;
}
}
if (client.available()) { // if there's bytes to read from the client,
String clientData = client.readStringUntil('W');
clientData = clientData + 'W';
Serial.println(clientData);
client.stop();
idxTemp = clientData.indexOf('Y'); //get the index of Y separator (25.47Y)
idxBatLevel = clientData.indexOf('W'); //get the index of W separator (3.12W)
clientTemp = clientData.substring(0, idxTemp); //25.47
clientBatLevel = clientData.substring(idxTemp+1, idxBatLevel); //3.12
Serial.print("temp: "); Serial.println(clientTemp);
Serial.print("bat: "); Serial.println(clientBatLevel);
delay(10);
}
else{
Serial.print("temp: "); Serial.println("-");
Serial.print("bat: "); Serial.println("-");
Serial.println("");
}
}
delay(10);
}
}A javasoltak alapján átraktam a változó deklarálást az elejére, hogy csak 1x történjen meg, ne minden ciklusban, illetve a client.read-et lecseréltem, hát ha az okoz gondot, de nem. (Egyébként érdekes mert én 11 karaktert küldök, még is 12-re kellett a tömböt létrehozzam a client.read-né még. client.print küldésnél a végére betesz valamilyen jelző bitet, \r, \n vagy valamit?)
"A wifi vétel elvileg pufferelt, és a 0-ás magon fut. "
Ezt úgy érted, hogy mindegy hogy én a bemásolt task-ot core 0 vagy core 1-re teszem, a wifi fogadása mindenképpen a core 0-án, a háttérben történik? Tehát ha én egy client.read vagy client.readStringUntil meghívást csinálok, akkor már nem a klienstől fog olvasni, hanem egy már háttérben beolvasott bufferből szedi ki az adatot? Tegyük fel működik, hogy átteszem core 1-re a kiolvasást. Akkor a core 0-ra nem tehetek semmit? A core 1-en van ntp lekérdezés, hőmérséklet olvasás, kijelző és még a wifi kliens olvasás is ide kerülne, nem lesz ez sok a core 1-en? A 4 taskból a wifi lekérdezést ezért akartam core 0-ra tenni, hogy még is zökkenőmentesen menjen, mert a core 1 ami igaz nem időkritikus de már így is 3 taskot futtat. -
_q
addikt
válasz
Tankblock
#9060
üzenetére
Szia,
Jelenleg ezt próbálgatom, de ugyan az az eredmény, küldés fogadás között valami történik, mert a szerver nem kapja meg, időközönként timeoutot kapok a while ciklusnál. Valamiért nem csatlakozik a kliens, pedig a kliens serial monitoron nézve kiküldi az adatot, majd elmegy aludni.
WiFiClient client = wifiServer.available();
if (client) {
CLIENT_TIMEOUT = millis();
while (client.available() == 0) {
if((millis() - CLIENT_TIMEOUT) > 10000) {
Serial.println(">>> Client Timeout !");
client.stop();
break;
}
}
if (client.available()) { // if there's bytes to read from the client,
String clientData = client.readStringUntil('W');
clientData = clientData + 'W';
Serial.println(clientData);
client.stop();
... -
Tankblock
aktív tag
Hello
itt a
void loop() {
// listen for incoming clients
WiFiClient client = server.available();
if (client) {
Serial.println("new client");
// an http request ends with a blank line
boolean currentLineIsBlank = true;
while (client.connected()) {
if (client.available()) {
char c = client.read();
Serial.write(c);
....itt hasonló módon nézi meg ugyanazt.... én nem vagyok híve a túl sok változó újrainicializálásnak....
-
_q
addikt
válasz
Janos250
#9058
üzenetére
Köszi. A küldés monitorozást megcsináltam és ott minden rendben volt, valami a szerver oldalon van. Arra jutottam hogy a
while(client.available())
{
....
}okozza. Nem jól programoztam le a fogadott adat kiíratását. Így mikor küld a kliens, de a szerver nem tudja fogadni, akkor egy W bentmaradt és azt írja ki illetve üres sort, hogy nincs adat. Így már csak az maradt kérdés, vajon miért nem sikerült továbbítani a kliensnek az adatot. 10 db wifi hálózat érhető el , lehet bezavarnak egymásnak és teljesen normális az, hogy nem mindig sikerül a kliensnek wifi routeren kersztül a szervernek elküldeni az adatot?
-
Janos250
őstag
Én mit néznék meg először:
1. Kiíratnám serialre azt az adatot, amit el akarok küldeni
2. Hogy a szenzor biztosan elvégezte-e a mérést. Nem tudom, milyen szenzor, de van, aminél kiadom a mérés parancsot, utána várni kell egy kicsit, mire tényleg olvasható.
De ez csak egy halk tipp. -
_q
addikt
Köszi a tippet és (#9056) Janos250-nak is. Nem konkrétan ezzel a sorral volt a gond, de a read_raw-hoz manuálisan hozzá adom a 'W'-t pár sorral lejjebb és ott már nem kellene az i indexet tovább léptetni, amit én viszont megtettem, így ott valóban túllépte a tömb a max elemszámát. Most ez a része kb. 20 perces futás alatt nem dobott hibát, cserébe ugyan itt előjött más
Ez a hiba. A serial monitoron jön egy 0-s index, illetve egy üres sor, mint ha nem küldene semmi adatot a kliens, majd amikor szétbontom a hőmérsékletet és az aksi szintet, az aksi szint üres, a hőmérséklet egy W. Ezek alapján az látszik, hogy valószínűleg küld valamit a kliens, különben be se lépne a fogadás programrészbe a szerver, viszont csak egy W-t.
Lehet elveszik az adat küldés közben? Érdemes lenne szervertől visszaküldenem az adatot a kliensnek, megnézni egyezik-e ha igen akkor oké, ha nem akkor küldje ismét a kliens? Változó hogy kb. 10-20-30 küldésenként jön elő, a küldés 5 másodpercenként megy. -
_q
addikt
Sziasztok!
Úgy alakult, hogy kellene freertos kódot használjak. Van 4 task, ebből 1 db fut core 0-n a többi core 1-en. Jelenleg a 0-ra tettem egy wifi-s részt, ami figyeli a klienstől jön-e adat, ha igen akkor fogadja. Tettem bele delay-t is, de sajnos mindig előjön valami, ami miatt restartol az ESP32. A hiba ez lenne:
A kód ahol előjön a hiba:
void wificlientTask( void * parameter)
{
while(1)
{
String clientData;
char raw_data[11];
int i = 0;
int idxBatLevel = 0;
int idxTemp = 0;
WiFiClient client = wifiServer.available();
if (client) {
unsigned long CLIENT_TIMEOUT = millis();
while (client.available() == 0) {
if((millis() - CLIENT_TIMEOUT) > 10000) {
Serial.println(">>> Client Timeout !");
client.stop();
return;
}
delay(10);
}
while (client.available()) { // if there's bytes to read from the client,
char c = client.read();
if(c != 'W')
{
raw_data[i++] = c;
}
Serial.print(c);
delay(10);
}
}
}Lenne ötletetek, hogy mit kellene csináljak? Valami a
while (client.available()résznél lehet, valamiért mint ha beakadna. -
Teasüti
nagyúr
Innen:
(#9043) xboy89
Meg, megoldható. Ha rákeresel a témára, akkor rendre ilyen 2-3 méter limitekről számolnak be, ami még üzembiztosnak mondható a célnak megfelelő kábelezéssel.(#9044) Janos250
Hantek 6022BE.
De van egy kézi DIY szkópom is, ha csak gyorsan meg akarok lesni vmit, vagy nem tudom vinni a laptopot és az usb-s szkópot. Ez is tök jó cucc az áráért (feléért is meg lehet találni), bár csak 10 uS-ig tud lemenni, ami a több száz Khz-es jelekhez már kevés. -
Janos250
őstag
"Resistor selection varies with devices on the bus, but a good rule of thumb is to start with 4.7k and adjust down if necessary. I2C is a fairly robust protocol, and can be used with short runs of wire (2-3m). For long runs, or systems with lots of devices, smaller resistors are better."
"Since the devices on the bus don’t actually drive the signals high, I2C allows for some flexibility in connecting devices with different I/O voltages. In general, in a system where one device is at a higher voltage than another, it may be possible to connect the two devices via I2C without any level shifting circuitry in between them. The trick is to connect the pull-up resistors to the lower of the two voltages. This only works in some cases, where the lower of the two system voltages exceeds the high-level input voltage of the the higher voltage system–for example, a 5V Arduino and a 3.3V accelerometer."
-
Janos250
őstag
"The pullup resistors pull the line high when it is not driven low by the open-drain interface.
The value of the pullup resistor is an important design consideration for I2C systems as an incorrect value can lead to signal loss. In this article we show the simple equations for the pullup resistor calculation which the system designer can use to do quick calculations for their design."
http://www.ti.com/lit/an/slva689/slva689.pdf -
_q
addikt
válasz
Teasüti
#9040
üzenetére
Elnézést, ha nem egyértelműen fogalmaztam. Illetve a legvégén oda írtam direkt, hogy ha valami nem jó akkor egész nyugodtan javítsatok ki.
Igen nálad került szóba az I2C és mivel ott se voltam biztos benne, most se tudom az okát gondoltam megint szóba hozom és akkor kiötletelünk valamit. Most már akkor tudom legalább, hogy megoldható nagyobb távon is aminek örülök
-
tvamos
nagyúr
-
-
Teasüti
nagyúr
A jegyzőkönyv kedvéért: ESP8266 és az ESP32 is 5V toleráns a GPIO lábakon.
A mikrovezérlő mondjuk ha 8266-ot használsz és bírja az 5V-ot, akkor úgy leosztani hogy az AD konverterre max 5 V kerüljön de inkább kevesebb.
Erre írtam, hogy bírni bírja, de az AD konverter 3,3V felett nem mér. GPIO használatban nincs különbség a 8266 és 32 között.I2C kapcsán meg mérés nélkül nem lehet rá mondani semmi értelmeset. Amiben biztosak lehetünk, hogy abban a beállításban nem működik. Nekem úgy tűnt tényszerűen kezelted, ezért ugrottam rá.
Korábban is azt hiszem az én esetemben került szóba a dolog, azóta kellően utánajártam a dolognak. Főleg ha már 2 méteres buszt tervezek rajta 6 slave-vel.
-
_q
addikt
válasz
Teasüti
#9038
üzenetére
Nem ismerem az ESP8266-ot. Itt azt írták többen, hogy 5 V-ot tolerál, ebből indultam ki. De megjegyeztem, az ESP32-nél hogy ott 3.3 V a max. Én ESP32-t használok, oda írtam példának, hogy én 2 V-ra állítanám be az ellenállásosztót. Vagy én írtam kétértelműen vagy neked volt az, de a lényeg, hogy én csak viszonyszámokat írtam, hogy a max tolerálható feszültséghez képest hogyan válassza meg az ellenállásosztó értékét.
Máskor az ESP8266-ot inkább kihagyom példa esetén, nehogy hasonló félreértés legyen.I2C: alapból 10k felhúzó ellenállások voltak, a plusz random ellenállás csak egy próba volt, mert nem értettem miért nem jó a mérés és gondoltam felhúzó ellenállás pluszban segíthetne. A konklúzió szó helyett úgy mondanám, hogy leírtam egy tapasztalatot, ahogy azt már te is többször tetted. Mivel korábban szóba került az I2C és annak hatótávja ezért most egy friss tapasztalat alapján gondoltam megosztom, hogy akárhogy is van én hatótáv korlátba ütköztem. Nem mértem semmit, így igaz hogy a probléma okát nem tudom biztosra. Örülök, ha neked 10 méter se okozott gondot.
-
Teasüti
nagyúr
Már ne haragudj, de honnan veszed ezeket a blődségeket?
ESP32 és ESP8266 portjai 5V toleránsak, ez igaz. De ez nem azt jelenti, hogy üzemszerűen rá kell küldeni az 5V-ot egy 3,3V-os logikára. Az meg hogy éppen egy ADC-re kötnél be 4V-ot, az meg külön vicces: ugye az tiszta, hogy 3,3V-ig tud csak mérni az ADC?I2C-hez visszatérve: I2C amúgy nem igazán plug&play protokoll, a buszt minden esetben méretezni kell egyrészt vezetékezés szempontjából, másrészt a buszon lógó eszközök szerint.
Az, hogy próbapanelen random összedugdosol vmit random felhúzókkal, random vezetékekkel az vagy működni fog, vagy nem. Az meg hogy mérés nélkül egyből konklúziót vonsz és olyan kijelentéseket teszel, hogy 10 cm felett nem működőképes az I2C, az még jóindulattal is megmosolyogtató.Mellékesen nekem sikerült értelmezhető jelet kicsikarnom egy SI1145-ös szenzorból 10 méter vezetéken keresztül.
A SCL-re kellett berakjak külső felhúzót, ami kb 3k-s eredővel rendelkezik. SDA-ra nem is kellett külső felhúzó, illetve inkább csak rontott a jelen, mint javított volna.
Ami viszont fura, hogy 1k-s felhúzóval meg se mukkant a busz.Ha vki hozzáértő megnézi az alábbi képet, akkor a sárga jelnél mi az a két lépcsős emelkedés? Ha erősebb felhúzót rakok rá, akkor magasabb feszültségre fut ki a feltölés. Aztán vmiért meredeken ugrik fel a tetejére. Ezt a hirtelen ugrást nem értem. Lehetséges vmi áthallás a két csatorna közt? Mintha az SCL húzná magával az SDA-t, úgy tűnik.
-
Az ábrán megadott feszültségosztó ellenállás értékek alapján 4,2V akkufeszültség esetén pont 3,3V lesz a bemeneten, ez így jó, kivéve, ha az akksi teljesen feltöltve 4,2V-ot meghaladja. Igaz, hogy a FET-en is esik valamennyi feszültség, talán annyi elég, hogy véletlenül se menjen 3,3V fölé. Igaz, hogy a digitális kimenetek 5V toleránsak, de tudtommal az ADC nem az, így arra nem kerülhet a tápnál magasabb feszültség. De fixme, ha tévedek!
Én részemről a 976k-t kicsit kisebbre venném, biztos, ami biztos, itt utána is számolhatsz. -
Janos250
őstag
"Panasonic NCR18650B"
Jó választás, tényleg tudja 3000 mAh feletti értéket. Mértem."BSS670S2L"
Majdhogynem bármilyen NPN FET-et használhatsz, aminek nem magas a "Gate threshold voltage" értéke. Ez az a küszöbfeszültség, ahol a FET elkezd nyitni.
Pl. IRL sorozat. A tokozás lehet gond, mert a nagy áramúak TO220, a kisebb áramúak (pl. BSS670S2L) többnyire SMD. Attól függ, Neked melyik a jobb.
Lehet, hogy egy olcsó BS170 is megfelelne, de abban nem vagyok biztos. -
_q
addikt
Én ebayről vagy aliexpress-ről rendelném. Esetleg lehet keresni hasonló paraméterekkel alternatívát. ID, VGS, VGS(th), rDS(on) ezeket figyelve.
A feszültség osztót úgy értettem, hogy ha mondjuk laptop aksikat használsz akkor lehet lesz 6 V-od is akár. A mikrovezérlő mondjuk ha 8266-ot használsz és bírja az 5V-ot, akkor úgy leosztani hogy az AD konverterre max 5 V kerüljön de inkább kevesebb. Ha ESP32-t akkor meg max 3 V körül. Ellenállásosztó képlettel kiszámolható, hogy Ube = 6 V esetén, pl. Uki = 4 V, hogy véletlen se érjük el a GPIO-ra kapcsolható max feszültséget, marad R1 és R2, R1-et tetszőlegesen megválasztva mondjuk 10k, akkor R2 kiszámolható a belinkelt képlet átrendezésével.Az, hogy a max GPIO-ra kapcsolható feszültséghez képest mennyit választasz nem számít szerintem most, mivel nem uV az amit mérni szeretnél (persze 0.5 V-ot nem biztos érdemes). Lényeg hogy a végén a feszültség számításakor vedd majd figyelembe. Tehát ha számolod a feszültséget alapból úgy kellene, hogy (6V-os aksi esetén) 6*mért érék/4095 (12 bites AD-nél). Viszont az AD nem fog 6 V-ot mérni mert az ESP tegyük fel 5 V toleráns, le lesz osztva feszültség osztóval. Ezért az előbbi számításban a 6 V helyett 4 V-al kell számolni (vagy amit szeretnél), mivel ez lett beállítva az osztón, majd arányosítani a 6 V-hoz, azaz 6/4 V -os viszonyszámmal vissza kell szorozni, így a mért értéket a 6 V-hoz képest kapod meg, tehát 4*6/4*mért érték/4095. Ez viszont ugyan azt adja vissza, mint ha 6 V-nak vennénk az AD által max mérhető feszültséget így ezt külön nem kell leprogramozni. Max könnyebb megérteni vagy jobban összezavar
Ha valakinek van kedve végigkövetni a logikát és nem jól írtam javítson ki
-
AcCEsS
senior tag
Köszönöm, huhhh, azt hiszem felfogtam a bekötési sémát. Írtad, hogy a "Feszültség osztót pedig úgy érdemes megválasztani, hogy passzoljon az aksidhoz". ??? Az is legyen zöld színű?
Ok, ez egy fárasztó poén volt, de kb. ennyire értek hozzá. Feltételezem, hogy a két ellenállás értékét kellene jól megválasztanom, de nem tudom hogyan kell... Az ábrán látható 270k és 976k az nem jó? Panasonic NCR18650B 3400mAh aksit használok. Ja, és az egyik alkatrész, a BSS670S2L fet még a Google számára is eléggé ismeretlen, legalábbis a magyar találatokra szűrve. -
_q
addikt
válasz
Teasüti
#9026
üzenetére
Én nem mértem rá szkóppal. Nagyon más okát pedig nem látom azon kívül, hogy a vezeték hossza számít. Egyébként kínai jumper wire köteget használtam, aminek a minősége megkérdőjelezhető akár, illetve próbapanelen toldottam meg a 10 cm -10 cm távolságot, mert egyben nem volt 20 cm-es vezetékem. Elképzelhető hogy ezek együtt okozták a gondot.
(#9025) aryes
Azt is próbáltam hogy az első 10 cm és az utána lévő 10 cm közé próbapanelen kötöttem még egy-egy felhúzó ellenállást. Ez se igazán javított, igaz az ellenállás értékét nem tudom, panelen volt 2 egyforma, talán 1k lehetett. -
RAiN91
őstag
Sziasztok. Sikeres lett a garázs riasztó, ha akció van, felhív telefonon, egy regi Siemens telefon gombjait nyomkodja a NodeMCU optocsatolókkal.
Megtetszett másnak is, így csinálok még, ehhez két kérdés.
Nodemcu helyett érdemes D1 Mini-t használni? Ha jól tudom, ugyan úgy kell programozni, de. legalább kisebb az egész, bár azt nem tudom, butább-e? Árban hasonló.
Telefont váltanám ki valami GSM modullal, tudtok ajánlani valamit? SIM 800L-et neztem, ami 3-4$, mást nem találtam ami hasonló áron van.
Köszi.
-
Teasüti
nagyúr
Akkor vmit rosszul csinálsz szerintem.
Több beszámoló szerint is működik néhány méterig, ha a busz kapacitása határértéken belül marad.
Csináltam egy gyors mérést 10cm-es és 10 méteres vezetékkel, 100 Khz-en. Felhúzó mindkét esetben az Uno belső ellenállása volt (50k körül, ha jól emlékszem).10 cm:
10 méter telefon vezeték (ez már nem működik):
Próbaképp beraktam egy-egy 10k-s külső felhúzót. Nem igazán láttam különbséget a felfutási és lecsengési időkben. Nem teszteltem sokáig, mert már késő van. De majd lesz kedvem játszadozok vele egy kicsit.
Mindenesetre nem tűnik annyira vészesnek, egy feszesebb felhúzóval talán életre kelthető.Ami nekem fura ezen, hogy a hosszú vezetéken hogy tud megjelenni 5,6V az 5V-os Unóról USB-ről táplálva?
Talán vmi indukció a vezetékben? Fel van tekercselve. -
Janos250
őstag
-
válasz
Teasüti
#9015
üzenetére
& Janos250:
Mivel esp8266-ot fog vezérelni, aminek a kimenetei 5V toleránsak, a védődióda helyett beépített snapback áramkör pedig csak 6V-nál nyit ki, ezért jó eséllyel meglesz a gate-en az aktuális akkufeszültség, tehát tökéletesen fog zárni.
Vagy tévedek, és esp32 lesz a páciens? Mert akkor nem mondtam semmit...
-
_q
addikt
válasz
Teasüti
#9015
üzenetére
Miért lenne a mikrovezérlőre kötve az aksi feszültsége? A rajz alapján ha a GPIO alacsony akkor a Q1 nem kapcsol, GPIO GND-n lesz. Ha GPIO magas, Q1 kapcsol, Q2-t és 100k-t lehúzza GND-re.
Mivel a VGS -0.7-1.5 V és ha mérünk, akkor Q2 GND-n lesz azaz 0V-on, így kapcsolni fog, nem 3 V-ra kerül a Q2 Gate.
-
Teasüti
nagyúr
Még véletlenül sem kéne felhúzni a portot az akku feszültségére!
Az egy dolog, hogy 4,1V-os akkunál és 3,3V-os vezérlésnél a Q2 PNP fet talán kapcsolható*, de ettől függetlenül a mikrovezérlő lábát nem lehet felhúzni 4,1V-ra!
Ráadod a HIGH értéket, kap a port egy visszirányú áramot és pápá mikrovezérlő.
Ebben az esetben az R54-et el kell hagyni!*Ami egyáltalán nem garantált, hisz az IRLML6302 Vgs(th) feszültséget -0,7 és -1,5V közé írja, a 4,1V-os akkuval és 3,3V-os mikrovezérlővel meg ugye -0,8V-ra lehet csak beállítani a Gate-et ami még nem biztos, hogy elég a teljes nyitáshoz. Ha 4V alá merül az akku, akkor már elvileg jó lesz.
Konklúzió: PNP tranyóhoz kell a driver.
-
_q
addikt
Utánajártam, ez kellene:
BATT_EN-el vezérled. LOW nincs mérés HIGH méri a feszültséget. Ha kevesebb áramkörrel akarod akkor a Q1 és alsó 100k nem kell, ez esetben a Q2-100k között van a BATT_EN, ekkor fordított logika lesz. LOW esetben mér, HIGH esetben nem mér. Feszültség osztót pedig úgy érdemes megválasztani, hogy passzoljon az aksidhoz.
-
gyapo11
őstag
válasz
MineFox54
#9011
üzenetére
Nem pwm-mel kellene hajtani, hanem a null átmenet érzékelésétől kell mérni az időt, max 10 ms, ennyi egy fél periódus, és ebben a tartományban minél később kapcsolod be a triakot, annál kevesebb teljesítmény jelenik meg a fogyasztón. Ez is villog 100 Hz-cel, de az már nagyjából jó, csak a sasszeműek látják.
És a mocxxxx-ből is olyan kell, ami nem nullátmenetes, hanem bármikor bekapcsolja a triakot. -
AcCEsS
senior tag
Köszönöm a millió ötletet, nagyon rendesek vagytok, de én még mindig ugyanott tartok.
Habár a rajzokon cikkcakk varrásminta meg a célkereszt nekem is teccik! Nagy segítség lenne, ha valami egyszerűbb, biorobot nyelven írnátok le: A Wemos A0 lábát kösd a mosfet (az a háromlábú bigyó?) "S" lábához, utána... stb. Na jó, ennyire nem kell lealacsonyodni, de ezek a kapcsolási rajzok nekem túl magas szintűek (ez mennyivel egyszerűbb!), - pedig próbálok folyamatosan utánaolvasni a dolgoknak - főleg a többlábú alkatrészek esetén érzem bajban magam. És milyen típusú/értékű alkatrészeket kell beszereznem? xboy89 rajzán azok jók? Bocs, a totál amatőrségért! -
Janos250
őstag
Igazad van! :-) Rajtad kívül ezt még senki nem vette észre, hogy rossz a rajzjel. Az már így marad.
Igen, a tokon belül a szubsztrát az S-el van összekötve. Szerencse, hogy nem a kapcsolásban van hiba, hanem a rajzjelben. :-)
Gondolom, copy-paste, S és D átírva, nyíl meg maradt. -
-
tvamos
nagyúr
válasz
Janos250
#9002
üzenetére
Sajnos pont a relevans reszbe (high side p-chanel mosfet) csuszott egy kis bibi. Igy mar helyes is:
(No, elsore nekem sem sikerult...)(#9001) aryes válasza xboy89 (#8997) üzenetére
Nagyon egyszeru. Az n-csatornas novekmenyes mosfetnek ahoz, hogy kinyisd, a gate-re a source-nal nagyobb feszultseget kell adni. Ha a high-side-ra kotod, akkor a source feszultsege valtozik a kimenettel egyutt, es raadasul a teljes kinyitashoz a tapnal nagyobb feszultseget kell raadni, ami nem mindig egyszeru. -
_q
addikt
válasz
Janos250
#9002
üzenetére
Köszi a linket. Elég hasznos és tök jó leírás.
(#9000) Teasüti
Már nem emlékszek sajnos a linkre, de volt egy feszültség monitorozós projekt, ott
a következőt használták: 2N7000. Itt 0.3-3V között kapcsolható a FET. Ez ha jól értem akkor egy GPIO ki-be kapcsolással vezérelhető, így nem kell a plusz tranzisztoros kapcsolás. Ha más FET van használva, aminél nem kapcsolható a FET direkt módon, ott lehet kell plusz tranzisztor. -
Na ez így már igen.
Egy dolgot nem értek, de már régebb óta. Miért van az, hogy az n csatornás feteknél a pozitív ágba kell tenni a fogyasztót, a p csatornásnál pedig a negatívba? Látom ennél a rajznál is azért van egy p csatornás bevonva, hogy az osztót a negatív ágba lehessen tenni ( a pozitív oldalon nem lenne értelme az osztónak).Teasüti: tranzisztoroknál és feteknél a "nyit" és a "zár" nem pont fordított értelemben használatos, mint a kapcsolóknál?
![;]](http://cdn.rios.hu/dl/s/v1.gif)
viszont ez így már jónak kellene legyen, csak nagy helyet foglalna el a panelen.
. Akkor ez is kilőve 
).
Ráadod a HIGH értéket, kap a port egy visszirányú áramot és pápá mikrovezérlő.
Új hozzászólás Aktív témák
Hirdetés
ekkold
- GOPRO Hero 11 BLACK - 5.3k akciókamera - 2 akku, tartozékok (5.)
- DJI AVATA 2 Fly More Combo 1 akku - drón szett DJI Goggles N3 FPV szemüveggel
- Sony PlayStation 5 ( PS5 ) Sony PlayStation VR2 Csomag
- Dell Precision 7680 Eco FHD+ 13600HX 14C / 16G D5 / 1T G4 workstation
- Gigabyte GA-Z68A-D3-B3 LGA 1155 alaplap
- AKCIÓ! ASUS TUF GAMING X670E-PLUS WiFi alaplap garanciával hibátlan működéssel
- ASUS TUF Gaming F15 FX506 - 15.6"FHD IPS 144Hz - i5-11400H - 8GB - 512GB - RTX 3050 Ti - 1,5 év gari
- Gyors, Precíz, Megbízható TELEFONSZERVIZ, amire számíthatsz! Akár 1 órán belül
- ÁRGARANCIA!Épített KomPhone Ryzen 7 7700X 32/64GB RAM RTX 5070 GAMER PC termékbeszámítással
- 118 - Lenovo Legion Pro 5 (16ARX8) - AMD Ryzen 9 7945HX, RTX 4070 - UK billentyűzet
Állásajánlatok
Cég: PC Trade Systems Kft.
Város: Szeged
Cég: CAMERA-PRO Hungary Kft
Város: Budapest