Fórum témák
» Több friss téma |
Hát igen. Találtál valamit, és úgy gondolod, hogy már mindent tudsz. Csak sajnos ami olyan egyszerűnek tűnik, az szokott a valóságban rettentő bonyolult lenni. Azok a képletek, amikre rátaláltál, általános érvényűek, és lég-, és végtelen üres térre vonatkoznak. Azonban itt a földön ilyen nincs, mert van légkör, a maga változatos tulajdonságaival, közelben a föld, mint egy ilyen olyan, lépésről lépésre változó elektromos tulajdonságokkal, no és épületek, emberek, járművek, növényzet stb. stb.
Először is kétféle "üzemmód" szokott lenni a rádió összeköttetések terén. Állandóhelyű, és mozgó, egy, és kétirányú, jelentős eltérésekkel az összeköttetés tulajdonságaiban, ezért más más eljárásokkal kell a számításokat elvégezni, amikben jelentős eltérések vannak, és leginkább statisztikai adatokkal jellemezhetők. A szakaszcsillapításos eljárás a mikrohullámú állandóhelyű összeköttetések számítási módszere, a mozgó összeköttetéseknél a besugárzás számításokat kell alkalmazni, ahol aztán tényleg minden változik, és a legtöbb jellemző egy statisztikai átlagszám.
Mint írtam, RF modulok kiválasztásához kellett valami elméleti képlet. Csak nem akartam mind a 8-at amit megnéztem megvenni. Pontosan tudom, hogy semmit sem tudok. (volt olyan modul, amilyet láttam már élőben: max 30-35-m-t vitt át beltéren erre meg kijött a Friis-egyenletből 13+ km (!)
  )... Megveszek ez alapján egy adó/vevő párt majd nekiállok mérni.Kaptam egy másik linket is, hogy itt: http://www.arrl.org/ nézzek még körül. pucuka: Ha van valami anyagod mozgó berendezésre azzal segítenél. :yes:
A helyzet az, hogy a modulok kimeneti teljesítménye korlátozva van. Így az jelentősen nem befolyásolható, ugyan igazából nem is nagyon van rá szükség. Ahogy tapasztaltad a képlet szerint elég nagy távolságot át lehet hidalni vele, legalábbis elméletben. A gubanc abban a bizonyos szakasz csillapításban rejlik, ugyanis ennek a meghatározása a körülményes, és felettébb bizonytalan. 10 - 20 dB -es eltérés igen könnyen adódik a környezeti tulajdonságokból, amit 10 - 100 szoros adóteljesítménnyel tudsz kompenzálni, amennyiben a vevő érzékenységet már kihasználtad.
Amit tehetsz, az annyi, hogy olyan párt választasz, ahol az adatátvitel FSK, a vevő pedig szuperheterodin rendszerű. Ezek nem a legolcsóbb fajták, de megéri a befektetés, és jó antennával, szabad rálátással jó eredményt érhetsz el. Olyan nagy távolságra modellezésnél meg nem igazán van szükség, csa addíg, amíg a modelledet egyáltalán látod, addíg meg a rádióhullám is biztosan elmegy.
Sziasztok! Nem tudom ki foglalkozott már HM-T868S és HM-R868S modulokkal, de én most kifogtam őket. Mindkettőt 1-1 pic-kel hajtom, adó oldalon egy 16F877-es küldi másodpercenként az "ON" majd az "OFF" karaktersorozatot. Vevő oldalon egy 16F628A figyel. Ha "ON" érkezik világít egy led, ha OFF akkor nem. Ez mind működik is, addig amíg az adó pic TX és a vevő RX lába egy vezetékkel össze van kötve. De amint az adatot a levegőben kellene átvinni nem működik. Van valami konfiguráció amit el kell végezni adó vagy vevő oldalon? 2400 baud-ra van állítva mindkét oldalon a sebesség...
A kulcsszó: Manchester kódolás. UART közvetlenül nem ad használható eredményt rádiós/infra modulokal.
Hello!
Én is ilyet használtam a kapu nyitomhoz tökéletesen müködik. Annyi különbség én AVR használok,de szerintem nem sokat változtat..ha mégis akkor bicsi szóval... Simán kapcsold az adó PIC Tx lábát ado modul tx lábához nem kell tranyó semmi más csak simán össze kell kapcsolni. A vevő oldalon is szintén így kell eljárni PIC Rx lábát a vevő modul RX lábával. Az Enable lábat 5Vra kell felhúzni és kész is vagy. Sima soros kommunikációt használok (Fizikus leírása) karaktert küldök ki majd ha vevő oldalon megegyezik akkor csinálja amit kell...
Szia!
Pontosan így van bekötve nálam is, de valamiért a vevő oldalon, nem jól érkeznek meg a karakterek. Vagy csak én vagyok hülye. Egyelőre Bonca segít privátban rájönni a hiba okára, most ott tartunk hogy a az első karaktersorozat ami "ON", meg is érkezik, ennek hatására egy LED világít is, viszont a 2000ms-al később érkező "OFF" már nem jön át... Vevő oldalon így néz ki a progi fő része:
Adó oldalon az ON illetve OFF előtt kiküldésre kerül 10 db "Z" (hogy a vevőnek legyen ideje felébredni, Bonca cikkében le van írva miért kell ez) ezért kell az az elágazás ami a Z-től különböző karaktereket figyeli. Tehát az "ON" esetén RB4-en LED bekapcs, "OFF" már nem jön össze sehogy...
Nos közben meglett a megoldás, nincs manchester kód meg egyebek, mindössze 10x küldöm ki az adott karaktereket. Mivel a vevő elég lusta
 így kell egy kis idő mire feléled. Ajánlom mindenkinek aki hasonló gondokban van E Z T a cikket, mert nagyon sokat segített! És mehet az 5 csillag értékelés is!
