Przypadek 1: tylko OmniRig

[artykuł nadrzędny: Konfiguracja]

Analiza możliwości wysyłania danych do portu szeregowego w konfiguracji z bardzo popularnym rozwiązaniem – OmniRIG.

Poprawnie skonfigurowany OmniRIG:

 – od razu może być wykorzystany przez aplikacje, które oferują możliwość podłączenia się do TRX poprzez OmniRIG.
Do sprawdzenia poprawności polecam OmniRIG Client – prosty programik, dostępny na stronie http://www.dxatlas.com/ w Omnirig, w sekcji DOWNLOADS / TOOLS.
Jeżeli wszystko będzie ok z konfiguracją, to w/w Client pokaże nam częstotliwości radia i pojawiające się Events (zdarzenia) generowane przez OmniRIG API:

W uproszczeniu – jeżeli coś się tu dzieje, to znaczy, że OmniRIG działa 😉

Wracając do rozważań – mamy taką sytuację:

czyli – TRX łączy się poprzez USB z komputerem; sterowniki USB2UART udostępniają nam port COM6, z którego korzysta OmniRIG. Wszystkie programy (App x), posiadające opcję OmniRIG’a bez problemu, poprzez programowe API, mają zapewnioną łączność z naszym TRX.
COM7 jest dostępny tylko dla jednej aplikacji, więc w w/w przypadku skorzysta z niego tylko App 3


OK, a co z wysyłaniem komend CAT bezpośrednio do portu COM6?

W konfiguracji tylko z OmniRIG nie mam możliwości bezpośredniego wysyłania komend CAT do portu COM6 (ścieżka CAT (App to TRX) na rysunku powyżej).
Port COM6 jest non stop zajęty, ponieważ OmniRIG utrzymuje ten port na wyłączność dla siebie, i wciąż odpytuje radio o wybrane parametry (dzieje się to z częstotliwością określoną w konfiguracji OmniRIG w sekcji Poll int [ms]  – u mnie jest to co 200 ms)

Dla programistów w rozpatrywanym przypadku zostaje tylko OmniRIG API.

Ciekawostka:
Lista komend CAT dla radia Yaesu FTdx 3000 to ok. 100 pozycji
Jeżeli dorzucimy do tego fakt, że poprzez komendy CAT możemy ustawiać praktycznie każdy ze 196 parametrów z MENU transceivera FTdx3000, chęć wysyłania „własnych” komend CAT, w dowolnej chwili, do radia jest bardzo kusząca.

Następne: OmniRIG + VSPE