Rig2Cast Lib to otwarty framework napisany w języku C# dla platformy .NET 8, przeznaczony do kontrolowania radiostacji amatorskich. Autor DeXTeRGT zaprojektował go jako modułową podstawę dla aplikacji desktopowych, interfejsów webowych, usług w tle oraz klientów sieciowych – z własną abstrakcją radia, bezpiecznym działaniem wielu klientów, modułowymi kontrolerami poszczególnych modeli, wykrywaniem możliwości urządzenia i opcjonalnymi adapterami protokołów.
W artykule przeczytasz
Dlaczego powstał Rig2Cast Lib i jest potrzebny?
Hamlib slúži rádioamatérskej komunite mimoriadne dobre – podporuje impozantné množstvo rádií a predstavuje desaťročia skúseností s CAT protokół i fizyczny sprzęt. Jego natywna architektura w języku C nie zawsze jednak naturalnie integruje się z zarządzanymi aplikacjami .NET. Użycie C# zwykle wymaga natywnych binarek, specyficznego dla platformy wdrożenia, warstwy interoperacyjnej oraz dodatkowej synchronizacji wokół współdzielonego dostępu do radia. Nowoczesne aplikacje często potrzebują również bezpiecznie udostępnić jedno radio wielu klientom jednocześnie przez natywne API, REST, gRPC, TCP, aplikacje desktopowe oraz interfejsy webowe.
Rig2Cast Lib podchodzi do tego problemu z nowego kierunku architektonicznego. Autor wyraźnie zaznacza, że nie jest to zamiennik Hamlibu ani jego bezpośredni przepis (port linia po linii) do C# – jest to niezależna rewizja kontroli radia dla nowoczesnych aplikacji .NET. Oficjalna dokumentacja producenta jest autorytetem w zakresie implementacji protokołu CAT; Hamlib służy jako użyteczna referencja oczekiwanego zachowania i ważny cel kompatybilności, ale sama architektura i implementacja Rig2Cast rozwija się niezależnie od dostępnych protokołów CAT radii.
Celem nie jest rywalizować z Hamlibem ani go poniżać. Hamlib pozostaje ważnym projektem, nieocenionym źródłem doświadczeń i istotnym celem kompatybilności. Rig2Cast bada kontrolę radia zaprojektowaną specjalnie dla nowoczesnych .NET: asynchronicznie, modułowo, sterowane możliwościami urządzenia, bezpieczne dla wielu klientów, niezależne od warstwy transportowej i łatwe do rozszerzenia.
Jedno urządzenie i wiele programów uzyskujących do niego dostęp

Fizyczne połączenie CAT jest w swojej istocie sekwencyjne – wiele aplikacji nie może bezpiecznie wysyłać dowolnych poleceń do tego samego portu szeregowego jednocześnie. Rig2Cast dlatego zapewnia jeden zarządzany harmonogram poleceń dla fizycznego radia. Wiele logicznych klientów może działać równolegle, podczas gdy sama komunikacja CAT pozostaje szeregowa, uporządkowana i chroniona.
Each application or network connection receives its own logical identity and session. The runtime provides roles and permissions for clients, ordered execution of commands with priorities, exclusive operations, time-limited access for sensitive operations, session cleanup after disconnection, and secure coordination among concurrent clients. Compound changes can be transactional at the level of radio operation - for example, changing mode and bandwidth can occur under exclusive control so that another client cannot insert a command between these two changes.Broadcast operations have additional protection and are not processed as regular setter commands.
Ta sama zarządzana instancja radia jest przeznaczona do obsługi opcjonalnych interfejsów: natywnego interfejsu API języka C#, interfejsu API REST (planowane), gRPC (planowane), bogatszych natywnych protokołów TCP (planowane), adaptera rigctld zgodnego z Hamlib (dostępna jest wstępna implementacja) oraz aplikacji stacjonarnych i internetowych lub usług w tle. Są to adaptery o tym samym czasie działania i modelu możliwości — logika CAT producenta pozostaje w sterowniku radiowym, zamiast być powielana w każdym interfejsie API i interfejsie użytkownika.
Możliwa kompatybilność z Hamlib

Rig2Cast zawiera oddzielny, opcjonalny adapter TCP kompatybilny z rigctld. Istniejący klienci kompatybilni z Hamlib mogą się łączyć, podczas gdy Rig2Cast zarządza w tle fizycznym radiem, sesjami logicznymi i szeregowym dostępem CAT. Obecny adapter obsługuje wielu współbieżnych klientów TCP i polecenia dla częstotliwości i aktywnego VFO, trybu pracy i pasma zależnego od trybu, operacji podziału i odczytu statusu PTT, krótkich i długich form poleceń oraz rozszerzonych odpowiedzi.
Adapter domyślnie nasłuchuje na interfejsie pętli zwrotnej i działa w trybie tylko do odczytu — zapisy muszą być jawnie włączone, a zapisy PTT pozostają niedostępne na tym początkowym kompatybilnym adapterze. Celem jest praktyczna kompatybilność bez osłabiania modelu bezpieczeństwa Rig2Cast. Jednocześnie Framework nie jest ograniczony przez starszy protokół rigctld - nowa funkcjonalność może pozostać dostępna za pośrednictwem natywnego interfejsu API C# i przyszłych kart REST, gRPC, TCP, komputerów stacjonarnych lub sieciowych, nawet jeśli nie ma dla nich polecenia Hamlib.
Aktualny stan i pobieranie
Projekt jest w fazie aktywnego wczesnego rozwoju - architektonicznego i funkcjonalnego „pionowego wycinka” dla Yaesu FTDX10 są gotowe, ale publiczne API nie jest jeszcze stabilne. FTDX10 jest pierwszym wspieranym i fizycznie przetestowanym transceiverem, z pokryciem identyfikacji, częstotliwości VFO A/B, trybów pracy, splitu, CAT PTT, filtrów, wzmocnienia AF/RF, potlačovača šumu, RIT/XIT, S-metra a ďalších meračov. Súčasne prebieha aj počiatočná podpora rodiny Elecraft K3/K3S/KX3/KX2, zaimplementowana zgodnie z oficjalną dokumentacją producenta, z podstawową warstwą zweryfikowaną na fizycznym K3S.
| Parametr | Wartość |
|---|---|
| Język i platforma | C#, .NET 8 |
| Licencja | GNU AGPL-3.0-only |
| Obsługiwane radia | Yaesu FTDX10 (fizycznie testowane), Elecraft K3S/K3/KX3/KX2 (wczesna faza) |
| Liczba testów automatycznych | 137 |
| Domyślny port adaptera rigctld | 127.0.0.1:4532 |
Kod źródłowy, dokumentacja i instrukcje budowy są dostępne w repozytorium DeXTeRGT/Rig2CastLib na GitHubie. Budowa wymaga .NET 8 SDK i działa na Windows i Linux; do pracy bez fizycznego radia dołączony jest także symulator FTDX10. Autor otwarcie wskazuje, że znaczna część kodu, testów i dokumentacji powstała przy pomocy AI pod nadzorem człowieka - wymagania, kierunki architektoniczne, decyzje dotyczące bezpieczeństwa oraz ostateczne decyzje techniczne pozostają pod kontrolą właściciela projektu, a wygenerowany kod przechodzi ten sam proces kontroli, kompilacji, testowania i weryfikacji w stosunku do fizycznego radia, co każdy inny wkład.
