Fórum témák
» Több friss téma |
Ahogy m.joco is írta IA4420 az nem biztos, sajnos nagyon gyér a dokumentáció az RFM12B-ről, s adatlapja szerint egy RFM12B nevű chip van benne.
Amúgy az IA4420, SI4420 és az MRF49XA mind ugyan azt tudják, a legjobb leírása szerintem a Microchip MR49XA-nak van, s míg az IA és SI azt írja, hogy a chip 5,4V-ról képes max működni addig az MRF 3,8-at ír, hasonlóan az RFM12B doksijához. Na de ha még nem ment tönkre a "magasabb" tápfesztől akkor nem valószínű, hogy ezért ad vissza a 0x0000-át. Az RFM12B spekben az van, hogy a SCK periódusidő minimum 50ns lehet, azaz maximum 20MHz, ennek ellenére nekem 1MHz-el nem ment. Illetve még egy dolog jutott eszembe, mekkora az utasítás végrehajtási sebességed? Mert akár attól is lehet hiba, hogy nincs meg a megfelelő idő pl a chipselect és a SCK között stb. (bár ilyen esetben lehet, hogy egyáltalán nem lenne kommunikáció) Azért tutira le kellene ellenőrizni, hogy a SPI kommunikáció jó-e, s a modul beállít mindent amit kell, tudom írtad, hogy a freki arra áll be amire beállítottad, van otthon spectrum analizátorod? Én pl úgy ellenőriztem, hogy betudok-e állítani "mindent", hogy a clock out lábat tiltottam, engedélyeztem, változtattam frekit, ezt egy frekimérős multival simán tudod ellenőrizni. Valamint még egy tapasztalat, hogy volt olyan problémám is, hogy a konfigurációs szavak nem mindegyikét vette, pl ha a clock out ki vagy be kapcs az elején volt akkor működött, de ha előtte már küldtem el más beállításokat is akkor nem, a probléma az időzítéssel volt.
Biztos, hogy IA4420 van rajta, mert rá van írva az IC-re, ami a modulba van forrasztva. Kipróbáltam 250KHz-es órajellel, de ugyanúgy semmi. A chip select után tettem 10ms időzítést, de így sem jobb. Spektrum analizátorom nincs, rádiószkennerem van, azon hallom, amikor engedélyezem a az adást, akkor megjön a vivő és amikor byteokat küldök, akkor hallani a "ciripelést". Ha nem lenne jó az spi beállítás, akkor nem tudnám adásba kapcsolni a modult szerintem. Még a clock out próbát megejtem, de csak hétvégén tudom ellenőrizni, most nincs nálam a frekimérőm. AVR esetén az a szerencsétlen helyzet van, hogy a SPI port lábain keresztül kell a procit felprogramozni és én egyre jobban arra gyanakszok, hogy a programozáskor rajtafelejtett modul SDO kimenete tönkrement. Mivel felváltva próbálgattam mindkét modult, így megeshetett, hogy mindkettőnél sikerült 1x rajtahagyni programozáskor.
Most megnéztem az MRF49XA adatlapját és tényleg ugyanannak tűnik. Még jó, hogy nem vettem...
Az inicializáció elé tegyél be egy 200ms-os várakozást a programban.
Üdv.
Hali!
Csak azért írok, mert beüzemeltem én is egy párt, rfm12bs és rfm12bp simán működik az adó és a vevő is az adóban pic16f872 a vevőben 16f88 van. Mindkét pic külső, a modulok által adott 10MHz frekvenciával üzemelnek, a tápfesz úgy van megoldva, hogy stabil 5V ról egy soros diódával a pic tápfesze 4,3V és egy további soros diódán keresztül kap a modul 3,8V-ot. A szintillesztés 1k és 4,7K ellenállásosztóval van lekorlátozva a modul felé. Az dso és nirq direktbe megy a pic-be.Jelenleg 5byte + ellenörző összeg megy át. Assembliben írtam meg a kódot., egy kicsit átalakítom, mert én másra használom, de később felteszem csak az adatátviteli részt, ha van rá igény... üdv.: Foxi
Hali!
Mivel priviben kérte valaki, hogy tegyem fel, átírtam, csak az átvitelhez szükséges részt hagytam meg, ezt a verziót viszont nem próbáltam ki de remélem hibamentes. Egyenlőre a vevő oldali részt csatolom.Még ma lehet meglesz az adó oldal is.A vevő veszi az adatokat úgy, hogy az adó teljesítményrésze nem is kap 12V-ot. Az átvitel kb 8-10m.
Sziasztok!
Nemrégiben szereztem be néhány RFM1/2-es 868-as modult. Sajnos napok óta nem birom kommunikációra birni őket. A kapcsolásokat modulok adatlapja alapján csináltam, a programokat mellékelem. A vevő programjában egyelőre csak annyi szerepel, hogy ha bármit vesz is, nIRQ alacsony szintre kerül, aprogram tovább halad és egy LED bekapcsol. De sajnos ez sem történik meg. Kommunikáció SPI-n kereszül elvileg megy, configurációs parancsokat végrehajtja pl. clk frekvenciát változtatja. Az adó fsk buszán látok jelet, de biztos nem lehet benne, hogy ad is, és a jel az fsk-n is csak tobbszöri ki-be kapcsolásra jeleni meg. Van ötletetek mi lehet a gond? Előre is köszönöm! Üdv: Pakibec
Hello!
rfm01/02 pár próbálok életre kelteni, de nem nagyon sikerül. Az adó oldal úgy néz ki, hogy jobban megy (a kellő időben megérkezik a megszakítás, és elkéri az adatokat), de a vevő felén ezt nem látom (ott a readFifo függvényben az SDO - vagy nIRQ - jelre várakozik folyamatosan). Nincs valakinek ötlete, hogy mi lehet a baj?
van itt egy topic rfm12b néven, a programozása ugyanaz, ott nézz körül, hátha találsz valamit.
üdv.: Foxi
Üdv a klubban
 - totál hasonló problémám van, már napok óta szivok vele. SPIn tudsz kommunikálni mindkét modullal? A config.biteket jól beállitottad? Milyen mikrovezérlőt használsz? Ha közben megoldodott, ird meg légyszi, hagy tanuljunk belőle. Üdv
