Elecraft K3: discontinued, K3/0: discontinued…
Avagy hogyan távvezéreljünk meglévő K3 twin rendszert K3/0 nélkül.
Az alapoktól mondom, sokan nyilván ismeritek; a K3/0 mini az az eszköz – bár ezt a funkciót egy „teljes” K3 is betöltheti -, ami kinézetre csak egy K3-előlap kicsi, KX3-szerű dobozban, és a K3 rádiók távkezelésére való. Ezt „twin” módnak vagy felállásnak szokták hívni – más gyártó is készít ilyen párokat különböző minőségben hasonló elnevezéssel.
A K3/0-t a rádió tervezésével együtt kellett, hogy megálmodják, mivel az „előlapnak” és a rádiónak közös a firmware-e… ami nyilván érzékeli, hogy melyik hardware-ben kell dolgoznia. Nem a CAT-kommunikációra épít, ami meglehetősen elavult és nehézkes, hanem van egy saját parancskészlete, pl. a CAT-ben nem szereplő Q… és Y… parancsok, de biztosan akad még. Ez szintén nem látszik egy fejlett protokollnak, csak a mórickás „betűket és számokat küldök ide-oda” nem hibajavított, adóvevőnél szerintem veszélyes megoldást használja, de gyors még a normál, 38K4-es sebességgel is, tényleg olyan, mintha a fizikai rádió előtt ülne az ember.
A rádió és a K3/0 előlapján nem használnak mindenre rotary encoder-eket, így a rádió potméterei afféle alapállapotot jelentenek az összekapcsolódás után, de más egyszerűsítés nem rémlik, a kijelzőjük is ugyanúgy működik szinkronban. A távkezeléshez persze kell valamilyen eszköz, ami soros kommunikációt biztosít és a hangot is átviszi. Ha a RemoteRig RRC-1258 rádió felőli dobozkáját és a kliensnél egy másik ilyen dobozkát használunk erre a célra (amin nagyjából csak egy elkey-sebességet állító potméter van pluszban), akkor annak a soros vonal-TCP/IP átalakítói töltik be az egyik funkciót és a hangfrekit a beépített, valószínűleg szabványos VoIP/SIP egységek viszik át, valamint a CAT vezérlés ezektől teljesen függetlenül közlekedik egy másik kihosszabbított soros vonalon. És igazán kicsik a késleltetések szemben az alap PC-s megoldásokkal, valamint könnyű üzembe helyezni az egészet.
Miért is mesélem mindezt? Mivel a fél világ K3-at használ távvezérelt, remote rádiónak meg egyébként is, és talán olvastátok, hogy a K3-at nem gyártják többé, valamint a tartozékait sem. Kitettek ugyan egy igényfelmérő lapot, de az semmire sem garancia. Helyette a K4 következik kb. másfélszeres áron, ami persze ismét azt jelenti, hogy egy cégnél egy idő után csak magasabb kategóriájú eszközt lehet kapni valami helyett. Ilyen a haladás… a K4 ismét nagy dobásnak tűnik, ami a rádiórészét illeti, de a használhatóság ma már a szoftvereken is legalább annyira múlik.
Még csak nem is az ár a fő probléma, hogy a meglevő K3-as rendszert drága leváltani K4-re, ha tönkremegy és esetleg nem javítható, hanem az, hogy nem megoldás, mert Elecrafték kijelentették – hiába van egy biztató TCP/IP csatlakozó a K4 hátulján -, hogy távvezérlés talán egyszer lesz a K4-hez, de egyelőre nem foglalkoznak vele. Egy K4/0 szóba sem került… Biztosan vannak okai, hiszen egy direkt konverziós rádióhoz a képességei miatt teljesen másfajta távkezelő hardver és szoftver szükséges, de máris olvastam olyanról, aki kifejezetten emiatt mondta le a rendelését és küldte vissza az előleget a K4-re – nehéz az élet…
És akkor a konkrét történet a HA-DX hetéről, amit el szeretnék mondani. Nemrég a RemoteRig RRC dobozkákat és a K3/0-kat használtuk versenyzéshez, a K3 eléréséhez, ahogy eddig is. A már megvásárolt hardverekkel nem is volt gond, de az új embereknél, aki én voltam, valahogy ki kellett alakítani a munkahelyet. Ennek az is akadálya, ha nincs valakinek RRC dobozkája, mivel a szoftveres klienst is annyira drágán adják (kivéve Androidra), hogy akkor már inkább rendelni kell egy RRC-t, de az még inkább gond, ha az amúgy is komoly összegekbe kerülő K3/0-t kapni sem lehet. A használtakat is elkapkodják, ha néha megjelenik egy-egy, azok is a tengerentúlon, meg amúgy is kissé hajmeresztőnek számít errefelé az ára, egy egyszerűbb új rádiót meg lehet venni belőle, mire ideér.
Mit lehet ilyenkor tenni? Emulálni, szimulálni, szoftverekkel kínlódni. Az első probléma, hogy ha egy ilyen távkezelő rendszer „K3 twin” beállításban működik, akkor az az ember, akinek nincs K3/0-ja, be sem tudja kapcsolni a távoli rádiót. Mint kiderült, ez egyébként az RRC-k hatásköre, tehát a lokális RRC-t kell meggyőzni-átverni, hogy rá van kötve egy K3/0 és bekapcsoltuk, az indítja a kapcsolatot a távoli RRC felé stb….
Ehhez vissza kellett fejtenem egy kicsit a K3/0 kommunikációját, mivel, ha nem mondtam volna, a CAT parancsokkal ellentétben az nem publikus. Természetesen kerestem előtte szoftvert, amit mások írtak emulálni a K3/0-t, de egyet találtam, annak is csak a nyoma van meg, évekkel ezelőtt bezárt az a webhely. Mindenesetre nem tűnt lehetetlennek.
Sikerült a mutatvány; a lokális RRC egyik portját felkonfiguráltam és rákötöttem a PC-re és egy RealTerm nevű terminált indítottam el, ami ha kell, ha nem, küldte a bekapcsolt állapotot jelző „választ” az RRC dobozkának, különben egy-két másodperc múlva leállt minden, a K3 kikapcsolt. Elvileg csak kérdésre kellett volna küldenie a programnak a dobozka felé ezeket a válaszokat, de nem volt idő programot írni, a RealTerm-ben végtelenítettem a megfelelő pár karakter küldését pár száz millisec-enként…
Tehát a rádió végre bekapcsolódott a távolban és úgy is maradt, a SIP elindult, hallottam a rádió hangját távolról és a CAT vezérlés is használhatóvá vált. Itt volt még egy kis gond, nem volt otthon több soros-RS-232 átalakítóm, de az RRC-ben szerencsére van egy négyportos USB hub is, így a többi soros vonal azon át jutott be a PC-be, miután a dobozkát sikerült felkonfigurálnom.
Ezek után az a probléma következett, hogy a CAT vezérlést meg kellett osztani a logger program, N1MM+ és egy K3-hoz való vezérlőprogram közt. Tehát nem SDR-program, inkább amolyan commander kellett, amivel a K3 távkezelhető a CAT csatornáján át, hogy pl. S&P-ben (Search and Pound) egyáltalán frekit lehessen változtatni.
Ilyen, egyébként a legstabilabb és leguniverzálisabb program a DXLab Commandere, aminek az a szépséghibája, hogy alapból nincsenek rajta kezelőszervek, fel kell konfigurálni, gyakorlatilag megírni a gombokhoz tartozó CAT parancsokat. 🙂 Előre elkészített config fájlt nem találtam, ami lelombozó, és rövid is volt az idő, így végül a K3-hoz készült-ajánlott Win4K3Suite-et használtam. Hát az sem egy robusztus, jól megírt rádióamatőr szoftver, de azért kicsit kínlódva működött.
A soros vonalak szétosztásához Kernel-drivert tartalmazó szoftver kellett, szerencsére létezik ilyen ingyen is és aláírt driverrel, ami nagy dolog mostanában – nem kellett a teszt módot bekapcsolni a Windows-on -, bár érdekes módon sok évvel ezelőtti a szoftver, és még érdekesebb módon tökéletesen működik, semmi kékhalál meg ilyenek – com0com a neve. Ezt is nagy sietség közben találtam, nyilván létezik másféle is.
Először elég nehéz bánni vele, aztán írtam rá cmd fájlt, hogy ne kelljen mindig kézzel felépíteni a soros vonal-párt – az ingyenes verzió restart után újra beállítandó. A lényeg, hogy ha egy ilyen párt hozzáadok a Windows-hoz, akkor azok nemcsak pl. a COM9, COM10 néven elérhetők, hanem még egy device-név alatt megnyithatók darabonként. Ez teszi lehetővé, hogy azt a soros vonalat ehhez a párhoz lehessen csatlakoztatni, ami a rádió felé megy, ill. onnan hozza a CAT-válaszokat. A létrehozott COM portokra pedig rá lehet ültetni a loggert és a rádióvezérlő programot.
Volt még egy kis küzdelem, hogy melyik irányból merre mehetnek vagy nem mehetnek az adatok a soros vonalakon (a két programot el kellett választani egymástól), ill. hogy a baudrate-et stb. beállításokar továbbítsák-e ezek a virtuális portok egymás közt vagy sem stb., de végül összeállt.
Természetesen vannak olyan programok, amik másként oldják meg a helyzetet, hogy ne kelljen a fenti erőfeszítés, de fizikai K3/0 nélkül nem igazán lehetett használni őket.
Szóval ettől kezdve megvolt a két program, alattuk a com0com által kezelt soros vonalak, onnan mentek az összeömlesztett kérések az RRC-ken át a K3 CAT portjáig – miközben valódi K3/0 nem volt nálam, csak az említett RealTerm program, ami továbbra is küldte helyette a „be vagyok kapcsolva” válaszokat.
A CAT két program által egyszerre történő használata azt eredményezte, hogy időnként hol az N1MM mutatott rossz sávot, hol a Win4K3Suite-on ment el a kijelzés egy kicsit – mégiscsak egy lassú porton küldözgette pár száz millisec-onként a státuszlekérdezéseit két program közösen… Csoda, hogy működtek, de nem volt fennakadás – néha kicsit várni kellett, de kezelhető volt a rádió is.
Ja, és még azt is meg kellett oldani, hogy egy újabb COM porton a CW billentyűzés is menjen a loggerből… át kellett irányítani a CAT-ről egy külön portra a programban. Szerencsére ez is működik USB-n (a virtuális handshake lábakkal), csak újabb konfigurációs lépéseket jelentett az RRC webfelületén.
Beleszámítva az RRC-k tanulmányozását is, a helyzet megoldásához kellett vagy két nap… Hát így sikerült nemrég RRC-vel, de K3/0 nélkül a meglevő rendszerhez illeszkedni és összehozni a távkezelést.
Az előző témához, a távvezérléshez még azt tenném hozzá, hogy említettem a problémát, mikor két program kommunikál CAT-en egy rádióval egy kettéosztott soros vonalon keresztül.
Ez egy korrektnek nem nevezhető, konkrétan agyrém szükségmegoldás, mivel mindkét program látja a rádió válaszait a saját és a másik program kéréseire is. Ilyen az állapotlekérdezés, amikor például a VFO frekvenciáját tudakolja meg egy program a rádiótól.
A fentiek megduplázzák a lekérdezések számát, amire programonként pár száz millisecundumonként kerül sor – némelyik rádióamatőr programban állítható a gyakoriságuk, némelyikben nem. Az egész távkezelő program fürgesége ezen múlik, úgyhogy túlságosan lassúra nem lehet venni, már másodpercesre sem.
Mivel a CAT kommunikáció amúgy is az elég lassú soros vonali kommunikációs csatornákon szokott történni, még ha soros-USB átalakító is van közben, ill. néhány rádiónál tényleg eleve USB csatlakozó van, de valószínűleg egy belső soros-USB átalakító végén, ez mindenképpen oda vezet, hogy a programok tévednek, összeakadnak, legalábbis ami státuszlekérdezéseket illeti. A CAT protokollal működő távvezérlés azért ezt szerencsére többé-kevésbé túléli – a parancsküldések némi várakozástól eltekintve teljesen stabilak voltak.
Hogyan lehet ezt a helyzetet felszámolni? Első körben úgy, hogy létre sem hozzuk – a „K3 twin” megoldásnál nincs meg ez a probléma, mivel rádióvezérlő programra nincs is szükség, azt a fizikai kezelőszerveket biztosító K3/0 (mini) valósítja meg. Létezhet más megoldás is az ismert rádióamatőr programokban (például amik többnyire nemcsak rádióvezérlésre alkalmasak, hanem inkább digitális üzemmódokat valósítanak meg), de egyelőre nem látom át.
Szoftveresen pedig készíthetünk egy virtuális rádiót, ami csak a memóriában él, a számítógépen belül, ahol a logger és a K3-at kezelő szoftver is fut. A virtuális rádiót tartalmazó program ugyanúgy soros vonalon, CAT-en kérdezi le a valóságos rádiótól a VFO állapotát és más fontos beállításokat, de a logprogramnak és a rádióvezérlő programnak ő fog felelgetni, mikor azok meg akarják tudni az aktuális frekvenciát és más beállításokat. Ez azt jelenti, hogy megszüntettük a dupla lekérdezéseket a távoli rádió és a mi gépünk közt, a virtuális rádiót tartalmazó szoftver végzi – intelligensen. Nyilván ez is csak virtuális soros portok segítségével fog menni, hiszen a logprogram és a rádióvezérlő program is csak soros vonalat képes megnyitni.
Nem akarom a képbe a HAMLib programcsomagot behozni, csak megemlítem, hogy elvileg azért lehet variálni és eleve TCP/IP-re tenni a CAT vezérlést, de egyelőre a távvezérlésnek az állomáson levő oldalán nem akartam változtatni.
Ha mindez megvan, akkor is akad még egy-két buktató, például hogy melyik programnak milyen beállításokhoz hagyunk hozzáférést, nehogy egymás ellen dolgozzanak vagy az egyik felülírja a másik által beállított valamilyen kritikus tulajdonságát a rádiónak, pl. az adóteljesítményt, de ez megoldható.
Virtuális rádiót megvalósító szoftver is létezik a világban, mint annyi minden, talán többféle is – én egyet láttam, az LP-Bridge-et. Elég komolynak tűnik, bele van építve a virtuális portok létrehozása, ami nem kis dolog, de távoli rádióval képtelen voltam életre lehelni, nem akart a tökéletesen működő soros vonalon a K3-hoz kapcsolódni. Nem próbáltam megfejteni, miért.
A kép csak egy illusztráció a WEB-ről, de az LP-Bridge szerepel benne:
73 ….. Tibor
|
