Zbieramy wymagania do protokołu komunikacji bezprzewodowej elektroda.pl

tzok wrote:

ylko jak to pogodzić z Arduino? Jeśli ma się przyjąć wśród amatorów, to moim zdaniem, musi działać na bazowym Arduino (ATMega 328PU) i pozostawiać jeszcze miejsce na program użytkownika.

To akurat nie jest problemem. Robisz nagłówki w C (export "C") i dodajesz do Arduino prekompilowany lib na ATM328. Prościej się nie da. Masz same zalety - zwięzłość kodu i prostota użycia poprzez wyeksportowane funkcje.

tzok wrote:

Jeden moduł ma własne MCU, który załatwia kodowanie, a może i adresację fizyczną i filtrowanie ramek, pozostaje tylko puścić bitstream na UART, czy SPI (i to jest jego warstwa fizyczna, bo oprogramowanie modułu jest zamknięte), a w innym module, musisz sobie kluczować tranzystorem w nadajniku (może trochę przesadzam). W drugą stronę jest chyba łatwiej - idziemy do warstwy aplikacji, czyli mamy metodę, która przyjmie wiadomość w formie ciągu znaków, czy tablicy bajtów i ją skutecznie prześle, pod wskazany adres (zajmując się jej podziałem na ramki, kontrolą błędów, potwierdzeniami, retransmisją).

Od tej strony (znaczy od góry, a może raczej od środka) bym poszedł. Kilka prostych funkcji umożliwiających wymianę danych. A potem co raz niżej, jak nisko to zależy od użytego modułu. To co wspiera w hardware wykorzystuje sterownik modułu. To czego hardware nie załatwia, załatwia załączony soft. W oparciu o taką koncepcję spokojnie udało mi się napisać prosty kod, który działa z RS485, RFM22, RFM63, z minimalnymi tylko zmianami w funkcjach operujących na sprzęcie.
Jeśli chodzi o protokół to:
- musi być możliwość nadawania z Ack lub bez, jeśli z Ack to automatyczne retransmisje,
- długość pakietu proponuję w zakresie 32-64 bajty - tak jak pisał Atom, powyżej zaczynają się kłopoty,, konieczność retransmisji, która wzrasta wykładniczo ze wzrostem długości pakietu, pojawia się problem zajętości RAM na bufory i po prostu jest to zbędne w większości transmisji. Dłuższe porcje danych można automatycznie segmentować na takie bloki.
- Adres - proponuję 8/16 bitowy (8 bitów adres urządzenia i 8 bitów opcjonalnie - adres sieci). Jeśli ktoś będzie miał powyżej 65000 urządzeń to i tak trzeba to podzielić na segmenty i zorganizować odpowiedni routing między nimi i to można załatwić zupełnie innym protokołem lub dodając kolejną warstwę. Długie adresy, np. 32-bitowe powodują, że już 8 bajtów jest zajęte na same adresy, a przy IoT jak mamy payload kilkubajtowy, to IMHO niepotrzebne.
- TTL pakietu - warto rozważyć, ale chyba też tylko jako opcję - warstwę nadawaną przez urządzenie routujące do innej podsieci.
- szyfrowanie - jak najbardziej, proponuję od razu przyjąć AES128. Tu proponuję osobny temat dotyczący dystrybucji kluczy. Pytanie (co zaproponował Atom) - o szyfrowanie adresu źródła i przeznaczenia. Szyfrowanie tych pól spowoduje, że wszystkie urządzenia muszą odebrać pakiet i go zdeszyfrować, co jest kosztowne. Nie wiem na ile taka opcja jest uzasadniona? Ale to też ciekawy temat na osobną dyskusję.

Czyli należałoby się ograniczyć do 2, max. 3 warstw - warstwy aplikacji, warstwy sieci i warstwy fizycznej, przy czym można by połączyć warstwę sieci i fizyczną. Proponowałbym nazwać je warstwą użytkownika i warstwą transmisji. Warstwę użytkownika stanowiłoby de facto API, a warstwę transmisji - cała reszta, ew. z warstwy transmisji można by wyodrębnić warstwę (dostępu do) sprzętu.

tmf wrote:

Długie adresy, np. 32-bitowe powodują, że już 8 bajtów jest zajęte na same adresy, a przy IoT jak mamy payload kilkubajtowy, to IMHO niepotrzebne.