Ha elkészülsz a termosztáttal, írj egy cikket. Azt is sokan tudnák hasznosítani.
Bonca
Szia! Sajnos nekem is ez az adó-vevő pár került a kezeim alá, viszont nem tudom, hogy normális dolog-e az, hogy ha az adó data lába a földre van kötve, akkor a vevő data lábán valami jel van. Nagy valószínűséggel valami zavar jel. Neked nem voltak gondjaid ezzel? Üdv.: Petya
Normális. Nem zavarjel, hanem zaj. Ha jön jel akkor megszűnik.
Nem tudom. A vevő data lábára tettem egy ledet, ha a vevő nem küld semmit akkor is világít. Ha küldök egy jelet akkor előbb fényesebben világít aztán elalszik egy időre, majd megint világít. Létezhet hogy ekkora nagy legyen a zaj? Csak ezt így nem tudom felhasználni mert akkora hogy a pic sokszor logikai 1-nek nézi...
Az imént volt egy érdekes élményem. Próbálgattam jelet küldeni a vevőnek, amikor egyszer csak elaludt a led. És csak akkor világított amikor az adónak felhúztam tápra a data lábát... Magyarul úgy viselkedett ahogy kellene
 Az egyetlen probléma, hogy próbaképp kihúztam a tápot és ekkor vissza állt eredeti állásba, tehát megint folyton világít a led...
