Witam,

W sąsiednim wątku (topic7694.html) na temat transmisji bezprzewodowej pojawił się interesujący mnie wpis, ale że nie chcę zaśmiecać autorowi jego tematu pozwoliłem sobie otworzyć mój własny "podtemat"

Oto cytat stamtąd:


Możesz to rozwinąć?

Bo może dojść do takiej sytuacji: Odbiorca poprawnie odebrał pakiet i wysłał potwierdzenie, a następnie wykonał rozkaz zawarty w pakiecie. Ale... Potwierdzenie nie doszło do nadawcy, więc ponawia on wysyłanie rozkazu. W rezultacie odbiorca ponownie dostaje rozkaz i ponownie go wykonuje, co może być błędem (np. rozkaz zwiększ wartość X o 1 - co przy podwójnym wykonaniu rozkazu da w rezultacie zwiększenie o 2).

Myślałem o wprowadzeniu tzw. bajtu serializacji, który zawierałby numer odp. temu która to liczba prób wysłania pakietu. I jeżeli odbiorca wykonałby wcześniej rozkaz z tego pakietu, a potem stwierdził, że przyszedł ten sam rozkaz, ale jest to kolejna "wysyłka" (spr. w/g bajtu serializacji), to nie wykonywałby już go ponownie, tylko pominął.

Problem w tym, że żeby stwierdzić, który to pakiet należałoby sprawdzić również wszystkie pozostałe bajty pakietu (bo rozkaz może być ten sam, ale różnić się zawartością pola danych), aby przekonać się czy to na pewno ten sam pakiet co poprzednio.
Dodatkowo jeszcze trzeba trzymać w buforze poprzednio odebrany pakiet. To wszystko wydłuża i komplikuje proces odbioru pakietu.

Czy może jest na to jakiś inny, prostszy sposób?

Qrcze - pisałem odpowiedź i jakaś dziwna przypadkowa kombinacja klawiszy zamknęła mi aplikację.....

Może jeszcze raz:

Własnie u mnie jest tak, że gada każdy-z-każdym, więc musiałbym przechowywać numery rozkazów dla każdego z "rozmówców", a dodatkowo ta liczba może być zmienna (jeśli wprowadzę "logowanie urządzeń do systemu").

W tej chwili jedyne sensowne rozwiązanie jakie mi przychodzi do głowy to takie:
Każdy pakiet ma bajt 'serializacji' zawierający liczbę odp. liczbie powtórek wysyłania pakietu.
Jeśli liczba ta wynosi zero=pierwszy pakiet, to warstwa wyższa protokołu obsługuje go normalnie (wykonuje rozkaz).
Natomiast jeśli serializacja>0, to wówczas przed wykonaniem rozkazu następuje porównanie bieżącego pakietu z kopią poprzedniego pakietu i jeżeli to ten sam pakiet, to rozkaz zawarty w nim nie będzie wykonywany.

To da tą oszczędność, że porównywanie nie będzie wykonywane za każdym razem, a tylko wówczas kiedy mamy do czynienia z powtórką. A bufory na dane z pakietów da się dwa, które będzie się tylko przełączać (unikamy dodatkowego kopiowania), a porównywać je będzie można 1-do-1'nego.

Oczywiście w niższej warstwie komunikacji odbiorca będzie przesyłał za każdym razem stosowne potwierdzenie odebrania pakietu.

To chyba ma sens

Qrcze, dobrze jest napisać posta na Forum, bo wtedy jakoś lepiej się myśli

Na razie napisałem z grubsza warstwę niskopoziomową tj. automatyczne przechodzenie w stan RX po wysłaniu pakietu lub potwierdzenia, odczyt danych z FIFO RFM'a po nadejściu rozkazu, obsługę CSMA ze slotami czasowymi i losowym wyborem slotu oraz timingi na oczekiwanie na odpowiedź - i jeśli nie przyjdzie w ustalonym czasie, zgłoszenie błędu do warstwy wyższej.
Przy czym są dwa rodzaje response - krótki 1 bajtowy, potwierdzający tylko poprawne odebranie pakietu, oraz drugi 'długi', który jednocześnie zwraca dane (jeśli życzy ich sobie nadawca).
Tak, żeby nie marnować czasu na dodatkowy rozkaz typu "przyślij dane".
I to jak wydaje się działa OK.

Żeby uniknąć sytuacji, że któryś z nadajników asynchronicznych może się władować ze swoim pakietem w moment między wysłaniem pakietu, a response, ustaliłem minimalny czas oczekiwania po wykryciu wolnej linii zanim rozpocznie się nadawanie, na dłuższy niż czas rozpoczęcia wysyłania response (plus oczywiście losowe sloty czasowe, ale z tą losowością to bym nie przesadzał dla liczby 4 bitowej ).
Przy kolejnych powtórkach wymyśliłem sobie, że nadawca będzie stopniowo zwiększał moc nadawania po każdej powtórce.

