Založil jsem toto vlákno jako obecnou diskusi o -L -R u nás.
OK1OGA-L jsem přestěhoval z 145.300 na pražský 70cm převaděč, známý jako OK0BN. Omlouvám se za drobné zmatky, vzhledem k problémům s nájmy jsem musel předělat koncesi oficiálně jsou jak 2m tak 70cm převaděče OK0N. Jelikož je to zažité mezi lidmi jako OK0BN, tak to nikomu moc nevyvracím. Aby těch zmatků nebylo málo, při návštěvě převaděče minulý rok jsem si popletl EPROMky a omylem jsem tam strčil tu se značkou OK0BNA. Tak že OK0BN je doopravdy OK0N, dává značku OK0BNA a je na něm echolink OK1OGA-L 😆 Jakmile se k tomu dostanu, pokusím se to dát do pořádku... ale myslím, že je důležité, že to funguje. Jinak kmitočet je 438.950 -7.6MHz, CTCSS 79,7Hz. Echolinkové rádio jede dupexem, ovládání není přes VOX, ale jako detekce přítomnosti CTCSS. Jelikož převaděč produkuje CTCSS jen když je na jeho vstupu užitečný signál, Echolink odpadne i když je ještě na převaděči nosná. Dekodér DTMF je externí. Jo abych nezapomněl, shození echolinku je pomocí *# , nikoli jen # jak je defautl.
Milane, jeste kdyby tak ty HIPy nevysilaly CTCSS pri rogeru, bylo by vse tak snadne.. 🙁
A čemu to vadí? Aspoň je na druhý straně poznat, že protistanice už vodklíčovala...
Stávalo se, že OGA-L někdy (tak 5% případů) zaklíčovaná do internetu i když ji zmizel příchozí signál. (je v plné náloži, po RS232 je DTMF dekodér, DCD je připojeno na výstup CTCSS modulu, DTR ovládá PTT, žádné VOXy....) Jelikož to dělalo i po vytažení RS232 pojal jsem podezření na bug v SW... po delším zkoumáním jsem přišel na to, že je to způsobené zaškrtnutím "Open in Duplex" v menu Audio. Toto jsem zaškrtnul v domnění že je to pro aplikace, kdy člověk používá duplexní rádio (to co tu mám dokáže přijímat i když vysílá, výhoda je, že kdy nějaký ťululum z Echolinku zaklíčuje, můžu ho shodit) ale po přečtení Helpu jsem se dověděl, že je to pro vyřešení nějakých problémů ohledně soundkarty a ovladačů. Tak že pozor na toto toto nastavení! ❗
Mám dobrou zprávu pro uživatele HIP2000. Začíná se pracovat na odstranění problémů s výpadkem CTCSS mezi odklíčováním (absencí užitečného signálu) stanice na převaděči a vysláním rogerpípu. Zároveň se vyřeší problém kdy mobilní stanice, když padá chvilkově pod SQL způsobuje krátkodobé výpadky CTCSS na výstupu převaděče. Než protistanice CTCSS znovu zdetetekovala, výpadky byly mnohem delší, než kdyby se používalo COR.
Jestli nedojde k nějakým komplikacím, řešení bude následovné:
1. Bude přidán SWITCH pro povolení/zakázání vysílání CTCSS při rogerpípu.
2. Jelikož mnoho uživatelů chce rogerpíp s CTCSS bude přidána časová konstanta která bude definovat, jak dlouho má být přítomen CTCSS po ztrátě užitečného signálu na vstupu převaděče. Tím se vyřeší
a) problém s mizením CTCSS na výstupu při mobilním provozu
b) když se nastaví tento čas tak dlouhý, aby překlenul "gap" mezi odklíčováním a vysláním CTCSS kvůli rogerpípu bude se bez přerušení vysílat až do odpípnutí, čímž se zamezí zacyklení v případě propojení dvou HIP přes Echolink, resp. nebude nutné ladit antitrip.
Oba tyto parametry bude možné nastavovat dálkově.
