Üdv!

Az lenne a kérésem, hogy valaki legyen szíves magyarázza már el, hogy az adatlap 35. oldalán levő Write1 és Write0 nevű függvények mit csinálnak. Assemblyben tudok programozni és próbálom megérteni, hogy mit kéne csinálni.

Köszi

Szia!

A modul SPI interfészen keresztül kommunikál a uC-vel, SPI-t két féle képpen tudsz megvalósítani:
#1 HW-es SPI használata: mikor uC-nek vannak dedikált lábai amik segítségével kommunikálni tudsz (data in, data out, clock, chip select), ebben az esetben, beírod amit kiszeretnél küldeni egy megadott regiszterbe és uC kiküldi (persze azért az SPI modult inicializálni kell)
#2 Ha nincs HW-es SPI akkor le kell programozni. Ami azt jelenti, hogy neked kell billegtetni a megfelelő lábakat (ami bármilyen IO portja lehet a uC-nek), ezt pollingolásnak hívják.

Tehát a write1 és write0 a második esetet valósítják meg, az egyik 1db 0-át küld ki a megadott lábon, a másik pedig 1db 1-est.

Részletezve pl a write0-át:
elsőként SDI lábat (ami: #define SDI RB7) nullára állítja,
majd az órajel lábat, SCK, szintén nullára huzza (előtte 1 volt), majd órajeltől függően vár 16 utasításnyi ciklus időt, s ezután az óra jelent vissza állítja magasba, s még vár egy utasítás ciklusnyi időt.

Üdv!
Köszönöm a válaszod!

Én a szofveres SPIt már megîrtam.
Azt elmondanád, hogy akkor a 36.oldalon levő writecommand nevű függvény pontosan mit csinál?

Nincs mit.
Az a függvény, a paraméterként megadott CMD nevű változót kiküldi SPI-on. A CMD egyébként egy 16bites változó. Ennek megfelelően létrehoz egy változót (n) 16-os értékkel, majd az órajelet nullára állítja, s a chip select-et nSEL) is nullába állítja, s ezzel engedélyezi a slave eszköz (RFM12B) SPI kommunikációját.
Ezt követi egy ciklus ami n-szer, azaz 16-szor fog lefutni, méghozzá úgy, hogy megnézi, hogy a CMD paraméternek megadott érték legfelső bitje 1-e (if(CMD & 0x8000)), ha 1, akkor meghívja a Write1 funkciót, amit már előbb leírtam, szóval kiküld egy 1-est, ha a legfelső bit nem 1-es, hanem nulla akkor pedig a write0 funkciót hívja meg. Majd a CMD paramétert eltolja (shift-eli) eggyel balra, s kezdődik a ciklus elölről, újból megvizsgálja a legfelső bitet és így tovább.
Ha kiküldte mind a 16bit-et, akkor az órajelet nullába állítja és a Slave eszköz SPI kommunikációját tiltja úgy, hogy magasra állítja azt.

Sziasztok! Nekem szintén az IA4420 FSK IC-vel akadt gondom. Minden létező konfigurációs módot kipróbáltam már, de nem tudok 57.6kbps-nál nagyobb sebességet elérni, úgy hogy az átvitt csomagok ne legyenek hibásak.

Ráadásul nagyobb sebességeken a vevő a zajból is érvényes csomagokat vesz (min érzékenységnél is). Ha pedig tényleg elkap valamit, akkor félremintavételezi (gondolom a kvarcok pontatlansága miatt, de mivel teljesen mást vesz, nem biztos, h ez a gond)

Azt sem értem, hogy miért képes az IC 240KHz-es eltolást (deviation) produkálni, ha összesen 400KHz a vételi sávszélesség.

Az FSK jell spektruma nagyjából 2(fD+baud) széles, tehát 115.2k-n már csak 80KHz marad a deviation-ra 400KHz-es szűrés mellett, ami nem elég.

