Fórum témák
» Több friss téma |
Kipróbáltam a a Clock állítását és legnagyobb meglepetésemre működött. Nagyon hálás vagyok ezért jó tippért. Magamtól nem jutott volna eszembe egy olyan paramétere sem, aminek a változtatása ilyen jól mérhető.
Viszont a Status olvasása továbbra sem működik. Van még esetleg valami láb, amit valahova kell kötni vagy valamilyen szintre húzni? Előre is köszönöm a segítséget.
Nagyon problémás a doksija az RFM01-RFM02 moduloknak. A példakódok pedig nem igazán működnek és sokszor nem is dokumentáltak. Pl: az adást végző példakód:
Azonban ha a mikrovezérlő pl. egy avr és ne adj isten a frekije sem túl magas (mondjuk a gyári alapértelmezett 1 MHz), akkor nem működik jól. A miértre csak egy nagy nehezen fellelt doksi alapján jöttem rá: a felfutó élre állítja az FSK, és utána várakozik. Viszont a felfutás után az 1-es ideje nagyon rövid (1.6 us) és könnyen előfordulhat, hogy a mikrokontroller kihagy egy-egy ilyen "tüskét". Magyarázata: Az assembly kód:
viszon az rjmp 2 órajel ciklus igényel, aminek az ideje 1MHz.es órajel esetén 2 us, ami több mint a tüske ideje.
A doksi képe lemaradt (nem szerette a png-t).
Sziasztok. Én is az RFM01-RFM02 adó-vevő modulal bajlodok. Szoftveres SPI-n müködik rendesen, de nekem hardveres SPI kell a megszakítás miatt. Hardveres SPI-n addig eljutottam, hogy inicializálom a vevő modult és az vár a szinkronizáló szavakra és utana bevadul, mind hülyeséget fogad. A FIFo 8 bitre van állítva, és megszakitás lesz ha eléri a 8 bitet az nIRQ alacsony szintre megy , az FFIT pedig magas szintre. Mindkettövel probáltam de semmi. A meszakitásokat a microvezérlő külső megszakítás vonalára kötöttem és az éleket figyelem. A modulok beállitásai azok amiket a HOPE adatlapjaban van. Átböngésztem az IA4320-as adatlapot is abban több mindenre jöttem rá de ugysem megy. Még pobálkozom, de jólenne valami öltet.
Sikerült megoldani a Status olvasás problémáját. Aki szintén ilyesmivel küzdenek javaslom, hogy először állítsák be úgy az eszközt, hogy a regiszterben legyen is valami érték és ne feledkezzenek meg arról, hogy sok bit olvasáskor törlődik.
 Viszont elő jött egy másik dolog: aki az SMD verziót használja milyen antennát tervezett hozzá?
