Sporo różnistych RFM'ów jest na rynku. Duża część już nie produkowana schodzi już ze stanów magazynowych i powstaje problem co wybrać.
Założenie z grubsza jest takie - centralka która co jakiś czas odpytuje kilka rozproszonych po domu czujników o dane i wystawia to w czytelnej formie na LCD/www.
Jakiego teraz transceivera użyć żebym mając książkę Mirka podołał w uruchomieniu tego? Początkowo zakładałem pójście na łatwiznę i użycie RFM12, ale czy jest sens pchać się w starocie?

_________________
Czekamy na RedBook'a!

Musisz sobie zadać pytanie czy dać coś sprawdzonego czy przyszłościowego, sam odszedłem od modułów RFM na rzecz wifi, co prawda cena jest znacznie wyższa, ale implementacja przyjemniejsza, a zasięg większy, oraz dużo większe możliwości przesyłu danych.

Zobacz u samego źródła czyli http://www.hoperf.com/rf/fsk_module/
Wybór masz spory i nie ma co liczyć że time to life będzie trwał wieczność .

Wiesz... przydało by się adresowanie i WakeOnRadio czego rfm12 nie posiada.

_________________
Czekamy na RedBook'a!

Wszystko zależy od potrzeb. Ja używam RFM73 i nie narzekam.

Jak z zasięgiem wewnątrz budynku?
Bo mam do pokonania dwa stropy i blaszany dach w jedną stronę i pewnie z metr (w sumie) ceglanej ściany w drugą i obawiam się, że 2.4G może mieć z tym problemy.

_________________
Czekamy na RedBook'a!

RFM69CW ma to co potrzebujesz:
- Listen Mode - oszczędzanie energii
- SyncWord - jako adres sieci 8 bajtów
- NodeAddress - adres w sieci 1 bajt
- BroadcastAddress - adres rozgłoszeniowy 1 bajt
i coś jeszcze:
- DC-Free Data Mechanisms (jak mogłeś sobie wyczytać w zielonej książce Mirka to nadawanie przykładowo samych zer kładzie komunikacje, bo układ ARW traci synchronizację)
- CRC - nie trzeba tego robić na piechotę
- AES - szyfrowanie ramek

Jest zgodny pinowo z RFM12B w obudowie SMD, a w razie czego jest jeszcze mocniejsza wersja RFM69HCW.

_________________
Dragonus Cracovus: Biomagia

Miło... przyjrzę się temu

Migracja z RFM12B do RFM69CW

Edit @ 29.04.2014:
Dzisiaj kurier przyniósł kilka sztuk RFM69CW... "będzie zabawa, będzie się działo..."

Jakby ktoś miał już jakieś zręby biblioteki i zechciał się podzielić to będzie mi bardzo miło.
Póki co staram się przeanalizować TO

_________________
Czekamy na RedBook'a!

No i zacząłem przeportowywać podaną wyżej ("TO") bibliotekę na AVR... Ciekawe czy coś mi z tego wyjdzie...(?)

Edit @ 01:41 - Narazie wiesza się na init

_________________
Czekamy na RedBook'a!

przerobienie tej biblioteki na AVR nie jest specjalnie trudne - zacznij od zamiany klasy na strukturę (te same parametry) i pozmieniaj tylko referencje w funkcjach
trzeba też przerobić wszystkie metody Arduinowe niestety, no i bool na uint8_t. Oprócz tego uruchomienie przerwania którym będziemy obsługiwali DIO0 z tej biblioteki.

Zabrałem się za RFM69HCW jakiś czas temu, udało mi się w ten weekend uruchomić komunikację między dwoma modułami ale biblioteka jest "porozwalana" i w powijakach. I tylko sztywne Rx, Tx, bez Listen Mode. Jak ogarnę lepiej to mogę się podzielić gdyby się nie udało

Udało się dogadać z RFM69 - czyta rejestry. Init przechodzi nawet.
Trzeba zobaczyć w tym ich kocim datasheecie co dalej żeby ustawić konkretną częstotliwość i nadawać/odbierać...

_________________
Czekamy na RedBook'a!

to podobno to samo,
tu jest wiele materiałów dla znających się na rzeczy, czyli nie dla mnie

http://www.semtech.com/wireless-rf/rf-t ... rs/sx1231/

Moduły są produkowane na różne pasma. Ustawianie częstotliwości może wyglądać tak:

Moduł konfiguruje się wysyłając tablice złożone z rejestru i wartości do wpisania:

Wspomagając się zieloną książką Mirka można sobie w końcu przygotować uniwersalne funkcje do wysyłania i odbioru:

W pliku main powinno się znaleźć:

W konfiguracji należy ustawić odpowiednie adresy i potem się ich trzymać. Tu też można posłużyć się tablicą i odpowiednią funkcją:

_________________
Dragonus Cracovus: Biomagia

Pasmo 868MHz to kilka-naście częstotliwości... od 860.48 do 879.54 MHz.
Dobrze, że podałeś:


Dla (przykładowo) 862.00MHz będzie FRF = 14123008... tej informacji mi m.in brakowało.

_________________
Czekamy na RedBook'a!

Siedzę cały dzień dzisiaj nad tym i niestety bez rezultatów

_________________
Czekamy na RedBook'a!

Na początek w funkcji RFM69_Send można sobie wstawić adres rozgłoszeniowy (BroadcastAddress), wtedy kod obu urządzeń jest identyczny. Byłoby fajnie jakbyś opublikował plik main.c z konfiguracją przerwań i timera.

_________________
Dragonus Cracovus: Biomagia

Obecnie walczę z USI w ATtiny4313 i chyba udało mi się zmusić go do pracy jako SPI (Uwaga dla początkujących: MOSI w USI to DataIN / MISO - DataOUT).
Poprzednio próbowałem software SPI, ale średnio to chodziło chyba . Pokombinuję nieco jeszcze zanim wrzucę tu main.c

Pewnie średnio poprawne (jak ktoś ulepszy/poprawi to będę wdzięczny) - USI jako SPI Master:




Coś się złego dzieje z tymi modułami na stykówce... dwa już odpowiadają zerem , albo mi SPI na M644P źle działa, ale w takie cuda to nie uwierzę.

_________________
Czekamy na RedBook'a!

Można przecież podejrzeć po kompilacji jak wygląda kod asm w pliku .lss

Jest jakaś szansa zablokowania tych modułów na amen? Bo albo mi się uszkodziły (w sumie z niewiadomych powodów - stykówka i konwerter poziomów na 2x ADuM1402), albo jakoś zablokowały.
Dwa mają permanentny stan niski na MISO... jak próbuję odczytać dowolny rejestr to cały czas na analizatorze Saleae dostaję 0x00 w odpowiedzi :/
Sam konwerter poziomów sprawny bo jak odłączę moduł i zewrę linię MISO z MOSI po stronie 3V to odbieram to co wysyłam.

_________________
Czekamy na RedBook'a!

Brakuje ci w kodzie sterowania CS. Jak ten pin jest w stanie wysokim to moduł RFM69 ustawia wyjście MISO w stan wysokiej impedancji i dlatego odczytujesz 0. Taki stan łatwo rozpoznać woltomierzem. Jak mierzysz pomiędzy MISO i GND masz 0V i pomiędzy VCC i MISO też masz 0V.
Zwracam jeszcze uwagę na sterowanie CS. Do współpracy z modułem CS zerujesz, wysyłasz 2 bajty i dopiero ustawiasz na 1. Przykład jest w funkcji RFM69_write.
Nop'y nie są potrzebne, bo moduł ma szybkie SPI. FSCK maksymalnie 10MHz. Atmel udostępnia gotową bibliotekę AVR319, która się dobrze nadaje, bo pinem SS/CS trzeba dodatkowo sterować.

_________________
Dragonus Cracovus: Biomagia

CSem akurat steruję ręcznie...

Chyba się wyjaśniło . Mam porąbane funkcje SPI / USI.
Mam coś takiego:


I różne rezultaty na SPI vs USI



SPI (M644P, wysyłanie 0x00 w spi_rx):

USI (t4313):



OMG... znalazłem błąd sprzętowy - przerwa w ścieżce/niedolut. I to tak perfidnie, że na VCC przy samym padzie - ilość prądu jaką dostawał po portach wystarczała na sensowne odpowiedzi po SPI ale nie na nadawanie/odbiór.

_________________
Czekamy na RedBook'a!

Poprawne funkcje zapisu i odczytu dla RFM69, przy wpisywaniu ważne jest ustawienie MSB adresu na 1 (przy okazji update powyżej):

W celu odbioru też należy wysłać 2 bajty. Pierwszy to adres, a drugi jest dowolny, ale dopiero po jego wysłaniu w rejestrze odbiorczym ląduje wartość rejestru RFM69.

_________________
Dragonus Cracovus: Biomagia

Doszedłem już do tego . Działa!

_________________
Czekamy na RedBook'a!

BRAWO!!!

a może pokusilibyście się napisać jakiś krótki kursik z miganiem diody:

"Jak podłączyć i uruchomić RFM69"

bo Wasze wywody są dla mnie za mądre
wdzięczność moja byłaby wielka

Witam wszystkich forumowiczów
Próbuję zaimplementować całość do atmeg 168, mam problem z odczytem w urządzeniu odbiorczym. Układ nadawczy ma cyklicznie wysyłać dane do odbiornika. Po analizie z oscyloskopem wygląda na to, że jest przerwanie na wyprowadzeniu DIO2 (FifoNotEmpty) w trakcie wysylania i pojawia się sygnał na wyjściu antenowym (wiem że częstotliwość przekracza możliwości oscyloskopu, ale coś się zmienia więc zakładam, że uklada nadawczy działa )
Problem mam po stronie odbiornika tzn. nie pojawia się przerwanie na wyprowadzeniu DIO0 (PayloadReady), ani na DIO2. Czym to może być spowodowane ?

Poniżej zamieszczam listingi do programu:

Kod nadajnika:



Kod odbiornika:

W kodzie odbiornika linia RFM69_Rx(); powinna być w "ciele" funkcji main za RFM69_Config();, bo teraz to odbiornik jest w trybie standby

Jak nie korzystamy z przerwań to kod funkcji main nadajnika może wyglądać na przykład tak:

a odbiornika tak:

_________________
Dragonus Cracovus: Biomagia

Wyglada na to, że odbiornik się zwiesza w trakcie wykonywania address = RFM69_read(RegFifo);
- czyli po drugim odczycie.



Nie miałem czasu się wgłębiać dlaczego poprzednia funkcja się zawiesza, ale gdy zmieniłem funkcję RFM69_Read(uint8_t * data) na tą od Szoplera to wszystko zaczęło działać.

Podziękowania dla Krauser'a za cenne fragmenty kodu.

Było o jeden while za dużo. Flaga SPIF jest zerowana po odczycie rejestru SPSR i następującej po nim operacji na rejestrze SPDR. Kolejny update.

_________________
Dragonus Cracovus: Biomagia

Teraz usiłuję skorzystać z listen mode...


Teoretycznie teraz jak wyłapie pakiet spełniający warunki to go odbierze, a wygląda jakby nic nie odebrał bo brak reakcji.
Jak ustawię na odbiór to jest OK.

Edit:
Ustawiłem większą wartość dla ListenResolRx bo pewnie przy domyślnych 64us przy niskim baudrate (2400bps) nie nadążał odbierać bajtów synchronizacji przed przejściem z powrotem w Idle.
Jednak na otrzymaną komendę brak odpowiedzi...



Edit2:
Stworzyłem funkcję:


I zmieniłem w RFM69_Send...


I wygląda na to że działa choć zdarzają się błędy w odbiorze np. wysyłam komendę "GiveVolt", a dochodzi "GiveVol".

_________________
Czekamy na RedBook'a!

Nie lepiej sobie dodać parę bitów:

Wtedy konfiguracja wygląda prościej:

Wyłączenie ListenMode powinno być po odebraniu ramki czyli w kodzie przerwania. Wciskanie tego do RFM69_Send jest dziwne moim zdaniem:

Przy domyślnych mnożnikach i rozdzielczościach 4.1ms wyjdzie 131,2ms odbioru i 1,0045s stanu Idle. Wypadałoby ustawić nadajnik, aby wysyłał ramkę co 100ms, a odbiornik musi wysłać odpowiedź zanim nadajnik zacznie nadawać kolejną ramkę, bo moduł w stanie nadawania nic nie odbierze. Jest też inna technika, gdzie okres wysyłania jest równy stanowi Idle (ale nie sumie stanu odbioru i Idle) wtedy przy czasach dobranych jak opisano raz na 10 wysłanych ramek jedna dotrze do odbiornika, a on będzie miał dużo czasu na odesłanie odpowiedzi. Błędy w odbiorze są niemożliwe skoro jest CRC. Możesz to dokładniej opisać? Co nadajesz i co robisz z odebraną ramką?

_________________
Dragonus Cracovus: Biomagia

Nadajnik: co 1s wysyła "GiveVolt" na adres odbiornika.
Odbiornik po odebraniu ramki wyrzuca buffer na UART@38400bps, parsuje go - jedno proste strncmp() i odsyła odpowiedź - wartość napięcia.

W main.c:

_________________
Czekamy na RedBook'a!