Elektroda.pl
Elektroda.pl
X
Elektroda.pl
CSICSI
Please add exception to AdBlock for elektroda.pl.
If you watch the ads, you support portal and users.

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

And! 06 Jan 2021 11:30 3828 32
  • 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


    Link


    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 ?

    Cool! Ranking DIY
    Can you write similar article? Send message to me and you will get SD card 64GB.
    About Author
    And!
    Admin of Design group
    Offline 
    Has specialization in: elektronika cyfrowa, mikrokontrolery, transmisja i przetwarzanie danych
    And! wrote 8525 posts with rating 598, helped 174 times. Been with us since 2002 year.
  • CSICSI
  • #2
    RebellionArts
    Level 21  
    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
    And!
    Admin of Design group
    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.
  • CSICSI
  • #4
    katakrowa
    Level 21  
  • #6
    RebellionArts
    Level 21  
    atom1477 wrote:
    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
    And!
    Admin of Design group
    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.
  • #9
    And!
    Admin of Design group
    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
    atom1477
    Level 43  
    No to zabrakło informacji że są ograniczenia we wpisywaniu się do zespołów.
    Oczywiście produkt końcowy wciąż może być otwarty. Bo jest wiele rodzajów otwartości.
    1. Otwarty kod źródłowy.
    2. Otwarta dokumentacja.
    3. Otwarty sposób użytkowania. Czyli że za darmo, itp.
    Ale i jest:
    4. Otwarty dostęp do tworzenia produktu, od początku do końca.
    A tu jest to ograniczone. Nic złego, ale zabrakło tej informacji.

    No i dla niektórych, a na pewno dla mnie, to spora wada. Bo oznacza brak otwartego wpływu na projekt. Czyli na sposób licencjonowania, planowanie kroków, itp. Brak wpływu na nazwę już pominę :D
    Po prostu jest to projekt konkretnych kilku osób, a jest otwarty jedynie na wykonawców tego konkretnego projektu.
    Oznacza to że każdy może przystąpić do wykonywania, ale nie ma wpływu na późniejszy sposób dystrybucji.
    Bo może być darmowe, ale wymagać rejestracji aby pobrać.
    Może być darmowe, ale tylko do zastosowań amatorskich a nie komercyjnych.
    Może być darmowe, ale na licencji GPL czyli wymagać przeniesienia licencji na własny kod.
    Może być wypuszczone z mniejszą albo większą ilością błędów.
    Może być wiele innych rzeczy do ustalenia, niezwiązanych z samym protokołem i jego tworzeniem.
    No a całkowita otwartość oznaczałaby że każdy twórca ma możliwość bezpośredniego wpływania na te rzeczy.
    A tu tego brakuje. Oczywiście wiem że będziecie słuchali propozycji. Ale to będzie z Waszej dobrej woli, a nie z otwartości. Wielu rzeczy możecie nie posłuchać, albo potem zmienić zdanie.

    Rozwiązanie o jakim mówisz może i jest standardowe, ale jest i inne też standardowe.
    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.
    Teraz przynajmniej wiemy że tutaj mowa nie o takim, ale o tym pierwszym. Gdzie liderzy są narzuceni od początku. Wbrew pozorom nie było to takie oczywiste na początku, bo nigdzie nie pisało że do tej akurat grupy nie można się zapisać.
  • #11
    Szymon Tarnowski
    Level 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
    atom1477
    Level 43  
    Ja z kolei się zastanawiam czy w ogóle taki system ma sens.
    Nic nie mówiłem skoro się pojawiło takie przedsięwzięcie, bo to oznacza że jakieś zainteresowanie chyba jest.
    Ale zanim się pojawiło, to od jakiegoś czasu miałem wrażenie że to nie ma sensu bo teraz wszystko idzie w WiFi, Bluetooth, LoRA czy inne IoT.
    Sam dla siebie miałem zrobić parę czujników czy sterowników, i zrezygnowałem z użycia prostych modułów RF na rzecz ESP8266.
    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ć.
    Inny moduł scalaka RF WiFi. Mała szerokość pasma. Może nawet inne pasmo (są jakieś wersje WiFi low energy na 868MHz).
  • #13
    Szymon Tarnowski
    Level 27  
    atom1477 wrote:
    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 wrote:
    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
    atom1477
    Level 43  
    Mi chodzi o zrobienie czegoś takiego jak ESP8266 czy EPS32.
    Najlepiej nawet jakoś tam zgodnego programowo.
    Chodzi tylko o inny hardware, żeby był mniejszy pobór prądu.
    Oraz o dodanie nowych funkcjonalności do software (lub po prostu zebranie istniejących gotowców do kupy). Czyli dorobienie wysokopoziomowego "protokołu". Żeby użytkownik widział tylko proste funkcje do nadawania i odbierania, bez tej całej zabawy w IP, UTP, itp.
    Dzięki temu nie wymyślalibyśmy niczego na nowo.
    Zrobili byśmy tylko to w czym obecnie jest nisza. Czyli low power.
    ESP pozwala zrobić low power tylko dla układów "master". Czyli takiego termometru, który sam się wybudza kiedy chce i wtedy wysyła dane. Brak jednak "slave" low power. Czyli takiego który by ciągłe nasłuchiwał czy nie przychodzą do niego jakieś rozkazy, aby je móc natychmiastowo wykonać.

    A jeżeli chodzi o gotowce, to jest jeszcze SimpliciTI. To jest w sumie najbliższe temu co jest tematem tego wątku. Gotowy protokół (nie będący WiFi czy BT), i działający na wielu modułach radiowych (choć raczej na tych bardziej skomplikowanych, jak CC2500). Z jakichś powodów się jednak nie przyjął (W USA był stosowany ale upadł, w Polsce nawet nie był specjalnie znany.).
  • #15
    Szymon Tarnowski
    Level 27  
    atom1477 wrote:
    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 wrote:
    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
    atom1477
    Level 43  
    Szymon Tarnowski wrote:
    Żeby było prościej zapytam wprost, to czy chcesz zrobić alternatywną platformę fizyczną, czy może własny firmware na platformy ESP?

    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.

    A kwestie certyfikacji nie są problemem. Prawo UE nie pozwala na przenoszenie certyfikacji na całość urządzenia. Jak się wbuduje ESP do swojego urządzenia, to i tak trzeba na to robić certyfikację od nowa.
    Więc czy ESP ma certyfikację czy nie, to bez znaczenia. Znaczenie ma to czy ESP ma odpowiednie parametry pozwalające przejść certyfikację.
    Podobnie było by z naszym nowym modułem. Nie musiałby mieć certyfikacji. Ważne żeby spełniał (z dużym zapasem) warunki techniczne przejścia certyfikacji. A to jest do zrobienia.
  • #17
    Szymon Tarnowski
    Level 27  
    atom1477 wrote:
    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.
  • #19
    Szymon Tarnowski
    Level 27  
    atom1477 wrote:
    Mówisz o HW czy SW?
    O całości jako "produktu", tak żeby było używalne dla potencjalnego hobbysty.
  • #21
    Szymon Tarnowski
    Level 27  
    atom1477 wrote:
    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ę.
  • #23
    tmf
    Moderator of Microcontroller designs
    atom1477 wrote:
    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 wrote:
    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
    atom1477
    Level 43  
    tmf wrote:
    To trochę nie tak, przynajmniej ja to widzę nieco inaczej niż przedstawiłeś w poście.
    To jest otwarte forum, na któym pisać moga wszyscy, zrobi się więc naturalny bałagan.

    Tyle że "bałagan" jest pożyteczny na początku takich projektów.

    tmf wrote:
    Musi więc od początku być jakiś lider, ale lider przede wszystkim w sensie zebrania wszystkich pomysłów, jakiegoś opanowania początkowego chaosu.

    Nie od początku. Przecież nawet obecna lista nie pojawiła się od razu, lecz wynikła z jakichś dyskusji. Czyli właśnie z "bałaganu". Tyle że działo się to poza oficjalnym forum, więc nikt z nas tego nie wiedział.
    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.
    Weź też pod uwagę że ta grupa wcale się nie nazywa "grupa liderów".
    Lecz "grupa sterująca". A na listę jej zadań jest wpisane przygotowanie materiałów promocyjnych i projektów PCB. A to nijak nie świadczy że o jakaś elitarna grupa do zarządzania, tylko raczej zwykła grupa robiąca projekt.
    Dlatego cały czas podkreślam że mnie głównie zniechęcił brak info że lista jest zamknięta, a nie sam fakt że jest zamknięta.

    tmf wrote:
    To kwestia dyskusyjna, wiele mitów wobół 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.

    Ale i wiele jest przeciwników GPLa ze strony zwolenników Open Source.
    Np. z mojej. Open Source to ideologia, a nie sytuacja że każdy kod ma być otwarty. Zwolennik może więc dopuszczać zamknięcie niektórych kodów, oraz być
    "otwartym" na zamykanie kodu :D
    Po prostu polega to na tym żeby nie narzucać swojego zdania innym. A więc samemu być za otwartym kodem, ale nie wymagać tego od innych.
    Dlatego jak dla mnie tylko licencja X11. Czyli ta którą nazwałeś MIT (choć to nieprecyzyjna nazwa).
  • #25
    tzok
    Moderator of Cars
    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
    And!
    Admin of Design group
    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
    tmf
    Moderator of Microcontroller designs
    atom1477 wrote:
    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 wrote:
    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 wrote:
    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 wrote:
    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
    atom1477
    Level 43  
    And! wrote:
    Zastanawiam się na jakiej licencji umieszczane są artykuły i DIY na elektroda.pl?

    Na mój gust właśnie na X11.

    And! wrote:
    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.

    No to dobrze, bo inaczej by się z tego zrobił potwór.

    tmf wrote:
    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ć.

    Tłumaczenia nie zmieniają rzeczywistości. Przecież widzę że jest zamknięta.
    A chętni przecież są.
    Jeszcze raz przypomnę że to nie problem. Mówię tylko żeby nazywać rzeczy po imieniu. Lista otwarta to lista otwarta. A lista zamknięta to lista zamknięta.
    Skoro do wszystkich punktów wykonawczych wpisywani są wszyscy chętni gdy tylko się zgłoszą, a do pierwszej listy wpiszecie dopiero kogoś po namyśle , po rozwoju projektu, po odejściu kogoś obecnego, to to lista po prostu nie jest tak samo otwarta jak te poprzednie.

    tmf wrote:
    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.

    W porządku. Jak pisałem to nie problem.
    Najwyższa pora zacząć więc działać, a tym żeby zaczęły działać osoby z obecnej pierwszej listy :D
  • #29
    tzok
    Moderator of Cars
    ... 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ę.