Elektroda.pl
Elektroda.pl
X

Search our partners

Find the latest content on electronic components. Datasheets.com
Elektroda.pl
OptexOptex
Please add exception to AdBlock for elektroda.pl.
If you watch the ads, you support portal and users.

Zbieramy wymagania do protokołu komunikacji bezprzewodowej elektroda.pl

06 Jan 2021 11:31 4335 42
  • Admin of Design group
    Zbieramy wymagania do protokołu komunikacji bezprzewodowej elektroda.pl
    W pierwszym etapie projektu protokołu bezprzewodowego tworzonego na elektroda.pl zbieramy proponowane wymagania.
    Zapraszamy do wypowiedzi w tym temacie. Jakie macie wymagania dla protokołu bezprzewodowego?

    Szczegóły o projekcie znajdziecie tutaj: projektujemy otwarty protokół bezprzewodowej komunikacji - unirf




    Zakładanym efektem końcowym jest dostarczenie otwartego protokołu na różne platformy sprzętowe. Protokół zapewni komunikację bezprzewodową z wykorzystaniem różnych dostępnych modułów radiowych. Podłączamy wybrany moduł, konfigurujemy potrzebne opcje, wywołujemy odpowiednie funkcjonalności i mamy zapewnioną komunikację. Protokół możliwy do wykorzystania zarówno w nieskomplikowanych projektach typu bezprzewodowy termometr, jak również w bardziej złożonych pomysłach typu automatyka domowa.


    Link


    maciej_333
    Trzeba odpowiedzieć na początek na kilka pytań:
    1. Komunikacja ma być punkt-punkt? Może punkt-wielopunkt? Co z kolizjami (unikanie-nasłuchiwanie, jakieś kary)? Stosowany ma być multihop?
    Ad 1. Komunikacja może być punkt-punkt, punkt-wielopunkt, jedno i dwu kierunkowa, z potwierdzeniem i bez, do wyboru podczas korzystania z protokołu. Kolizje: możliwe nasłuchiwanie / sloty czasowe. Multihop / routing do przemyślenia - nie ograniczać w projekcie protokołu.

    2. Czy trzeba oszczędzać energię? Protokoły komunikacyjne tego rodzaju działają kompletnie inaczej. Coś takiego jest np. w licznikach zużycia gazu.
    Ad 2. Można oszczędzać lub nie energię (np. nasłuchiwanie ciągłe lub tylko po nadawniu)

    3. Jakie to ma mieć ograniczenia? Pamięć RAM i pamięć programu danego mikrokontrolera jest ograniczeniem? Ile węzłów sieci jest przewidzianych? Czy w ogóle mowa o sieci (patrz punkt 1)?
    Ad 3. Ograniczenia co do RAM i ilości węzłów do przemyślenia.
    Nastawienie na sieć z bramką (bramkami) ale możliwość też zainicjalizowania jako punkt-punkt albo np. mesh 3-4 urządzeń.

    4. Co z szyfrowaniem transmisji? Jest to potrzebne?
    Ad4. Szyfrowanie gdy potrzebne - włączone. Temat do dyskusji dystrybucja/przechowywanie klucza/kluczy.

    5. Co z kompresją danych? Kompresja prowadzi do mniejszej liczby i krótszych pakietów wysyłanych.
    Ad5. Kompresja do przemyślenia (często ramki będą dość krótkie) a kompresja wymaga często narzutu większego niż szyfrowanie. Projekt protokołu nie powinien wykluczać, czy będzie implementowane to się zobaczy. Np. pole data może być danymi zaszyfrowanymi, raw, lub skompresowanymi.

    6. obsługa prostych modułów OOK PWM/manchester?

    7. WOR

    excray
    notatki do projektu opartego o nrf24L01:
    - sensor włącza się co określony czas (np co 0.99s) i 1-nasłuchuje lub 2-nadaje, po czym czeka jakiś czas na instrukcje/odpowiedź. Przy nasłuchu (1) czeka na inną transmisję i się synchronizuje czasowo.
    - sensor odpowiada na indywidualne zapytania, grupowe oraz "do wszystkich".
    - przy pierwszym uruchomieniu jest aktywny i czeka określony czas aż uda mu się zsynchronizować z innymi sensorami
    - sensor można zdalnie wyłączyć
    - sensor posiada mapę routingu z alternatywnymi połaczeniami na wypadek awarii jakiegoś sensora pośredniczącego
    - sensor może pracować w trybie normalnym i oszczędnym. W tym drugim trybie nie wybudza się co 1s i nie pośredniczy w transmisji tylko i wyłacznie wybudza się gdy sam musi coś nadać bądź co określony czas znacznie rzadziej niż normalnie (tryb 2).
    - sensor ma własne id, transmisje mają własne ID
    - sensor nie przekazuje informacji z ID zgodnym z zapisem nadanych już transmisji chyba że jest w specjalnym trybie
    - komunikacja zawiera adres docelowy, adres następnego węzła oraz TTL.
    - określanie optymalnej ścieżki na podstawie TTL
    - dodawanie swojego adresu do transmisji + zwiększenie wskaźnika adresu w trybie "routing"
    - protokół z zadaną ścieżką transmisji/powrotu
    - protokoły programujące moduł np protokół zadający modułowi sprawdzanie param. co np. 10 minut i wysłanie wyniku

    RebellionArts
    -Na pewno uniwersalność, czujnik ruchu nie równa się z czujnikiem dymu, ale komunikacja nie powinna być ani gorsza ani lepsza - oba powinny reprezentować ten sam poziom, jakość.

    -Adresacja urządzeń będzie istotną sprawą i oznaczenie ,,matki". Czy matka będzie miała adres 0000 zawsze, a reszta od 0001 - do 9999?

    -To jest myśl do rozwinięcia, chodzi o łatwość dodawania kolejnych elementów do systemu za pomocą protokołu.

    -Przykłady zastosowań: jak dla większego projektu to nie radze robić ograniczeń. Jest wiele modułów które rozbudowują system..., i demontują ilość papieru wartościowego w portfelu...

    -Możliwość dodania czujnika bez rozbudowania serca automatyki to dobry cel, warto pomyśleć nad tym, by zaproponowane rozwiązanie protokołu z hardware mogło obsłużyć do 100 urządzeń lub więcej ( w myśl aby przy komunikacji 60 urządzeń naraz nie spadła prędkość transmisji - 'zbytnio' :) )

    -Rozwiązaniem może być stworzenie portów (węzłów) które odbierają tylko określony typ urządzenia (czujnika), czyli w ramce z adresem trzeba by też określić typ slave-a . A porty przekazują dane do matki.
    To wszystko jednak zależy od tego na ile wydajny będzie ten protokół.

    -Co do szyfrowania to myślę, że dobrym pomysłem może być stosowanie własnych 'soli' jak w przypadku baz danych na serwerze

    -Takim jeszcze pierwszym spojrzeniem na temat można popracować nad weryfikacją danych - czy są niezakłamane (za pomocą sumy kontrolnej?) Załóżmy że mamy jakiś przekaźnik który odbiera dane z domu i (podbijając ich moc) przekazuje do czujników na zewnątrz. Przekaźnik ten mógłby sprawdzać poprawność danych ,,przy okazji"

    atom1477
    - Długie adresowanie, co najmniej 32-bitowe.
    - Adresowanie nadawcy. Też 32-bitowe.
    Przy czym oba adresy może powinno być opcjonalne, i zaznaczane np. 1 bitem w adresie. Czyli np. 8 bitów "statusu", a za nimi 24 + 32 bitów opcjonalnych adresów (jak "status" wskazuje że adresy są przesyłane, jak nie wskazuje to ramka jest krótsza, no i siłą rzeczy taka ramka jest typu rozgłoszeniowego).
    - CRC co najmniej 32-bitowe.
    - Praca z potwierdzeniami i bez potwierdzania (wybierane przy nadawaniu).
    - Szyfrowanie transmisji, z wyborem czy adresy też są szyfrowane czy nie (też 1 bit ze "statusu").
    - Użycie tylko warstwy fizycznej modułów, w celu zapewnienia kompatybilności tego samego protokołu z różnymi modułami. To wymaga używania np. UARTa.
    Ten punkt pewnie się spotka z oporem, ale to jest mus gdy to ma być kompatybilne z duża ilością całkiem różnych modułów. Na pewno moduły mają różne tryby adresowania oraz różne wymagane preambuły, więc nie da się zrobić uniwersalnego protokołu bez zaangażowania uC do dekodowania ramek.
    Szkoda, bo wtedy nie da się zrobić WoR (Wake on Radio), no ale to jest wynik założeń uniwersalności.

    And!
    -Możemy określić sobie modele transceiverów i to może się przydać, jednak jest wiele innych możliwych propozycji wymagań,

    -Gdy na samym końcu protokół zostanie zaimplementowany i połączony ze "sterownikami" do modułów radiowych to wyobrażam to sobie tak jak np. w projekcie do obsługi wyświetlaczy LCD/TFT/OLED z magistralami I2C oraz SPI https://github.com/olikraus/u8g2
    gdzie tworzymy obiekt danej klasy uruchamiając komunikację po SPI z LCD na ST7920
    U8G2_ST7920_128X64_1_SW_SPI u8g2(U8G2_R0, /* clock=*/ 13, /* data=*/ 11, /* CS=*/ 10, /* reset=*/ 8);
    albo z OLED na SSD1306 po I2C
    U8G2_SSD1306_128X32_UNIVISION_F_SW_I2C u8g2(U8G2_R0, /* clock=*/ 1, /* data=*/ 2, /* reset=*/ 3);

    -Od strony wykorzystania widzę to tak:
    wykorzystanie protokołu->protokół->sterownik->kodowanie->moduł->modulacja->transmisja radiowa

    acctr
    - koncentracja na tanich, prostych, chińskich modułach (zaawansowane moduły mają już własne protokoły lub wsparcie w postaci bibliotek i społeczności, brnięcie w protokół na mocnym module nie skończy się dobrze)
    - protokół zorientowany na istniejące HW (zawężenie zestawu modułów RF, które mają mało zaimplementowane, przedyskutowanie ich słabych i mocnych stron)
    - obsługa różnych topologii (połączenie jeden to jeden, wiele do jednego,..),
    - wyodrębnione role urządzeń (nadajnik, odbiornik, transceiver, stacja bazowa, repeater,..)
    - co najmniej dwa kanały logiczne
    * Data Channel - głównie dla użytkownika końcowego, przesył danych lub danych kontrolnych z najwyższej warstwy, kontrola integralności danych, update oprogramowania (?)
    * Control Channel - kontrola jakości połączenia, stanu każdego z elementów sieci, attach/detach, parametry pracy modułu RF, sterowanie modułem
    - konfigurowalna długość ramki w zależności od HW i potrzeb w zastosowanym projekcie (niewykorzystanie funkcji protokołu powinno wpływać na uproszczenie ramki)
    - określenie minimalnego wymagania co do MCU (nie ma sensu zakładać, że pójdzie na byle czym, ceny wydajnych mikrokontrolerów to pojedyncze złotówki)

    maciej_333

    Jeśli cokolwiek ma z tego wyjść, to może tak:
    -Przyjąć tylko kilka transceiverów: CC1101, S2-LP, jakiś biedny jak RFM12B (nawet dokumentacja jest wyraźnie gorsza od poprzednio wymienionych).
    -Protokół powinien być głównie dla sieci sensorycznych z multihop (musi być wtedy pole TTL, by nie zalać sieci pakietami, które będą krążyły w nieskończoność). Powiedzmy, że chodzi o liczniki energii elektrycznej (brak konieczności oszczędności energii). Takie coś znajdzie też zastosowanie w IOT, które jest obecnie bardzo popularne z jakiegoś nieznanego powodu. Na czymś takim da się też wykonywać prostsze połączenia (punkt-punkt), bez modyfikacji.
    -Odpuszczenie sobie łączenia różnych transceiverów ze sobą. Jest to ogromne ułatwienie.
    -Pula adresów 16 bitów, CRC sprzętowe, jakie udostępnia transceiver, adresowanie węzłów sprzętowe lub programowe (nie każdy transceiver to ma). Pakiet rozgłoszeniowy z adresem np. 0x0000.
    -Brak węzła wyróżnionego.
    -Maksymalne wykorzystanie sprzętu.
    -CSMA/CA (sprzętowe lub częściowo programowe).
    -Mimo braku konieczności oszczędzania energii nasłuch może być z WOR. Da się zrobić protokół z tym i bez tego (wyłączalne).
    -Brak warstw o dużym poziomie abstrakcji. Generalnie użytkownik może wykorzystywać bardzo różne własne komunikaty, polecenia itp. Zatem tym powinna zająć się warstwa aplikacji.
    -Model warstwowy może być taki:
    3. Warstwa aplikacji - jest to program użytkownika.
    2. Warstwa łącza danych (adresacja, obsługa przerwań, CSMA/CA) - wspólna dla wszystkich transiceiverów, ale
    częściowo modyfikowana za pomocą kompilacji warunkowej, zależnie od typu transceivera.
    1. Warstwa adaptacji do sprzętu (ang. HAL - Hardware Adaptative Layer) - całkowicie inna dla każdego
    transceivera. Jej wariant jest wybierany za pomocą kompilacji warunkowej, zależnie od typu transceivera.
    0. Warstwa fizyczna
    -Jakieś w miarę proste szyfrowanie. Tu jest problem, bo tanie mikrokontrolery tego nie wspierają i trzeba to robić programowo. Można wykorzystać np. DES.
    -Raczej brak kompresji. Jest to bardzo przydatne, ale pominąłbym to dla znacznego uproszczenia. Załóżmy, że nikt nie będzie robił np. bootloadera bezprzewodowego w sieci sensorycznej.
    -Przyjąć np. tylko dwie lub trzy różne przepływności bitowe i co za tym idzie symbolowe. Tylko jedna modulacja.
    -Wybór tylko kilku kanałów w ISM. Jest to uproszczenie i to spore. Należy też zapomnieć o dynamicznej zmianie kanału w trakcie pracy lub wyborze automatycznym kanału o mniejszej zajętości. Szerokość kanału zależy od punktu poprzedniego.


    Do zastosowań amatorskich można zaimplementować coś w rodzaju MODBUS, ale bezprzewodowo. Chodziłoby wówczas o zdalny dostęp do rejestrów. Rejestry te wypełniałaby i odczytywała aplikacja użytkownika. Byłoby to proste w użyciu. Wystarczyłoby w trakcie inicjalizacji podać wskaźnik na tablicę z tymi rejestrami. Jednak uważam to za kiepski pomysł, ponadto widać od razu pewne problemy implementacyjne, jeśli interfejs między aplikacją użytkownika a warstwą trzecią ma być tak prosty.

    tmf
    - 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ę.
    [30.03.2021, darmowy webinar] Nowoczesna diagnostyka maszyn, monitorowanie i przewidywanie awarii. Zarejestruj się
  • OptexOptex
  • Helpful post
    Level 35  
    Różnego rodzaju protokoły komunikacyjne do tego celu już są. Też kiedyś, tak jak cała masa innych osób wymyśliłem taki protokół (dla CC1101). Co jednak z tego? Nic. Nie jest to nic szczególnego. Jednak tworzenie czegoś w pełni niezależnego od sprzętu nie pozwoli w pełni tegoż sprzęt wykorzystać. Jakiś moduł może mieć np. wake on radio, inny nie. W jakimś będzie ta funkcja działać w inny sposób niż w np. CC1101. Niektóre moduły mają fizyczną adresację, inne nie. Co z modułami które mają tylko samą warstwę fizyczną? Tj. kluczowanie nośnej OOK? Tutaj najpierw należałoby zastosować np. jakąś modulację impulsową (kiedyś użyłem PWM, co dało dosyć dobry efekt), kody korekcyjne itd.

    Trzeba odpowiedzieć na początek na kilka pytań:
    1. Komunikacja ma być punkt-punkt? Może punkt-wielopunkt? Co z kolizjami (unikanie-nasłuchiwanie, jakieś kary)? Stosowany ma być multihop?
    2. Czy trzeba oszczędzać energię? Protokoły komunikacyjne tego rodzaju działają kompletnie inaczej. Coś takiego jest np. w licznikach zużycia gazu.
    3. Jakie to ma mieć ograniczenia? Pamięć RAM i pamięć programu danego mikrokontrolera jest ograniczeniem? Ile węzłów sieci jest przewidzianych? Czy w ogóle mowa o sieci (patrz punkt 1)?
    4. Co z szyfrowaniem transmisji? Jest to potrzebne?
    5. Co z kompresją danych? Kompresja prowadzi do mniejszej liczby i krótszych pakietów wysyłanych.
  • OptexOptex
  • Admin of Design group
    Dzięki za pierwsze przemyślenia i propozycję wymagań.
    Ważna jest wariantowość i uniwersalność.

    To prawda oderwanie się od sprzętu i zaprojektowanie protokołu o "warstwę wyżej" ma jak wszystko swoje wady i zalety.
    Pomysł jest taki aby protokół podobnie jak np. IP działał z różnym sprzętem.
    W przypadku modułów radiowych jest znacznie większe zróżnicowanie możliwości.

    Gdy uda się zaprojektować protokół to podczas implementacji połączy się go z różnymi "sterownikami"

    Zainicjalizowanie protokołu pozwoli wybrać "sterownik" i możliwości. Jeżeli moduł będzie tylko nadajnikiem to będziemy mogli wysyłać komunikaty bez potwierdzenia. Gdy moduł będzie transciverem to będziemy mogli wysyłać i odbierać dane więc możemy lecz nie musimy wybrać komunikację z potwierdzeniem, oczekiwanie na komendy (cały czas lub po nadawaniu) itp.

    Podobnie z szyfrowaniem, jeżeli jest nam potrzebne to można zrealizować jako oprogramowanie lub wykorzystać zasoby modułu.

    W jednym module wyślemy dane po SPI i "packet engine" załatwi sprawę, w module OOK "on wire" sami musimy zakodować np. do manchester i z odpowiednią szybkością zmieniać stany logiczne na pinie.

    To trudne zadanie ale spróbujemy.

    Na początek wymagania.

    Później projekt protokołu.

    Implementacja - stopniowa.

    Połączenie ze sterownikami - stopniowe.

    Testy - wysyłka modułów do zainteresowanych.

    Poprawki - rozbudowywanie wsparcia dla modułów i funkcjonalności.

    Jak dla mnie:
    Ad 1. Komunikacja może być punkt-punkt, punkt-wielopunkt, jedno i dwu kierunkowa, z potwierdzeniem i bez, do wyboru podczas korzystania z protokołu. Kolizje: możliwe nasłuchiwanie / sloty czasowe. Multihop / routing do przemyślenia - nie ograniczać w projekcie protokołu.

    Ad 2. Można oszczędzać lub nie energię (np. nasłuchiwanie ciągłe lub tylko po nadawniu)

    Ad 3. Ograniczenia co do RAM i ilości węzłów do przemyślenia.
    Nastawienie na sieć z bramką (bramkami) ale możliwość też zainicjalizowania jako punkt-punkt albo np. mesh 3-4 urządzeń.

    Ad4. Szyfrowanie gdy potrzebne - włączone. Temat do dyskusji dystrybucja/przechowywanie klucza/kluczy.

    Ad5. Kompresja do przemyślenia (często ramki będą dość krótkie) a kompresja wymaga często narzutu większego niż szyfrowanie. Projekt protokołu nie powinien wykluczać, czy będzie implementowane to się zobaczy. Np. pole data może być danymi zaszyfrowanymi, raw, lub skompresowanymi.
  • Helpful post
    Level 35  
    And! wrote:
    ...w module OOK "on wire" sami musimy zakodować np. do manchester i z odpowiednią szybkością zmieniać stany logiczne na pinie....

    Lepiej PWM. Wiele lat temu w trakcie studiów zrobiłem to tak:
    Zbieramy wymagania do protokołu komunikacji bezprzewodowej elektroda.pl
    Generalnie szczelina bitowa miała jakiś tam czas trwania. Impuls przez całą szczelinę bitową to synchronizacja. 1/3 szczeliny bitowej stanowi 0, 2/3 to zaś 1.
    Coś takiego działa na zasadzie pomiaru czasu, momenty początku i końca danej szczeliny wyznacza odbiornik. Nie ma tu reakcji na zbocza. Odbiornik wykorzystywał tylko początkowe zbocze i mierzył czas trwania poziomu 1 w trakcie pierwszej szczeliny. W przypadku jakichś zakłóceń i wielokrotnych przeskoków 1/0 i 0/1 nie dojdzie do błędu, jeśli czasy nie zostaną nadto zaburzone. Wg takiej idei działały np. układy RX2/TX2 od popularnych w latach 90-tych chińskich zabawek.

    Proponuję przyjąć ograniczenia, bo inaczej nigdy się tego nie zrobi. Może na początek wybrać tylko kilka transciverów i odpowiedzieć sobie na moje wcześniejsze pytania. Generalnie jak coś jest do wszystkiego, to jest do niczego.
  • Helpful post
    Level 40  
    Bardzo ambitny temat i jednocześnie trudny do zunifikowania. Jak już wspomniano - zbyt wiele różnych wymagań. Może zamiast skonsolidowanego projektu zrobić z tego zestaw różnych bibliotek, współpracujących ze sobą w miarę możliwości.

    Dodano po 18 [minuty]:

    Kiedyś robiłem projekt w podobnym temacie i wrzucam tutaj notatki z tego projektu - może się przydadzą. Z złożenia miała być to sieć typu mesh, z niskim poborem energii i z raczej niską przepustowością oparta o nrf24L01:
    Quote:
    - sensor włącza się co określony czas (np co 0.99s) i 1-nasłuchuje lub 2-nadaje, po czym czeka jakiś czas na instrukcje/odpowiedź. Przy nasłuchu (1) czeka na inną transmisję i się synchronizuje czasowo.
    - sensor odpowiada na indywidualne zapytania, grupowe oraz "do wszystkich".
    - przy pierwszym uruchomieniu jest aktywny i czeka określony czas aż uda mu się zsynchronizować z innymi sensorami
    - sensor można zdalnie wyłączyć
    - sensor posiada mapę routingu z alternatywnymi połaczeniami na wypadek awarii jakiegoś sensora pośredniczącego
    - sensor może pracować w trybie normalnym i oszczędnym. W tym drugim trybie nie wybudza się co 1s i nie pośredniczy w transmisji tylko i wyłacznie wybudza się gdy sam musi coś nadać bądź co określony czas znacznie rzadziej niż normalnie (tryb 2).
    - sensor ma własne id, transmisje mają własne ID
    - sensor nie przekazuje informacji z ID zgodnym z zapisem nadanych już transmisji chyba że jest w specjalnym trybie
    - komunikacja zawiera adres docelowy, adres następnego węzła oraz TTL.
    - określanie optymalnej ścieżki na podstawie TTL
    - dodawanie swojego adresu do transmisji + zwiększenie wskaźnika adresu w trybie "routing"
    - protokół z zadaną ścieżką transmisji/powrotu
    - protokoły programujące moduł np protokół zadający modułowi sprawdzanie param. co np. 10 minut i wysłanie wyniku
  • Helpful post
    Level 21  
    Witam,

    Myślę, że zacznę podpowiadać z tej drugiej strony, ze strony klienta :)
    Spoiler:
    Pisane w oparciu o system automatyki domowej - wizja wszystko bezprzewodowo


    ,,wymagania do protokołu komunikacji bezprzewodowej"

    Na pewno uniwersalność, czujnik ruchu nie równa się z czujnikiem dymu, ale komunikacja nie powinna być ani gorsza ani lepsza - oba powinny reprezentować ten sam poziom, jakość.
    I dlatego zastanawiam się czy to jest tylko podłoże software-owe czy też będzie to podchodzić pod hardware.

    Adresacja urządzeń będzie istotną sprawą i oznaczenie ,,matki".
    Czy matka będzie miała adres 0000 zawsze, a reszta od 0001 - do 9999?
    To jest myśl do rozwinięcia, chodzi o łatwość dodawania kolejnych elementów do systemu za pomocą protokołu.
    Przykłady zastosowań: jak dla większego projektu to nie radze robić ograniczeń. Jest wiele modułów które rozbudowują system..., i demontują ilość papieru wartościowego w portfelu...
    Spoiler:

    https://shop.loxone.com/plpl/ai-extension.html
    https://shop.loxone.com/plpl/ao-extension.html
    Nie mam zamiaru zniesławić marki Loxone, pokazuję tylko problem jaki klienci muszą do dobrej automatyki przekonać się 'finansowo'


    Możliwość dodania czujnika bez rozbudowania serca automatyki to dobry cel, warto pomyśleć nad tym, by zaproponowane rozwiązanie protokołu z hardware mogło obsłużyć do 100 urządzeń lub więcej ( w myśl aby przy komunikacji 60 urządzeń naraz nie spadła prędkość transmisji - 'zbytnio' :) )

    Rozwiązaniem może być stworzenie portów (węzłów) które odbierają tylko określony typ urządzenia (czujnika), czyli w ramce z adresem trzeba by też określić typ slave-a . A porty przekazują dane do matki.
    To wszystko jednak zależy od tego na ile wydajny będzie ten protokół.

    Co do szyfrowania to myślę, że dobrym pomysłem może być stosowanie własnych 'soli' jak w przypadku baz danych na serwerze

    Takim jeszcze pierwszym spojrzeniem na temat można popracować nad weryfikacją danych - czy są niezakłamane (za pomocą sumy kontrolnej?) Załóżmy że mamy jakiś przekaźnik który odbiera dane z domu i (podbijając ich moc) przekazuje do czujników na zewnątrz. Przekaźnik ten mógłby sprawdzać poprawność danych ,,przy okazji"
  • Helpful post
    Level 35  
    And! wrote:
    ...

    Jak dla mnie:
    Ad 1. Komunikacja może być punkt-punkt, punkt-wielopunkt, jedno i dwu kierunkowa, z potwierdzeniem i bez, do wyboru podczas korzystania z protokołu. Kolizje: możliwe nasłuchiwanie / sloty czasowe. Multihop / routing do przemyślenia - nie ograniczać w projekcie protokołu.

    Ad 2. Można oszczędzać lub nie energię (np. nasłuchiwanie ciągłe lub tylko po nadawniu)

    Ad 3. Ograniczenia co do RAM i ilości węzłów do przemyślenia.
    Nastawienie na sieć z bramką (bramkami) ale możliwość też zainicjalizowania jako punkt-punkt albo np. mesh 3-4 urządzeń.

    Ad4. Szyfrowanie gdy potrzebne - włączone. Temat do dyskusji dystrybucja/przechowywanie klucza/kluczy.

    Ad5. Kompresja do przemyślenia (często ramki będą dość krótkie) a kompresja wymaga często narzutu większego niż szyfrowanie. Projekt protokołu nie powinien wykluczać, czy będzie implementowane to się zobaczy. Np. pole data może być danymi zaszyfrowanymi, raw, lub skompresowanymi.

    Problem braku ograniczeń. Nasłuch to zależnie od ustawień pobór prądu nawet kilkanaście mA (zależnie od transcieviera). Tu powinno być wake on radio (WOR).

    Kiedyś robiłem coś podobnego jak kolega excray, tylko na CC1101. Chodziło o zbieranie danych z czujników zasilanych bateryjnie. Założenie było takie, że bateria ma starczyć na kilka lat. Przepływność bitowa była niska, odczyt najwyżej kilka razy na dobę. Poszczególne czujniki miały WOR. Załączały odbiór co kilka minut na bardzo krótki czas. W razie potrzeby odczytu stacja bazowa wysyłała stosowną serię pakietów, tak by każdy węzeł mógł trafić na odpowiedni poziom sygnału i wyłapać słowo synchronizacji. Potem była odpowiedź. Każdy węzeł czekał po otrzymaniu pakietu polecenia odczytu (były też polecenia zmiany jakiegoś parametru) w uśpieniu na swoją kolej. Czas do wysłania pakietu był obliczany przez węzeł jako jego ID*jakiś interwał. Były też uwzględniane błędy i możliwości retransmisji. Przy właściwym doborze czasów dało się uniknąć kolizji. Nie było też multihop. W takim protokole uwzględniłem też jeszcze wiele innych okoliczności z odpowiednim usypianiem mikrokontrolera, transceivera, zmianą częstotliwości taktowania mikrokontrolera itd. Był to protokół bardzo dobrze dostosowany do swojego zastosowania. Odczyt zajmował nawet 10 minut, ale nie miało to większego znaczenia.
  • Helpful post
    Level 43  
    maciej_333 wrote:
    Co z modułami które mają tylko samą warstwę fizyczną? Tj. kluczowanie nośnej OOK?

    To nie jest to samo, tzn. nie jest to tożsame.
    Coś nie rozumiesz tą warstwę fizyczną. Można mieć np. kodowanie QAM16, a ciągle nie mieć adresowania. To zupełnie różne rzeczy, nie mające ze sobą związku.
    Nie ma żadnego problemu z używaniem modułów z wyłącznie warstwa fizyczną.
    W sumie mi się takie używało najwygodniej.
    Zapewniało to też kompatybilność pomiędzy różnymi modułami.
    A jak to zrobić? Użyć UARTRa.

    Jak dla mnie to wymagania powinny być takie:
    - Długie adresowanie, co najmniej 32-bitowe.
    - Adresowanie nadawcy. Też 32-bitowe.
    Przy czym oba adresy może powinno być opcjonalne, i zaznaczane np. 1 bitem w adresie. Czyli np. 8 bitów "statusu", a za nimi 24 + 32 bitów opcjonalnych adresów (jak "status" wskazuje że adresy są przesyłane, jak nie wskazuje to ramka jest krótsza, no i siłą rzeczy taka ramka jest typu rozgłoszeniowego).
    - CRC co najmniej 32-bitowe.
    - Praca z potwierdzeniami i bez potwierdzania (wybierane przy nadawaniu).
    - Szyfrowanie transmisji, z wyborem czy adresy też są szyfrowane czy nie (też 1 bit ze "statusu").
    - Użycie tylko warstwy fizycznej modułów, w celu zapewnienia kompatybilności tego samego protokołu z różnymi modułami. To wymaga używania np. UARTa.
    Ten punkt pewnie się spotka z oporem, ale to jest mus gdy to ma być kompatybilne z duża ilością całkiem różnych modułów. Na pewno moduły mają różne tryby adresowania oraz różne wymagane preambuły, więc nie da się zrobić uniwersalnego protokołu bez zaangażowania uC do dekodowania ramek.
    Szkoda, bo wtedy nie da się zrobić WoR (Wake on Radio), no ale to jest wynik założeń uniwersalności.
  • Level 35  
    atom1477 wrote:
    maciej_333 wrote:
    Co z modułami które mają tylko samą warstwę fizyczną? Tj. kluczowanie nośnej OOK?

    To nie jest to samo, tzn. nie jest to tożsame.
    Coś nie rozumiesz tą warstwę fizyczną. Można mieć np. kodowanie QAM16, a ciągle nie mieć adresowania. To zupełnie różne rzeczy, nie mające ze sobą związku.

    Warstwa fizyczna/logiczna jest umowna. Może być tak, że moduł ma tylko sprzętowe np. FSK lub OOK. Zatem sporo musi być realizowane programowo (np. jakaś modulacja impulsowa). Innym razem transceiver może otrzymywać tylko dane do wysłania (np. poprzez SPI). Trudno postawić "kreskę" między warstwami w tym samym miejscu dla obu przypadków.
    QAM to rodzaj modulacji, nie kodowanie. Kodowanie może być np. kanałowe, są też kody korekcyjne, kody liniowe (dla torów kablowych) itd. Zresztą cyfrowych modulacji jest cała masa. Niektóre są naprawdę egzotyczne. Tu wystarczy FSK lub bardziej kompromisowo GFSK.

    atom1477 wrote:
    Nie ma żadnego problemu z używaniem modułów z wyłącznie warstwa fizyczną.
    W sumie mi się takie używało najwygodniej.
    Zapewniało to też kompatybilność pomiędzy różnymi modułami.
    A jak to zrobić? Użyć UARTRa.

    Trudno będzie uzyskać akceptowalną pakietową stopę błędów (PER). Próbowałem, to zrobić. Więcej zachodu, jak pożytku. Kiedy pobawiłem się CC1101 zobaczyłem jakie zyskuje się możliwości.

    atom1477 wrote:
    Jak dla mnie to wymagania powinny być takie:
    - Długie adresowanie, co najmniej 32-bitowe.
    - Adresowanie nadawcy. Też 32-bitowe.
    Przy czym oba adresy może powinno być opcjonalne, i zaznaczane np. 1 bitem w adresie. Czyli np. 8 bitów "statusu", a za nimi 24 + 32 bitów opcjonalnych adresów (jak "status" wskazuje że adresy są przesyłane, jak nie wskazuje to ramka jest krótsza, no i siłą rzeczy taka ramka jest typu rozgłoszeniowego).
    - CRC co najmniej 32-bitowe.
    - Praca z potwierdzeniami i bez potwierdzania (wybierane przy nadawaniu).
    - Szyfrowanie transmisji, z wyborem czy adresy też są szyfrowane czy nie (też 1 bit ze "statusu").
    - Użycie tylko warstwy fizycznej modułów, w celu zapewnienia kompatybilności tego samego protokołu z różnymi modułami. To wymaga używania np. UARTa.
    Ten punkt pewnie się spotka z oporem, ale to jest mus gdy to ma być kompatybilne z duża ilością całkiem różnych modułów. Na pewno moduły mają różne tryby adresowania oraz różne wymagane preambuły, więc nie da się zrobić uniwersalnego protokołu bez zaangażowania uC do dekodowania ramek.
    Szkoda, bo wtedy nie da się zrobić WoR (Wake on Radio), no ale to jest wynik założeń uniwersalności.

    Generalnie taka pula adresów chyba ma być globalna. Zdecydowanie wystarczą dwa bajty. Po co tyle? Różne moduły mogą ze sobą współpracować. CC1101 jest tak elastyczny, że chyba można go dopasować do prawie wszystkiego. Inna sprawa to jak wiele jest zachodu z konfiguracją tego układu. Nawet po uzyskaniu wstępnej konfiguracji ze SmartRF Studio trzeba dosyć dokładnie znać ustawienia poszczególnych rejestrów, by zrobić dokładnie to, co trzeba.
  • Level 43  
    maciej_333 wrote:
    Warstwa fizyczna/logiczna jest umowna. Może być tak, że moduł ma tylko sprzętowe np. FSK lub OOK. Zatem sporo musi być realizowane programowo (np. jakaś modulacja impulsowa)

    Myślałem że dla Ciebie warstwa fizyczna to OOK. A FSK to już coś więcej. Dlatego się przyczepiłem.

    maciej_333 wrote:
    atom1477 wrote:
    A jak to zrobić? Użyć UARTRa.

    Trudno będzie uzyskać akceptowalną pakietową stopę błędów (PER). Próbowałem, to zrobić. Więcej zachodu, jak pożytku. Kiedy pobawiłem się CC1101 zobaczyłem jakie zyskuje się możliwości.

    Dziwne, bo ja właśnie na UARCie uzyskiwałem najlepsze osiągi.
    No i tu mowa o modułach RFM12 czy TX05. Na nich się nie da zrobić tego co jest w CC1101. Nie będzie kompatybilności jak się użyje specyficznych sposobów "kodowania danych" z CC1101.

    maciej_333 wrote:
    Generalnie taka pula adresów chyba ma być globalna. Zdecydowanie wystarczą dwa bajty. Po co tyle? Różne moduły mogą ze sobą współpracować. CC1101 jest tak elastyczny, że chyba można go dopasować do prawie wszystkiego. Inna sprawa to jak wiele jest zachodu z konfiguracją tego układu. Nawet po uzyskaniu wstępnej konfiguracji ze SmartRF Studio trzeba dosyć dokładnie znać ustawienia poszczególnych rejestrów, by zrobić dokładnie to, co trzeba.

    Dopasowanie CC1101 do "prawie wszystkiego" oznacza po prostu niekorzystanie z jego specyficznych funkcji.
    A po co tyle adresów? No właśnie jest przydatne, do robienia urządzeń wirtualnych (gdy jedno urządzenie udaje wiele urządzeń).
  • Admin of Design group
    @maciej_333 może być PWM może być manchester to już kwestia implementacji, na etapie projektowania protokołu jesteśmy poziom wyżej i zwracamy uwagę aby nie blokować różnych możliwości implementacji i funkcjonalności.

    Możemy określić sobie modele transceiverów i to może się przydać, jednak jest wiele innych możliwych propozycji wymagań,
    podobnie w drugim etapie tworząc protokół modele transceiverów trzeba mieć w pamięci jednak myśleć na poziomie +1 czyli ogólnego protokołu, który później będziemy implementować.

    Gdy na samym końcu protokół zostanie zaimplementowany i połączony ze "sterownikami" do modułów radiowych to wyobrażam to sobie tak jak np. w projekcie do obsługi wyświetlaczy LCD/TFT/OLED z magistralami I2C oraz SPI https://github.com/olikraus/u8g2
    gdzie tworzymy obiekt danej klasy uruchamiając komunikację po SPI z LCD na ST7920
    U8G2_ST7920_128X64_1_SW_SPI u8g2(U8G2_R0, /* clock=*/ 13, /* data=*/ 11, /* CS=*/ 10, /* reset=*/ 8);

    albo z OLED na SSD1306 po I2C
    U8G2_SSD1306_128X32_UNIVISION_F_SW_I2C u8g2(U8G2_R0, /* clock=*/ 1, /* data=*/ 2, /* reset=*/ 3);

    WOR na pewno jest do dalszej dyskusji.

    @excray wiem że jest to trudny to realizacji pomysł... można podejść tak aby zaprojektować jak najbardziej elastyczny protokół i później zobaczyć co uda się zaimplementować.
    Ważne aby nie zablokować możliwości na niższej warstwie, założeniami z warstwy wyżej.

    Dzięki za notatki, niebawem zacznę przekładać Wasze pomysły do pierwszego postu.

    @RebellionArts to na razie nawet nie jest podłoże sotwarowe,
    drugi etap to będzie dopiero projekt protokołu na podstawie zbieranych teraz wymagań.
    Finalnie to będzie podłoże programowe, które ma ułatwić używanie sprzętu, a także łatwą wymianę modułu z zachowaniem części napisanego już kodu.

    Gdy uda się projekt, na koniec w etapie bonusowym możemy zrobić kilka PCB prototypów różnych klas urządzeń wykorzystujących protokół i rozesłać PCB do zainteresowanych. Projekt stawia na warstwę programową i uniwersalny protokół to jest produkt projektu.

    @atom1477 zgadza się warstwa sprzętowa, rodzaje modułów i ich interfejsy, modulacje to sprawa sterownika modułu, jest to warstwa i etap niżej niż projekt protokołu.

    Czy adresowanie powinno być 32b ? to sprawa do ustalenia ile urządzeń będzie w zasięgu jednej / kilku bramek / systemu. Można też pomyśleć o połączonych po IP kilku systemach/bramkach i np. chcemy mieć unikalne adresy urządzeń. Adresy mogą być też np. 16b lub mniej bitowe i "natowane" przy tunelowaniu protokołu. Być może pole adresu może mieć różną długość.

    Dziękuję za uwagi wynikające z przeprowadzonych już eksperymentów, w ramach projektu możemy to wykorzystać i wykonać kolejne próby praktyczne.
  • Helpful post
    Level 43  
    Mimo wszystko można sobie wybierać sposób komunikacji czy "kodowania" danych, nawet jak moduły mają jakieś swoje protokoły.
    Większość modułów, a na pewno RFM12 i CC2500 (CC1101 pewnie też) mają opcję pracy "przezroczystej". Czyli jako "przedłużacz drutu".
    A w takim wypadku można zastosować dowolny własny sposób "kodowania" danych.
    Ja używam UARTa, bo to najwygodniejsze.
    Ale oczywiście inny sposób był by lepszy. Problem tylko że innych nie ma wbudowanych z mikrokonkrolery. Więc trzeba by je implementować programowo, i to do działania ciągłego. A to oznacza konieczność utrzymywania uC w stanie pracy przez cały czas. Przy UARTcie przynajmniej odpada konieczność odbierania pakietów po 10b (najkrótsza ramka UARTa: 8N1). Ciągle trzeba by wybudzać procesor przy każdym znaku, ale zawsze to już jakaś oszczędność wobec pracy ciągłej.
    Użycie PWMa czy manchestera oznacza że uC musiał by działać non stop.

    Więc trzeba zdecydować czy idziemy w dobry mechanizm komunikacji (piszę mechanizm, bo nazwy kodowanie, interfejs, protokół łatwo użyć w niepoprawnym znaczeniu), ale wymagający ciągłej obsługi przez uC.
    Czy idziemy w gorszy, np. UARTa, ale dający jakieś oszczędności prądu i mocy obliczeniowej procesora.
    I te dwie opcje mają zaletę że zadziałają na każdym module.
    Czy też idziemy w opcję trzecią, czyli używamy gotowego trybu pracy modułu np. CC2500. Gdzie są kody nadmiarowe, automatyczne adresowanie, automatyczne liczenie CRC, WOR, itp.
    To da dobre parametry toru oraz mały pobór prądu, ale nie da kompatybilności pomiędzy modułami (ani nawet możliwości pracy na dwóch takich samych modułach innych niż CC2500).
    No i opcja czwarta, czyli konfigurowanie trybów pracy. Gdzie się da wybrać jaki ma być interfejs/protokół. Ale to znowu ma wadę że wyjdzie z tego wielki projekt. Długi w doprowadzeniu do końca, i trudny w utrzymywaniu. I trudny w użytkowaniu w sumie też.
  • Helpful post
    Level 17  
    Jak to zwykle na początku projektu bywa, warto wejść w tryb brainstormingu ;) Wymagania co do samego protokołu:
    - koncentracja na tanich, prostych, chińskich modułach (zaawansowane moduły mają już własne protokoły lub wsparcie w postaci bibliotek i społeczności, brnięcie w protokół na mocnym module nie skończy się dobrze)
    - protokół zorientowany na istniejące HW (zawężenie zestawu modułów RF, które mają mało zaimplementowane, przedyskutowanie ich słabych i mocnych stron)
    - obsługa różnych topologii (połączenie jeden to jeden, wiele do jednego,..),
    - wyodrębnione role urządzeń (nadajnik, odbiornik, transceiver, stacja bazowa, repeater,..)
    - co najmniej dwa kanały logiczne
    * Data Channel - głównie dla użytkownika końcowego, przesył danych lub danych kontrolnych z najwyższej warstwy, kontrola integralności danych, update oprogramowania (?)
    * Control Channel - kontrola jakości połączenia, stanu każdego z elementów sieci, attach/detach, parametry pracy modułu RF, sterowanie modułem
    - konfigurowalna długość ramki w zależności od HW i potrzeb w zastosowanym projekcie (niewykorzystanie funkcji protokołu powinno wpływać na uproszczenie ramki)
    - określenie minimalnego wymagania co do MCU (nie ma sensu zakładać, że pójdzie na byle czym, ceny wydajnych mikrokontrolerów to pojedyncze złotówki)
  • Admin of Design group
    Od strony wykorzystania widzę to tak:
    wykorzystanie protokołu->protokół->sterownik->kodowanie->moduł->modulacja->transmisja radiowa

    @atom1477 w sterowniku zawarty jest interfejs do modułu to może być SPI lub UART a także linie cyfrowe które np. informują o odebraniu pakietu.
    Ten interfejs to może być też pojedyncza linia cyfrowa do modułu OOK "on wire" wtedy mikrokontroler niestety jest silnie obciążony, ale to tylko jedna z opcji jaką może wybrać użytkownik protokołu, może wybrać przecież moduł z SPI. Wybór ma swoje konsekwencje, wybór modułu nadajnika (nie transceivera) pozwoli tylko na jednokierunkową transmisję. Wsparcie dla modułów można rozbudowywać w projekcie stopniowo.

    Wybór zestawu modułów "na start" do dobry pomysł i do tych modułów mogą zostać na początek zaimplementowane sterowniki a później z ich wykorzystaniem będą prowadzone testy.

    @acctr brainstorming jest OK, dziękuję za bardzo przemyślany zestaw wymagań.

    "koncentracja na tanich, prostych, chińskich modułach" - jestem za, np. RFM się w to sensownie wpisuje.
    + protokół zorientowany na istniejące HW

    Niebawem przełożę Wasze pomysły do pierwszego postu.
  • Level 43  
    And! wrote:
    @atom1477 w sterowniku zawarty jest interfejs do modułu to może być SPI lub UART a także linie cyfrowe które np. informują o odebraniu pakietu
    Ten interfejs to może być też pojedyncza linia cyfrowa do modułu OOK "on wire" wtedy mikrokontroler niestety jest silnie obciążony, ale to tylko jedna z opcji jaką może wybrać użytkownik protokołu, może wybrać przecież moduł z SPI.

    W sumie to nie.
    Przy użyciu trybu "Wire" zwykle ciągle będzie używane SPI. Tylko że to SPI będzie tylko do konfigurowania i zmieniania trybów pracy, a komunikacja będzie szła osobnym pinem czy pinami (UARTem, RXD i TXD).
    Tak jest przynajmniej dla modułów RFM12B i CC2500.
    Można sobie użyć UARTa do komunikacji, ale SPI ciągle jest używane do konfiguracji po włączeniu zasilania, do zmieniania kierunku transmisji i np. do odczytywania RSSI.

    And! wrote:
    Wsparcie dla modułów można rozbudowywać w projekcie stopniowo.

    No inaczej się nawet nie da :D

    Moje pomysły na budowę ramki w załącznikach.
    CRC jest zawsze 32-bitowe, bo bez tego będzie sporo problemów z działaniem.
    Długości ramek ograniczyłem do 32 B, bo dla dłuższych szybko wzrasta stopa błędów.
    Do wyboru są adresu 8 B i 32 B. 16 B już nie robiłem. Za dużo kombinacji.
    Format zakłada że można używać różnych długości ramek i adresów na raz. Nie trzeba tego wybierać przy konfigurowaniu protokołu. Po prostu on zawsze zaakceptuje każdy format ramki (o ile będzie miał ustawione że ma odbierać określone ramki, z określonych adresów).
    Gdzieś tam trzeba przesyłać czy dane ramki mają być potwierdzanie czy nie.
    Albo ustawiać to w konfiguracji urządzeń (miała by przypisane jakie komunikaty ma potwierdzać a jakie nie). Przy czym ta opcja ma wadę że urządzenie nadawcze nie mogło by wtedy wymusić potwierdzenia. Więc przesyłanie tej informacji w ramce ma większy sens.
  • Moderator of Cars
    Protokół można wymyślać, ale jeśli ma to być lekki protokół, to raczej wyklucza jego warstwową budowę, zatem nie uda się uniknąć powiązania ze sprzętem i trzeba się będzie zdecydować jaki sprzęt wspieramy, a jaki odrzucamy. Tak czy inaczej, podchodzę sceptycznie (pesymistycznie), bo już trochę takich protokołów jest. Niektóre są bardzo uniwersalne. Jeśli miałby się przyjąć, należałoby znaleźć jakąś niszę. Z XBee (Zigbee, IEEE 802.15.4, DigiMesh, BLE) nie mamy nawet co próbować konkurować, ale np. protokół dla ATTiny85 z "gołym" modułem radiowym, mógłby zyskać jakąś popularność. To ma być protokół do systemów sterowania, akwizycji danych? Ma to być protokół do sieci sensorowej (mesh z retransmisją przez węzły), sieci server-host, czy peer to peer? Możemy konkurować ceną, czyli tanią i prostą platformą, do zastosowań amatorskich/DIY. Tak popularność zyskało Arduino. Mimo niewątpliwych zalet STM32 przebija się na tym rynku z trudem. To pokazuje, że na rynku DIY więcej opcji/możliwości wcale nie oznacza lepiej.

    Kiedyś natknąłem się na problem implementacji istniejących protokołów (może to za dużo powiedziane) do systemów zdalnego sterowania automatyką domową (np. bramy garażowe). Może warto byłoby pójść w tę stronę (otwarte biblioteki wspierające istniejące protokoły), zamiast wymyślać nowy protokół? Choć pewnie mogłoby to rodzić pewne problemy natury prawnej.
  • Admin of Design group
    @atom1477 z punkt widzenia protokołu to czy moduł komunikuje się po SPI czy UART czy robimy "bitbanging" na modułach OOK typu 1->nośna 0->brak nośnej. To załatwia sterownik. Niedawno na głównej był mini test modułu który zarówno konfiguruje się po UART jak i przekazuje dane po UART modem UART LoRa chociaż to właśnie bardziej kompletny modem niż prosty moduł RF.

    Dzięki za kolejne pomysły, "CRC" 32b wydaje się mocne, można pomyśleć o kodach korekcyjnych.
    Długość ramek 32B wydaje się sensowna, chociaż wolałbym nie ograniczać i dać zmienną długość nawet do 512B + ew. mocniejsze zabezpieczenie spójności, do sprawdzenia. Ważne aby się nie ograniczać już na wstępie. Długość pola data można określić jednym bajtem wtedy wyjdzie nam 255B max w ramce.
    Przyda się też pole wersja protokołu - do wykorzystania na przyszłość.

    Z adresacji 8-32b najbardziej atrakcyjna wydaje mi się 16b chociaż 8b też może mieć zastosowanie.

    Ruszyliśmy już ramki to będzie kolejny etap, czyli projektowanie protokołu, na razie zbieramy dalej funkcjonalności.

    @tzok chcę pozostać przy warstwowości i uniwersalności mimo że będzie narzut. Oczywiście można zrobić rozwiązanie szyte na miarę gdzie wykorzystany jest każdy bit, jednak to będzie bardzo optymalne i bardzo specjalizowane niestety. Co ciekawe projekty typu " protokół dla ATTiny85 z "gołym" modułem radiowym" to moje ulubione gdzie można wycisnąć maksimum ze sprzętu i "odstawić konkurencję". Jednak w tym projekcie promuję podejście etapowe i uniwersalne. Wiem że to jest trudne, gdyż już na etapie zbierania funkcjonalności "ciężko wytrzymać" i już się myśli o strukturze ramki, wiem bo sam tak mam :)
  • Level 43  
    And! wrote:
    @atom1477 z punkt widzenia protokołu to czy moduł komunikuje się po SPI czy UART czy robimy "bitbanging" na modułach OOK typu 1->nośna 0->brak nośnej. To załatwia sterownik. Niedawno na głównej był mini test modułu który zarówno konfiguruje się po UART jak i przekazuje dane po UART modem UART LoRa chociaż to właśnie bardziej kompletny modem niż prosty moduł RF.

    Chyba nie zrozumiałeś o czym napisałem.
    UART nie jest zamienny z SPI. To nie chodzi o to że UARTem się wysyła dane, a moduł je potem wysyła dalej po swojemu. Mi chodzi o przypadek gdy moduł nie ma własnych trybów pracy, i nie konwertuje dostarczanych mu danych. Więc dane lecą UARTem wprost.
    Inaczej niż w module LoRa jaki podałeś.
    Jednak w tym co opisuję, mimo użycia UARTa wprost do transmisji, moduły ciągle mogą wymagać konfigurowania. I do tego najczęściej jest SPI.
    To że moduł wysyła transmisją OOK, nie znaczy że nie ma opcji konfigurowania.

    And! wrote:
    Długość ramek 32B wydaje się sensowna, chociaż wolałbym nie ograniczać i dać zmienną długość nawet do 512B + ew. mocniejsze zabezpieczenie spójności, do sprawdzenia. Ważne aby się nie ograniczać już na wstępie.

    No to jesteś w błędzie. Długie ramki to proszenie się o kłopoty. Długa transmisja na długo blokująca procesor, i duże prawdopodobieństwo błędu.
    Nawet te 32B to już sporo jak na proste moduły radiowe i prostą transmisję.
    Choć można oczywiście przewidzieć taką opcję w konfiguracji. Tyle że sądzę ona raczej się okaże że będzie martwa.
    Można przewidzieć wiele pól do konfiguracji, ale wtedy się okaże że ramki są długie już z samego powodu posiadania dużej ilości pół konfiguracyjnych.
    Dlatego w mojej wersji ograniczyłem się do jednego bajtu, a długość adresowania zrobiłem kodowana w samym adresie. Dzięki temu dla krótkich adresów nie ma długiego słowa kodującego długość. Długość słowa kodującego rozrasta się wraz z długością adresu.
    Podobnie można zrobić z innymi konfigurowanymi rzeczami.
    Np. długość ramki kodować słowem konfiguracyjnym, ale obecnym tylko dla jakiegoś jednego rodzaju ramki. Czyli przykładowo będzie 15 rodzajów ramek z którejś mojej wersji ramki, a 16 rodzaj to będzie dodatkowe słowo konfiguracyjne kodujące długość i jeszcze inne parametry. W słowie kodującym nie kodował bym długości co do bajtu, lecz zrobił kilkanaście kroków. Wtedy zostanie miejsce na kodowanie innych rzeczy.
  • Helpful post
    Moderator of Cars
    Może się nie znam, ale nie bardzo rozumiem o protokole której warstwy rozmawiamy. Padają tu określenia sterownik, UART... może jednak chodzi o stos protokołów?

    Co nasz protokół ma zapewniać? Czy ma obejmować warstwę fizyczną (sterownik)? Jeśli tak to odpadają wszystkie moduły, które mają już wbudowaną tę warstwę, a dane do wysłania/odbioru idą przez UART. Takie moduły już same się troszczą o modulację, kodowanie sygnału etc. Czy mamy się troszczyć o dostęp do medium (MAC) i wymyślać jakieś zastępstwo dla CSMA/CA? Część modułów załatwia również adresację fizyczną.

    And! wrote:
    chcę pozostać przy warstwowości i uniwersalności mimo że będzie narzut.

    Więc chyba trzeba by zacząć od określenia ile ma być warstw i jak "nisko" chcemy zejść. Następnie rozdzielić zadania pomiędzy zespoły zajmujące się protokołami poszczególnych warstw. Skoro będą warstwy, to muszą działać niezależnie, nie ma więc powodu, aby pracowań nad nimi w jednym zespole. Trzeba tylko opracować specyfikę formatu danych (datagramu) na styku poszczególnych warstw.
  • Helpful post
    Level 43  
    tzok wrote:
    Więc chyba trzeba by zacząć od określenia ile ma być warstw i jak "nisko" chcemy zejść.

    Jak nisko to wiadomo. Do samego dołu. Aż do warstwy fizycznej czyli modułów.
    Pytanie raczej jak wysoko. Na ile wysokopoziomowe to ma być od strony użytkownika.
  • Helpful post
    Level 35  
    Zarówno ja, jak i kolega tzok mówimy o przyjęciu wstępnych ograniczeń. W temacie jednak ustalono, że nie ma się czym przejmować, ani ograniczać. Podejście jest zatem w stylu typowej polskiej uczelni. Należy zatem opracować protokół komunikacyjny, potem zaś "zobaczyć co uda się zaimplementować". Jest to błąd już u samych założeń.

    Ponadto jest tu wątek stosowania jak najtańszych modułów, zamiast porządnych transceiverów jak CC1101 (i inne układy TI). Ciekawy wydaje się też np. być S2-LP z ST. Ma gotowe np. CSMA/CA. Dostępna jest też cała masa mikrokontrolerów z transceiverami na pasma ISM.
    Podobno nawet z takimi tanimi modułami "można zostawić konkurencję daleko w tyle". Pod względem kosztów i produkcji wielkoseryjnej może tak, ale PER będzie gorsze i nie tylko to. W odpowiednich warunkach tani moduł nie zapewni żadnej komunikacji.

    Przepraszam za pewne złośliwości, ale niestety inaczej nie da się tego napisać. Odpowiedzmy sobie na pytanie dlaczego trzeba wprowadzić ograniczenia? Zwróćmy uwagę, że tak naprawdę każdy producent, który coś robi z ISM ma jakiś własny protokół komunikacyjny. Nawet jeśli producent zdalnie sterowanych gadżetów erotycznych i producent zdalnie sterowanych bram garażowych stosują te same moduły, to mają inne protokoły. Dlaczego? Każdy z nich może stworzyć protokół idealny do swoich potrzeb. Kolejna sprawa, to aspekt, że ktoś w darmową implementację mógł wpisać jakieś "ciekawe" funkcje (np. backdoor). Stąd jeśli przyjąć ograniczenia, jest jakaś szansa zrobić coś, co może się udać. Być może wtedy jakaś grupa amatorów-Arduinowców to wykorzysta. Prawdopodobnie to jest jedyna grupa docelowa. Człowiek z odpowiednią wiedzą zrobi to sam. Może to wynikać z chęci podjęcia wyzwania lub z uznania, że "sam zrobię to lepiej".


    Jeśli cokolwiek ma z tego wyjść, to może tak:
    -Przyjąć tylko kilka transceiverów: CC1101, S2-LP, jakiś biedny jak RFM12B (nawet dokumentacja jest wyraźnie gorsza od poprzednio wymienionych).
    -Protokół powinien być głównie dla sieci sensorycznych z multihop (musi być wtedy pole TTL, by nie zalać sieci pakietami, które będą krążyły w nieskończoność). Powiedzmy, że chodzi o liczniki energii elektrycznej (brak konieczności oszczędności energii). Takie coś znajdzie też zastosowanie w IOT, które jest obecnie bardzo popularne z jakiegoś nieznanego powodu. Na czymś takim da się też wykonywać prostsze połączenia (punkt-punkt), bez modyfikacji.
    -Odpuszczenie sobie łączenia różnych transceiverów ze sobą. Jest to ogromne ułatwienie.
    -Pula adresów 16 bitów, CRC sprzętowe, jakie udostępnia transceiver, adresowanie węzłów sprzętowe lub programowe (nie każdy transceiver to ma). Pakiet rozgłoszeniowy z adresem np. 0x0000.
    -Brak węzła wyróżnionego.
    -Maksymalne wykorzystanie sprzętu.
    -CSMA/CA (sprzętowe lub częściowo programowe).
    -Mimo braku konieczności oszczędzania energii nasłuch może być z WOR. Da się zrobić protokół z tym i bez tego (wyłączalne).
    -Brak warstw o dużym poziomie abstrakcji. Generalnie użytkownik może wykorzystywać bardzo różne własne komunikaty, polecenia itp. Zatem tym powinna zająć się warstwa aplikacji.
    -Model warstwowy może być taki:
    3. Warstwa aplikacji - jest to program użytkownika.
    2. Warstwa łącza danych (adresacja, obsługa przerwań, CSMA/CA) - wspólna dla wszystkich transiceiverów, ale
    częściowo modyfikowana za pomocą kompilacji warunkowej, zależnie od typu transceivera.
    1. Warstwa adaptacji do sprzętu (ang. HAL - Hardware Adaptative Layer) - całkowicie inna dla każdego
    transceivera. Jej wariant jest wybierany za pomocą kompilacji warunkowej, zależnie od typu transceivera.
    0. Warstwa fizyczna
    -Jakieś w miarę proste szyfrowanie. Tu jest problem, bo tanie mikrokontrolery tego nie wspierają i trzeba to robić programowo. Można wykorzystać np. DES.
    -Raczej brak kompresji. Jest to bardzo przydatne, ale pominąłbym to dla znacznego uproszczenia. Załóżmy, że nikt nie będzie robił np. bootloadera bezprzewodowego w sieci sensorycznej.
    -Przyjąć np. tylko dwie lub trzy różne przepływności bitowe i co za tym idzie symbolowe. Tylko jedna modulacja.
    -Wybór tylko kilku kanałów w ISM. Jest to uproszczenie i to spore. Należy też zapomnieć o dynamicznej zmianie kanału w trakcie pracy lub wyborze automatycznym kanału o mniejszej zajętości. Szerokość kanału zależy od punktu poprzedniego.


    Do zastosowań amatorskich można zaimplementować coś w rodzaju MODBUS, ale bezprzewodowo. Chodziłoby wówczas o zdalny dostęp do rejestrów. Rejestry te wypełniałaby i odczytywała aplikacja użytkownika. Byłoby to proste w użyciu. Wystarczyłoby w trakcie inicjalizacji podać wskaźnik na tablicę z tymi rejestrami. Jednak uważam to za kiepski pomysł, ponadto widać od razu pewne problemy implementacyjne, jeśli interfejs między aplikacją użytkownika a warstwą trzecią ma być tak prosty.
  • Helpful post
    Level 27  
    Ja bym pozostał przy modułach z wbudowaną logiką transmisji - proste moduły na 433Mhz, irdy itp to trochę inna bajka i przez zbyt szerokie podejście wyjdzie coś do wszystkiego czyli niczego. Jest zbyt wiele platform i np sprzętowe modulacje PWM, uarty i spi działają inaczej. Dodatkowo nie ma tam kanałów gdzie można by uciekać przed kolizjami.
  • Helpful post
    Level 43  
    Tyle że własny protokół ma sens właśnie z prostymi modułami nie posiadającymi logiki transmisji (albo pozwalającymi ją wyłączyć).
    Ograniczenie się do modułów z wbudowaną logiką ogranicza funkcjonalność, bo każdy moduł ma swoją własną indywidualną logikę. I to nie pozwala łączyć różnych modułów.
    Nie uda się więc stworzyć np. sieci domowej z czujnikami od różnych hobbystów. Bo każdy użyje innego modułu.
    Biblioteka może pasować do każdego, bo w bibliotece się wybierze jaki mamy moduł i ona się na niego skompiluje. Ale to za mało aby przesył danych był uniwersalny. Uniwersalność musi być nie tylko w możliwości konfiguracji, ale też w tym żeby mimo używania różnych konfiguracji, te konfiguracje były też ze sobą zgodne w eterze. Czyli różnice w konfiguracji powinny być na poziomie sposobu konfigurowania modułu (jeden na I2C, inny na SPI, inne adresy, inne adresy rejestrów, itp), ale powinny konfigurować to samo (ten sam kanał, tą samą modulację, te same preambuły, to samo kodowanie bitów (kodowanie manchester, kody nadmiarowe, itp)). Ostatnie z wymienionych rzeczy są różne pomiędzy modułami i może się nie dać skonfigurować tak samo używając hardware modułów. Da się dopiero gdy to wszytko będzie w software w uC (ale oczywiście kosztem pewnych uproszczeń i kosztem mocy obliczeniowej uC).

    Przykładowo bez korzystania z wbudowanej logiki, komunikowałem ze sobą moduły CC2500, RFM12B , RFM01/02, RFM119, RFM217, RFM219 oraz jakiś bez oznaczeń (taki bez konfiguracji, tylko z wejściem DATA).
    Oczywiście było CRC, mała ilość traconych ramek, i całkiem spore zasięgi. Mało brakowało do kodów nadmiarowych.
    Szyfrowanie to już tylko algorytm. Więc naprawdę mało brakuje mimo robienia wszystkiego na własną rękę.
    Zresztą taki chyba miał być cel bo ja w zdjęciu tytułowym tematu widzę tylko proste moduły :D I to do nich potrzeba jakiegoś protokołu. Te skompilowane z wbudowaną logiką już w sumie mają w sobie coś co jest bliskie protokołowi.

    Nie mniej jednak można też zrobić bibliotekę do wszystkich modułów.
    Wtedy zadziałają i te skomplikowanie z użyciem ich wbudowanej logiki, i zadziałają prostsze albo z powyłączaną logiką.
  • Admin of Design group
    @atom1477 właśnie chodzi o to aby użytkownik protokołu średnio się musiał zastanawiać nad zamiennością UART czy SPI czy jakiegoś innego sposobu komunikacji z modułem. Podobnie z możliwością konfiguracji lub jej brakiem. Wywołuje funkcje protokołu i przechodzą one przez kolejne warstwy aż do modulacji w module RF.
    Ilość dostępnych funkcji na "górze" protokołu będzie zależała od wykorzystanego modułu na końcu protokołu.

    @tzok stos jest dobrą analogią, protokół ma określone właściwości, formowana jest ramka i wyższe warstwy średnio obchodzi co z tym zrobi sterownik na niższej warstwie, dane zostaną przesłane do modułu (w niektórych przypadkach dodatkowo zakodowane), to jakim interfejsem zostaną przesłane to już realizuje warstwa sterownika.
    Podobnie sprawa konfiguracji modułu, to czy da się go skonfigurować i jak to kwestia sterownika.

    wykorzystanie protokołu->protokół->sterownik->kodowanie->moduł->modulacja->transmisja radiowa

    Protokół ma zapewniać komunikację w różnych wariantach (potwierdzenia/brak, punkt-punkt/bramka, spójność danych itd.),
    implementacja protokołu ma dać użytkownikowi zestaw funkcji typu:
    inicjalizacja
    prześlij do adresu
    prześlij do adresu z potwierdzeniem
    prześlij do grupy
    prześlij i czekaj na dane zwrotne
    oczekuj na dane
    itd.

    Implementacja sterownika połączy implementację protokołu ze sprzętem,
    sterownik może zapewnić komunikację przez proste moduły OOK "on wire" ale praktyczniejsze zastosowanie to komunikacja z modułami mającymi swoją logikę "silnik pakietów" itd.

    Efekt końcowy podobny do korzystania np. z u8g2 dla wyświetlaczy https://github.com/olikraus/u8g2
    ten projekt obsługuje wyświetlacze LCD/TFT/OLED z magistralami I2C oraz SPI
    gdzie tworzymy obiekt danej klasy uruchamiając komunikację po SPI z LCD na ST7920
    U8G2_ST7920_128X64_1_SW_SPI u8g2(U8G2_R0, /* clock=*/ 13, /* data=*/ 11, /* CS=*/ 10, /* reset=*/ 8);
    albo z OLED na SSD1306 po I2C
    U8G2_SSD1306_128X32_UNIVISION_F_SW_I2C u8g2(U8G2_R0, /* clock=*/ 1, /* data=*/ 2, /* reset=*/ 3);

    Na razie zbieramy wymagania,
    ile ma być warstw zobaczymy w następnym etapie przy projekcie protokołu a także przy jego implementacji,
    patrząc na prosty pomysł:

    wykorzystanie protokołu->protokół->sterownik->kodowanie->moduł->modulacja->transmisja radiowa

    potrzebna jest minimum:
    -warstwa implementująca protokół i udostępniająca funkcjonalności użytkownikowi
    -potrzebna jest warstwa uniwersalnego "uchwytu" sterownika dla protokołu
    -w warstwie sterownika uniwersalne metody zostaną przetłumaczone na możliwości danego modułu radiowego i przekaże do niego parametry i dane, w tej warstwie może się dziać więcej (proste moduły) lub mniej (moduły z silnikiem pakietów) oraz często wykorzystanie gotowej implementacji komunikacji z modułem

    -widać też warstwę "czasu rzeczywistego" która musi powiadamiać o odebranym pakiecie lub innych sytuacjach lub pilnować nadawania/odbierania dla prostych modułów lecz zajmujących czas i inne zasoby mikrokontrolera

    Podejście jest trudne i zajmujące więcej czasu niż zrobienie optymalnego oprogramowania dla konkretnego modułu na konkretny mikrokontroler.

    @Zaaaaap bezpieczeństwo to ważny temat, dobrze aby była możliwość wybrania protokołu bez szyfrowania i autoryzacji (np. dla bezprzewodowego termometru o małej istotności), gdy chcemy dobrze aby była możliwość uruchomienia sprawdzenia czy dane wysłało nasze urządzenie (coś w rodzaju funkcjonalności jakie dają podpisy cyfrowe), gdy chcemy aby nasza komunikacja nie była czytelna dla "podsłuchującego" potrzebne jest szyfrowanie przesyłanych danych.

    Przygotowaniem takich funkcjonalności zwykle zajmuje się warstwa protokołu gdyż rozumie wszystkie dane w ramce i może wysłać zarówno tekst jawny jak i szyfrogram widoczne dla niższych warstw jako pole danych. Jednak wcale nie musi tak być to zależy, warto tutaj wspomnieć o:
    -modułach radiowych realizujących szyfrowanie (odciążenie mikrokontrolera)
    -układach realizujących np. sprzętowe sha i bezpieczny magazyn kluczy

    Dystrybucja kluczy to kolejny temat na długą dyskusję. Ważne aby były różne opcje do wyboru i aby się nie okazało że przesadziliśmy i musimy mieć minimum RaspberryPi aby coś ledwo zadziałało i aby przesłać odczyt temperatury ;)

    @maciej_333 ukierunkowanie na "lekkie" transmisje danych, czyli nie będziemy strumieniowali wideo tylko np. przesyłali punkt-punkt dane z czujnika w bezprzewodowym jednokanałowym interfejsie lub jeżeli będziemy chcieli to wykorzystamy protokół w sieci sensorowej i urządzeń wykonawczych z bramką/bramkami np. w automatyce domowej.

    "-Odpuszczenie sobie łączenia różnych transceiverów ze sobą. Jest to ogromne ułatwienie."

    Chodzi o wykorzystanie różnych modułów radiowych ale pracujących ze sobą w parze/grupie, czyli opakowujemy kodem istniejące moduły,
    raczej nie skupiajmy się na kompatybilności transmisji między rożnymi modułami to będzie zbyt ograniczające i trudne.
    Natomiast jeżeli uda się umożliwić połączenia między różnymi modułami (przy odpowiedniej konfiguracji) to dobrze, ale nie jest to rdzeń projektu i nie tutaj jest nacisk.
    Jeżeli mamy 2 rodzaje niekompatybilnych modułów to np. bramkę/bramki można wyposażyć w oba rodzaje.

    @satanistik od modułów z wbudowaną logiką warto zacząć, szybsze testowanie i nie tracimy czasu na coś co nie jest rdzeniem projektu. Natomiast podejście warstwowe nie wyklucza zastosowania jednokierunkowego modułu OOK "on wire" pod warunkiem że będzie zainteresowanie obsługą takiego modułu oraz czas i motywacja na implementację sterownika. Każdy wybierze to co potrzebuje, łatwo może się przenieść na inny moduł, inaczej zainicjalizuje bibliotekę/obiekt i być może dostanie możliwość wywołania dodatkowych funkcji.
  • Moderator of Cars
    atom1477 wrote:
    Jak nisko to wiadomo. Do samego dołu. Aż do warstwy fizycznej czyli modułów.

    ...tylko gdzie ten "dół" leży. 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ą).
  • Admin of Design group
    Dlatego protokół musi wywoływać uniwersalne metody/funkcje sterownika,
    sterownik dla określonego modułu albo będzie "kluczował tranzystorem" ;)
    albo prześle paczkę danych do modułu celem wysłania pod wskazany adres,
    podobnie z metodą konfiguracji dla pierwszego przypadku konfiguracja bardziej dotyczy zasobów mikrokontrolera (porty/przerwania),
    w drugim przypadku to pisanie/czytanie po rejestrach modułu oraz być może sterowanie stanami modułu podczas pracy (oszczędzania energii itp.), przyjmowanie przerwań o kompletnej odebranej ramce.
  • Helpful post
    Moderator of Cars
    Tylko 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. Czy też może celujemy co najmniej w STM32/SAMD21, albo i SoC pokroju RPi?
  • Admin of Design group
    Implementacje protokołu mogą być na różne platformy,
    w przypadku Arduino wspomniane "bazowe" ATMega 328PU i moduły ESP8266/32 są dobrym pakietem startowym.
pcbway logo