Během opravy transcieveru TRX210 Sněžka, kterou mi do péče svěřil Luďek OK2KZ, jsem se docela zapotil s diagnostikou a opravou pro mne zajímavé závady. Jelikož jsem na internetu nenašel žádnou zmínku o podobném problému, rozhodl jsem se svou anabázi sepsat na svůj blog. Zaznamenal jsem jen povzdechy nad nestabilním VCO, což by mohlo s mou závadou a její příčinou korelovat. Zasvěcenému čtenáři se mohou některé mé diagnostické postupy a kroky zdát poněkud nestandardní - rád bych zde uvedl, že jsem samouk a dost narážím hlavně na chybějící zkušenosti. Zde jsem jich opět několik cenných získal, za což jsem rád a což je důvodem, proč se touto oblastí zabývám. Ale pojďme k samotné závadě.

Při oživování transcieveru jsem si na SSB příjmu všiml, že se zcela náhodně jakoby rozevírá propustné pásmo druhé mezifrekvence. Díky obsaženému krystalovému filtru by mělo být toto pásmo široké něco kolem 2.5kHz. Pokud jsem se však naladil nad přijímaný signál právě lehce za hranu filtru a nechal trx v klidu, v nepravidelných intervalech na nepravidelnou dobu pronikal signál na demodulátor. Stejně tak, pokud jsem byl naladěn do propustného pásma, přijímaný demodulovaný tón se frekvenčně změnil. Takovéto příznaky samotné indikují ujíždějící VCO, zde mne však zmátl, a dlouho ve svém pátrání vedl jiným směrem, ještě jeden příznak - pokud totiž k závadě došlo, ladění trxu v rozsahu 10kHz nemělo žádný vliv, tón se neměnil, jen zobrazovaná frekvence se měnila jak měla. Po překročení 10kHz (resp. po změně hodnoty desítek kHz na stupnici) závada jakoby záhadně zmizela a do dalšího výskytu trx přijímal zcela normálně. O to vypečenější bylo, že se závada často projevovala jako studený spoj - občas po poklepu na stůl nebo trx zmizela, občas jsem mohl bouchat co chtěl a nic se neměnilo. Jen samotné odhalení všech těchto projevů a návazností mi zabralo spoustu času i během samotné opravy, což postupně zpřesňovalo mé pátrání. Proto mé první kroky mohou vypadat poněkud nelogicky....

Kontrolou spojů v části druhé MF jsem nic studeného neodhalil. Pohledem do schématu jsem pojal podezření na bypass cestu pro FM modulaci, která obchází krystalový filtr SSB. Proměřil jsem konkrétní spínací diody a napětí na nich, což bylo obtížnější než se zdá díky náhodnému a časově nestálému výskytu závady. Ani zde jsem však neobjevil problém.

V dalším kroku jsem začal podezřívat a prověřovat obvody AVC. Ačkoliv by chyba v těchto obvodech zřejmě nemohla způsobit takovéto divné chování, trochu jsem zde propadl víře v duchařinu, modulaci tranzistorů špatně filtrovaným ovládacím napětím, pronikání VF všude možně a podobným špekům, co mne napadly. Po mnoha měřeních a pokusech jsem finálním odpojením ovládacího napětí AVC a jeho simulaci z externího zdroje musel konstatovat, že ani zde není chyba.

Následně jsem pojal podezření v mechanické poškození samotného filtru. Zde by se mi hodila nějaká zkušenost, zda je takovéto poškození vůbec možné, kdy se šířka přenášeného pásma filtru dokáže díky mechanické závadě takto měnit. Filtr jsem vytáhnul z desky a na generátoru a spektráku jej orientačně změřil. Bohužel, fungoval bezvadně, i toto byla slepá cesta.

Přesunul jsem se do části před filtrem do sekce směšovače a začal podezřívat, že mi ujíždní některý z kmitočtů. Jelikož "hlavní" VCO je v podstatě digitálně řízené a dotahované PLL smyčkou, a jelikož ledka detekující výpadek závěsu nic podezřelého neindikovala, zaměřil jsem se na oscilátor 12.4MHz. Kontrolou a měřením jsem musel konstatovat, že je sice o pár desítek Hz mimo, ale stabilní.

Poladil jsem symetrii směšovače a začal rozkrývat obvody hlavního VCO 122.6MHz. Měření kmitočtu VCO konečně odhalilo, že v momentě výskytu závady opravdu frekvence uhne. Dále se mi potvrdilo, že během trvání poruchy ujetá frekvence zůstávala stejná, i když jsem otáčel ladícím prvkem, ačkoliv na dispeji se změna frekvence projevovala. Až po překročení zmiňovaných 10kHz se výstup VCO změnil. Na změnu v menších řádech než 10kHz VCO většinou nereagovalo. Toto chování spolu se studiem způsobu zapojení syntézy mne navedlo směrem k obvodům pomocného VCXO 15.2MHz, které je rozlaďováno právě na základě změn v nejnižších řádech jednotek kHz a níže.

Zaměřil jsem své pátrání do části desky obsahující tyto obvody. Po orientační kontrole 10kHz reference jsem se přesunul k VXCO. Samotný oscilátor je řízen výstupem IO51 (MAA741), který tvoří ovládací napětí na základě napěťové reference IO50 (MAA723) a "změnou zesílení" realizovanou pomocí dvou D/A převodníků - podle mě docela pěkně vymyšlené. Měřením jsem zjistil, že 15.2MHz signál opravdu ujíždí při poruše a je příčinou ujíždění celého VCO. Otázkou zůstávalo, proč se tomu tak děje.