A 240KHz-es dev-vel még a 0.6kbps mellett is túl széles lesz a spektrum ahhoz, h venni lehessen egy 400KHz-es bemeneti szűrővel. akkor meg minek a 240KHz?

foglalkozott már valaki az IA4420 nagyobb sebességeivel?

Szia!
Csatoltam egy ábrát amivel talán sikerül megérteni a dolgot (hozzá teszem én sem vagyok 100%-ig biztos benne, de az ábra tuti jó). Szóval a lényeg, hogy a deviation és a BandWidth is mind a két irányba értendő, vagyis ha a deviation 240kHz akkor a center frekitől (ami soha nem jelenik meg adás közben) a 0-nák megfelelő érték f₀-240kHz-re lesz ha pedig 1-et ad akkor f₀+240kHz-re (ez persze csak akkor igaz, ha a moduláció polaritás bit 0, TX Configuration Control Command-ben).
A sávszűrő teljes sávszélessége, 400kHz-es beállítás mellett (400kHz * 2) + (2 * 10kHz).
A 10kHz azért van, mert a BB szűrőnek van egy úgy nevezett DC cancelaiton (sajnos magyarul nem ugrik be) tulajdonsága.
Én egyébként a következő képlettel számítanám ki a sávszélességet: BW = BaudRate + 2*deviation, de ez a teljes sávszélesség, s a modulnak csak ennek a felét kell beállítani.
Ha a fent leírtak alapján számolunk akkor 115,2kbps-os sebesség mellett, 240kHz-es deviation-t választva, 297,6kHz jön ki, s ebből még le kell vonni a 10kHz-es DC cancelation-t azaz 287,6kHz es BB szűrőt kell alkalmazni vagyis a 270kHz-eset vagy 340kHz-eset, a 270kHz az nem a legjobb választás, mert a számításokban nem vettük figyelembe a kristály és egyéb alkatrészek szórását, s a 270kHz amúgy is szűkebb s így még jobban elnyomhatja a szűrő a hasznos jelet is. Viszont a 340kHz jóval szélesebb, s ennek a hátránya az, hogy több zaj jut a vevőbe ami kihatássál van a vevő érzékenységére.

Üdv!

Megint a programozáshoz szeretném a segítségeteket kérni.
Valaki leírná, hogy pontosan mit csinál az alábbi kódban a WriteFSKByte függvény?

Köszönöm előre is!

Szia!

Nem részletezném a funkció pontos leírását, a lényeg, hogy a DATA-ként megadott változót ( WriteFSKbyte( uchar DATA ) ) betölti a TX regiszterbe (Transmitter Regsiter Write Command; 0xB800), s ha betöltötte, akkor a modul ezt kiküldi RF-en. Vagyis ez a függvény képes a paraméterként megadott 8bites adatot RF-en továbbítani.

Üdv!

Köszi a választ!
De ezt én is tudtam.
Azért kérem a pontos leírást mert assemblyben szeretném megírni ugyanezt.

Szia!
Egy lényeges infó a működés megértéséhez, több módszer van annak kiderítésére, hogy az RF modul kiküldte a TX bufferban lévő adatokat vagy sem, az egyik amit ez a kód is használ az az SPI SDO vonalának állapota, ami alap estben nulla, majd ha a byte kiküldésre került akkor magasra vált, ezzel jelezve, hogy a TX buffer üres. Erről egy szemléltető ábra a HOPE RF RFM12B V1.1-es dokumentumának 21. oldalán található.
Akkor a WriteFSKbyte működése:
- létrehoz egy RGIT nevű 8bites változót, amit feltölt 0-ával
- létrehoz egy temp nevű változót, ami kezdő értéke 0xB800 (Ttansmitter Register Write Command)
- majd össze "vagyolja" a 0xB800-át és a funkció bemenő adatát (DATA), s az eredményt a temp-ben tárolja.
- ezt követi egy "pollingolás" várva az SDO magas szintre.
Amit úgy csinál, hogy aktiválja a slave eszközt (RFM12B), úgy, hogy a chip select lábat nullára állítja, majd a SDI lábat nullába állítja, az órajelet pedig magasba, s megnézi, hogy az SDO 1-e, ha igen, akkor az RGIT változót egyre állítja, ha SDO nulla akkor az RGIT nulla lesz, ezután az órajelet nullába állítja, az SDI-t pedig 1-re, majd tiltja az SPI kommunikációt (nSEL=1), ezután megvizsgálja, hogy az RGIT értéke nulla-e, ha igen akkor megismétli a fenti lépéseket, ha RGIT 1-re lett állítva akkor meghívja a WriteCMD rutint ami elküldi SPI-on temp változó tartalmát.

