only CTCSS, nebo DSQ na převaděči
only CTCSS, nebo DSQ na převaděči
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
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
Re: only CTCSS, nebo DSQ na převaděči
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.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.
Re: only CTCSS, nebo DSQ na převaděči
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.
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.
Re: only CTCSS, nebo DSQ na převaděči
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.
Re: only CTCSS, nebo DSQ na převaděči
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: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.
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
Re: only CTCSS, nebo DSQ na převaděči
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á...
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á...
Re: only CTCSS, nebo DSQ na převaděči
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.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á...
Re: only CTCSS, nebo DSQ na převaděči
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.
Prostě to jde.
Re: only CTCSS, nebo DSQ na převaděči
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.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.
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.
Re: only CTCSS, nebo DSQ na převaděči
Jak to tedy je ( bylo) řešené u HIPu? Tam to taky nepšouká .... a delay line tam není pokud vím.
Who is online
Users browsing this forum: No registered users and 12 guests