Wcześniej podałem workaround na to.
A długie adresy są całkiem potrzebne. Dzięki nim można zrobić np. piloty zdalnego sterowania gdzie każdy będzie miał swój indywidualny adres. Oczywiście można też zrobić inaczej, gdzie identyfikator był by wysyłany jako dane, i wtedy długi adres nie był by potrzebny. No ale możliwość wykorzystania do tego adresu zawsze była by jakimś plusem.

tzok wrote:

Proponowałbym nazwać je warstwą użytkownika i warstwą transmisji. Warstwę użytkownika stanowiłoby de facto API, a warstwę transmisji - cała reszta, ew. z warstwy transmisji można by wyodrębnić warstwę (dostępu do) sprzętu.

Dokładnie tak. Jeśli ktoś potrzebowałby więcej, to zawsze można dodać jakieś wyższe warstwy, przy czym myślę, że tu nie ma co kombinować i trzeba przyjąć, że protokół ma obsługiwać sieci lokalne o ograniczonym zasięgu i liczbie urządzeń. Komunikację międzysieciową można zrealizować przy pomocy istniejącego protokołu - chociażby TCP/IP. Tu narzuty sprzętowe są bez znaczenia, bo to będzie zupełnie inny rodzaj wymienianych danych i będą one wymieniane pomiędzy węzłami sieci, więc z definicji urządzeniami dysponującymi znacznie większymi zasobami.

atom1477 wrote:

Wcześniej podałem workaround na to.

Ok, czyli np. tak to można zrobić - podstawowe kodowanie adresu 8 bit. Przy czym dwa najbardziej znaczące bity określają np. liczbę bajtów adresu - 00 - 1, 01 - 2, 10 - 3, 11 - 4. w ten sposób można przy 8-bitowym adresie mieć max. 64 urządzenia (62 + broadcast + gate). W sumie pasuje nawet do specyfikacji RS485, gdzie zasadniczo mamy 32 urządzenia, lub odpowiednio więcej o ułamkowych obciążeniach. Można ew. poświęcić te 2 bity z pola payload len pakietu, jako, że payload nie przekroczy 64 bajtów (proponuję taką granicę, bo raz, że jest to górna granica rozsądku, dwa, że takimi buforami dysponuje wiele transceiverów radiowych).

A nie lepiej tak jak podałem, gdzie na kodowanie długości idzie 1 bit z każdego bajtu, i prawie nie ma ograniczenia długości kodowania?
Wtedy 8 bitów koduje 128 adresów. Więcej niż u Ciebie.
A dodatkowo nie oma ograniczenia że adres może być maksymalnie tylko 32 bitowy. To akurat mała zaleta, no ale zawsze.

Zglaszam się do działań w zakresie tworzenia wymagań na taki protokoł.
Jak rozumiem
- chcemy przesyłać dane czujników w pasmie nie wymagajacym licencji.
- prawdopodobne pasmo to 43xMHz albo 2.4GHz
- na 43xM pasmo calego kanalu to 20kHz a wiec tam bedzie podobny poziom zaklocen co na 2.4G na Ursynowie
- 2.4G - duzy poziom zaklocen ale wieksze pasmo (20M na kanal)
- Dopuszczalna modulacja - teoretycznie na 43x jest tylko modulacja kluczowaniem amplitudy ale... Po pierwsze - pasmo to 20k wiec uzyteczna modulacja w warunkach amatorskich to bedzie jakies kilka kb/s. Stosując sensowniejszą modulację mozna to podnieść ale,...
- Na 43x - dookola jest duzo kanalow uzywanych przez radioamatorow - na przykład do łącznosci z ultra niskim poziomem sygnalu wiec sygnal w antenie musi byc czysty,
- konfiguracje stacji:
+ tylko nadajnik (np. czujnik temperatury zewnętrznej)
+ tylko odbiornik (np. stacja pogodowa)
+ nadajnik / odbiornik (element wykonawczy z wbudowanym czujnikiem)
- Czujników może być dużo w jednej sieci (>256). Chyba dobrym wyjściem było by użycie rozwiązania z sieci (dlugi MAC - ustalanie MAC jako randomizowanych numerów w dużej odległości kodowej od już znanych.)
- moze istniec dużo sieci pomiarowych na jednej czestotliwosci (<255).
- Powinno byc 'maskowanie' adresow wlasnych czujników
- Rozumiem że sieci miały by brak konfiguracji uzycia pasma radiowego (oprocz randomizacji opoznienia dostepu).
- Pakiet danych powinien byc zabezpieczony kodem korekcyjnym o duzej mocy. Długość pakietu powinna byc relatywnie niewielka - kilkanaście do 100 bytów - po dodaniu sum korekcyjnych to może być ok. 2000 bitów co było by równoważne z maksymalnym czasem zajęcia kanału rzędu 0.2-0.5s. Jeśli będzie wymaganie krótszego zajęcia kanału to będzie musiał być krótszy najdłuższy komunikat
- pakiety były by numerowane (z krótkim licznikiem - np. 1 byte) aby umożliwić wychwycenie strat w sieci (a przy takich zakłóceniach były by na pewno)
- Stacje posiadają 'randomizację' momentów nadawania aby zmniejszyć kolizje. Przy nadawaniu cyklicznym dawało by to powiedzmy dla czujnika temperatury zewnętrznej czas co 10 sek z rozrzutem od 5 do 15 sek. Czas 'losowy' wynikałby z numeru MAC i numeru komunikatu.
- dla komunikatów krytycznych komunikaty były by powtarzane wielokrotnie z zachowaniem randomizacji.