Hali!
Az ideális antennahossz az a negyedhullám. 433MHz re 17,3cm .Mivel ez túl hosszú, lehet rövidíteni, de ekkor egy soros tekercs kell még. Talán valamelyik adatlapban van hozzá adat.
Helló!
Valaki nem tudja véletlenül, hogy az RGUR bit (Register Under Run) konkrétan mit is jelent? Én sajnos nem jöttem az adatlapból.  Előre is köszi! Üdv.: Gábor
Hello!
Vételi problémám van az RFM12B adó-vevővel, de nem RF probléma hanem kommunikációs szerintem. Egyik modullal küldök valamit egy másiknak, akkor amelyik vételen generál egy IRQ-t, ez a láb a PIC RB0-ás portjára van kötve, ami lefutó él interruptra van beállítva. Amint kapok IT-t lekérdezem az RF modul státusz wordjét, amivel eddig semmi probléma, szépen látom, hogy RX FIFO IT jött amit le is kezelek A probléma a SPI CLK beállításánál kezdődik, véletlen 100kHz-es órajel helyett ~65kHz-eset állítottam be (ez úgy lehetett, hogy egy regiszterbe 79 decimális szám helyett 0x79-et állítottam be). Szóval ha ~65kHz az órajel, akkor a képen látható jeleket kaptam: 65kHz_SPI_com_IRQ.bmp Viszont ha megnövelem 100kHz-re akkor valamiért a modul elengedi a IRQ lábat, majd egy kicsit később újra lehúzza ezzel generál egy újabb IRQ-t ami ismét le is kérdezek amit végzett a FIFO kiolvasásával, ez látható a következő ábrán: 100kHz_SPI_com_IRQ.bmp A kommunikációt jobb felbontásban ez a fájl tartalmazza: 100kHz_SPI_com_IRQ_zoom.bmp Valaki találkozott már hasonló problémával? Sajnos én nem jövök rá miért húzza újra le a modul az IRQ lábat, hisz az RX FIFO flag eltűnésén kívül (ami egyébként normális hisz elkezdem olvasni a FIFO tartalmát) nincs más változás.
Hello!
Sajnos nekem is csak tippen van. Valószínű hasonló lehet mint pl UART-nál: Bővebben: Link Itt a következőt írja: Idézet: „Underrun error An "underrun error" occurs when the UART transmitter has completed sending a character and the transmit buffer is empty. In asynchronous modes this is treated as an indication that no data remains to be transmitted, rather than an error, since additional stop bits can be appended. This error indication is commonly found in USARTs, since an underrun is more serious in synchronous systems.” Tehát valami olyasmi, hogy küldés közben kiürült a TX buffer, bár erre van külön bit, az RGIT, de talán nem 100%-ba azonos a jelentése.
Jó ötlet összehasonlítani az USART-tal. Valóban olyasmi lehet. Kösz szépen!
Sziasztok. Nezegettem, milyen lehetosegek vannak a drotnelkuli ket iranyu komunikaciora es elsore a Zigbee tetszett, de meg az alapfogalmakban sem konnyu kiigazodni. Aztan ratalaltam az RFM12-re es az lenne a kerdesem, hogy erdemes-e beleasnom magam, vagy van valami jobb, ami kelloen egyszeru, de jol mukodik. Esetleg tul bugos ez a modul? A ketiranyu komunikacio hogy van megoldva? Honnan tudja az egyik modul hogy mikor adhat, es addig mit csinal az adatokkal, vagy mi tortenik ha tobb ilyen mukodik 1 frekvencian? Koszi elore is az utbaigazitast.
Egyebkent ezt talaltam az RFM12-hoz (ha valakit erdekel): http://blog.strobotics.com.au/2008/01/08/rfm12-tutorial-part1/
Ha kétirányút szeretnél, akkor ez a megoldás, ráadásul SPI vezérlése van. Ide kötheted a mikrovezérlők SPI csatoló felületét. Ezen keresztül lehet a modult konfigurálni is, valamint az adatokat is küldözgetheted. A kommunikációt a két mikrovezérlő irányítja egyébként is.
Csak az a lényeg, hogy a vevő közvetlen környezetében ne legyen azonos frekvencián ugyanilyen kommunikáció lehetőleg. A két mikrovezérlő azonosítását is meg kell oldani a kommunikáció részeként.
Sziasztok!
Vettem 2db TRX 433 modult, amiről időközben kiderült, hogy =rfm12b. Az spi-n minden szépen látszik, az adó oldal küldi az RF csomagokat, de a vevőt egyelőre nem tudom életre lehelni. Az spi ott is ketyeg, csak épp a fifo üres, mint a tök.) A két modulnak azonosak a beállításai, de a pll, stb. beállításokban nem vagyok biztos. Néztem példaprogikat is, de azokkal sem jutottam előrébb. Várom a jobbnál-jobb ötleteket!
Hello
Egy robotos projektben szeretnék használni RFM23B rádiós modulokat. A kommunikáció jól működik, de ha működnek a DC motorok, akkor egy idő után nincs vétel. A roboton a mikrovezérlő galvanikusan le van választva a motorok teljesítmény meghajtójától (optocsatoló). A motorok egyébként PWM-mel vannak meghajtva. Ha a motorok meghajtója ki van kapcsolva, akkor a vétel jól működik, szóval ilyenkor a PIC bekapcsol egy LED-et. Ha viszont a meghajtó be van kapcsolva, és a motorok nem alacsony fordulaton járnak, akkor 3-4 másodperc működés után már nincs vétel. Az adó oldalon hiába tolom a joysticket, nincs vétel. Az általam használt rádiós modulnak van 3 programozható IO lába, az egyik nekem Valid Sync Word esetén aktív. Nos, erre a lábra is tettem egy LED-et, motorok nélkül működés közben ez világít, viszont amikor megdöglik a vétel, akkor már ez sem. Szkóppal ránéztem az RF modul tápjára. Működés közben 2 mV-os tüskéket generál maga az RF modul, de abban a pillanatban, amikor abbamarad a vétel, 20-50 mV-os kilengés is megfigyelhető. Gondolom ez lesz a baj, nyilván elektromágneses zavar a motorok miatt. Nos próbáltam kerámia és párezer mikrós kondenzátorokat tenni a tápra, közel a modulhoz, de nem segített. A motorok sarkain 100nF-os kondenzátorok vannak, és maga a robot váza alumíniumból van. Mit lehetne kezdeni ezzel? Üdv.
Szia!
Szerintem jól sejted, véleményem szerint is EMC problémával állsz szemben. Azt kellene kideríteni, hogy vezetett vagy sugárzott zajról van szó. vezetett zaj esetében a hidegítő kondik segíthetnek, de a µF-od felejtsd el ebben az esetben, pár nano (max 100nF), de lehet, hogy pikofaráddal kell próbálkozni. Milyen PWM frekit használsz a motor hajtására? Ha sugárzott zajról beszélünk akkor pedig a hosszú nyák vonalakat kellene megnézni, kommunikáci (SPI), stb. amik antenna ként működhetnek. Valamint a motor vezetékek a lehető legrövidebbek legyenek. A forrás felderítéséhez nem lenne rossz egy spekrum analizátor. Javaslom, hogy a táp vezetékeket hidegítsd mind a két oldalán pár nanoval. A sugárzott zajnál pedig próbálkozhatnál árnyékolással, pl az RF modul teljes árnyákolásával, úgy, hogy csak az antenna legyen kívül. Esetleg egy kapcsolási és nyák rajz is jó lenne, hát ha eredményesebben tudok/tudunk segíteni.
Hello
Kipróbáltam valamit: A motor meghajtót kikapcsoltam, az adón toltam a joysticket. A vevő vett szépen. Ezután egy kicsi DC motort elemről táplálva odatettem a vevő mellé, és nem történt semmi. A vevő vett tovább (világított a LED ). Azt hiszem a probléma oka az lesz, hogy a váz fémből van és az közvetíti a zajt. Bővebben: Link Így néz ki a majdani robot, de itt még RFM12B modult használtam, megjegyzem azért tértem át RFM23B-re, mert az ugyanezt a hibát produkálta, mint a mostani... Üdv.
Sziasztok!
Néhány napja kezdtem el élesztgetni egy pár RFM12B modult az itt található PIC24-es függvénykönyvtár kis módosításával, és eljutottam addig, hogy át tudok lőni információt az egyik modulról a másikra. A probléma az volna, hogy nem egészen stabil az adatátvitel. Egy breadboard-ra van felszerelve a két modul, egy-egy PIC16F884 hajtja őket teljesen azonos kapcsolásban (egyik adó, másik vevő). A vevő 4 byte-nyi információ vétele után átmegy ledvillogtatásba, és kiírja a rákötött LCD-re a kapott adatot. Az adó reset után elküldi a 4 byte-nyi információt (természetesen keretezve), utána ő is végtelen ledvillogtatásba kezd. Először resetelem a vevőt, aztán az adót, így a vevő nem késik le az adásról. A gond az, hogy a vevő nem mindig kapja meg a csomagot, többször kell resetelni az adó PIC-et. Ellenben ha megkapja az információt, az hibátlanul érkezik meg. Nekem kicsit olyan, mintha a vevő nem mindig hangolódna rá automatikusan az adás frekvenciájára, viszont ha megteszi, akkor hibátlanul megérkeznek az adatok. Próbáltam több 0xAA-t küldeni a fejlécben, hátha az AFC könnyebben beállítja magát, de nem lett jobb. Valakinek van valami ötlete, hogy mi lehet a gond? szerk: A PIC-ek 4MHz-s belső órajellel mennek, a választott adatátviteli sebesség 4800 kbps. A vevő kicsit inkorrekt módon kizárólag a nIRQ kivezetés lefutó élét vizsgálja, de a modul nem húzza le azt, amikor nem érzékeli az adást. Egyébként a szokásos beállításokat használom, ami mindegyik példában meg van adva.
Lejjebb vettem az átviteli sebességet 1200-ra. Így is elvész egy-egy packet, de sokkal ritkábban (olyan 20 packetenként egy).
Hali mindenkinek.
Látom látom vannak itt szépszámban rfm12-s tulajok. nekem most most meg 2 db 868-s a kérdésem az lenne , van e valaki aki összerakott már működő modult SPIvel(harveres nem pedig "bitbang"el). Nekem Ti mikrokontrollerek vannak de valahogy nem sikerül életet lehelnem bele. Ha vki lenne olyan kedves a forrása azon részét megoszatni velemi amiben az inicializáslás van , megköszönném. + érdekelne , hogy mennyi mhz-n ketyeg az éppen müködő kontroller és belső órát vagy kristályt használ. köszönöm.
Sziasztok!
Lenne nekem egy TX-4MDIL adóm és egy BC-NBK vevőm 433Mhz-es! Soros kommunikációt csinálok 2db atmega8-al 2400bps használok mert probáltam 1200bps de nekem itt nem ment egyáltalán! Megy az adat ha nincs a közelében semmi akár 50m-ről is! Most egy PC-táp 5V hajtom a vevőt plusz még vannak benne cuccok!Szerintem ezzel semmi baj!Bár nem tudom! A vevő-t is stab 5V hajtom de mióta PC-táp meg stb , azóta rengeteg a ZAJ és rengeteg a hibás adat.Szinte olvashatatlan meg meg se érkezik! Az a helyzet hogy kapcsolgatom 1sec-enként a vevőt az adón pedig folyamatosan adok! Egyszer 1 sec-ig megjön az adat sokszor hibamentesen ahogy kell, a másik 1sec-en pedig baromságok jönnek de mindig ugyan azok és ugyan olyan sorrendben!! Próbáltam kondikat beakasztani a proci tápjaira meg a adó-vevő tápra de semmi!! Esetleg valaki nem tudja mi lehet a hiba vagy nem-e találkozott ilyen problémával??Vagy esetleg ha szűrés baj van akkor milyen kondik és mekkorák és hova?? Köszi szépen!!
Szia!
Nekem HW-es SPI-al működik a modul. PIC16LF1827-es kontrollelt használok, 4x-es PLL 32MHz-es belső órával. Az SPI init így nézki:
Remélem hasznos az infó.
Üdv!
Elolvastam az egész topic-ot, és számomra az jött le, hogy rengeteg szívás van ezekkel a ketyerékkel. Van nekem is kettő darab rfm12b (868MHz-es) modulom, egyiket adásra, másikat vételre szeretném használni. A kérdés, hogy tényleg ennyire gáz ez a modul, vagy rá valami esély, hogy ezek normálisan menni fognak? Van olyan példaprogram ami valóban működik is? Mega8-as kontrollerrel használnám.
Igazából nincs vele semmi gond. A problémák jelentős részét azok generálták, akik a példaprogramok ollózásával akarták életre kelteni. Ha nem veszel tudomást arról amit itt írnak, és elolvasod az adatlapot, gond nélkül menni fog!!
Valóban, elég sok probléma van ezekkel a "ketyerékkel", de azért úrrá lehet lenni rajta. Addig amíg a vezetékes kapcsolat nem működik rendesen, addig nem is érdemes az RF modulokat bekötni. Az is igaz, hogy a RF összeköttetés más mint egy vezeték, és ezzel is számolni kell. (jelsebesség, vonali kódolás, hibaellenőrzés)
A modulokat igazából nem érdekli milyen vezérlőket kötnek össze, ha azokat a jeleket, és úgy kapják, ahogy az adatlapon ajánlják. Ezzel együtt van olyan amivel több gond van, míg másokkal kevesebb, a nagyon primitívekkel, és a nagyon komplikáltakkal szokott a legtöbb gond lenni.
Köszi a válaszokat!
Idézet: „van olyan amivel több gond van, míg másokkal kevesebb, a nagyon primitívekkel, és a nagyon komplikáltakkal szokott a legtöbb gond lenni.” Ez mit jelent? Az rfm12b ami nekem van, azt hova soroljuk, az egyszerűhőz, vagy a bonyolultabbhoz?
Ez a bonyolultabbak közé sorolnám, a rádiós része az rendben lenne, de a kezelése szoftveresen egy kissé bonyolultabb. De ha rájössz, akkor egy jó darab.
Ezt a "rájövést" szeretném időben minimalizálni. Amik linkelve voltak példaprogramok, azokra mindre büfögött valaki. Van olyan ami tényleg működik is? Nem akarom én határértéken járatni, de azért egy stabil kapcsolat jó lenne.
Ebben nem tudok segíteni, csak a rádiós részhez, és az adatátvitelhez értek valamelyest, a programmozáshoz nemigen.
|
Bejelentkezés
Hirdetés |