Remélem sikerült érhetően leírnom.

Köszönöm!

:worship:

Üdv!

Már próbálkozok egy ideje ezekkel az modulokkal meg két PIC16f871-el, de eddig nem sok sikert értem el.
A programot assemblyben írtam mert csak ilyen nyelven tudok valamennyire programozni. Az adatlapon talált programot próbáltam meg lefordítani, de nem működik.
Annyit kéne tennie, hogy a receiveren egy led elkezd világítani ha megkapta az előírt üzenetet.
Valaki legyen már szíves átnézni, hogy mi miatt nem működik mert én már kezdem feladni.

Előre is köszönöm!

Üdv!
Szerintetek a 3,8v ról üzemelő modul SDO ja 1esbe tudja állítani az 5v ról működő PIC bemenetét? Ha nem akkor hogyan lehetne ezt megoldani? (a PICnél 4,5V a minimális tápfesz)

Szia!
Ha a PIC 5V-ról megy és az F871-et használod akkor nem fog működni a 3,3V-os RF modullal.
A PIC nem fogja érzékelni magasnak a jeleket, az adatlap alapján 0,8*VDD-től, azaz 5V esetén 4V-tól érzékel magasat. Egyébként az F-es változat 4V-ról még képes működni (adatlap alapján).
Két megoldás van, hogy működésre bírd a rendszert:
#1: építesz egy szint illesztőt a modul és a PIC közé (egyébként ezt nem javaslom, csak bonyolítja a dolgot)
#2: veszel egy LF871-es PIC-et, ez 3,3V-nál még 10MHz-es órajelel képes működni (én ezt a megoldást javasolnám) ennek az egy hátránya, hogy a ChipCAD-nél nincs raktáron.
Esetleg egy 3. megoldás, hogy keresel egy olyan PIC-et, LF-es változatban ami van raktáron a ChipCAD-nél.
De miért is használsz ennyire szokatlan típust?
Ráadásul még nem is olcsó.

Üdv!
Ha 4,4 voltról menne a PIC a modul meg 3,8ról akkor működne szerinted?

Amúgy azért választottam ezt a PICet mert szügségem van a 40 lábra és ahol vettem ott ezen kívül csak 877 es volt 40 lábú ami még drágább.

Hát elég necces úgy is, mert az RFM12B adatlapja alapján a magas szint VDD-0,4V, vagyis ha 3,8-ról járatod akkor a kimenetek (2mA-es áram mellett) 3,4V lesz (ez a magas szint a kimeneteken).
S ha a PIC 4,4V-ról jár akkor a magas szint érzékelési szintje 0,8*4,4V=3,52V.
Ami szintén azt jelenti, hogy nem működik, a 3,4V-ot nem fogja magasnak érzékelni.
A 871-es adatlapja az írja egyébként, hogy kompatibilis az összes 40 lábú chippel, s a microchip honlapja a 871-es helyett a 884-es ajánlja, mert a 871-es már nincs gyártás alatt, s a ChipCAD-nél kapható a 884-es jóval olcsóbban mint a 871-es, s van raktáron DIP40-es tokban.
Ami még jó a 884-ben, hogy 3V-ról egészen 10MHz-es órajelig működik.
Nem tudom honnét szerezted az chipet, de továbbra is csak azt tudom ajánlani, hogy váltsd le a 871-et
s a 884-es jó megoldás lehet.