Dziękuję, dodałem.

Tutaj zbieramy wymagania: https://www.elektroda.pl/rtvforum/topic3764817.html

- chcemy przesyłać dane czujników w pasmie nie wymagajacym licencji
->TAK to kwestia wybrania modułów, protokół jest wyżej

- prawdopodobne pasmo to 43xMHz albo 2.4GHz
->TAK moduły na pasma ISM 433/868/2400

- na 43xM pasmo calego kanalu to 20kHz a wiec tam bedzie podobny poziom zaklocen co na 2.4G na Ursynowie
->korzystamy z gotowych modułów, dostępnych pasm i musimy się liczyć z ograniczeniami...

- 2.4G - duzy poziom zaklocen ale wieksze pasmo (20M na kanal)
->protokół ma być do "lekkich" transmisji więc nie będziemy strumieniowali wideo, bardziej sieci czujnikowe, automatyka domowa a nawet proste projekty typu bezprzewodowy termometr

- Dopuszczalna modulacja - teoretycznie na 43x jest tylko modulacja kluczowaniem amplitudy ale... Po pierwsze - pasmo to 20k wiec ->użyteczna modulacja w warunkach amatorskich to bedzie jakies kilka kb/s. Stosując sensowniejszą modulację mozna to podnieść ale,...
korzystamy z gotowych modułów, "sterownik" do modułu pozwala na wykorzystanie modułu przez protokół

- Na 43x - dookola jest duzo kanalow uzywanych przez radioamatorow - na przykład do łącznosci z ultra niskim poziomem sygnalu wiec sygnal w antenie musi byc czysty,
->ISM i pasma amatorskie zachodzą na siebie, szczególnie 433

- konfiguracje stacji:
- tylko nadajnik (np. czujnik temperatury zewnetrznej)
- tylko odbiornik (np. stacja pogodowa)
- nadajnik / odbiornik (element wykonawczy z wbudowanym czujnikiem)
->dowolne konfiguracje jedno/dwu kierunkowe, punkt-punkt, sieci z wieloma węzłami, sieci z bramką, komunikacja z potwierdzeniami i bez

- Czujników może być dużo w jednej sieci (>256). Chyba dobrym wyjsciem było by uzycie rozwiazania z sieci (dlugi MAC - ustalanie MAC jako randomizowanych numerów w dużej odległości kodowej od już znanych.)
- moze istniec dużo sieci pomiarowych na jednej czestotliwosci (<255).
- Powinno byc 'maskowanie' adresow wlasnych czujników
- Rozumiem że sieci miały by brak konfiguracji uzycia pasma radiowego (oprocz randomizacji opoznienia dostepu).
- Pakiet danych powinien byc zabezpieczony kodem korekcyjnym o duzej mocy.
->Z praktycznego punktu widzenia bramka/obszar nie przekroczy pewnie 255 urządzeń, adresowanie 16bit powinno wystarczyć, jeżeli włączymy szyfrowanie to kilka sieci o tym samym adresie może koegzystować. Funkcja skrótu / CRC to ważna sprawa przy zabezpieczeniu integralności, potrzebny będzie wybór ilości bitów takiego zabezpieczenia, może 32b wystarczy aby uniknąć 128b?