Pakiet jest o zmiennej długości - o jego wielkości powiadamia odbiorcę bajt 'length' - wykorzystałem tutaj sprzętową właściwość RFM'ów.
Wielkość pakietu max 64bajty danych (tyle ile się mieści jednorazowo w buforze FIFO.

Tak to mniej więcej wygląda.
Warstwa wyższa jeszcze nie jest napisana - trzeba ją dopiero wymyślić

Z tymi sesjami to możesz mieć rację - czytałem o zastosowaniu RTC/CTS w protokole CSMA/CA, aczkolwiek jak piszą "nie wszyscy to implementują".

Jak rozumiem, po wysłaniu żądania dostępu RTS do odbiorcy, odbiorca wysyła potwierdzenie CTS do nadawcy, ale jednocześnie jest to broadcast do wszystkich w sieci, żeby wstrzymali się ze swoimi próbami nadawania (czyli otwarcie kanału dostępu 1-na-1)?
Mówisz, że to musi być z time-out'em, żeby nie zablokować sieci?

Zastanawiam się jeszcze nad sposobem zaimplementowania automatycznego logowania urządzeń/nowych urządzeń w sieci po włączeniu ich zasilania.

Generalnie - mimo protokołu wielodostępowego chciałem, aby był jakiś sterownik nadrzędny (Master Controller), który mógłby być jednocześnie bramką do innych sieci (np. różne sieci bezprzewodowe, ethernet) oraz mógł on sterować pracą urządzeń na podstawie jakiś zdarzeń, itp...
Z drugiej strony intersująca byłaby inteligencja rozproszona, gdzie każde urządzenie mogłoby gadać z każdym niezależnie od MC.
Jeszcze nie mam ostatecznej koncepcji Może da się zmieszać jedno z drugim.

W tym kontekście "logowanie do sieci" musi wyglądać trochę inaczej dla każdego z rodzajów.
Na szczęście moduły oferują możliwość rozkazów typu broadcast, więc można porobić kategorie urządzeń - i w przypadku logowania do sieci z rozproszoną inteligencją można by informować o swojej obecności tylko pewną grupę urządzeń (takim grupowym rozkazem) - tą którą taka obecność "może zainteresować".

Z drugiej strony - co rozumieć przez "zalogowanie do sieci" - bo jeżeli nowe urządzenie ma być "wpięte w ciąg zdarzeń" jaki się w sieci rozgrywa, to nie unikniemy chyba ręcznej konfiguracji "jak na jakie zdarzenie ma dane urządzenie reagować"?

Chyba, że przez zalogowanie rozumieć tylko "hej, nie bylem dostępny, ale już jestem, jak mieliście do mnie jakieś sprawy, to czekam na rozkazy"

Generalnie ma to służyć do automatyki domowej - na razie nic do końca nie jest jeszcze ustalone

Heh...dokładnej koncepcji jeszcze nie ma, bo dopiero teraz przyszedł czas na jej tworzenie.
Najpierw musiałem sprawdzić jak działa sama transmisja (i nie obyło się bez pewnych problemów, na szczęście udało się je w miarę łatwo znaleźć).

Właściwie, to nawet teraz dałem sobie przerwę z protokołem i robię co innego, żeby umysł trochę sobie odpoczął od tej tematyki, ale "tematy się przewijają" i same się "wywołują do odpowiedzi"

Jak człowiek nie korzysta z jakiegoś gotowca, to otwiera się przed nim wiele możliwości i trzeba wybrać to, co nam najlepiej pasuje, ale zanim to się stanie, trzeba przećwiczyć to i tamto.
Chociaż muszę przyznać, że trochę pomysłów zaczerpnąłem ze specyfikacji protokołu LonTalk - jest to tam tak zgrabnie opisane

Niestety CSMA/CD (w/g mojej wiedzy) nie da się zrobić z modułami radiowymi pracującymi w półdupleksie - moduł musiałby podczas nadawania jednocześnie nasłuchiwać linii, żeby stwierdzić że coś zakłóca transmisję. A on niestety wyłącza nasłuch podczas nadawania

Jeśli chodzi o połączenia między nodami, to myślę o tym z tego względu, że mamy ciągłe zmiany w rodzajach transceiverów radiowych - te które są obecne teraz, za kilka lat mogą zostać wycofane z produkcji i trzeba będzie stosować nowe moduły.
Może zresztą będą one "nowsze, lepsze i piękniejsze" pod każdym względem i aż będzie się chciało je stosować.
Często jest tak, że nie są one kompatybilne wstecznie - zresztą, zmiana może być też z producenta X, na producenta Y, który zaproponuje lepsze układy.
W związku z tym trzeba będzie dołączać nowe gałęzie obok starych.
A muszą się one jakoś ze sobą komunikować.
Ale to oczywiście będzie sukcesywnie w razie potrzeby implementowane.


Szczerze mówiąc, to raczej staram się stosować wszędzie "minimalizm". To co powstaje wynika z tego, że jest to potrzebne.
Chociaż z drugiej strony czasami dobrze jest zrobić coś więcej - teraz wszyscy mamy kłopot z IPv4 i trzeba wprowadzać IPv6

To nie jest mój pierwszy protokół i pierwszy system automatyki domowej, ale "to było już tak dawno temu" (2002r), że wszystko się prawie teraz zmieniło, są nowe możliwości, nowe pomysły i znowu trzeba wszystko wymyślać od nowa.

A głowa ma właśnie "pęknąć" - takie jest założenie, żeby trochę rozruszać szare komórki