Hello
Már jóideje kísérletezgetek ezekkel a modulokkal, de sehogy tudok csomagot küldeni és venni velük. Jelenleg az adó egy 3 bájtos csomagot küld másodpercenként - állandóan ugyanazt -, de a vevő oldalon csak az első bájt stimmel. A második és a harmadik mindig más. Az adó oldalon a küldések előtt az nSEL alacsonyra állítása után a modul SDO lábát figyelem, hogy mikor küldhetek, a vevő oldalon pedig az FFIT lábat pollingozom (de már próbáltam itt is az SDO-t figyelni, de ua.). 3 vett bájt után törlöm a FIFO-t. Olyan, mintha rosszkor jelezne a modul az adó oldalon, hogy mikor lehet a köv. bájtot küldeni, mert ha két küldés közé beteszek egy 1 ms késleltetést, akkor az első és a második bájt helyesen megjön, viszont az utolsó megint rossz és változó is az értéke. Ha viszont 2 ms késleltetést használok, akkor az első és utolsó bájt jó, a második pedig stabil 0 értékű, de az se jó. Találkozott már valaki ezzel a problémával? Üdv.
Szia,
bár te előbbre vagy, mint én, de mostanában elég sokat agyalok ezen a két modulon és feltünt, hogy az SDO-t figyeled. Amennyire én tudom küldésnél az nIRQ-t figyeljük. Vagyis az init után tx be, majd várunk, nIRQ-ra és a "falling edge"-nél irjuk ki a bitet az FSK-ra. Megszakitásból többeknek nem ment, én ezt a kódot kaptam hozzá (áll. tesztelt):
A vételél szintén nIRQ-t figyled - amennyire tudom, de javitsatok ki, ha tévedek. Üdv
Az adó egy attiny45, a vevő 2313
Elvileg az spi komminukáció mindkét esetben megy. A státuszra is jön vissza valami, de nekem nem sokat mond. A problémám egyébként az, hogy az adóból elküldöm a csomagot, a vevőbe viszont nem érkezik meg, és nem tudom, hogy lehetne kideríteni, hogy hol veszik el.
Nézz rá szkoppal a VDI-re, ha jól állitottad be a mudulokat a VDI kb. azt kell látnod, amit az adó FSK-ján. Ha nem akkor nincs jól összehangolva a 2 modul.
VDI-t állitsd előtte DQD-re és ellenőrid a thresholdot!
VDI-t DQD-re állítottam, threshold -79dBm (0xC069). A vdi lábon van mindenféle adat, de elég véletlennek tűnik, nem annak, amit küldtem). a kiolvasás viszontnem ad vissza semmit.
Hali!
Én úgy élesztettem föl az adó és vevő modulokat, hogy elsőnek jelentősen lelassítottam a kontroller sebességét és mindenhova ledet és nyomógombokat tettem. Nekem is sok szívás volt, mert látszólag működnie kellett volna (szimulátor) de végül is a PiC konfigurácós szavában volt hiba, külső órajelre állítva nem volt hajlandó működni, HS-re kellett konfigurálni,akkor már elfogadta a külső órajelet. utána már jól működött. Ha nagyobb az átviteli sebesség akkor konfigurálni kell az adó modulációs mélységét, valamint a vevő sávszélességét is .Valamelyik adatlapban van leírás róla, de nekem is 19,2KBaud dal megy esetleg ott lehet még hiba, ha a vevő nem veszi az adatokat. Az adó biztosan jól megy nem szokott összevissza fogadójeleket küldeni... Még nem próbáltam, de az FFIT láb akkor lesz magas, ha megfelelő számú bit érkezett be a vevőbe. Akkor az nSEL lábat magasan kell tartani az nFFS lábat alacsonyra húzni és máris kinn van az első adat órajel nélkül az SDO-n következő órajelre már a következő bit kerül ki, és addig kell folytatni a kiolvasást, amíg magas az FFIT láb. Nem biztos, hogy 8 vagy a beállított bitszám olvasható ki, mert időközben érkezhetett még.Ha elfogyott az adat, akkor vissza kell állítani az nFFS lábat. Ha beérketett az összes adat, akkor tiltani kell a FIFO-t és az újbóli FIFO enable parancs után inicializálódik a puffer, vár a 2D D4 számokra... Ezt a verziót is meg fogom írni, de még nincs rá időm.. üdv.: Foxi
Nálam sajnos az FFIT alacsonyan van...
Bár a leírás 2 lábon is jelzi az FFIT-t: FFIT/DCLK/CFIL ill. SDO/FFIT. Gondolom az elsőt kell monitorozni. Azon gondolkoztam, hogy hogy állitod a modult "digitális" módba? Mert a CFIL-re kondit kell rakni analog mód esetén. Elég a fifo-t engedélyezni, vagy más is van? Nincs véletlenül valakinek meg a chip leírása, mint RFM12 esetében? Üdv
Esetleg még a tápfesszel lehet probléma, mert a te modulod ha jól tudom 5V ról megy, azonaban a 12b ic 3.3 V-ról megy próbáld meg csökkenteni a tápfeszt, lehet az is gond.Bár nem megy tönkre 5V-tól, de nem is működik.
Gondolom ugyanaz a chip van abban is. Az,hogy analóg vagy digitális módba megy a konfigurációs parancs dönti el inicializáláskor.
Köszönöm a válaszod.
Lehet, hogy nem fogalmaztam egyértelműen, én egyelőre az RFM01 és 02-es modulokkal szivok, a 12-es a hétvégi tervek része Csak átnéztem a 12-es chip dokumentációját (IA4421) és sokkal részletesebb, mint az alap leírás. Gondoltam talán az RFM01/02 höz is lézetik ilyen, mert az sok gondunkat megoldná. Egyébként elég sokat nézegettem a konfig beállitásokat, melyikre gondolsz, hogy analóg/digitálist állitja?
16. oldal data filter comand S kapcsoló
Hello
Kipróbáltam az adást és vételt is az nIRQ láb figyelésével, de így sem jó. Az első csomag jól jön meg, de utána csupa 0-kat vesz a vevő, pedig a csomag 3. bájtja után törlöm a FIFO-t. Még mielőtt kipróbáltam volna az nIRQ láb használatát rájöttem, hogy a csomag 3. bájtjának kiküldése után jó kiküldeni kétszer a 0xAA bájtot, még mielőtt kikapcsolnám az adó módot, mert akkor kevesebb a hiba. Üdv.
Helló!
Már pár napja próbálkozok életre kelteni ezt a bizonyos RFM12B modult, de nem sok sikerrel. Gondolom ha a STATUS-t tudnám olvasni már egyenesben lennék, de sajnos nem jön össze. Ha valakinek van pár perce, akkor legyen olyan kedves és vessen egy pillantást a kódra. Az SPI lábak értelem szerűen vannak bekötve, és a táp is 3,3 V. A DATA láb tápra van húzva egy 10k-val. A kód lényegesebb részei így festenek: (Az LCD_N egy LCD-re író makró)
Szia!
Nos nem tudom, hogy a pic soros adatátviteli egysége az adat kiírásakor egyből fogadja is az adatokat, de az rfm modulnak az nSEL és Sdi lábak alacsonyra húzása után 16 órajel alatt kell beérkeznie az SDO lábon a státusz adatoknak.A további ( 16.-24). órajel alatt pedig a 8 adatbitnek.Azonkívül nem derül ki, hogy az SDI SDO és SCK lábak stimmelnek -e a pic soros moduljának kivezetéseivel... Aztán, lehet, hogy st bemenete van a soros portnak, és nem is érzékeli az rfm modul jeleit. Csak ttl szintű bemenet jó, amennyiben nem LF sorozatú a PIC és nem 3,3V-ról megy az is.
Valóban arra nem gondoltam, hogy tll vagy st-e a bemenet, de ttl
Viszont nézegettem szkóppal, LED-del mindenféle képpen, de a PIC SDI-jén mindig 0 van.Ezek szerint a dolog nem látszik elvi hibásnak, a dolgok megfelelő sorrendben történnek stb...
Talán meg kéne tudni, hogy egyáltalán van-e kommunikáció
Küldd ki egy parancsban, hogy a modul 1MHz órajele amit kiad, legyen 10MHz. akkor ha az beáll, akkor már félig nyert ügyed van, mert a parancsokat fogadja.
Jó ötlet! Köszi szépen! Amint lesz egy kis időm kipróbálom.
|
Bejelentkezés
Hirdetés |