Dlugosc pakietu powinna byc relatywnie niewielka - kilkanascie do 100 bytow - po dodaniu sum korekcyjnych to może być ok. 2000 bitów co było by równoważne z maksymalnym czasem zajęcia kanału rzędu 0.2-0.5s. Jeśli będzie wymaganie krótszego zajęcia kanału to będzie musiał być krótszy najdłuższy komunikat
- pakiety były by numerowane (z krótkim licznikiem - np. 1 byte) aby umożliwić wychwycenie strat w sieci (a przy takich zaklóceniach były by na pewno)
- Stacje posiadają 'randomizację' momentów nadawania aby zmniejszyć kolizje. Przy nadawaniu cyklicznym dawało by to powiedzmy dla czujnika temperatury zewnętrznej czas co 10 sek z rozrzutem od 5 do 15 sek. Czas 'losowy' wynikałby z numeru MAC i numeru komunikatu.
- dla komunikatów krytycznych komunikaty były by powtarzane wielokrotnie z zachowaniem randomizacji.
->zgadza się są też pomysły z RTC i szczelinami czasowymi, wszystko zależy od możliwości sprzętu i wybranych opcji protokołu

And! wrote:

Dziękuję, dodałem.

Quote:

Tutaj zbieramy wymagania: https://www.elektroda.pl/rtvforum/topic3764817.html

Mozesz przerzucic ten wątek?

Quote:

- chcemy przesyłać dane czujników w pasmie nie wymagajacym licencji
->TAK to kwestia wybrania modułów, protokół jest wyżej

W związku z istnieniem ciekawych procesorów TI nie wykluczałbym własnego dłubania (i później przejście przez badania typu)

Quote:

- prawdopodobne pasmo to 43xMHz albo 2.4GHz
->TAK moduły na pasma ISM 433/868/2400

Co do 868M to jego status jest niedobry. Owszem 'kluczyki' to używają ale jedynie dlatego ze kto bogatemu zabroni...

Quote:

- na 43xM pasmo calego kanalu to 20kHz a wiec tam bedzie podobny poziom zaklocen co na 2.4G na Ursynowie
->korzystamy z gotowych modułów, dostępnych pasm i musimy się liczyć z ograniczeniami...

Moduły (w większości) dają kluczowanie nadajnika i tyle. Nie wchodzą zbytnio w przygotowanie sygnału do modulacji. A tu dużo można zrobic (dobrego i zlego)

Quote:

- 2.4G - duzy poziom zaklocen ale wieksze pasmo (20M na kanal)
->protokół ma być do "lekkich" transmisji więc nie będziemy strumieniowali wideo, bardziej sieci czujnikowe, automatyka domowa a nawet proste projekty typu bezprzewodowy termometr

No nie byłbym tak halo do przodu... Powiedzmy że mamy przemysł (wystarczy duże osiedle), duże zakłócenia i kilka sieci. W sieci pomiarowo dozorowej moze byc spokojnie kilkaset czujek / mierników. Każdy niby 'bierze' tyle co nic z pasma ale suma to mogą być na granicy wydolności dla 43x (jesli nie poza nia). Do tego dochodzi problem Tx-only - a wiec ilość wymaganych retransmisji i tak dalej... W sumie pasmo jest istotne. No chyba że mówimy o stacji pogodowej z jednym czujnikiem - w środku lasu... Wtedy wystarczy zrobic reverse engineering ze stacji meteo i gotowe.

Quote:

- Dopuszczalna modulacja - teoretycznie na 43x jest tylko modulacja kluczowaniem amplitudy ale... Po pierwsze - pasmo to 20k wiec ->użyteczna modulacja w warunkach amatorskich to bedzie jakies kilka kb/s. Stosując sensowniejszą modulację mozna to podnieść ale,...
korzystamy z gotowych modułów, "sterownik" do modułu pozwala na wykorzystanie modułu przez protokół