Hello
Én PIC16F690-nel tesztelgetem ezt az adó-vevő modult. Szoftveres SPI-t használok, és nálam nincs gond a kommunikációval. A PIC 5V-ról jár, a modul bemeneteire pedig feszültségosztón keresztül érkezik a leosztott jel (4,7k & 10k).

Használja valaki ezeket a modulokat 16bites FIFO beállítással? 8 bites FIFO-val működik nekem rendesen, de szeretnék manchester kódolást alkalmazni, és ezért célszerű lenne a 16bites FIFO.
Arra lennék kíváncsi, hogy ilyenkor az adóval ugyanúgy kell küldeni, mintha 8 bites lenne a vevő FIFO-ja? Vagy ebben az esetben a küldő parancsnál az adónak be lehet "tolni" egyszerre 16 bitet egyben?
Üdv.

Hi!
Igen, nálad azért működhet, mert TTL szintű portot használsz, ugyanis TTL-es bemenetnél, (0,25*VDD)+0,8V a detektálási szint, (de minimum 2V) vagyis 5V-os tápnál: 2,05V.
@kalmangabi:
Ha át tudod tenni az SPI portodat olyan portra ami TTL bemenetű, nem pedig Schmitt Trigger bemenettel rendelkezik akkor működhet is.
Illetve elsőkként ki kell deríteni, hogy az a port amin használod milyen bemenettel rendelkezik.

Üdv!
Meggyőztél. Le fogom váltani a 871et.
De a költekezés előtt teszek egy kísérletet a 871-gyel 4 voltról. A modult pedig 3,8 voltról hajtva. Így elméletileg működnie kéne akármilyen portot használok.

Szia!
Két féle képen lehet küldeni ezzel a modullal:
#1: Minden egyes 8bites adat előtt elküldöd a TX write command-ot.
#2: Elküldöd a TX write command-ot majd küldöd folyamatosan a 8 bites adatokat egymás után.
Én a második módszert még nem használtam.
A 16 bites SPI-t mind a két esetben ki lehet használni.
Én 16 bites SPI esetében azt csinálnám amit 8bitessel is csinálok, az az 1-es küldési mód. 16 bites SPI esetén egyszerre be lehet tölteni commandot és az adatot.
Egyébként 8bites SPI-t használok és manchester kódolást is alkalmazok, így kétszer kell 8bitet küldenem ahhoz, hogy a dekódolt adat 8 bit legyen.

Remélem azért tudtam segíteni.

Hello
Sehogy se tudok 19200bps-nél nagyobb sebességet elérni az adó-vevő modulokkal, pedig többféle BW és Deviation beállítást is kipróbáltam. A receiver BW most 340kHz, a deviation pedig 90kHz (próbáltam 150kHz-cel is), és 38400bps-en már nem megy a kommunikáció.
Mi lehet a gond?
Üdv.

Hello
Próbálkozok a 16 bites FIFO móddal 9,6kbps-en, de egyelőre nem akar működni. A FIFO IT LEVEL-t 0x0-ra állítottam, gondolom ez akar lenni a 16 bites mód.
Adásnál egyszerre küldöm ki a 16 bitet, persze úgy, hogy először a küldő utasítás 8 bitje és a hasznos adat felső 8 bitje megy ki, ezután megvárom míg a modul SDO-ja magasra vált, ezután küldöm a hasznos adat alsó 8 bitjét.
Összességében először 0xAAAA-t, 0x2DD4-t, majd ezután 16 bitnyi hasznos adatot küldök.
Vételi oldalon figyelem az FFIT-t, hogy mikor vált magasra. Miután ez megtörténik, kétszer használom a FIFO Read parancsot, majd törlöm a FIFO-t.
Ez így jó?
Üdv.