Další mé podezření logicky padlo na napěťovou referenci s IO50 (MAA723). Na výstupu jsem naměřil 9.4V, zarazilo mne však, že i malé zatížení výstupu reference 1MΩ vstupem osciloskopu způsobí znatelný pokles referenčního napětí. Také jsem si ověřil, že při výskytu poruchy se spolu se změnou ovládacího napětí změní i napětí reference. Začal jsem jásat, že problém je zde - ukázalo se však, že předčasně.

Po výměně IO50 jsem na jeho výstupu naměřil "tvrdých" 10V - zcela jistě tento IO pomalu odcházel a na výskyt poruchy měl vliv - porucha však přetrvávala. Po lehkém intermezzu se zkoumáním stavu a měřením trimrů nastavujících celý obvod (zejména P4 - tomuto typu nevěřím, uhnívají mu nohy a blbě se s ním kroutí) jsem opět musel konstatovat, že zde jádro pudla neleží. Výměnou reference jsem dosáhl jen menšího počtu výskytu poruchy, což teda ještě více ztížilo další pátrání. Naštěstí jsem byl již cíli na dohled, i když jsem to ještě nevěděl.

Pátrání se přesunulo na horní stranu desky, k D/A převodníkům. Jedná se vlastně o dva digitální spínače na obvodech MHB4066, které na základě BCD stavu vstupu spínají směrem k zemi paralelní sadu rezistorů, čímž se nastavuje dělič na vstupu dříve zmiňovaného IO51. Jeden převodník řeší změny pro krok 1kHz, druhý pak změny pro krok 100Hz. Zde jsem zjistil, co už jsem předpokládal (nebo spíše v co jsem doufal), že výstupy těchto obvodů chaoticky spínají v neurčitých okamžicích na neurčitě dlouhou dobu. Tím vlastně ovlivňují řídící napětí pro VCXO, který se díky tomu náhodně přelaďuje. Proč tomu tak je jsem zjistil záhy, měřením na vstupech těchto dvou IO (IO34 a IO35). Napětí na vstupech totiž kolísalo kolem 3.7V, což je zřejmě kritická rozhodovací úroveň pro samotné spínače. Vstupy těchto převodníků jsou ovládány ze dvou multiplexerů IO25 a IO26 (MH74157). Zajímavé je, že napájecí napětí na šínách celé desky i samotných MUXech je stabilních 5V, přesto po zapnutí studeného trxu je na výstupech těchto MUXů 4.7V, které zahřátím postupně klesá (během cca minuty) na uvedenou hraniční úroveň, kde se pak již drží. Tato úroveň zřejmě stále postačuje pro paralelně připojené převodníky BCD/7segment, které zobrazují hodnoty na display, ale pro samotné spínače je to už málo.

Nové IO tohoto typu mají výstupy zřejmě dostatečně "tvrdé", stárnutím o tuto vlastnost přicházejí a nejsou schopny dostatečně napěťově vybudit výstupní sběrnici (s podobným problémem ujetých parametrů jsem se potýkal už dříve při opravě dekodérů ladícího knoflíku). Je i možné, že vstupy připojených IO samotnou sběrnici více zatěžují než "za mlada" a tahají napětí k zemi. Ač tak či tak, rozhodl jsem se podepřít výstupy MUXů pull-upovými rezistory, což je dle mého dobrým zvykem (a netuším, proč toto není již z výroby). Zkusmo jsem zvolil hodnotu 4k7 a jak se zdá, tato úprava vyřešila celou závadu. Nezdá se, že by některý z dotčených IO protestoval a třeba více topil. Může být, že některý z IO na inkriminované sběrnici je "načatý" a moje řešení mu přivodí dřívější konec, je však celkem jedno, zda ty IO vyměním teď, nebo až (pokud) odejdou. Teď už se o nich ví...

Je docela možné, že nestabilita VCO u tohoto typu transcieveru, na kterou si uživatelé stěžují, může mít stejnou příčinu. Pokud by totiž došlo k uvedenému stavu jen na sběrnici pro 100Hz kroky, pak celkový drift VCO bude v rozmezí 100Hz - 1kHz, což lze neoprávněně přičítat i jiným příčinám - např. teplotní drift. Proto, díky nynějším zkušenostem, bych při hledání příčiny driftujícího VCO u tohoto typu trxu doporučil zkontrolovat napěťový stav uvedené sběrnice.

Celá popsaná anabáze mi zabrala zhruba tři týdny volného času. Zase jsem se posunul o kousek dál ve svých znalostech a zkušenostech - proto to dělám. Rozhodl jsem se sepsat tento článek pro případ, že by někdo řešil stejný problém a neměl tolik elánu a prostoru. Budu také rád, pokud mi případní zkušenější kolegové - čtenáři dají zpětnou vazbu či vyspílají za nějaké mé pochybení při této opravě.

Poděkovat bych chtěl kolegům OK2KKW, OK1HGA a OM6BB, kteří na svých stránkách sdílejí schémata, popisy a další info k transcieveru, bez kterých bych se jen těžko probíjel.

Méně ▲