Moduł zwykle dopuszcza różne szybkości transmisji... No chyba że tematem jest jak zrobic reverse engineering termometrow chinczyka

Quote:

- Na 43x - dookola jest duzo kanalow uzywanych przez radioamatorow - na przykład do łącznosci z ultra niskim poziomem sygnalu wiec sygnal w antenie musi byc czysty,
->ISM i pasma amatorskie zachodzą na siebie, szczególnie 433

Na 433 nie powinno byc komercji. Moze sie pojawiac (bo kto chinczykowi zabroni) ale wyjatkowo. Raczej 430 / 439 no powiedzmy jeszcze jakas teledacja by sie dopasowala... Krajowy plan zagospodarowania częstotliwości radiowych tako rzecze.

- konfiguracje stacji:
- tylko nadajnik (np. czujnik temperatury zewnetrznej)
- tylko odbiornik (np. stacja pogodowa)
- nadajnik / odbiornik (element wykonawczy z wbudowanym czujnikiem)
->dowolne konfiguracje jedno/dwu kierunkowe, punkt-punkt, sieci z wieloma węzłami, sieci z bramką, komunikacja z potwierdzeniami i bez

Quote:

- Czujników może być dużo w jednej sieci (>256). Chyba dobrym wyjsciem było by uzycie rozwiazania z sieci (dlugi MAC - ustalanie MAC jako randomizowanych numerów w dużej odległości kodowej od już znanych.)
- moze istniec dużo sieci pomiarowych na jednej czestotliwosci (<255).
- Powinno byc 'maskowanie' adresow wlasnych czujników
- Rozumiem że sieci miały by brak konfiguracji uzycia pasma radiowego (oprocz randomizacji opoznienia dostepu).
- Pakiet danych powinien byc zabezpieczony kodem korekcyjnym o duzej mocy.
->Z praktycznego punktu widzenia bramka/obszar nie przekroczy pewnie 255 urządzeń, adresowanie 16bit powinno wystarczyć, jeżeli włączymy szyfrowanie to kilka sieci o tym samym adresie może koegzystować. Funkcja skrótu / CRC to ważna sprawa przy zabezpieczeniu integralności, potrzebny będzie wybór ilości bitów takiego zabezpieczenia, może 32b wystarczy aby uniknąć 128b?

Tu trzeba myslec o przyszlosci. Powiedzmy ze standart sie przyjmie. I ze ktos do 'naszego' obszaru przywlecze obca siec. 16 bit wtedy to za malo (to praktycznie gwarancja ze sie pokryja). Trzeba by zrobic strone z alokatorem MAC i dac powiedzmy 48 bit (6B).
Funkcja skrotu/crc to ochrona transmisyjna a ja raczej bym proponowal mocne kody korekcyjne (orchard tree albo cos takiego)

Quote:

Dlugosc pakietu powinna byc relatywnie niewielka - kilkanascie do 100 bytow - po dodaniu sum korekcyjnych to może być ok. 2000 bitów co było by równoważne z maksymalnym czasem zajęcia kanału rzędu 0.2-0.5s. Jeśli będzie wymaganie krótszego zajęcia kanału to będzie musiał być krótszy najdłuższy komunikat
- pakiety były by numerowane (z krótkim licznikiem - np. 1 byte) aby umożliwić wychwycenie strat w sieci (a przy takich zaklóceniach były by na pewno)
- Stacje posiadają 'randomizację' momentów nadawania aby zmniejszyć kolizje. Przy nadawaniu cyklicznym dawało by to powiedzmy dla czujnika temperatury zewnętrznej czas co 10 sek z rozrzutem od 5 do 15 sek. Czas 'losowy' wynikałby z numeru MAC i numeru komunikatu.
- dla komunikatów krytycznych komunikaty były by powtarzane wielokrotnie z zachowaniem randomizacji.
->zgadza się są też pomysły z RTC i szczelinami czasowymi, wszystko zależy od możliwości sprzętu i wybranych opcji protokołu

RTC nie bedzie działał (dryfty w czasie) - no chyba ze mocno podwyzszamy cene urzadzen (bateria do podrzymania, rtc, dobry kwarc 32k/4M). Stawiałbym na randomizację i powtórzenia

