[artykuł nadrzędny: Konfiguracja]
Wysyłanie komend CAT do tego samego portu COM z wielu aplikacji w tym samym czasie staje się możliwe, po zainstalowaniu wspomnianego wcześniej emulatora portów szeregowych – VSPE
Dokumentacja VSPE na stronie twórców.
VSPE jest bardzo rozbudowanym narzędziem do manipulowania portami COM w komputerze. Po szczegóły odsyłam do strony www, a po zainstalowaniu go w komputerze – do przyzwoitego help’a wbudowanego w sam program.
Z radiowego punktu widzenia wykorzystuję opcję Splitter w VSPE, czyli możliwość udostępniania fizycznego portu COM wielu aplikacjom.
Nasz ogólny cel:
Utworzenie takiego portu wirtualnego z opcją splitter jest opisane w pomocy programu.
U mnie wygląda to tak: port COM6 (udostępniany przez sterownik USB2UART), dedykowany do komunikacji CAT, został przy pomocy VSPE przekierowany na wirtualny COM8 w trybie splitter. Konfiguracja tego przekierowania:
Zwróć uwagę na checkbox’y – dla poprawnej pracy jedynie w/w ustawienia dają u mnie oczekiwany efekt.
Ustawienia samego portu (Speed, Parity, Bits – prawe okienko) są tożsame z ustawieniami, które mamy w systemowym Menedżerze urządzeń i w Radiu.
I podobnie z COM7 (to port odpowiedzialny w radiu za kluczowania PTT/CW) – tworzymy przekierowanie typu splitter na COM9:
Ważne: Znowu zwróć uwagę na checkboxy! Dla COM7-COM9 są inne niż dla pary COM6-COM8
Zamykamy okienka konfiguracyjne. Zieloną strzałką (1) inicjujemy przekierowania – w efekcie powinniśmy zobaczyć taki ekran VSPE:
Status (2) – Ready
Informacja o stanie Inicjalizacji (3) – OK
Uwaga: W mojej konfiguracji, w trakcie startu VSPE na krótką chwilę podawany jest sygnał PTT na radio.
Ostrzegałem, jakby co
Jeżeli wszystko jest ok, proponuję zapisać konfigurację VSPE do pliku (File, Save As..) żeby nie konfigurować portów po każdym uruchomieniu programu.
VSPE umożliwia start z plikiem konfiguracyjnych jako parametrem startowym, np. z pliku .cmd (poniżej fragment help):
OK – VSPE działa.
Wracamy do rozważań – schematycznie mamy teraz taką sytuację:
czyli – TRX łączy się poprzez USB z komputerem; sterownik USB2UART udostępnia nam port COM6, który przy pomocy nakładki VSPE przekierowany jest na wirtualny port COM8 (z opcją „wielodostępu”!).
OmniRIG skonfigurowany jest w tym układzie do pracy z portem COM8 (już nie COM6).
Wszystkie programy (na rys. App 1, 2, 3), posiadające opcję OmniRIG’a bez problemu, poprzez programowe API, mają dalej zapewnioną łączność z naszym TRX.
VSPE dba o to, aby port COM8 nie był blokowany tak, jak to się dzieje z klasycznym portem COM, i aby port był dostępny również dla innych aplikacji. I to pomimo tego, że podłączony do COM8 OmniRIG ciągle, jak karabin maszynowy, co 200ms wysyła komendy CAT do TRX’a, a TRX w odpowiedzi na nie wysyła swoje statusy.
Zresztą, sam VSPE daje możliwość pełnego podglądu, co dzieje się na każdym wirtualnym porcie, w szczególności COM8:
co widzimy? Uruchomiony OmniRIG.exe, wysyła do COM8 i dalej do TRX’a komendy CAT: IF;FA;FB;KP;FT;TX; i tak w kółko.
Oznacza to w ludzkim języku mniej więcej:
IF; „podaj mi ogólny status radia”
FA; „podaj mi częstotliość VFO A”
FB; „podaj mi częstotliość VFO B”
KP; „podaj mi częstotliość pitch dla CW”
FT; „podaj mi aktywowane dla nadawania VFO x”
TX; „podaj mi status nadajnika”
w odpowiedzi radio wysyła do komputera ciągi znaków:
widać, że momencie tworzenia tej strony mam w radiu ustawione:
FA014030700; czyli VFO A = 14030700 Hz
FB021076200; czyli VFO B = 21076200 Hz
i np.
KP26; oznacza CW pitch -> 300+26*10Hz = 560Hz
Jako ciekawostka, popularny N1M Logger+ podpięty pod COM8 wysyła troszkę inny „zestaw pytań” do radia:
IF;OI;FA;FB;FT;VS;AG0;
N1MM korzystający z portu COM i komend CAT, robi to samo co OmniRIG – odpytuje radio, i dostaje zwrotnie bardzo podobne odpowiedzi.
Skoro wszystko już fajnie działa, to co możemy teraz zrobić np. ze skryptu AHK?
Po pierwsze, w dalszym ciągu mamy dostępne dla skryptów programowe API z OmniRIG (podobnie jak dla innych aplikacji).
Po drugie – możemy już wysyłać bezpośrednio do wirtualnego portu COM8 dowolną komendę CAT, która zostanie wysłana do naszego TRXa:
Co się dzieje, gdy nasz skrypt wyśle jakieś dane do portu COM8?
No i skąd VSPE będzie wiedział, co z tymi danymi zrobić, i gdzie je dalej wysłać?
Odpowiedź brzmi: VSPE nie wie.
I w związku z tym VSPE rozsyła te dane do wszystkich odbiorów, którzy są aktualnie podpięci pod port COM8 – czerwona ścieżka na schemacie poniżej:
Mamy: Skrypt AHK_1 (lub każda inna aplikacja, korzystająca z tego portu) wysyła dane „CAT data1” do naszego wirtualnego COM8.
VPSE w trybie spliter rozsyła te dane do wszystkich:
– po pierwsze – do TRX, poprzez port COM6 / UART2USB
– po drugie – do OmniRIG
– i do każdej innej aplikacji, która korzystałaby w tym czasie z tego wirtualnego portu COM8
Czy jest to problem? I tak, i nie.
Wszystko zależy od „odporności” danej aplikacji (podpiętej też pod COM8, podobnie jak OmniRIG) na pojawianie się na porcie COM8 danych, których ta aplikacja się nie spodziewa.
Tak jak wcześniej pokazałem, OmniRIG wysyła do portu konkretne komendy CAT: IF; FA; FB; KP; FT; TX; i oczekuje, że w odpowiedzi dostanie ściśle sformatowane dane zwrotne z radia:
Stwierdziłem, że OmniRig ( 1.19 ) nie ma problemu z „obcymi” paczkami danych pojawiającymi się na wirtualnym porcie (wysyłanymi przez np. przez skrypty AHK), i w żadem sposób nie zakłóca to współpracy OmniRIG z aplikacjami, które z niego korzystają. I to jest dobra informacja.
Podsumowując – możemy w tej konfiguracji wysyłać do wirtualnego portu wszelkie komendy CAT przeznaczone dla TRXa (np. ze skryptu AHK), a OmniRIG jak ich nie będzie rozumiał, to je po prostu… zignoruje , a komenda i tak z powodzeniem trafi do radia.
A czy można ODCZYTAĆ skryptem AHK dane, które pojawiają się na wirtualnym COM8?
Generalnie nie ma problemu, żeby odczytywać dane wysyłane przez TRX lub inne aplikacje, „podpięte” pod nasz wirtualny port COM8. Wiąże się to oczywiście ze sporym nakładem programistycznym, bo de facto musielibyśmy sobie napisać takiego mini OmniRIGa, ale w języku AHK… czyli taka programistyczna nieskończona pętla, która na bieżąco (np. co 200ms) monitoruje to, co się dzieje na np. COM8 i analizuje wszystkie dane, wybiera te, które są dla niej, itd.
Powiem tak – gra nie warta świeczki. Najważniejsze dane, które wysyła radio, dostępne są przez proste API z OmniRIG’a.
Następne: VSPE