Hirdetés
- iPhone topik
- Miért fárad gyorsabban az iPhone akku, mint az androidos?
- „Új mérce az Android világában” – Kezünkben a Vivo X300 és X300 Pro
- Milyen okostelefont vegyek?
- Kis méret, nagy változás a Motorolánál
- Samsung Galaxy Z Fold7 - ezt vártuk, de…
- Fotók, videók mobillal
- Xiaomi 15T Pro - a téma nincs lezárva
- Samsung Galaxy S25 - végre van kicsi!
- Samsung Galaxy Z Flip5 - ami kint, az van bent
-
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
-
Használta már itt valaki a SPIFFS fájlrendszert esp32-n? Sqlite adatbázist próbálok használni rajta, az olvasás hibátlanul működik, de az írás nem. Ha írok az adatbázisba, hiba nélkül lefut a kód, de 3ból 2x a kiírt adat egyszerűen elveszik. Néha viszont sikerül írni az adatbázisba és az adat is megmarad.
Néhány írási próbálkozás után pedig néha lefagy az egész esp! Hiába túrom a netet, semmit sem találok a témában. Egyszerűen nem tudok rájönni, hogy hardverhiba, bug valamelyik lib-ben, vagy én rontok el valamit a programban. Talán vmi flush parancs kellene, hogy kírja a változásokat, de egyik példakódban sincs nyoma, hogy létezne, vagy hogy használni kellene... -
válasz
Victoryus
#11142
üzenetére
Milyen library-vel próbálod ezt a shield-et használni a Wemos d1-el? Az uno-hoz való adafruit-ossal?
Az alsó sor jobb szélső két pin az SDA SCL, ugyanez duplázva a felső sor bal szélső két pin-en.
A lolin32-vel vigyázz, mert ezen a shield-en ha jól tudom rajta vannak az i2c felhúzó ellenállások, amik 5V-ra húzzák a pineket, de amíg az esp8266 gpio-i 5V toleránsak, az esp32 kimenetei állítólag nem azok. -
-
válasz
Breaker
#11118
üzenetére
Vettél egy 800mAh lítium akksit, amit egy belső step‐up converter 9V‐ra konvertál, így már csak 300mAh körül képes leadni, ha jóindulatú 90%‐os hatásfokkal számolok (ha 70%‐al számolok, akkor már csak 230mAh!). Ezt visszakonvertálod 5V‐ra (majdnem a felét elfűti), amit a D1 még lekonvertál az onboard konverterével 3,3V‐ra (még elfűt belőle egy kicsit). Jól értem?
-
Vettem nemrég egy wire wrap tool-t, nem is gondoltam, hogy én is ilyen menő kötéseket tudok majd vele csinálni.
-
Kedves esp32 szakértők! Egy játékot készítek most lolin32-vel (végre találtam neki egy jó kis feladatot
), néhány gpio-t bemenetként akarok használni rajta internal pullup-al, okozhat-e gondot, ha ezek a boot alatt közvetlenül GND-ra vannak kötve?
Ennek az oldalnak a leírása alapján olyan lábakat néztem ki, amik állapota nem zavarja a boot-ot, nincs se fel, se lehúzva és nem ad ki rajta PWM jelet se boot közben (16,17,18,19,23). A kérdés inkább arra irányul, hogy boot közben ezek a lábak hi-z állapotban vannak-e, vagy nem, utóbbi esetben tegyek-e áramkorlátozó ellenállást a GND és a bemenetek közé. -
válasz
gyapo11
#11080
üzenetére
Sajnos azt nem tudom, de vannak régebbi, laptop akksiból bontott celláim, amik a névleges kapacitás felét, 2/3-át tudják még, de normális minőségű (Xtar vc-4) li-ion töltőben töltve soha nem áll le a töltés, viszont elkezd melegedni a cella. Ezekből a cellákból használok 8db-ot egy power bank-ban (több mint 2 éve), de abban töltve sem áll le soha a töltés, az elektronika nem érzékeli, hogy 100%-on vannak a cellák, csak elkezd melegedni az egész, úgyhogy nekem kell lehúzni a töltőről, mielőtt kigyulladna.
Ebből én arra következtetek, hogy ezen a feszültségen létezés az akku természetes tulajdonsága, lehet hogy árt neki
Nem, a teljes töltöttségen tartózkodás hosszú távon károsítja, nem véletlen, hogy a li akksikat 40% körüli töltöttséggel tárolják és szállítják.
-
válasz
Attix70
#11075
üzenetére
Ha mindenki csak arra válaszolna, amihez ért, akkor most kit oktatnátok ki habzó szájjal?
Semmi megalapozatlant nem írtam, csak felhívtam a figyelmet valamire, ami a nagytudásúak figyelmét elkerülte, tudniillik ha teszem azt egy 500mA töltőáramú egységre köt 4cellát, és az a töltőáram 1/10-énél kapcsol le, az 12,5mA cellánként, egy gyengébb minőségű vagy elhasználódott cella ennyit feltöltve is képes folyamatosan felvenni, nem áll le a töltés, véletlenül éjszakára rajta hagyja, reggelig ki is gyulladhat. Melyikőtök vállalja érte a felelősséget?
"Ez persze hosszú távon valamelyest csökkenti az akku élettartamát"
Mert ez aztán egy szakmailag megalapozott, szakszerű tanács. Gratulálok. -
"Az okosabb töltők lekapcsolnak a
kezdeti töltőáram x (általában 10) %-ánál"Hát nem pont erről beszélek? Két cella -> fele töltőáram -> hosszabb töltési idő kisebb árammal, mert a töltőnek senki se szólt, hogy most a 20% a 10%.
"de ez nem jelenti azt, hogy ennél
kisebb árammal tovább töltve (továbbra is max. 4,2V-on) tönkremenne az akku."Pedig pont ez történik, a lítium alapú cellák nem bírják a csepptöltést (szemben a Ni-MH-del, aminek még jót is tesz). Kristályosodás indul meg bennük gázfejlődés kíséretében, és előbb-utóbb zárlatosak lesznek. Eleve az sem tesz már jót egy lítium alapú akksinak, ha túl sokáig van 90%-os töltöttség felett.
(És még én ragadtam le a Ni-Cd/Ni-MH akkuk töltési mechanizmusánál...)
-
válasz
Teasüti
#11069
üzenetére
Sejtettem.
De megnéztem mégegyszer a kódot, és megvan a hiba.
pinMode(button, INPUT_PULLUP);
}
void loop ( )
{
bool buttonState = digitalRead(button);
if (buttonState == HIGH)
{Stateállapota, mivel adigitalRead(button);mindig magas értéket ad, de a gomb azINPUT_PULLUPmiatt eleve magasan van.
if (buttonState == LOW)esetén a kód működni fog, persze ha a gomb jól van bekötve. -
válasz
vargalex
#11059
üzenetére
A másik pedig, hogy a töltő az áramfelvétel csökkenése alapján figyeli a töltöttséget, és több akkunál, még ha történetesen egyformán is veszik fel a töltést, annyifelé oszlik ez az áram, ahány akksi össze van kötve. Így könnyen túl lehet tölteni a cellákat, mert nem áll le a töltés időben.
-
#11058
Aryes
nagyúr
---gabika---
#11057
válasz
---gabika---
#11057
üzenetére
Első körben cseréld ezt a sort:
if (buttonState == HIGH)
erre:
if (buttonState == true)
mert a bool változónak nincs olyan állapota, hogyHIGH, de ha mégis lenne, akkor viszont a pergésmentesítés hiánya lehet még a probléma. -
-
válasz
zsolti_20
#11002
üzenetére
Én ezt a Tescoban vettem, úgy 4 évvel ezelőtt...
De például ez itt tudja. De vigyázz, mert ez csak egy ház, az akksit neked kell bele előteremteni!
"charging and discharging at the same time" <- ezt keresd a leírásban.
Ez a linkelt olyan jól néz ki, lehet én is veszek egyet. :) Van már egy hasonló, 8db cella fér bele, de az például nem tud egyszerre tölteni és töltődni. Bontott laptop akksi cellákat tettem bele. -
válasz
lac14548
#10984
üzenetére
Puff neki...
Elvileg az adat vonalnak nem kellett volna károsodni, ha tudsz szerezni külső tápos usb hub-ot, esetleg tegyél egy próbát vele, hátha csak a táp része égett meg. Laptop vagy asztali gép? Szerencse, hogy az alaplapot nem vitte magával.
Hogy lehet, hogy polyfuse nélkül is kiadnak arduino-t? Úgy emlékszem, ami nekem van nano, azon is van. De lehet rosszul emlékszem. Annak idején kezdő koromban ezek szerint sokszor megmentette a gépet az uno-n lévő polyfuse, amikor rajta felejtettem egy motort. Akkor csak bosszankodtam rajta, hogy lekapcsolta magát a lap, pedig rosszabb is lehetett volna ezek szerint... -
válasz
lac14548
#10982
üzenetére
"A windows-os Arduino nem látja."
A gép usb portját már tesztelted?
A linkelt képen nem látszik a polyfuse, ami a portot védi a túlterhelés ellen, ha a másik oldalán sincs, akkor könnyen lehet, hogy nem a nano, hanem az usb port f.ngott ki... A szervo akár túl is terhelhette. -
válasz
ecaddsell
#10937
üzenetére
Én smd-re nem használnám, de pl. chip lábakat beforrasztani kevesebb tököléssel járna, talán szebb lenne az eredmény még egy egyszerű pillanatpákával is. Most külön bekenem a nyákot tisztítás után a zsírral, ha ügyes vagyok, mindenhová egyformán jut, de általában nem. Utána takarítani kéne, de nem igazán megy.
-
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.
Elvileg az adat vonalnak nem kellett volna károsodni, ha tudsz szerezni külső tápos usb hub-ot, esetleg tegyél egy próbát vele, hátha csak a táp része égett meg. Laptop vagy asztali gép? Szerencse, hogy az alaplapot nem vitte magával. 
![;]](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
ekkold- PlayStation 5
- Elektromos autók - motorok
- Telekom otthoni szolgáltatások (TV, internet, telefon)
- Kerékpárosok, bringások ide!
- Mesterséges intelligencia topik
- sziku69: Fűzzük össze a szavakat :)
- Luck Dragon: Asszociációs játék. :)
- Vicces képek
- Milyen asztali (teljes vagy fél-) gépet vegyek?
- iPhone topik
- További aktív témák...
- Microsoft Surface Hub 2s - Interaktiv 4K monitor/ All in one PC - I5 8. generációs - Piaci ár alatt
- Benq - LU951- 5000 Ansi Lézer projektor - Piaci ár alatt
- -ÚJ,2 ÉV GAR- GAMER PC: i5-14400F (10mag/16szál) +RX 6600/6700XT +16-64GB DDR4! SZÁMLA! 70 féle ház!
- Capriolo Oxygen 29" MTB Új
- DJI Convertible Carrying Bag + Ajándék DJI rádió nyakpánt
- Bomba ár! Dell Latitude E5450 - i5-5GEN I 4GB I 320GB I 14" HD I HDMI I Cam I W10 I Gari!
- MacBook felváráslás!! MacBook, MacBook Air, MacBook Pro
- Targus DOCK423A - USB-C Dual HDMI 4K HUB - 2 x HDMI (120Hz)
- Gamer PC-Számítógép! Csere-Beszámítás! R5 8400F / RX 6800 16GB / 32GB DDR5 / 1TB SSD
- HIBÁTLAN iPhone 15 Pro Max 256GB Black -1 ÉV GARANCIA - Kártyafüggetlen, MS3495, 100% Akkumulátor
Állásajánlatok
Cég: Laptopműhely Bt.
Város: Budapest
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest