only CTCSS, nebo DSQ na převaděči

OK1MHK
Posts: 122
Joined: Fri 10. Jul 2009 7:21:39
Location: JN69PJ
Contact:

only CTCSS, nebo DSQ na převaděči

Post by OK1MHK »

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
ok1mx
Posts: 1077
Joined: Fri 06. Mar 2009 10:24:01
Jméno: Milan
Location: JN79TX
Contact:

Re: only CTCSS, nebo DSQ na převaděči

Post by ok1mx »

OK1MHK wrote: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.
ok1uhu
Posts: 3
Joined: Fri 16. Sep 2011 22:13:40
Jméno: Karel
Contact:

Re: only CTCSS, nebo DSQ na převaděči

Post by ok1uhu »

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.
OK1COM
Posts: 306
Joined: Sun 08. Mar 2009 3:06:31
Location: Praha-Strašnice
Contact:

Re: only CTCSS, nebo DSQ na převaděči

Post by OK1COM »

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.
ok1mx
Posts: 1077
Joined: Fri 06. Mar 2009 10:24:01
Jméno: Milan
Location: JN79TX
Contact:

Re: only CTCSS, nebo DSQ na převaděči

Post by ok1mx »

OK1COM wrote: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
OK1MHK
Posts: 122
Joined: Fri 10. Jul 2009 7:21:39
Location: JN69PJ
Contact:

Re: only CTCSS, nebo DSQ na převaděči

Post by OK1MHK »

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.[/quote]

Tohle řešení po zmizení CTCSS signálu ale " pšoukne" což mě osobně se nelíbí. Je fakt, že takhle funguje 50 procent převaděčů ( HIP to má vychytaný tam to nepšouká) , ale mě osobně se to nelíbí.
Prostě když něco dělám, chci to pořádně. Na druhé straně pokud se objeví rušení tak to stejně pšouká...
ok1mx
Posts: 1077
Joined: Fri 06. Mar 2009 10:24:01
Jméno: Milan
Location: JN79TX
Contact:

Re: only CTCSS, nebo DSQ na převaděči

Post by ok1mx »

OK1MHK wrote: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.

Tohle řešení po zmizení CTCSS signálu ale " pšoukne" což mě osobně se nelíbí. Je fakt, že takhle funguje 50 procent převaděčů ( HIP to má vychytaný tam to nepšouká) , ale mě osobně se to nelíbí.
Prostě když něco dělám, chci to pořádně. Na druhé straně pokud se objeví rušení tak to stejně pšouká...
Aby ASQ fungoval dobře není jen o rozpoznání užitečného signálu či RSSI, ale hlavně o časovačích, kterými se zajišťuje hystereze v různých režimech. Jedna hystereze je pro otevření, jedna pro zavření, dále pak záleží na čase, který uběhl od poslední relace. Když třeba HIP není 5 min. aktivní, musí mít výstup ASQ log. 1 po dobu půl sekundy, tím je zajištěno, že krátkodobé štrejchnutí o ASQ (třeba pulzní rušení) ho nenahodí. Jakmile se převaděč probudí, změní (zmenší) se i nastavení hytereze. Hystereze pro zavření je tam zase kvůli tomu, aby převaděč nepípal i při mírném mobilefektu, kdy se na krátkou dobu padá pod ASQ.
ok1uhu
Posts: 3
Joined: Fri 16. Sep 2011 22:13:40
Jméno: Karel
Contact:

Re: only CTCSS, nebo DSQ na převaděči

Post by ok1uhu »

Mimochodem, jediný rozumný způsob, jak se zbavit pšouknutí, je zpožďovací linka v audiu. Na OK0J taková linka je a chodí to luxusně. Squelch má hysterezi kolem 3-4dB, softwarem řídicího procesoru jsou ignorována ona "štrejchnutí", která byla, zrovna na lokalitě tohoto převaděče, brutálně silná. ASQ má logaritmický detektor a komparátor, dovolující nastavit práh ASQ od 0,2uV do nějakých, pokud se dobře pamatuji, 150uV :)))

Prostě to jde.
ok1mx
Posts: 1077
Joined: Fri 06. Mar 2009 10:24:01
Jméno: Milan
Location: JN79TX
Contact:

Re: only CTCSS, nebo DSQ na převaděči

Post by ok1mx »

ok1uhu wrote:Mimochodem, jediný rozumný způsob, jak se zbavit pšouknutí, je zpožďovací linka v audiu. Na OK0J taková linka je a chodí to luxusně. Squelch má hysterezi kolem 3-4dB, softwarem řídicího procesoru jsou ignorována ona "štrejchnutí", která byla, zrovna na lokalitě tohoto převaděče, brutálně silná. ASQ má logaritmický detektor a komparátor, dovolující nastavit práh ASQ od 0,2uV do nějakých, pokud se dobře pamatuji, 150uV :)))

Prostě to jde.
Souhlasím, jde úplně všechno, je to jen otázkou schopností, času nebo peněz. Ti kteří vymyšlení a realizaci takovéhoto řešení jsou schopni na to nemají čas, nebo se jim nechce, za dlouhý peníz se to dá koupit i hotové. Nebývá nic jiného, než pracovat s duševním , fyzickým potenciálem a objemem peněz, který je k dispozici. Když si to člověk zasadí do souvislosti s tím, že dělat SYSOPA nebo VO je spíš masochistická činnost, kde uživatelé dokážou vezkreze jen kušnit když náhodou něco není ve 100% stavu nelze se divit, že se nikomu nechce dávat si nohu za krk. Pak to obvykle končí dvěma motorolama a zetronem z aukra.

Nicméně s tou zpožďovací linkou to mám vyzkoušené a chodí to docela pěkně. Nevýhoda je, že to zase HW o pár stokorun prodraží.

M.
OK1MHK
Posts: 122
Joined: Fri 10. Jul 2009 7:21:39
Location: JN69PJ
Contact:

Re: only CTCSS, nebo DSQ na převaděči

Post by OK1MHK »

Jak to tedy je ( bylo) řešené u HIPu? Tam to taky nepšouká .... a delay line tam není pokud vím.
Post Reply

Who is online

Users browsing this forum: No registered users and 9 guests