| Mam świadomość, że wątek lekko zdryfował z pierwotnego kursu, jakim był fakt uruchomienia nowego przemiennika w Poznaniu, ale dyskusja na tyle interesująco się rozwinęła, że uznałem, że warto dodać kilka własnych spostrzeżeń. Na pewno istnym jest to, o czym wspomniał w ostatnim poście Adam, iż głównym napędem w rozwoju otwartych rozwiązań DV jest Jonathan G4KLX. Oczywiście nie jest to wyłączna zasługa Jonathana, ale sztabu ludzi na całym świecie wspólnie pracujących nad tym by rozwiązania DV tworzyły spójną i stabilną całość. Doskonale było to widać na przykładzie D-Stara gdzie prócz „fabrycznej” sieci G2 (D-Plus) rozwinęły się alternatywne konwergentne sieci ircDDB, CSS, DCS, DExtra, Star-Net. Mogę być w błędzie, ale w mojej ocenie było to możliwe dzięki zasadniczej kwestii, która w dotychczasowej dyskusji została „przemilczana” a mianowicie faktu, iż D-Star jest w pełni otwartym standardem, który został opracowany, ustandaryzowany i udostępniony przez samych krótkofalowców a jego rozwój w dalszym ciągu jest w ich rękach tj. JARL (Japan Amateur Radio League). Niestety tego nie można powiedzieć o systemie Fusion, który na obecną chwilę jest wyłączną własnością firmy Yaesu i jak na razie nic nie wskazuje na to by Yaesu chciało się podzielić tą wiedzą ze światem krótkofalowców. Oczywiście nie można mieć za złe, że Yaesu chroni własne wartości intelektualne, ale fakt ten sprawia, że opracowanie i zbudowanie alternatywnych otwartych sieci wspierających ten standard zajmie sporo czasu i może się okazać, że będzie to długotrwała, żmudna praca na zasadzie debagowania i szczegółowej analizy transmitowanego strumienia danych. Nie jest tajemnicą, że zespół współpracujących z Jonathanem pracuje nad implementacją obsługi Fusion (C4FM) w uniwersalnym modemie MMDVM nie mniej jednak z ostatnich informacji (koniec ubiegłego tygodnia) wynika, że implementacja Fusion ma obecnie najniższy priorytet. Z kontekstu dyskusji można wywnioskować, że kluczową „barierą” jest wspomniany wcześniej temat braku szczegółów dotyczących samego standardu obsługi protokołu Fusion. Tak, więc mimo początkowych optymistycznych informacji pojawiających się w gronie osób pracujących nad MMDVM o rychłej implementacji Fusion obecnie temu tematowi obniżono priorytet (1. D-Star, 2. DMR, 3. Fusion). Nie należy z tego wyciągać wniosków o tym, że będzie to wyłącznie system „zmonopolizowany” przez Yaesu, ale obecnie wiele rzeczy wskazuje na to, że do momentu pełnego rozwinięcia skrzydeł przez Fusion jeszcze sporo wody w Wiśle upłynie. |