Szia! Nem tudom te PIC-kel akarod-e hajtani vagy sem, de ha PIC-kel csinálod akkor csak ennyit kell tenned, hogy az PIC TX lábád az adó DATA lábára kötöd, vevő oldalon pedig a vevő DATA lábát a PIC RX lábára. Egyelőre csak próbapanelon próbáltam ki a modult, de az már biztos, hogy 10x el kell küldeni az adatot ahhoz, hogy legalább egyszer meg is érkezzen hiba nélkül a vevő oldalon!
Ez nem törvényszerű, hogy 10x kell küldeni, függ sokmindentől. Én 2 bájtot küldök 3-szor (és ezt percenként ismétlem) egy külső hőmérőtől, mindig megérkezik az adat. Üdv!
Egyetértek Panhard-dal.
Dave87, peti13! Olvassátok el ezt a topikot az elejétől és főleg olvassátok el Topi írását. Pontosan benne van, hogy ezeknek a moduloknak mik a korlátai és miért. Az is, hogy hogyan lehet mégis megbízhatóan használni, miért érdemes a soros adatátvitellel byte-okat küldeni és miért kell azt valami formába kódolni. A manchester kódolás egyfajta megoldás arra, hogy ne kerüljön több 1-es vagy 0-ás bit egymás után a küldendő adatba. Nem kell tőle idegenkedni, mert rém egyszerűen megoldható, csak egy előre megírt tömbből kell a félbyte-oknak megfelelő mintát kivenni. Pl. kódtábla:
Pl. kódolás:
Pl. dekódolás:
Én sem írtam, hogy törvényszerű lenne, a saját példám alapján írtam le a tapasztalataimat.
MPi-c: A manchaster kódolással nem foglalkoztam még, de jelenleg nekem hibátlanul működik az adatküldés.
Nem is a manchestertől fog jól működni, inkább attól, hogy a küldött adatban ne legyen sok 1-es vagy 0-ás bit egymás mellett, ennek okát Topi cikke írja.
Sziasztok !
Nekem ez bejött ! Lakáson belül simán gyüjthetem az adatokat. Egy ócska PC soros portján veszem több adó jelét, és a program kiszűri a hibákat, vagy az adók összeveszését ! A mellékelt program rövidítve csak egy csatornát mér, de 887-be ugyan így egy 8 csatornás mérőt is építettem. ( A rajzról lemaradtak a +5 Voltokra kötendő 47µF -os kondik.)
Nem az a baj, hogy miként kódolod, hanem a vevő "lustasága". Dave-nek azért kell tízszer küldenie ugyanazt az adatot, mert neki is kb. 40 ms múlva éled fel a vevő. Az is jó megoldás lenne, hogy 40 ms-ig küldi az ASCII "U" karaktert, majd egyszer a hasznos adatot. Nekem szintén ez volt a jó megoldás. Ha ezután nincs folyamatosan logikai 1-ben az adatláb kb. 80 ms-ig, akkor már elegendő egyszer is adatot küldeni, tökéletesen venni fog a vevő. Akkor van baj, ha pl. az ASCII "Z" karaktert küldöd több, mint 80 ms-ig, mert az a folyamatos logikai 1. ilyenkor a vevő tétlenséget feltételez, és alvó állapotba kerül. Az ilyen speciális esetekre valóban jó megoldás a manchester kódolás.
Ezeket a késleltetéseket én is a szkópos méréseknél láttam, ahhoz igazítottam a programokat. Az adó és a vevő adatlapja nem írt erről semmit.
ASCII "Z" helyett ASCII 255-öt akartam írni.
Köszönöm a válaszokat, Topi cikk-jét már többször is elolvastam. Igen, PIC-el szeretném a dolgot elintézni, de azt szeretném kérdezni a többi kollégától aki a HM-R és HM-T párost használja, hogy nektek is, alapállapotban amikor nincs semmi adás, akkor a vevő data lába folyamatosan logikai szintet vált? Arra számítottam, hogy lesz valamennyi zaj, de ennyi?
Elképzelhető, hogy a környezetében ezen a frekvencián működik valami: termosztát, csengő, belső telefon... Onnan szedhet össze zajt.
Bonca
Az FSK moduláció is olyan, mint egy FM moduláció. Mivel A vevő érzékenysége zajhatárig ki van használva, (ez az előnye, hogy igen érzékeny) vivő hiányában a vevő kimenetén erős (fehér) zaj jelenik meg, amiből a vevő kimeneti jelformálója véletlenszerű digitális jeleket kreál. Az FM készüléket is ha elhangolod, megnő a zaj, csak azt hallod. Erre a feladatra van a zajzár, hogy ne legyen zavaró. Az ilyen dolgok miatt is kell használni vonali kódolást, hogy a mikrovezérlő tudja, hogy mikor jön érvényes adat, és mikor csak zaj.
Sziasztok!
Felmerült egy kérdés: Szerintetek hogyan lehetne megoldani, hogy a videokártya D-Sub jelét Composit jellé alakítva egy ilyen kis adó-vevő párossal lehessen továbbítani? Mik kellenének hozzá?
Ezeknek az adó vevő párosoknak az adatátviteli sebessége nem elegendő vídeójel továbbítására sem analóg, sem digitális módban. Amúgy hang és kép átvitel nem engedélyezett ebben a sávban, pontosan a nem elegendő rendelkezésre álló RF sávszélesség miatt.
Máskülönben miféle jel az a D-Sub?
Ha jól tévedek akkor ez: VGA cable pinouts
A csatlakozó típusa a SUB-D. Többféle pólusszámal létezik.
|
Bejelentkezés
Hirdetés |
