- Motorola Edge 50 Ultra - szépen kifaragták
- Apple Watch Sport - ez is csak egy okosóra
- Redmi Note 12 4G - valaki fizetni fog
- iPhone topik
- Samsung Galaxy A56 - megbízható középszerűség
- Azonnali mobilos kérdések órája
- Samsung Galaxy S24 Ultra - ha működik, ne változtass!
- Google Pixel topik
- Megvan, milyen chipet használ a Pura 80 Ultra
- Xiaomi 15 - kicsi telefon nagy energiával
- Telekom otthoni szolgáltatások (TV, internet, telefon)
- Egyre csak fejlődik az AI, emberek tízezreit rúgja majd ki a BT
- One otthoni szolgáltatások (TV, internet, telefon)
- Mexikó tisztázta a Google-t a monopóliummal kapcsolatos vádak alól
- Macron betiltatná az EU-ban a közösségi médiát a 15 év alattiaknak
-
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
-
Ez a második (Y) paraméter beérkezése után hajtja végre a kódot:
megVarokParametert=false;
token="";
for (byte i = 0; i <= messageSize; i++) {
if (isAlpha(Message[i]) || isPunct(Message[i])) {
switch (Message[i]) {
case 'R':
token='R';
parameter = atoi(& Message[i + 1]); break;
case 'G':
megVarokParametert=true;
token='G';
parameter = atoi(& Message[i + 1]); break;
case 'X':
parameterX = atoi(& Message[i + 1]); break;
case 'Y':
megVarokParametert=false;
parameterY = atoi(& Message[i + 1]); break;
}
}
if (megVarokParametert==false){
hajtsdVegreAKodot(token);
} -
válasz
Teasüti
#10903
üzenetére
Én állapotgéppel csinálnám, akkor semmit nem kell bonyolítani a beolvasáson, csak olvasod szépen sorba a tokeneket. Ha Gxx érkezik, az állapotgép átbillen paraméter állásba, így a következő beolvasások mind az előző parancs paraméterei közé kerülnek, és ha újra Gxx érkezik, akkor az állapotgép visszabillen parancs állásba, ekkor hajtod csak végre az előző parancsot az összes paraméterével együtt.
-
válasz
Teasüti
#10901
üzenetére
Ha jól értem, te nem akarsz kompatibilis lenni semmivel, hanem építesz egy saját protokollt egy meglévő alapján. Vagyis amíg kerested rá a megoldást a kódban, akár meg is írhattad volna.
A leírás alapján nagyon egyszerűnek tűnik a megoldás, csinálni kell egy tömböt, amiben leírod, hogy a G01 után lesz még két paraméter, és akár betűtől függetlenül a következő kettőt beolvassa, legyen X0 Y0 vagy akár újra G0 G0 (vagy használd csak erre az X Y betűket és akkor még hibaellenőrzésre is használhatod). -
válasz
zsolti_20
#10843
üzenetére
Ha a Q1 egy LDO, akkor meg kell nézni az adatlapját, mekkora a minimum tápfesz, és mekkora árammal terhelhető. A 3db AA akksira kell kötni a nano lap 5V-ját, az Oled kijelző Vcc-jét, és ha a konverter engedi, a rádiót a konverter kimenetére kötném, hogy megkapja a stabil 3,3V tápot, mert a kisebb táp miatt a nano 3,3V kimenete nem lesz alkalmas tápnak. Illetve ha a rádió 5V-ról is üzemeltethető, akkor azt is a 3db AA akksira.
Ha a Q1 mégsem konverter, és se az oled, se a rádió nem tud 5V-ról üzemelni, abban az esetben kelleni fog egy plusz 3,3V konverter is. -
válasz
zsolti_20
#10803
üzenetére
Akkor a szűk keresztmetszet itt a lapon lévő 3,3V konverter lesz, gondolom az oled és az rf modul is arról van táplálva. Annak kell utánanézni, illetve tesztelni, hogy mekkora az a táp, amiről még megbízhatóan elő tudja állítani a 3,3V-ot.
Ha ennek is kell +0.6-1.2V a voltage drop miatt, akkor az elemes táplálást máshogy kell megoldani. Akkor én úgy csinálnám, hogy egy 3,3V buck konverter-re kötném az egész cuccot, aztán arra már olyan tápot kötsz, amilyet jól esik (mármint 3,3V feletti tápot). Vagy maradna a 3db AA elem, és az oled+rf modulnak beteszel egy buck konvertert, ami mondjuk 3,5V-ig el tudja látni őket.
Boost konverterrel két ceruzaelem (3V) is elég, ha a méret számít. Egy boost-buck konverterrel meg egészen szárazra lehet szívni az elemeket
vagy mehet egy 18650 celláról, vagy akár 1db 1S li-polimer akksiról (méretben, súlyban ez a legjobb).
Végülis a 9V elem is opció lehet (Vin lábra!), próbáld ki, hogy meddig bírja, és ha túl kevés, akkor a fentiek közül válassz egyet. -
válasz
zsolti_20
#10797
üzenetére
Hát egy 9V elem jó ha 800mAh-t le tud adni, ráadásul abból egy csomót maga a konverter fog elpazarolni.
Egy pár, illetve inkább 3db AA elem vagy ceruza akksi több mint 3x ennyit bír. Az a kérdés, hogy a rádiónak mennyi az áramfelvétele és hajlandó-e működni 5V alatt, mert 3db új AA elem konverter nélkül 4,8V-3,3Vig fogja ellátni a cuccot, 3db AA ceruza akkumulátor mondjuk 4,2-2,4V közt. Maga a kontroller 3V alatt is működik (kisebb órajelen 1,8V-ig is, mint azt tegnap megtudtam )t72killer: ki mondta, hogy baj van vele?
-
válasz
szuszinho
#10773
üzenetére
Olyan nincs is... 8 meg 16MHz-est látok.
Régebben teszteltem úgy az uno-t (ATmega328), hogy az 5V lábra ceruzaelemeket kötöttem konverter nélkül, és egészen 3V-ig stabilan működött. Szóval ha oda kötöd, működni fog, de ha érzékelők is vannak rá kötve, akkor azok már nem biztos, hogy ezt tolerálják. 4V alatt a 3,3V kimeneten se lesz 3,3V. -
válasz
t72killer
#10765
üzenetére
Ez esetben még mindig ott van az a lehetőség, hogy olyan routert veszel, ami tud egyszerre két wan kapcsolatot kezelni, az egyik a mobilnet, vagy free wifi, a másik pedig a kamera lenne, így mégis csak a routeren keresztül tudnád elérni, pl vpn-en keresztül. Ekkor megint nem kellene a raspberry, mert közvetlenül otthonról tudnál rá kapcsolódni, a többit pedig az attiny elintézi (ki-be kapcsolgatás, exponálás). De akkor még mindig ott van az a probléma, hogy free wifi-re kapcsolódva nem fogod tudni elérni kívülről az egész cumót publikus ip cím nélkül, sőt szerintem LTE modem mögül se biztos, ha NAT-olt.
-
válasz
t72killer
#10756
üzenetére
Az a baj, hogy egyszerre akarsz mindent is.
Amit most leírtál, azt valószínű legjobban tényleg raspberry-vel lehetne megoldani, de nem azért írom itt a raspberry-t, a raspberry topikban meg az arduino-t, hogy szivassalak.
Az attiny felesleges redundancia lenne a projektben, mert az esp simán tudná vezérelni a gombokat és wifi-n keresztül http parancsokat adni. Ahogy én csinálnám: egy routert beállítanék repeater módba, ami a környéken fogható free wifi-re csatlakozna, erre kapcsolódna a kamera és az esp is, így nem kéne két hálózatot kezelni. Az esp szerintem képes arra, hogy 4Mbyte-os jpeg-eket leszedjen a kameráról és továbbítson, ha tényleg http parancsokkal ezt meg lehet oldani (az esp szakértők majd kijavítanak, ha tévedek), ez esetben viszont nem világos, hogy ha már a kamera a netre van kötve, miért nem próbálod otthonról a neten keresztül letölteni a kameráról a képeket és az esetleges videó streamet?
A kamera vezérlésről http protokollon keresztül tudsz leírást adni? -
válasz
Gergosz2
#10749
üzenetére
Én meg pont úgy tudom, hogy az atmega328 lábai gyárilag boot alatt input (nagyellenállású) módban vannak (ezt éppen hívhatjuk lebegésnek is). Az persze lehet, hogy a bootloader állítgatja közben őket, de a legjobb lenne a kérdéses lábakat külső ellenállásokkal földre húzni. Én először biztos ezt csinálnám, mielőtt nekiesek kiirtani a bootloadert. Plusz tennék egy nagy puffer kondit a nano tápjára.
-
-
-
válasz
Teasüti
#10677
üzenetére
Azért off, mert már túl sok vagyok ebben a topikban, nem akarom ingerelni a többieket.
Hát a koncepció az, hogy egyforma teljesítménnyel adom le a jelet, de elhangolom a vivő frekvenciát 38kHz-ről, hogy a vevő nehezebben érzékelje.![;]](//cdn.rios.hu/dl/s/v1.gif)
Azt hittem, hogy ez egyszerű dolog: addig növelem a frekvenciát, amíg már nem tudja fogni a vevő a jelet, de tévedtem: gyakorlatilag minden frekvencián képes fogni a jelet, 2kHz-től 100kHz-ig. 
Viszont vannak frekvenciák, amikre kevésbé érzékeny, ezeket vagyok kénytelen használni.(#10678) tvamos: nem igaz, hogy nem számít, biztosan jobb lenne az egész, ha cm pontossággal tudnék mérni, de egyrészt nem akartam lehetetlen célt kitűzni, másrészt pedig az említett Lego robot is így lett kitalálva, és így is jól használható. Már akkor boldog lennék, ha azt a pontosságot sikerülne elérnem.
-
válasz
Teasüti
#10672
üzenetére
Abszolút hatótávolságot.
Most annyit tudok mérni, hogy az adó 0-50cm-en belül van, 50-100cm közt, vagy 100cm-en túl. Én pont ennyit akartam eredetileg. És amiért ez szerintem érdekes, az az a tény, hogy az ir vevőn és két ir leden kívül csak egy előtét ellenállást használok, minden más szoftveresen van megoldva. -
válasz
Teasüti
#10668
üzenetére
"Én ezt megoldanám frekvencia modulációval"
Mit? Vagy 6 különböző funkciót írtam le az előbb csak 1 tankhoz. És még vannak ötleteim. Például a beacon jel jelenthetné, hogy sikeres volt a találat, vagy akár a tank egészségi állapotát. És valahogy össze is kell hangolni a kommunikációt, ha nem akarom, hogy az összes tank egyszerre beszéljen."különböző jelerősségekhez is lehetne saját frekvenciát rendelni. Mondjuk az első tank 30-33 Khz között sugároz, a második 34-37 közt "
És honnan vegyek ennyi különböző ir vevőt? Arról nem is beszélve, hogy a 38kHz-es tsop vevő 25 és 45kHz között simán vesz minden frekvencián. -
válasz
Teasüti
#10666
üzenetére
Pedig eddig azt hittem, figyeltél.
A beacon jelben benne kell lenni a tank azonosítójának, vagyis, hogy ki sugározza éppen a jelet. Ebből tudja a másik, hogy kit lát (terv szerint kettőnél több tank is részt vehetne egy harcban, bár elsőre örülök, ha kettőt meg tudok építeni...
), illetve, hogy nem a saját maga által küldött jelet látja mondjuk egy falról visszatükröződve.
A másik, hogy mivel analóg jelet nem tudok kivenni az ir vevőből, kell egy trükk, hogy távolságot tudjak mérni.
Több különböző "fényerővel" fogom kiküldeni a beacon jelet. Mondjuk 5mA lesz az 1-es fényerő, 10mA a 2-es, stb. A különböző fényerők más-más távolságról fognak látszódni. De honnan tudom, hogy ha látok egy beacon jelet, az egy közeli tank gyenge jele, vagy egy távoli tank erős jele? Hát onnan, hogy maga a jel tartalmazni fogja, hogy ki küldte és milyen erősséggel.
Tehát mondjuk így fog kinézni az 1-es tank 5-ös erősségű beacon jele: 0x15. A lövés meg legyen mondjuk 0x1F. Akár még azt is bele lehet írni, hogy a tank eleje vagy a hátsó része sugároz, így az egyik tank egy jelből meg tudná állapítani, hogy a másik tank menekül előle, vagy éppen célba vette.
-
válasz
Teasüti
#10664
üzenetére
A GCR kódolás. Az volt a baj, hogy ha túl sok 0 vagy 1 jött egymás után a soros adatfolyamban, megzavarta a vevőt, elmászott a gain (begerjedt?
), az adatlapon lehet olvasni, hogy bizonyos jelhosszúság (0) után kötelező szünetet (1) beiktatni.
Először az 5 bites, Commodore-féle változatot próbáltam, de az csak az egymást követő 0 bitek számát maximálta 2-ben, az 1 biteket nem, így akár 8db 1-es bit is jöhetett egymás után, és nem akart úgy működni, ahogy vártam. Ezért kitaláltam egy 6 bites kódolást, ahol se kettőnél több 0, se kettőnél több 1 nem jöhet egymás után, és ezt már szereti a vevő. Plusz két ellenőrző bitet használok az átviteli hibák detektálásához. Így a normál soros kommunikáció 11 bitje (1 start + 8 adat + 1 paritás + 1 stop) helyett ugyan 16 bitet küldök (1 start + 2x6 adat + 2 ellenőrző + 1 stop) egy byte átviteléhez, de azt akár 4000baud sebességgel (~230byte/s), és majdnem minden átviteli hibát ki tudok szűrni. 
A hibás adatot felismeri a rendszer és eldobja.
Így most nem az történik, hogy bizonyos távolságból elkezd a hasznos adat közé mindenféle szemét keveredni, hanem van egy
határozott távolság, ahol egyszerűen megszűnik a kommunikáció. És ez volt a cél. -
Az a poén, hogy miközben próbáltam tervez(tet)ni egy workaround megoldást az ir receiver "hisztis" viselkedése miatt, sikerült olyan jól módosítani a softwareserial lib-et, hogy most már együtt tud működni a tsop vevővel és elkezdett úgy működni, ahogy eredetileg vártam.
Úgyhogy ezen a vonalon megyek tovább, és egyelőre ejtem a high pass filteres mókát. Köszönöm a türelmet és a segítséget mindenkinek!
-
válasz
Gergosz2
#10655
üzenetére
A NEC protokollal két gond van. Az egyik, hogy l-a-s-s-ú.
Kb. 50 baudos adatátviteli sebességet lehet vele elérni, az kb 6byte egy másodperc alatt, iszonyú kevés... 
A másik, hogy a hozzá kapcsolódó library csak egy darab ir vevőt képes kezelni, míg a softwareserial lib többet is, egyidejűleg!Ellenben a softwareserial libet mostanra annyira átírtam, hogy 4000baudos sebességgel tudok küldeni vele adatot GCR kódolással és magas hibatűréssel.
-
válasz
tvamos
#10657
üzenetére
"Raadasul demodulalnod kene elotte a jelet"
Azt hiszem most kezdem érteni, hogy miért kérdezed azt, hogy hogy akarom demodulálni. Ugyanis összekevertem a felül áteresztő szűrőt az alul áteresztővel.
Eddig azt gondoltam, hogy a high pass szűrő után kapok egy, a jel amplitúdójával arányos feszültségszintet, de valójában csak a négyszögjelet kapom vissza, amit eredetileg küldtem.
És ha ezt a négyszögjelet integrálom egy kondenzátor+diódával? -
válasz
Teasüti
#10651
üzenetére
Te tényleg értesz.
"Az adó-vevő hókuszpókusz"
Ez sajnos kudarcba fulladt, mert nem bírok belőle analóg jelet kifacsarni. De maga a soros kommunikáció már egészen jól működik. Viszont távolságtól függetlenül néha egészen közelről is hibák jelentkeznek, amit képtelen vagyok visszafejteni, ehhez már vagy egy oszcilloszkóp kéne, amit linkeltél, vagy egy digitális jelanalizátor, amit Janos250 kolléga ajanlott régebben, de egyik sincs itthon sajnos. Gyanítom már nem a kommunikációban van a hiba, inkább valami esp specifikus dolog lehet, ami néha megzavarja a pontosan időzített küldést."38 Khz-es négyszögjel esetén - vagy ami átjön a bandpass filteren - húzza GND-re."
Analóg jel esetén ez úgy működne, hogy a jel mindig valahol 3.3V és 0V közt lenne, az adó távolságától és az adás teljesítményétől függően. A kettő közt félúton van egy választóvonal, ami alatt 0-nak, fölötte pedig 1-nek veszi a feszültségszintet, tehát bizonyos távolságból az adás egyszerűen csak el fog tűnni. Persze tudom, hogy van egy sáv, ahol határozatlan lesz a, mondjuk 1.8-2.5V közt, itt valószínűleg véletlenszerű adatokat fogok kapni. -
Nem rossz ötlet, de pont a lövéssel nincs gondom, ott nem kell távolságot mérni.
Beacon jelnek tényleg lehetne használni, de az a baj az ultrahanggal, hogy egyrészt nagyon irányított, tehát 360°-ra kellene vagy 8db adóvevő, másrészt 80cm-en túl gyakorlatilag használhatatlan. Ezen kívül nagyon érzékeny a visszaverődésekre (hiszen ez a dolga), és ha két robot széklábak és játéktároló dobozok közt bújkálva keresi egymást, annyi visszhang lenne, hogy nem lehetne használni.
De tartaléktervnek azért elteszem. -
válasz
Janos250
#10639
üzenetére
Egy nagyon vázlatos rajz:
Az IR led bizonyos időközönként kiküld egy 1-2 byte-os beacon üzenetet, amit vagy látnak a körülötte lévő robotok, vagy nem, az üzenet tartalma pedig a robot azonosító száma, és egyéb rendszerüzenetek, pl. lövés (ez utóbbi üzenet csak egy dedikált, irányított LED-ből fog érkezni, vagyis csak az fogja látni, akit "eltalál" vele).
Ezt az üzenetet több különböző teljesítményen (pl 5mA - 100mA) szándékozok küldeni egymás után, ami reményeim szerint csak bizonyos távolságokból látható (pl az 1-es erősségű jel csak 20cm-ről, az 5-ös erősségű meg mondjuk 3 méterről), ebből a vevő robot egy hozzávetőleges távolsági becslést fog tudni számolni az alapján, hogy melyik infra vevő melyik jelet fogta. Az üzenetben természetesen benne lesz, hogy milyen erősséggel lett kiküldve. Példa: "15" <- az 1-es számú robot 5-ös erősségű beacon jele.
Nem kell se a távolságot, se az irányt pontosan tudni, elég, ha annyit tud az egyik robot, hogy a másik előtte van, vagy tőle jobbra, közel, közepesen távol, vagy valahol messze.
Mondjuk egy ilyen koordináta rendszerben:
A piros a közel, a zöld a távol, a többi meg látszik a rajzon.Amit most leírtam, pontosan ezt tudja a Lego Spybotics robot, 76kHz-es IR vevőkkel és ledekkel. Azt szeretném lemásolni.
-
válasz
tvamos
#10635
üzenetére
Meg mernék esküdni, hogy az utóbbi két napban legalább háromszor leírtam már (én ugyan high pass filtert írtam), de legyen:
Szükségem lenne egy bandpass filterre, ami egy ir tranzisztor jelét szűri olyan módon, hogy megfelelő amplitúdójú 38kHz-es négyszögjelre alacsony jelszintet hozzon létre egy esp8266 bemenetén.
Hiába van ez a tervező, ezzel a rajzzal nem tudok mit kezdeni:
Nem a számolás részével van problémám, nincs kész kapcsolási rajzom!
Hova kössem az ir tranzisztort? Hogy fog ez nekem alacsony jelet produkálni az arduino bemenetén? -
válasz
brickm
#10632
üzenetére
Most az egész projektet nem érted, vagy azt sem, hogy kellene egy 32kHz vágási frekvenciával rendelkező high pass filtert tervezni ir tranzisztorhoz, ami egy esp8266 bemenetét vezérelné? Bemegy egy 38kHz négyszögjel, ennek az amplitúdóját szeretném megkapni analóg módon az esp bemenetére.
-
válasz
Janos250
#10630
üzenetére
"Tehát van egy mozgó kocsi, aminek infókat akarsz küldeni IR-en. Ez alapján akkor a vevőnek a kocsin kell lenni."
Igen, és az adónak is! Így beszélgetnének egymással. Minden kocsin 1 vagy 2 LED az adó, és 3-4 vevő. A ledek fényét pedig valamilyen kerek, fényvisszaverő felülettel szórnám, hogy 360°-ban le tudjam fedni a környezetét.
"Ahhoz, hogy elfogadható pontosságot kapj, muszáj lesz (szerintem) a vevőt egy pincurka servo- vagy léptetőmotorral az adó, azaz a maximális jel erősség irányába állítani"
Ez biztosan nem így lesz, vagy 3db vevő lesz körben az autón, egymással kb 120°-os szögben, vagy ha ennek túl nagy lenne a holt tere, ami elég valószínű, akkor 4 vevő, 90° szögben. A háromszögelés pedig 1 adó + két vevő között történne.
"b.) Egyszerre akarod a kódot is és a távolságot is megkapni. Akkor jön a vér izzadása, hogy mindenféle szűrésekkel megold."
Ezt akarom. A vért pedig már izzadom vagy 3 hete. -
-
válasz
Janos250
#10622
üzenetére
" a jel erőssége nem csak a távolságtól függ, hanem pl. attól is, milyen szöget zár be a vevő és az adó."
Ez tény, sajnos nem tudok vele mit kezdeni. Max annyit, hogy a LED fényét nem direkt módon irányítom kifelé, hanem szétszórom, tükör vagy fényvisszaverő felület segítségével."Az IR-rel a távolságmérést nem a jel erőssége, hanem a visszavert jel visszaérkezési idejéből számítják."
Na ezt majdnem biztosan állítom, hogy ebben a formában nem igaz, a sharp távolság szenzornál a beesési szögből számolják, CCD érzékelő segítségével. Sima ir tranzisztorral pedig a fény intenzitásából, itt van olyan variáció, ahol egy 555-ös IC-vel szaggatják a fényt, a vevő oldalon pedig felüláteresztő szűrővel szűrik ki a jelet a környezeti fényből, ezt akarom én is, csak szoftveresen.
Aminek a visszaérkezési idejéből számítják a távolságot, amit írtál, szerintem az a lézeres mérő, de annak már igazán nem hobbista az árszabása... -
válasz
tvamos
#10623
üzenetére
"Szerintem nem uszod meg a haromszog beiktatasat"
Persze, hogy nem, azzal szeretném az adó irányát megbecsülni, de ahhoz kell, hogy sikerüljön valami távolság adatot is végre kinyerni."En azt javasolnam, hogy eloszor dugd ossze az aramkorod, ... szaladj korbe a lakasban, kulonbozo napszakokban, "
Pontosan ezt fogom tenni. Amit nem tudok kiszámolni, azt mindig empirikusan szoktam megoldani: addig próbálgatom, amíg nem sikerül. Csak ez sajnos időigényes, és ennyi időm nincs.
Oscilloscope-om sincs sajnos. Tervezem, hogy veszek, aztán mindig másra kell a pénz. Kicsit körülményes, de megoldom valahogy anélkül. Elvégre az uart kapcsolat már összejött, pedig azt sem volt egyszerű összehozni. -
válasz
tvamos
#10620
üzenetére
Köszönöm az észrevételeket, ezekkel már tudok mit kezdeni.
"Tehat, ha a nap besut az ablakon, es a robotod azzal szembe megy, akkor nem lesz jeled."
Igen, ez egy kompromisszum, a smart car-ommal szerzett tapasztalatok alapján direkt napfényben nem hatékony a szimpla ir tranzisztor, nem akarom a fizika törvényeit megszegni, ha kell, lehúzom a redőnyt.
De ha a tsop képes direkt napfényben is működni, akkor valamilyen megoldásnak létezni kell."hogyan tudnad a tavolsagot merni, ha nem mashogy, mint egy masik tavmero szenzorral, vagy haromszogelessel."
Két ir szenzor + háromszögelés
"A terhelesed nincs impedancia illesztve. Ha a kimeneted feszultseg, akkor az R2 legalabb 100k kene legyen"
Ha jól értem az esp bemeneti impedancia számít, ami ez esetben ha jól tudom MΩ nagyságrendű. Az R2 azért ennyi, mert erre találtam példát az egyik fórumon.
"Ha mondjuk 200mVpp az AC, es 3.3V a a tap, akkor 3.2V es 3.4V kozott lesz a kimeno feszultseg. Ez kell neked?"
Igazából 0V és 3.3V közti értékeket szeretnék kapni. Hogy ezt milyen áramkörrel lehet elérni - na azt szeretném most megtudni... Gondolom kellene bele egy(-két?) dióda, ami nem engedi a jelet a tápfeszültség fölé menni.
-
válasz
Janos250
#10616
üzenetére
Én nem analóg jelet akarok átküldeni, hanem digitális információt. Emellett a küldő oldal jelerőssége alapján szeretnék hozzávetőleges távolságmérést csinálni. Tudom, hogy nem ördögtől való az ötlet, mert árulnak arduino-hoz való ir távolságszenzort, ami egy egyszerű reflektív optokapuból + némi elektronikából áll, ahol az ir led fényét frekvenciamodulálják, hogy ne zavarja a környezeti fény.
-
válasz
tvamos
#10614
üzenetére
Ennél pontosabban nem tudom leírni: egy ir receivert szeretnék, de AGC nélkül, hogy korlátozott legyen a hatósugara. 38kHz-es négyszög jelre (ez nem különösebben lényeges szempont, a lényeg, hogy a környezeti fényt hatékonyan kiszűrje) alacsony jelszintet produkáljon az arduino bemeneten.
A linkelt kapcsolási rajz szerintem ezt teljesíti (32kHz-es vágási határfrekvenciával), csak azt írtad, hogy az R2 magasabb, mint az R1, és ez nem jó. Ha nem jó, miért nem, mennyinek kellene lenni, és egyáltalán tényleg azt csinálja-e az áramkör, amit szeretnék. -
válasz
Teasüti
#10613
üzenetére
Én kérek elnézést, nem akartam senkit megsérteni, és természetesen csak azokhoz szólt az előbbi, akik tudnának segíteni, csak valamilyen okból mégsem tették. Tele van a fórum mérnökökkel és műszerészekkel, reménykedtem, hogy valaki csak megszólítva érzi magát.
Érdekes ez a DBU, köszi a tippet, utána fogok olvasni, ez tényleg hasonló, mint amit én akarok, de nem pont olyan. -
válasz
tvamos
#10609
üzenetére
Úgy, hogy a hasamra ütöttem, és választottam egy értéket. Mivel írtam, hogy nem értek hozzá, nem tudom, hogy oda milyen ellenállást illik tenni, és miért, ezért azt sem tudom, miért baj, ha az R2 nagyobb, mint az R1. Próbálom egyedül megtervezni ezt a rendkívül bonyolult áramkört, mivel még mindig nem kaptam érdemi segítséget se itt, se a hobbielektronika topikban (értsd: egy hét alatt kb. 5x megkérdeztem, de mindenki csak átnéz a kérdésemen). Nem értem, talán derogál egy hozzáértőnek egy ilyen egyszerű feladatra válaszolni? Azt hittem erre való ez a fórum, de látom, hogy a "Mikrokontrollerek Arduino környezetben (programozás, építés, tippek)" topikban sokkal érdekesebb és relevánsabb téma az ólommentes forrasztás körüli vita.
-
-
válasz
Janos250
#10597
üzenetére
Az impulzushosszt hogy érted pontosan? Az analóg jelet úgy értem, hogy az adó és a vevő távolságát akarom megbecsülni a fogott infra jel erősségéből, miközben ugyanezzel a jellel adatot is akarok átvinni.
A receiver belső elektronikája mindent elkövet, hogy a bejövő analóg jelből tökéletes digitális jelet csináljon, és nagyon jól végzi a dolgát
, mert semmilyen anomáliát sem sikerül keresztül vinnem rajta, sem a négyszögjel kitöltési tényezője, se a vivőfrekvencia elhangolása nem okoz semmilyen elváltozást a kimeneten. Az impulzushossz (mármint a soros átvitel bitjeinek hossza) a jel erősségétől nagyjából függetlenül csak átviteli hibákat okoz, 500us-nál rövidebb impulzus (kb. 18 periódusnyi négyszögjel 38kHz-en) nem megy át, 2-3ms viszont már gondot okoz, ha nem küldök közben szünetet, túl hosszú neki. A kettő közt meg sima négyszögjel jön ki belőle.
Jelen pillanatban azon töröm a fejem, hogy sima ir tranzisztorral veszem a jelet, ami elé teszek egy high pass filtert, de az istennek sem találok kész rajzot hozzá, nekem kellene terveznem úgy, hogy láma vagyok az analóg elektronikához, segítséget meg nem nagyon kapok hozzá, pedig biztos lenne itt valaki, aki 5 perc alatt tudna rajzolni egyet...
Ha ez összejön, akkor vagy ez veszi a digitális jelet (vagy nem veszi, ha távol van az adó, ez lenne a cél), vagy csak simán analóg jelerősséget mérek rajta, miközben az adatot magát a vs1838 vevővel veszem. És amíg van új ötletem, addig nem adom fel. -
válasz
robohw
#10593
üzenetére
"A másik, hogy kopasz diódákkal, tranyókkal kiépítesz egy saját rendszert."
Ezt is szeretném, mivel már kiderült, hogy egy ir receiver kimenetéről sehogy sem tudok analóg jelet levenni.
Egy erősítés (opamp) nélküli sima RC tagot kellene tenni a tranzisztor és a bemenet közé, csak nem tudom egyedül kiszámolni. Tud valaki segíteni egy kapcsolási rajzzal? Analóg áramkörökhöz nagyon láma vagyok"Amit itt kutyulsz, az véleményem szerint aligha fog eredményre vezetni."
Miért mondod ezt? Ez nekem hobbi. Máris volt eredménye a "kutyulásnak", szeretek tanulni, egy csomó mindent tanultam az esp8266-ról, amíg utána néztem a dolgoknak. Beleástam magam az ir és a serial (uart) protokollba, módosítottam egy library-t, kiegészítettem paritás ellenőrzéssel, meg frekvencia modulációval úgy, hogy működőképes maradt.
Bele fogom tenni a GCR kódolást is, mert azzal 1600baudos sebességet fogok tudni elérni, szemben pl a BI Phase Coding-gal, amivel elméleti szinten is legfeljebb csak 1000baud lehetséges (azzal a vevővel legalább is, amivel én próbálkozom).
Elnézést, ha zavarok a kérdéseimmel, sosem tanultam elektronikát, se programozást, csak autodidakta módon, és kizárólag azt kérdezem itt meg, amire hosszas kitartó guglizás és utánaolvasás után sem találok választ. -
válasz
Janos250
#10591
üzenetére
Ez nem ide vágó dolog, akkor lenne érdekes, ha nem csak 8+2 bit hosszan kellene tartani a szinkront, de itt byte-onként újra történik a szinkronizálás (minden küldött byte start bittel kezdődik, ami megszakítást generál), szóval a hiba tuti nem itt jön be. Már csak azért sem, mert teszteltem az átvitelt még 38kHz moduláció nélkül, sima ir tranzisztorral, és 4800baud sebességgel simán működött. A gond azután kezdődött, hogy bejött a képbe a VS1838 ir receiver, mert nem jöttek át rajta a bitek úgy, mint vártam. A túl rövid és a túl hosszú jel is zavarja, az elsőt még csak értem, de az nem tiszta, hogy miért zavarja, ha több 0 bit érkezik egymás után szünet nélkül, mert a dekódolásban semmi szerepe, a bitek dekódolását én végzem a fogadó oldalon, csak közvetítő szerepe van.
-
válasz
tvamos
#10587
üzenetére
Nem feltétlenül szívás a GCR (amúgyis szeretek programozni), de az adatlap szerint, amit linkeltél, van jobb megoldás is. A fig.7.-en látható megoldás kiküszöböli, hogy hosszú, megszakítás nélküli 0 bitsorozatok (burst) alakuljanak ki (bár ehhez ezen a sebességen az én vevőm lehet, hogy lassú).
Azt viszont nem értem, hogy miért baj, ha hosszú ideig tart egy impulzus? A NEC kód az adatlap szerint direkt egy 9ms-os burst-tel indít, hogy -ha jól értettem - a vevőnek legyen ideje beállítani a gain-t. Vagy inkább a hosszú szünetekkel van baj? Vagy azzal, hogy gyakran változik az impulzusok hossza és elmászik a gain?
Akkor viszont elvileg nem jobban kéne működjön magasabb bitrátán...? -
válasz
tvamos
#10578
üzenetére
Hát ha rászoknék, hogy adatlapot olvasok mielőtt egy egész napom rámegy a kísérletezésre, spórolhatnék magamnak egy kis időt.
"Maximum number of continuous short bursts/second 1800"
Ez meg is magyarázza, miért nem működik már 4800baud sebességgel a rendszer.Mondjuk az én vevőm nem tsop, hanem VS1838, arról nem lehet ilyen részletes adatlapot találni, ebben olyat találtam, hogy "output pulse
width min. 500μs", ami ha jól számolok 2000baud-os elméleti sebességet enged.Még ennyi kérdésem lenne, hogy miért írják a legtöbb helyen, hogy ellenállásokat kell rakni a Vcc és az OUT lábakra?
Kipróbáltam (a 10k helyett a belső felhúzó ellenállást használtam), de semmit nem befolyásolt a működésen, 100ohm nélkül sem melegedett vagy purcant ki... -
IR-kommunikáció témakörben előre léptem egyet. Átírtam az esp software serial lib-et, tettem bele paritás vizsgálatot és pwm modulációt, hogy 38kHz-es ir receivert tudjak használni.
A helyzet a következő: az analogWrite túl szép volt, hogy igaz legyen, valamiért használhatatlan, gondolom inkább hangfrekvenciára lett tervezve. Ezért kénytelen voltam a jó öreg "bit-bang" módszerrel (ha valaki tudja, hogy mondják ezt magyarul, megköszönöm, ha megírja ) csinálni, elég durva, de működik.
Ezután egészen váratlan dologgal szembesültem: egyrészt túl jó az adatátvitel hatótávolsága (10mA árammal 2m-ről simán tudok adatot küldeni), másrészt a távolsággal csökken az átviteli sebesség.
Sem a duty cycle, se a hordozó frekvencia durva elállítása nincs különösebb hatással a vételre, 5%-os kitöltés és 20kHz esetén sem csökken drasztikusan a hatósugár, létezik, hogy ezekben a kis vevőkben automatikus gain szabályozás van? Viszont az átviteli sebesség csökken, zavarérzékeny lesz a kapcsolat, és nem eltűnik az adat, hanem kicserélődik garbage-ra... És sajnos 1200baud-nál gyorsabban nem igazán működik. Az eredeti terv 4800baud lett volna, de ennél a sebességnél egy másik rejtélyes dolog történik: túl érzékeny lesz a vevő! Ha túl közel viszem az adót, megszűnik az adatforgalom és szemét jön csak helyette. -
válasz
Janos250
#10539
üzenetére
Annyi minden alkatrész van már itthon, amit megvettem az évek során, de még nem használtam fel, hogy elsősorban azokból szeretném összehozni a dolgot.
Van pl. két wemos d1 mini-m, ami arra vár, hogy kikerüljön a dobozból. Van hozzájuk i2c motor shield is.Már ott tartok a dologban, hogy nem az ir remote protokollt fogom használni, mert nem praktikus, és ram-pocsékolás is lenne, hanem software serial-t, egy kis módosítással:
ebben a kódban a megfelelő helyeken kicserélem adigitalWrite(m_txPin, LOW );
sorokat erre:analogWrite(m_txPin, 512);Előtte pedig valahová beszúrok egy ilyet:
analogWriteFreq(38000);Jól gondolom, hogy ez úgy fog működni, ahogy én szeretném?
Azt meg tudod modani, hogy ha az analogWriteFreq-el módosítom a PWM frekcenciát, és egyébként nem használok PWM-et, el tud az állítódni magától (vagy nem magától, hanem valamelyik gyári lib-től)?
(#10535) tvamos: Köszi a szoftveres ötletet, ez jócskán leegyszerűsíti az elektronika részét a projektnek.
-
válasz
tvamos
#10535
üzenetére
Lesz még jócskán annyi kihívás ebben a projekben, hogy nehezítsem a saját dolgomat.
Egyébként most, hogy így mondod, lehet, hogy tényleg érdemesebb lenne először megnéznem a softwareserial lib-et, hátha tudom úgy módosítani, hogy egy tranyóval is működjön az egész. Mert én forrasztani sem szeretek, viszont az esp-vel még nem kötöttem olyan szoros barátságot szoftveresen, mint az uno-mega lapokkal... Ha nem lenne jóval több ram-ja az esp-nek, és nem akarnám wifi-n keresztül programozni, inkább egy nano-val csinálnám az egészet.Jó ide jönni, mindig kap az ember jó ötleteket!
-
válasz
Teasüti
#10530
üzenetére
Nem azt a linket.
Amit a kijelzővel kapcsolatban írtam.
Egy hobbiprojekthez elfogadható kendácsolás az i2c busz alacsonyabb feszültségre húzása, természetesen ha a megbízható működés alapfeltétel, vagy sorozatgyártásba kerül a készülék, akkor persze érdemes rendes szintillesztést beletenni. -
válasz
Atamano
#10523
üzenetére
Ha az LCD i2c vonalain nincs gyárilag felhúzó ellenállás, akkor működhet level converter nélkül is, úgy, hogy csak 3,3V-ra húzod fel a vonalakat! Ha az LCD elektronikája elfogadja a 3,3V-ot magas szintnek, akkor problem solved.
Egy 5V TTL szintű logika 2,5-3V feletti feszültséget már magasnak szokott értelmezni. Ha ez nem jön be, akkor marad a level converter. -
válasz
tvamos
#10509
üzenetére
Nincs ellenemre semmilyen működő megoldás, de 1db mosfet-tel hogy tudnám modulálni a soros port jelét a 38kHz-es hordozó jellel?
Igen, én is úgy akarom, hogy a táp és a kimenet közé teszem a ledet, máshogy nem is lenne jó, mert alacsony jelre kell, hogy a led világítson, a soros port és az ir vevő is low active. Inkább csak az a kérdés, hogy a standby láb is bírni fogja-e a 38kHz-es jelet, mert erre vonatkozóan nem látok infót az adatlapon, csak egy általános 100kHz-es limitet. Biztos nem gondoltak arra, hogy valaki kifordítva akarja használni. -
-
Persze, hogy nem okoz gondot, úgy kell összerakni.
A linkelt robot hidd el, minőségi anyagból van, ugyan nem Lego minőség (ami egyébként meg sem közelíti a 10-20 évvel ezelőtti anyagminőséget...), de majdnem ott van, és az általam eddig kézben fogott kínai Lego másolatokat magasan veri. -
válasz
MineFox54
#10494
üzenetére
Azt nem írtad, hogy 0-10V közötti analóg jelet kellene küldeni. Ez alapján én is egy jól kiszámolt RC tag + tranzisztor megoldásra szavazok (plusz 10V-os táp) PWM meghajtással, de analóg elektronikai kérdésekben talán itt jobban tudnak segíteni.
(#10495) MineFox54: igen, ez jónak tűnik. V2 helyére menne az arduino kimenetről a pwm jel.
-
válasz
Teasüti
#10489
üzenetére
Miért, az usb vezérlő chip is csak egy mikrovezérlő.
Én ilyen dolgokat, ha nem otthon vagyok, a telefonommal szoktam megoldani, OTG kábel + kártyaolvasóval. Mondjuk én csak a telefonomban lévő SD-ről mentek pendrive-ra, de az elv hasonló.
Az említett raspi zero-nak van mass storage módja, amivel ha gépre kötöd, pendrive-ként viselkedik, ha meg hdd-t kötsz rá, meg lehet oldani egy automatizált script-tel, hogy át mentse rá a tartalmát, mindezt akár egy powerbank-ről. De ez itt eléggé off téma. -
válasz
MrChris
#10487
üzenetére
Én erre raspberry pi-t használnék. Egy zero kb. akkora, mint egy arduino nano, és nem sokkal drágább, mint egy eredeti uno board (használtan meg kb fillérekért beszerezhető). Hátránya, hogy kell hozzá egy otg usb hub, ami miatt némileg elveszíti a fenti méretbeli előnyét. Amúgy létezik hordozható hdd beépített sd backup funkcióval, az nem lenne jó? Vagy az építés a lényeg?
-
Ha jól értem, te olyat szeretnél, hogy legyen mellé még csomagolva valaki is, aki össze is rakja?
Miért nem raksz össze saját tervezésű valamit? Az általad linkelt videókon még csak nem is Lego motorok vannak, szóval gyakorlatilag bármely, technic elemekből álló jármű alkalmas lenne a feladatra.
Ugyan nem Lego, és drágább is, mint 10ezer, viszont ajánlom neked ezt a Wall-e kinézetű robotot. Csak össze kell rakni (max 30perc) és egy remek grafikus felületen már lehet is programozni (legalábbis a 6 éves fiam már remekül boldogul vele) , Android vagy iOS alatt. Csak azért ajánlom, mert kettőt is vettem belőle a tavalyi akcióban, és fantasztikus minőségi cucc! Sajnos a látszattal ellentétben nem kompatibilis a Lego technic elemekkel.
Az első linkelt videó nagyon elgondolkodtatott, hogy minden eddigi lego motorizálási feladatnak rosszul álltam neki, mert az a nema8 stepper olyan, mintha maga a Lego találta volna ki, annyira illik a Lego mellé.
Asszem be is szerzek párat. -
válasz
tvamos
#10466
üzenetére
Találtam az uln chipeknél sokkal cizelláltabb megoldást a ledek meghajtására.
Van itthon TB6612FNG breakout boardom, ami egy dual H-bridge motor driver. Mivel a ledeket úgyis csak egy irányba lehet meghajtani, ez azt jelenti, hogy 4db ledet tudok rá kötni, az standby lábra pedig mehet a 38kHz jel, és kész is az infra meghajtású soros port.
Az adatlapja szerint 100kHz-ig lehet hajtani, és a minimum tápfeszültség 2,5V (ezért is rendeltem, ilyen van az arduino motor shield v2-n is, ami nagyon jól működik). -
-
Na úgy néz ki mégsem kell újra feltalálnom a meleg vizet.
Addig olvastam, amíg kiderült, hogy a mintának tekintett Lego Spybotics egyszerű soros kommunikációt használt, 4800baud sebességgel, 72kHz-es infra jelre ültetve, nem a távirányítóknál használt protokollt. Tehát elméletileg 1 hardveres + 2 szoftveres serial meg is oldja a 3 infra vevő egyidejű használatának problémáját. Legalábbis a lib leírása szerint az avr software serial-lal szemben az esp változatnak nem okoz gondot két példány egyidejű működése.
Ráadásul a küldés is leegyszerűsödik (legalábbis a kód része), és nem kell használnom azt a hatalmas és komplikált irlib-et, ami nem is kimondottan erre való.
Viszont ahhoz, hogy a soros kimenetet tudjam használni, kelleni fog egy AND kapu, vagy egy hasonló működésű logika + egy 38kHz pwm-met kell valahogy előállítani. -
válasz
tvamos
#10475
üzenetére
De én nem a visszavert jelet akarom dekódolni! Az egyik roboton lesz az adó, a másikon a vevő.
Ha különböző frekvenciájú ir vevőkkel különböztetném meg a robotokat, akkor nem tudnám bővíteni a rendszert, vagyis nem tudnék kettőnél több robotot építeni. Lehet, hogy nem is fogok soha, de azért a lehetőséget szeretném meghagyni rá.
![;]](http://cdn.rios.hu/dl/s/v1.gif)
Azt hittem, hogy ez egyszerű dolog: addig növelem a frekvenciát, amíg már nem tudja fogni a vevő a jelet, de tévedtem: gyakorlatilag minden frekvencián képes fogni a jelet, 2kHz-től 100kHz-ig. 
Viszont vannak frekvenciák, amikre kevésbé érzékeny, ezeket vagyok kénytelen használni.
A hibás adatot felismeri a rendszer és eldobja.
Új hozzászólás Aktív témák
Hirdetés
ekkold- Telekom otthoni szolgáltatások (TV, internet, telefon)
- D1Rect: Nagy "hülyétkapokazapróktól" topik
- Elektromos autók - motorok
- Kerékpárosok, bringások ide!
- AMD K6-III, és minden ami RETRO - Oldschool tuning
- Motorola Edge 50 Ultra - szépen kifaragták
- Apple Watch Sport - ez is csak egy okosóra
- NVIDIA GeForce RTX 5070 / 5070 Ti (GB205 / 203)
- Egyre csak fejlődik az AI, emberek tízezreit rúgja majd ki a BT
- Győr és környéke adok-veszek-beszélgetek
- További aktív témák...
- Nitro ANV15-41 15.6" FHD IPS Ryzen 7 7735HS RTX 4060 32GB 1TB NVMe gar
- ASRock RX 5700 XT 8GB GDDR6 Phantom Gaming D OC Eladó!
- SilentiumPC Signum SG1 TG
- ThinkPad T490 27% 14" FHD IPS i7-8565U 16GB 512GB NVMe ujjlolv IR kam új akku gar
- X1 Tablet Gen3 13" 3K IPS érintő i7-8550U 16GB 512GB NVMe ujjlolv IR kam 4G LTE gar
- Samsung Galaxy A14 64GB, Kártyafüggetlen, 1 Év Garanciával
- DELL Precision 7540 - Intel Core i9-9980HK, RTX 3000 (nagyon erős GPU-val)
- Gamer laptop felvásárlás Magas áron, gyorsan és egyszerűen!
- Apple iPhone 13 256GB Kártyafüggetlen, 1Év Garanciával
- Billentyűzet magyarosítás magyarítás lézerrel is! 10-15ezer közötti áron! Óriási betűkészeletünk van
Állásajánlatok
Cég: CAMERA-PRO Hungary Kft
Város: Budapest
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest