Witam,

czy ma ktoś z Was doświadczenie w obsłudze układów HM-R i HM-T (433MHz) od HopeRF? Próbuję je zmusić do gadania, ale brak dokumentacji u producenta sprawy nie ułatwia...
W swojej aplikacji wykorzystałem przykład z "Pasji programowania" Mirosława Kardasia (rozdział 2.) jako bazę.
Wykorzystuję 2 płytki ZL8AVR z mikrokontrolerami ATmega128.

Jestem na etapie, w którym transmisja dwóch bajtów (sekwencja startowa i bit znaku) przebiega prawie całkowicie pomyślnie. Prawie, ponieważ pierwszy zarejestrowany bit jest zerem, podczas gdy powinien być jedynką. Od dłuższego czasu próbuję zlokalizować przyczynę tego stanu rzeczy.

Do nadawania wykorzystuję kodowanie Manchester, odbiór realizowany za pomocą przerwań i wyznaczania czasu trwania impulsów. Połówka bitu trwa 104us.
Na początku wysyłane są 64 jedynki dla celów fazowania. Następnie przerwa o długości całego bitu i dopiero potem dane właściwe.
Próbowałem różne warianty jeżeli chodzi o stan nóżki w czasie przerwy po fazowaniu, o długości czasów trwania przerw i bitów itp. i lepszej konfiguracji niż ta co teraz nie trafiłem.

Najpewniej problem jest w samym programie (źródła na końcu posta), ponieważ gdy łączę piny mikrokontrolerów przewodem pomijając moduły transmisji bezprzewodowej rezultat transmisji jest taki sam. Na razie jednak kilka godzin bezskutecznie błądzę w kodzie. Zapewne przez niedostateczną wiedzę i umiejętności z tematu, za jaki się zabrałem; również pierwszy raz korzystam na poważnie z języka C więc kod mógłby być zdecydowanie wyższej jakości, ale na razie skupiam się na samym problemie.

Też na inne dziwne zjawisko trafiłem przy okazji: gdy trzymam przycisk nadawania wciśnięty (powtarzanie transmisji co 100 milisekund), czasem co kilkanaście/kilkadziesiąt ramek odbiornik przestaje funkcjonować prawidłowo (tak, jak bym chciał); program wtedy w ogóle nie wchodzi w obsługę przerwania i dopiero po kilkunastu/kilkudziesięciu ramkach powraca do normalnej pracy (chyba, że wcześniej zwolnię klawisz, wtedy od razu się poprawia). Ten problem jest raczej związany z modułem samym w sobie, gdyż nie zdarzyło mi się tak przy połączeniu mikrokontrolerów samym przewodem.

Jeżeli jest ktoś z Was w stanie pomóc mi zlokalizować przyczynę problemu uprzejmie proszę o wskazówki.

Pozdrawiam serdecznie.

----------------
Kod źródłowy programu obsługującego nadawanie:


Kod źródłowy programu obsługującego odbiór (diody użyte dla debugowania, brak wcięć celowo):

Masz dostęp gdzieś do oscyloskopu ? Warto byłoby sprawdzić jak to się na nim przedstawia - czyli jak wygląda ramka nadawana i odebrana

_________________
zapraszam na blog: http://www.mirekk36.blogspot.com (mój nick Skype: mirekk36 ) [ obejrzyj Kurs EAGLE ] [ mój kanał YT TV www.youtube.com/mirekk36 ]

Hej,

dzisiaj dostałem się do oscyloskopu i niżej załączam zdjęcie (zmniejszyłem też liczbę sekwencji fazującej do 4, wystarczy dla tych modułów). Przebieg wygląda zgodnie z oczekiwaniami, tak samo przy nadajniku jak i przy odbiorniku.
Zauważyłem, że w "Pasji programowania" pierwszy bit sekwencji startowej jest 0. Teoretycznie sam mogę problem zignorować robiąc podobnie, choć jak zbiorę siły to jutro będę na nowo analizował. Chciałbym mieć jasno w głowie na temat tego, co się tam dzieje.

Pozdrawiam.

Ale posłuchaj - ja w książce pokazałem przykład. To nie oznacza, że każdy w każdym przypadku MUSI robić tak samo - jak piszesz o tej sekwencji startowej.....

Moim celem było to aby ktoś kto czyta zrozumiał jaką drogą do analizy problemu ja podszedłem i na tej podstawie spokojnie zrobił ze zrozumieniem i poradził sobie dalej ....

Myślę, że kod nadajnika jest o wiele prostszy i tu pewnie nie masz najmniejszego kłopotu ze zrozumieniem. Za to powinieneś sobie jak już masz oscyl sprawdzić np ile bitów preambuły potrzebujesz - może mniej niż w przykładach z tymi kompletami która ja wykorzystywałem - może mniej ? ... przecież tu też pisałem że to wyraźnie zależy od sprzętu który się posiada.

Możesz zatem zacząć próby wprost od przesyłania jakichś krótkich sekwencji po kilka bitów aby tylko próbować je wyłapać w kodzie odbiornika ....

z drugiej zaś strony - jak widzę w kodzie:

#define F_CPU xxxxxx to już się domyślam że po pierwsze kompilujesz i piszesz kod być może w AVR Studio a jeśli jesteś początkujący (tego nie wiem ale tak tylko się domyślam po takich wpisach) ... to nawet nie wiesz ile jeszcze innych pułapek czeka na ciebie w tym AVR Studio. Więc jak najszybciej przejdź na Eclipse a z kodów WYWAL w diabły te definicje #define F_CPU ma ich w ogóle nie być w kodzie .... bo jak na końcu się okaże że masz jakiś czeski błąd np przez źle działające delaje to potem sam sobie w brodę będziesz pluł i może w końcu doczytasz i zrozumiesz że w kodzie się tego nie robi.

Można jednak być mądrzejszym PRZED szkodą, i posłuchać takiej porady i od razu tego nie wpisywać - a jeśli coś nie wychodzi to dopytać jak sobie poradzić.

Ale generalnie widok z oscyla napawa nadzieję, że już niedużo ci brakuje do odpalenia tego z powodzeniem

Dokładnie niedawno na tym forum ktoś na podstawie tej książki odpalał na jeszcze innych modułach komunikację i miał podobny kłopot na początku - i się załamywał - a później sam zobaczył, że bez wgryzienia się w szczegóły ciężko to odpalić ... tyle że te szczegóły nie są takie trudne ... dlatego polecam dobrze przeanalizować co ma się dziać w przerwaniu ICP

a podstawy tego masz także opisane dobrze i szczegółowo w pierwszej niebieskiej książce przy dekodowaniu RC5

_________________
zapraszam na blog: http://www.mirekk36.blogspot.com (mój nick Skype: mirekk36 ) [ obejrzyj Kurs EAGLE ] [ mój kanał YT TV www.youtube.com/mirekk36 ]

Hej,

wielkie dzięki za wskazówki. Udało się dojść do dobrej formy. FYI, czterobitowa preambuła okazała się być wystarczającą.
Widzę jeszcze jedną rzecz, już niezwiązaną z częścią opartą na książce, mianowicie z obliczaniem sumy kontrolnej.
Obserwując w odbiorniku stopę błędów oraz liczbę odebranych i poprawnie odebranych pakietów, widzę, że zawsze w tych samych momentach następuje błąd - ewidentnie nie jest on losowym wynikającym z przekłamań transmisji. Dla funkcji crc16_update() różne CRC jest wyliczone na przykład dla 60. pakietu (dalej nie analizuję). Dla crc_ccitt_update() dla około setnego. W teorii tak być nie powinno, wszak zgodnie z sygnaturą sumę kontrolną przechowuję w zmiennej 16b, a dane wejściowe są 8b...?

Pozdrawiam.

Jeśli chodzi o to co piszesz z CRC to sorki ale w ogóle nie zrozumiałem co chciałeś przekazać

że crc źle działa ? czy jak ? .... przecież to niemożliwe - crc działa zawsze dobrze - no chyba że chodziło o coś innego

_________________
zapraszam na blog: http://www.mirekk36.blogspot.com (mój nick Skype: mirekk36 ) [ obejrzyj Kurs EAGLE ] [ mój kanał YT TV www.youtube.com/mirekk36 ]

Wywołuję crc16_update(checksum, bajt[i]) w nadajniku, wysyłam razem z pakietem tę sumę kontrolną (wyliczoną dla 16 wysyłanych bajtów danych).
W odbiorniku na odebranych danych wywołuję crc16_update(checksum, bajt[i]) dla 16 bajtów danych. Porównuję wyliczoną sumę kontrolną z przechwyconą w pakiecie - jest różnica. Zawsze w 60. pakiecie.

Chyba będę musiał potestować i popatrzeć co do bitu jak te dwie sumy kontrolne wyglądają.




Kod umieszczamy w syntax=c - Zielony J.