Hello!
Szerintem ha 0-ra állítod az nem jó, az adatlap azt írja, hogy akkor lesz IT ha a vett bitek száma megegyezik a FIFO IT level-nél beállított értékkel. Tehát max 15-öt tudsz megadni. (az adatlap nem tér ki arra, hogy a 0, 16 vett bitet jelentene)
A küldés egyébként szerintem jó.
A vételnek is elvileg működni kellene.
Nem használsz IRQ-t?
Milyen gyors az SPI kommunikáció?
Ugyanis a FIFO olvasásakor az SPI órajel frekvencia nem lehet nagyobb a modul referencia órajel negyedénél. Vagyis ha a modult 10MHz kristállyal van szerelve akkor az SPI órajel max 2,5MHz lehet.
Egyébként 8bites üzemmódban működik a dolog?
Illetve azt is kipróbálhatod, hogy 8 vett bit után kérsz IT-t és addig meg jön a következő 8, a vett 8-at betöltöd egy 16bites változó felső byte-jába, sokkal nem lesz lassabb a működés.
Üdv.

Hello
Az adatlap szerint 16 bites a FIFO, tehát szerintem biztos be lehet valahogy állítani annyinak; így gondolom a 0x0 érték lehet az. Nem használok IRQ-t, az FFIT lábat figyelem a vételi oldalon, 8 bites üzemmódban így tökéletesen működik is. Az órajel se lépi túl a 2,5MHz-et. Már beleírtam a programba a manchester kódolást, megpróbálom azt a részt kiiktatni, hátha ott van a gubanc.
Viszont ahogy feljebb írtam, nem tudom még 8 bites módban se nagyobb sebességen működtetni a modulokat. Te mekkora max. sebességet tudtál elérni a modulokkal?
Üdv.

Nekem sokat segített hiba keresésben a PICkit2-nek a logikai analizátor funkciója. Így ellenőrizni tudod, hogy 0x00-val valóban a 16. bit után jelez-e.
Sajnos a sebességről nem tudok nyilatkozni, mert még nem mértem, az én alkalmazásomnál nem lényeg a sebesség.
De most már gondolkozom rajta, hogy a saját alkalmazásomat hogyan tudnám egyszerűen átalakítani, hogy sebességet mérjek.

Hello
Sikerült megoldani a problémát: az IT Level-t tényleg 0xF -re kellett állítani. Így rögtön működött
Átküldtem így egyszerre 16 bájtnyi adatot (manchester kódolással), és a vételi oldalon tökéletesen megérkeztek. Szóval elvileg akkor így most jó. Most már csak a bitsebességet kéne valahogy feltornázni 9600bps-ről nagyobbra, de majd külföldi fórumokon utánanézek, hogy mások hogy csinálják.
Üdv.

Na, szuper.
Most olvastam az adatlapban, hogy ha a Configuration settings-nél beállítod az "el" bitet akkor az FSK lábat fel kell húzni 10k-val. Nálad hogy van? (ezt egyébként én is lehagytam)
Valamint jó lenne ha megtudnád nézni a tápfeszültséget oszcival.
Ha nem megy akkor kipróbálhatnád úgy a különböző sebességeket, hogy a modul táplálását elemről oldod meg.
Egyébként milyen tápot használsz?
Így ezzel ki lehetne szűrni, hogy a táppal minden rendben van.

Hello
Az FSK és az nRES láb is fel van húzva 10k-val tápra. Az adó áramkört PicKit2-ről, a vevő áramkört pedig 9V-os elemről hajtom tranzisztoros emitterkövető stabilizálással.
Van szkópom, a tápra majd holnap rálesek vele.
Üdv.

Hello!
Az elemes táplálás jónak tűnik, az emitterkövetős táp is jó lehet ha megfelelő puffer van a kimenetén, s talán a PicKit2 is tudod annyi tápot szolgáltatni ami az adónak elég, de ezt szerintem nézd meg mindenképpen, mivel az adó megrángathatja rendesen tápot.
És amúgy mikor nagyobb kommunikációra állítod akkor egyáltalán nem tudsz venni semmit, vagy csak hibás vétel?
Üdv.