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:
while(n--)
{
while(!nIRQ);
while(nIRQ);
if(DATA&0x80) FSK=1; else FSK=0;
DATA=DATA<<1;
}
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:
sbic 0x16, 2
rjmp .-4
sbis 0x16, 2
rjmp .-4
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.
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
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.
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.
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.
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!
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.
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.
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.
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??
Hírek.rss
» A fájlok letöltéséhez be kell jelentkezned! «
