K zamyšlení mě dovedla diskuse na pásmu, kde se ve jméhu subj. vedla diskuse.
Protože ve volných chvílích dělám na úpravě modulu k použití na převaděč není mi tahle otázka lhostejná.
Tedy když shrnu plusy pro DSQ:
1) Možnost použití TRXu bez CTCSS TX ( existuje dnes takový ?? )
2) V neznámém prostředí možnost práce na převaděči bez CTCSS TX ( v době internetu a možnosti zaplnit i 200 pamětí v TRXu v klidu doma u PC ...?
Neznalost místního CTCSS lze eliminovat tím, že převaděč bude reagovat na řadu CTCSS subtónů - vyloučeny skupiny těch , které používá sousední RPT v doslechu. Subtónů je dost, otestované to mám, RPT dokáže reagovat na všechny CTCSS tóny, nebo lze jeden až několik "vyloučit"
Jako záloha použít pro "nahození" 1750Hz, info o CTCSS kmitčtu dá identifikace. 1750 Hz má v bnejhorším každý " v hubě"
Mínusy:
1) V době, kdy rušení přeleze přes analogový SQ nutný zásah sysopa. ( nejde obejít, snad jen nějakým propertiálním řešením na bázi signal procesingu )
2) Konstrukčně složitější převaděč. ( Aby to fungovalo dobře je třeba teoreticky 3x SQ : jeden těsně nad hranicí prahové citlivosti RX, nad ním CTCSS SQ a nad ním další analog SQ , který je dobré mít možnost řídit kvůli možnému vzniku rušení. Tohle celé proto, aby po ztrátě signálu ze vstupu RX převaděče tento
" nepšouknul"¨.

Takže co? Má smysl se dnes prasit s DSQ? Používáte někdo TRXy mez možnosti CTCSS TX?

Děkuji za názory.
Honza OK1MHK

Můj osobní názor je, že to dnes už smysl nemá. Jiná situace byla v době, kdy se do stanic musely dokupovat CTCSS moduly, případně kdy ještě existovali HAMové, kteří si stanice dělali.

M.

Jakožto autor řešení DSQ na OK0J pravím ANO. Doplnit DSQ do hardwaru, který uměl jak ASQ, tak, po doplnění dekodéru, PL či DPL, není vůbec žádné "prasení se s tím", ale vcelku jednoduchá záležitost. Kdo nevěří, ať tam běží.

Proč? Absolvoval jsem teď trochu toulání po Evropě, větší část Španělska, Baleáry, Německo a pak překvapivý skok do Holandska. A ono jaksi sehnat aktuální seznam převaděčů v těchto oblastech (a to jde ještě vcelku o civilizaci, jsou horší místa), není v některých případech nic prostého. A tak jsem tu ručku vytáhl jen párkrát, většinou na monitoring služeb a AIR.

Takže - dokud nebude snadno přístupný centralizovaný přehled všech převaděčů ve všech zemích (což jen tak brzo nebude, protože to stojí sádlo a/nebo prachy), považuji rozumně nastavený DSQ za dobré řešení.

Btw., úvaha se 3 squelchi je, samozřejmě, hloupost. Stačí klasický jeden ASQ, kterému jde štelovat práh, a jeden PL/DPL, co je v provozu furt a je nad ASQ prioritní. Dvě diody, kapišto? U ok0j to vychází na cca 0,2uV bez rušení (ASQ), cca 2-5uV s rušením (priorita PL SQ). Takže žádné drama.

Co kdyby prevadec umel reagovat na skupinu CTCSS tonu, ktere by vysilal i na vystupu? Dalo by se to vyuzit na to, ze se muze skupina uzivatelu zavrit pod jeden ton a nemusi poslouchat druhou skupinu (co mel Franta k obedu) nebo nahazovace prevadece. Prevadec by mel jeden verejny CTCSS a pak nekolik "tajnych" skupinovych. Na rucce by pak stacilo nastavit TSQL dle zvolene skupiny.

Co kdyby prevadec umel reagovat na skupinu CTCSS tonu, ktere by vysilal i na vystupu? Dalo by se to vyuzit na to, ze se muze skupina uzivatelu zavrit pod jeden ton a nemusi poslouchat druhou skupinu (co mel Franta k obedu) nebo nahazovace prevadece. Prevadec by mel jeden verejny CTCSS a pak nekolik "tajnych" skupinovych. Na rucce by pak stacilo nastavit TSQL dle zvolene skupiny.

Ono se to lehko řekne ale hůře udělá. Tyhle funkci umí několik typů Zetronů a pár PROFI managerů. Nikde jsem neviděl "home made" řešení dekodéru který by to použitelně dokázal. Není to až taková sranda. Je potřeba:
1. aby ze šumu negeneroval falešnou detekci
2. aby dokázal sprané CTCSS vyhodnotit optimálně do 150 ms
3. aby měl citlivost tak 8-10dB/SINAD
4. aby měl teplotní stabilitu tak 10-50C