Co oznacza, że status 868MHz jest niedobry?
Finalnie jest to ew. ograniczenie ilości modułów z jakimi może współpracować protokół.

Moduły poza "kluczowaniem przez dane" mogą robić znacznie więcej, wliczając w to bufor, "silnik pakietów", preambułę do WOR i sync word, CRC, szyfrowanie, a zaczynając od konfiguracji parametrów modułu. Oczywiście są też proste moduły OOK "on wire".

Przywleczenie obcej sieci w naszą adresację to problem, chyba że włączymy szyfrowanie lub "podpisy cyfrowe" urządzeń.

Co do zarządzania pasmem szczeliny czasowe i RTC zadziałają jeżeli będzie synchronizacja RTC przy każdej z transmisji, to tylko jeden z możliwych pomysłów, randomizacja również nie rozwiązuje problemu jednak może być dobra np. przy transmisjach jednokierunkowych.
Jak widzisz schemat randomizacji transmisji urządzeń tylko nadających przy założeniu interwału raportowania 60min?

And! wrote:

Co oznacza, że status 868MHz jest niedobry?

Zarządzenie nr 22 z 17.09.2007
https://bip.uke.gov.pl/gfx/bip/userfiles/_sha...odarowania_czestot/868-870_mhz_2007-09-17.pdf
streszczajac: Użytkowanie rządowe.

And! wrote:

Przywleczenie obcej sieci w naszą adresację to problem, chyba że włączymy szyfrowanie lub "podpisy cyfrowe" urządzeń.

Przywleczenie obcych sieci jest naturalną cechą fal radiowych. Przykładowo dla 400MHz i okolic bedziesz miał odbicia od księżyca (Moon relay jest rzeczywiście używane w radiokomunikacji amatorskiej.) Proponowane rozwiązanie podałem. Skuteczne (o ile nie będzie kozaków którzy będą dawali adresy z powietrza wzięte).

And! wrote:

Co do zarządzania pasmem szczeliny czasowe i RTC zadziałają jeżeli będzie synchronizacja RTC przy każdej z transmisji, to tylko jeden z możliwych pomysłów, randomizacja również nie rozwiązuje problemu jednak może być dobra np. przy transmisjach jednokierunkowych.
Jak widzisz schemat randomizacji transmisji urządzeń tylko nadających przy założeniu interwału raportowania 60min?

Nie będzie synchronizacji bo w pakiecie nie idzie czas - a z reszta ktoś może 'truć' czas (problem NTP). Synchronizacja czasu dla sieci o nieheterogonicznych jeśli chodzi o straty czy opóźnienia to złożona sprawa (kiedyś się tym zajmowałem dla sieci radiowych trochę bardziej profesjonalnych). Dodatkowo dla typowego użycia nadajnik nie będzie miał szansy na korektę bo nie będzie niczego odbierał.
Propozycja randomizacji dla sygnałów okresowych jest w tekście. W przypadku dużych okresów retransmisji wystarczy zakres zmienności powiedzmy +/- kilkanaście / kilkadziesiąt sekund (zależy od długości pakietu, błędów zegarów) itd.

Sposobów na zarządzanie pasmem jest wiele zarówno nadawanie w różnych cyklach jak i synchronizowanie czasu dla sieci. W przypadku stosowania transceiverów czas można przekazywać w pakietach z potwierdzeniem, urządzenie bateryjne, które zwykle nadaje może nasłuchiwać po nadawaniu przez ograniczony czas czy bramka ma do niego jakieś dane. Urządzenie bateryjne z transceiverem samo może wysłać zapytanie o czas do bramki.

And! wrote:

Sposobów na zarządzanie pasmem jest wiele zarówno nadawanie w różnych cyklach jak i synchronizowanie czasu dla sieci. W przypadku stosowania transceiverów czas można przekazywać w pakietach z potwierdzeniem, urządzenie bateryjne, które zwykle nadaje może nasłuchiwać po nadawaniu przez ograniczony czas czy bramka ma do niego jakieś dane. Urządzenie bateryjne z transceiverem samo może wysłać zapytanie o czas do bramki.

Widze ze moj poprzedni text nie doszedl.

Przy urządzeniach jednokierunkowych nie da sie potwierdzac czy uzganiac czas czy dostep do sieci. Nie da sie.