logo elektroda
logo elektroda
X
logo elektroda
Adblock/uBlockOrigin/AdGuard mogą powodować znikanie niektórych postów z powodu nowej reguły.

Na elektroda.pl projektujemy otwarty protokół bezprzewodowej komunikacji - unirf

And! 06 Sty 2021 11:30 6474 36
  • Na elektroda.pl projektujemy otwarty protokół bezprzewodowej komunikacji - unirf
    Zapraszamy do udziału we wspólnym projektowaniu i implementacji otwartego protokołu komunikacji bezprzewodowej o roboczej nazwie unirf. Zakładanym efektem końcowym jest dostarczenie 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.


    Zaczynamy od zebrania wymagań w temacie: zbieramy wymagania do protokołu komunikacji bezprzewodowej.
    -następnie zaprojektujemy protokół,
    -później przejdziemy do implementacji na wiele różnych modułów radiowych np. z serii RFMXX.
    -kolejny etap to testowanie i poprawki

    Elektroda.pl wspiera projekt i mamy pomoc od gulson zarówno na wstępnych etapach, jak również na późniejszych gdy będziemy mogli wysłać moduły bezprzewodowe do zainteresowanych, a także przy wykonaniu płytek do prototypów. Projekt wspierają moderatorzy i redaktorzy elektroda.pl Gdzie uda się nam wspólnie dotrzeć, to zależy od nas.

    Zapraszamy do zgłoszeń uczestnictwa w zespole, oraz do udziału w kolejnych etapach.
    temat ze zgłoszeniami do udziału w projekcie protokołu komunikacji bezprzewodowej elektroda.pl





    Kolejne kroki zależą od powodzenia poprzednich. Jeżeli się uda to otrzymacie otwarty protokół pozwalający na komunikację jednokierunkową i dwukierunkową, do wykorzystania w złożonych i mniej skomplikowanych projektach.
    W praktyce po podłączeniu np. do płytki arduino lub mikrokontrolera wybranego modułu np. RFM12 wywołacie odpowiednie funkcje/metody aby komunikować się z bramką/innym węzłem/wszystkimi węzłami. Wymiana modułu pozwala na ponowne użycie kodu programu.

    Zaczynamy od wymagań, później przejdziemy do projektu protokołu jak najbardziej oderwanego od sprzętu (uniwersalność), implementacja i "sterowniki" do wybranych modułów RF w późniejszym czasie.

    Do dyspozycji macie tematy:
    zbieramy wymagania do protokołu komunikacji bezprzewodowej elektroda.pl
    temat ze zgłoszeniami do udziału w projekcie protokołu komunikacji bezprzewodowej elektroda.pl
    protokół komunikacji bezprzewodowej elektroda.pl - temat ogłoszeniowy - warto dodać ten temat do śledzonych aby otrzymywać powiadomienia o kolejnych etapach projektu.

    Aktualny status projektu: zbieranie wymagań dla protokołu.

    Planowane kolejne kroki:
    -zbieranie wymagań dla protokołu (w realizacji)
    -opracowanie protokołu
    -implementacja protokołu
    -implementacja "sterowników" do modułów radiowych
    -testy i wysyłka modułów do aktywnych zainteresowanych uczestników projektu
    -poprawki protokołu i implementacji
    -projekt min. 3 urządzeń: czujnik, element wykonawczy, bramka/kontroler

    Zespoły

    zespół sterujący:
    gulson - koordynacja i zasoby
    And! - koordynacja i nawigacja
    techekspert - implementacja, testowanie, materiały informacyjne
    Marek_Skalski - warstwa sprzętowa, dobór komponentów, przygotowanie schematów i projektów PCB
    tmf - warstwa sprzętowa i implementacja protokołu

    zespół implementacji:
    atom1477
    w_d

    zespół testujący:
    RebellionArts
    atom1477
    dzi_dziuś - doświadczenie w projektowaniu elektroniki i PCB

    Napiszcie co myślicie o tym otwartym projekcie?
    Może macie już pomysł na wymagania do protokołu komunikacji bezprzewodowej elektroda.pl ?

    Fajne? Ranking DIY
    O autorze
    And!
    Admin grupy Projektowanie
    Offline 
    Specjalizuje się w: elektronika cyfrowa, mikrokontrolery, transmisja i przetwarzanie danych
    And! napisał 9013 postów o ocenie 773, pomógł 175 razy. Jest z nami od 2002 roku.
  • #2 19162915
    RebellionArts
    Poziom 23  
    Witam,

    Pomysł na opracowanie własnego protokołu uważam za bardzo dobry. Szanowane grono specjalistów z elektrody będzie mogło w końcu zająć się czymś co wyróżni ich na scenie internetowych forum technicznych, co zawsze uważałem za najbogatsze to (elektroda), jednak oddając coś społeczeństwu jako własny projekt utworzony przez zrzeszających się specjalistów z długim stażem na forum potwierdzi poziom jaki forum reprezentuje i da przykład, że punkty i statystyki to nie to samo co wiedza, za pomocą której można stworzyć nowy dział w 'technice'. Czemu się tak ,,zapaliłem"? :)
    Sam aktualnie pracuję nad własną automatyką domową, przez rozległy rynek różnych systemów, ciężko dostosować na 100% do użytkownika taki system sterownia domem..., chyba że się go tworzy samemu. Niby dużo filozofii nie ma, żeby czymś sterować, coś nadzorować, wyświetlić komunikat. Problem zaczyna się właśnie przy komunikacji i szybkości działania oraz jej niezawodności. Ciągnięcie kabli w lewo i w prawo jest rozwiązaniem zakłócających się urządzeń elektrycznych, lub ścian, stropów czy chociażby (ostatecznie) odległość. Fibaro, stosując system Z-wave nie działa prawidłowo zamknięty już w szafie technicznej, moduły do komunikacji bezprzewodowej są też drogie (Loxone - ponad 400 zł) gdzie i tak stoi pod znakiem zapytania ich skuteczność połączenia.

    Chętnie podejmę się testera, mam dużą działkę gdzie mógłbym na zewnątrz i w środku ( domu ) oraz wewnątrz/zewnątrz sprawdzać stan komunikacji i z radością bym wykorzystał ten protokół do własnych zastosowań. Sterowanie światłem, pomiar temperatury, odczyt skali (analogowo) wzrostu, różnicy - mam dobry poligon doświadczalny :)

    Jeden przykład czujnik ruchu.
    Pracuję nad czujnikiem ruchu (mam elektronicznie poskładany bez obudowy - pracuję nad modelem drukarki 3D) , który nadzoruje ruch w pomieszczeniu, załóżmy w łazience (po co czujnik ruchu w łazience? to nie alarmowy :) ), nadzoruje on ruch w pomieszczeniu i zależnie od godziny dobiera światło (by nie raziło po oczach i 2 w nocy na siusiu), figurant idzie pod prysznic, często zdarza się że światło gaśnie bo czujnik nie widzi już figuranta, mój czujnik jest wyposażony też w czujnik dźwięku i tak długo utrzymuje wskaźnik ruchu jak słyszy, jak skończy słyszeć (15 sekund) to do ponownego wykrycia ruchu się wygłusza). W mojej ocenie czujnik ruchu powinny mieć możliwość działania bezprzewodowo, i dlatego ten protokół mógłby się sprawdzić, gdy wykryje ruch otwiera połączenie bezprzewodowe, przesyła jaki ruch został wykryty, jak długo, podaje koniec ruchu (15 sekund) i się wyłącza. Z racji tego że zapalenie światła musi być bezpośrednie do ruchu, komunikacja ta musi być szybka i wydajna. Dlatego chętnie wezmę udział w tym projekcie, podejmę się testowania, i oferuję wsparcie finansowe.

    Z innego spojrzenia jakie udało mi się wypracować na tym forum, że nie każde urządzenie działa prawidłowo, wykonane przez producenta. Często pojawia się wskazanie błędu przez jakiegoś użytkownika, że w chińskim układzie jest źle dobrana wartość rezystora, czy że można by to zrobić bardziej precyzyjnie, tu pod górkę, ten obwód produkuje straty, to jest mało praktyczne, częste awarie, itp...
    Działanie protokołu komunikacyjnego stworzonego w oparciu o specjalistów z elektrody może być przełomem w technice (tak przewiduję), jeżeli z taką starannością to zrobicie - na pewno ujrzy to światło dzienne.
  • #3 19162978
    And!
    Admin grupy Projektowanie
    Dziękuję, wpisałem na listę.

    Projekt jest trudny, jednak czemu nie spróbować.
    Można sporo się nauczyć, natomiast dostarczenie produktu końcowego to może być spory wkład w DIY, ułatwienie uruchamiania swoich pomysłów.
  • #5 19163221
    Konto nie istnieje
    Poziom 1  
  • #6 19163231
    RebellionArts
    Poziom 23  
    atom1477 napisał:
    Mnie możesz wpisać do wszystkich 3 zespołów:
    zespół sterujący
    zespół implementacji
    zespół testujący

    bo sobie nie wyobrażam pracy inaczej niż "od początku do końca".


    W pewnym sensie dobra rada, prawdę mówiąc szczerze miałem nadzieję, że będę mieć podgląd na konwersację z implementacji oraz sterowania, żebym mógł znać wszystkie 'ale' i 'i'
    Jak ktoś też już wspomniał, jest to też dobra metoda na nauczenie się tego działu.
    Mam nadzieję że będzie to wzięte pod uwagę
  • #7 19164052
    And!
    Admin grupy Projektowanie
    Dziękuję za kolejne zgłoszenie, dodałem.
    Projekt jest otwarty więc dostęp do postępów prac na każdym etapie będzie dla każdego chętnego uczestnika dyskusji.
    Zespoły określamy aby mierzyć siły na zamiary, czyli mamy listę osób które deklarują się do aktywnego udziału w określonym etapie.

    Sukces projektu opera się o aktywność członków regularnych zespołów, ale także o osoby aktywne w tematach, które dzielą się swoimi spostrzeżeniami i pomysłami, jednak na razie nie chcą dołączać do określonego zespołu.
  • #8 19164072
    Konto nie istnieje
    Poziom 1  
  • #9 19164193
    And!
    Admin grupy Projektowanie
    Projekt i jego rezultaty są otwarte, mamy wsparcie elektroda.pl i mamy też zespół sterujący projektem, to dość standardowe rozwiązanie.

    Temat zbierający wymagania rozwija się.
  • #10 19164948
    Konto nie istnieje
    Poziom 1  
  • #11 19165065
    Szymon Tarnowski
    Poziom 27  
    Mam mieszane uczucia. Inicjatywa wydaje się ciekawa, ale tak stanie przed ścianą jak pogodzić sprzeczne założenia np, oszczędzanie energii, przepustowość i pośrednictwo w przekazywaniu danych pomiędzy urządzeniami. Zawsze ktoś będzie niezadowolony.

    Lepszym podejściem byłoby żeby ktoś (leader albo mniejszy team) zaproponował protokół dedykowany np do inteligentnego domu albo sieci sensorów, a każdy potencjalnie zainteresowany zaadaptuje sobie go do własnych zastosowań.

    Mam też kilka uwag do planu, licencja GPL może być gwoździem do trumny, bo ogranicza integrację z systemami komercyjnymi i utrudnia niekomercyjną sprzedaż produktów hobbystycznych (np sensorów po customizacji pcb).

    W planie brakuje też swego rodzaju "certyfikacji", specyfikacji testów zarówno pozytywnych jak i negatywnych jakie urządzenie musi przejść zanim będzie uznane za "kompatybilne". Jest to konieczne jeśli będzie nie tylko jedna platforma.

    Do celów edukacyjnych dokumentacja powinna posiadać wyjaśnienie dlaczego dana decyzja techniczne projektowana została podjęta, np format pakietu, typ sumy kontrolnej, preambuły, modulacji, etc. Jest to przydatne też przy dyskusji w gronie a także własnej modyfikacji do innego celu/platformy.

    Tak z zabawnej strony przypomniał mi się pewien obrazek.
    https://imgs.xkcd.com/comics/standards.png
    Na elektroda.pl projektujemy otwarty protokół bezprzewodowej komunikacji - unirf
  • #12 19165152
    Konto nie istnieje
    Poziom 1  
  • #13 19165230
    Szymon Tarnowski
    Poziom 27  
    atom1477 napisał:
    Może więc zamiast projektować protokół, lepiej zaprojektować jakiś własny moduł WiFi?
    Głównym problemem w WiFi jest pobór prądu, ale jest wiele rozwiązań które pozwalałyby go ograniczyć.
    A da się hobbystycznie zrobić WiFi tanio i miniaturowo jak ESP8266 albo ESP32, boję się że hobbystyczne WiFi kończy się na RaspberryPI Zero i klonach.

    atom1477 napisał:
    Inny moduł scalaka RF WiFi. Mała szerokość pasma. Może nawet inne pasmo (są jakieś wersje WiFi low energy na 868MHz).
    Ale to nie jest "normalne" WiFi. Tak jak BLE to Bluetooth, ale nie każdy moduł Bluetooth dobrze obsługuje BLE.

    Może lepiej iść w kierunku własnego protokołu opartego na IEEE 802.15.4 (to samo co jest transportem dla Zigbee), TI ma procesory (chyba cc24xx albo cc25xx) z radyjkiem w jednej kostce na których chodzi Zigbee, ale można dać własny kod zamiast stosu Zigbee, można nawet używać tooli TI do snifowania pakietów.
    Tylko że znowu wymyślamy koło na nowo, są już Zigbee, XBee, MiWi.
  • #14 19165282
    Konto nie istnieje
    Poziom 1  
  • #15 19165339
    Szymon Tarnowski
    Poziom 27  
    atom1477 napisał:
    Mi chodzi o zrobienie czegoś takiego jak ESP8266 czy EPS32.
    Najlepiej nawet jakoś tam zgodnego programowo.
    Żeby było prościej zapytam wprost, to czy chcesz zrobić alternatywną platformę fizyczną, czy może własny firmware na platformy ESP? W drugim przypadku wątpię czy producent pozwoli zrobić coś więcej niż własną warstwę aplikacji (serwis postawiony na sockecie TCP/IP), w przypadku tknięcia części radiowej traci certyfikację WiFi.

    Wiem że jest w Polsce firma która sprzedaje moduły wyglądające jak ESP8266 z customowym firmware, wydaje mi się że mieli obsługę NTP dostępną przez komendy AT.

    atom1477 napisał:
    A jeżeli chodzi o gotowce, to jest jeszcze SimpliciTI.
    To jest dokładnie to o czym pisałem, kiedyś planowałem robić projekt z użyciem CC2530F256 z komunikacją w oparciu o surowe IEEE 802.15.4.

    Jeśli iść w kierunku jakiegoś "WiFi-light", to trzeba dostarczyć jeszcze rodzaj "bramki" najlepiej z możliwością programowania. Wtedy konkretny standard komunikacji radiowej i tak jest kontrolowany zarówno od strony bramki jak i urządzenia zdalnego. Digi swego czasu miało w ofercie np programowalne w Pythonie bramki XBee z dostępem do LAN.
  • #16 19165365
    Konto nie istnieje
    Poziom 1  
  • #17 19165391
    Szymon Tarnowski
    Poziom 27  
    atom1477 napisał:
    Alternatywną platformę fizyczną.
    A do niej firmware zgodny (z punktu widzenia użytkowania) z ESP, ale oczywiście zawierający potrzebne zmiany pozwalające mu działać na innym Hardware.
    IMHO wysoko stawiasz poprzeczkę, hobbystycznie wykonalne, ale trzeba by mieć mocny zespół który włoży w to mnóstwo pracy. Nie ogarnie się tego w 5 osób pracując po godzinach pracy etatowej.
  • #18 19165401
    Konto nie istnieje
    Poziom 1  
  • #19 19165406
    Szymon Tarnowski
    Poziom 27  
    atom1477 napisał:
    Mówisz o HW czy SW?
    O całości jako "produktu", tak żeby było używalne dla potencjalnego hobbysty.
  • #20 19165423
    Konto nie istnieje
    Poziom 1  
  • #21 19165460
    Szymon Tarnowski
    Poziom 27  
    atom1477 napisał:
    Chyba nie bardzie niż własny protokół który miał by być bardzo uniwersalny i konfigurowalny.
    Własny protokół to tylko SW pod konkretną platformę.
  • #22 19165467
    Konto nie istnieje
    Poziom 1  
  • #23 19165583
    tmf
    VIP Zasłużony dla elektroda
    atom1477 napisał:
    Mianowicie takie że wszyscy przystępują do projektu, zaczynając od bardzo wstępnych założeń. Bez wyraźnego lidera. Gdzie wszystko jest ustalane od początku. Liderzy też tam się wyłaniają, ale wyłaniają się samoistnie z całej grupy. Każdy może aspirować lub zostać wyłoniony samoistnie. Takie rozwiązanie też jest popularne.

    To trochę nie tak, przynajmniej ja to widzę nieco inaczej niż przedstawiłeś w poście.
    To jest otwarte forum, na którym pisać mogą wszyscy, zrobi się więc naturalny bałagan. Musi więc od początku być jakiś lider, ale lider przede wszystkim w sensie zebrania wszystkich pomysłów, jakiegoś opanowania początkowego chaosu. I chyba tylko w tym sensie są ci liderzy wyznaczeni. Oczywistym jest, że jeśli z osób zainteresowanych wyłoni się osoba chętna to poprowadzić, która będzie zapychać jak mały motorek to do tego grona dołączy. Nic nie jest na zawsze i myślę, że z przyjemnością powitamy takie osoby. Tylko na początku nic nie wiemy, z samych deklaracji trudno wyczuć, kto się zaangażuje na serio, a kto tylko naobiecuje złote góry. A działać trzeba.
    Także projekt jest całkowicie otwarty.
    Szymon Tarnowski napisał:
    Mam też kilka uwag do planu, licencja GPL może być gwoździem do trumny, bo ogranicza integrację z systemami komercyjnymi i utrudnia niekomercyjną sprzedaż produktów hobbystycznych (np. sensorów po customizacji pcb).

    To kwestia dyskusyjna, wiele mitów wokół licencji GPL narosło na skutek działań przeciwników open source. Niemniej to też kwestia do dyskusji - może być np. licencja MIT, może być inna. Te kwestie licencyjne istotnie trzeba ustalić na samym początku, bo pewnie dla części osób to może być decyzja typu - przyłączam się do projektu lub nie.
  • #24 19165634
    Konto nie istnieje
    Poziom 1  
  • #25 19165806
    tzok
    Moderator Samochody
    Moimi ulubionymi licencjami są licencje BSD... zwłaszcza licencja "Simplified BSD License". Nie wspominając już o "Zero Clause BSD", czyli w skrócie "róbta co chceta".
  • #26 19166439
    And!
    Admin grupy Projektowanie
    Proponuję aby darmowy i otwarty protokół był możliwy do wykorzystania w dowolny sposób, zarówno przez hobbystów jak i w projekcie komercyjnym.

    Dyskusja o licencji jest tu bardzo ważna, jaki model wybrać aby było dobrze i bez zbędnego komplikowania. Być może uruchomimy osobny temat do ustalenia jaka licencja jest nam potrzebna.

    Zastanawiam się na jakiej licencji umieszczane są artykuły i DIY na elektroda.pl?

    Protokół ma być do "lekkiej" komunikacji z wykorzystaniem modułów radiowych, typowe przypadki użycia to przesłanie stanu urządzenia, odczytu parametrów, wysłanie komendy sterującej. Możliwość pracy punkt-punkt, punkt-grupa, wsparcie dla rozwiązań z bramką/bramkami.

    Ułatwienie wykorzystania istniejących modułów radiowych, oraz możliwość wymiany modułu radiowego z zachowaniem części napisanego już kodu.

    Czy zrobimy "15" standard? zobaczymy, nawet jeżeli tak będzie, ale będzie zgodny z popularnym sprzętem to czemu nie :)

    ESP i WiFi jest tanie i ma średni zasięg (2.4GHz) a także dobrą przepustowość oraz przenoszenie IP, jest nawet konkurencja dla WiFi ESP-NOW.

    WiFi, Bluetooth, LoRA, Sigfox, Zigbee, XBee, MiWi są i będą, mają wiele różnych zastosowań oraz cech jednak potrzebują konkretnie określonego "radia" nie da się je przeskalować do radia OOK. Więc w projekcie nie będziemy tworzyć nowego rodzaju modulacji i frontendu radiowego tylko protokół, który przykryje moduły do których będą dostępne sterowniki dla protokołu.
  • #27 19166717
    tmf
    VIP Zasłużony dla elektroda
    atom1477 napisał:
    Tyle że "bałagan" jest pożyteczny na początku takich projektów.

    Nikt tego nie neguje. Dlatego zresztą ten temat pojawił się publicznie, a nie na zamkniętej grupie, do której są zaproszone "zaufane" osoby.
    atom1477 napisał:
    No ale nawet jak założymy że trzeba liderów od początku, to nie musi ich być aż czterech :D
    I to czterech, bez informacji że tych czterech to jest zamknięta lista.

    Ależ ci tłumaczę, że to nie jest zamknięta lista. Po prostu zakładamy, że może nie być innych chętnych, którzy będą chcieli się jakoś bardziej zaangażować. Aby pomysł nie stanął w miejscu, zgłosiły się osoby, które chcą realizować pewne elementy. Jeśli znajdą się inne, może bardziej zdeterminowane, może lepsze, to przecież nie ma problemu aby dołączyły do tej grupy lub zastąpiły którąś z osób.
    atom1477 napisał:
    Weź też pod uwagę że ta grupa wcale się nie nazywa "grupa liderów".

    Naprawdę na tym etapie nie ma co bawić się w semantykę. Czy nazwiemy ich liderami, ojcami założycielami, grupą trzymającą władzę, czy jeszcze inaczej, jest bez znaczenia. Po prostu ktoś zapodał pomysł, innym się spodobał, a może niezależnie te osoby myślały i realizowały coś podobnego i postanowiły zadziałać wspólnie? Obojętne. W każdym razie grupa jest otwarta.
    atom1477 napisał:
    Ale i wiele jest przeciwników GPLa ze strony zwolenników Open Source.

    Ok, dlatego jest to temat do dyskusji. Przy czym typ licencji IMHO powinny określić osoby, które przyłączą się do projektu np. przez głosowanie po dyskusji na temat za lub przeciw różnym licencjom.
  • #28 19167322
    Konto nie istnieje
    Poziom 1  
  • #29 19167547
    tzok
    Moderator Samochody
    ... i tak skończy się jak poprzednio. Po 3 miesiącach dyskusji nie uda się osiągnąć żadnego porozumienia, skończą się argumenty, ludzie się poobrażają i "rozejdą". Musi być silny lider, który będzie potrafił odrzucić nierealistyczne postulaty i samodzielnie podjąć decyzję.

Podsumowanie tematu

Na forum elektroda.pl rozpoczęto projektowanie otwartego protokołu komunikacji bezprzewodowej o nazwie unirf. Celem jest stworzenie protokołu, który umożliwi komunikację z różnymi modułami radiowymi, takimi jak RFMXX, i będzie użyteczny w projektach od prostych, jak bezprzewodowe termometry, po bardziej złożone, jak automatyka domowa. Uczestnicy dyskusji podkreślają znaczenie niezawodności komunikacji oraz elastyczności protokołu. Pojawiają się różne opinie na temat otwartości projektu, licencji (w tym GPL) oraz możliwości integracji z istniejącymi systemami, takimi jak ESP8266 i ESP32. Wskazano również na potrzebę certyfikacji i testowania urządzeń. Projekt napotyka na wyzwania związane z organizacją pracy zespołowej oraz zaangażowaniem uczestników.
Podsumowanie wygenerowane przez model językowy.
REKLAMA