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

OK1MHK
Příspěvky: 122
Registrován: pát 10. črc 2009 7:21:39
Bydliště: JN69PJ

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

Příspěvek od OK1MHK » pát 16. zář 2011 14:41:32

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
Příspěvky: 1077
Registrován: pát 06. bře 2009 10:24:01
Jméno: Milan
Bydliště: JN79TX
Kontaktovat uživatele:

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

Příspěvek od OK1MX » pát 16. zář 2011 16:46:34

OK1MHK píše: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
Příspěvky: 3
Registrován: pát 16. zář 2011 22:13:40
Jméno: Karel

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

Příspěvek od ok1uhu » pát 16. zář 2011 22:26:33

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.
Uživatelský avatar
OK1COM
Příspěvky: 306
Registrován: ned 08. bře 2009 3:06:31
Bydliště: Praha-Strašnice
Kontaktovat uživatele:

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

Příspěvek od OK1COM » sob 17. zář 2011 13:13:06

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
Příspěvky: 1077
Registrován: pát 06. bře 2009 10:24:01
Jméno: Milan
Bydliště: JN79TX
Kontaktovat uživatele:

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

Příspěvek od OK1MX » sob 17. zář 2011 17:45:24

OK1COM píše: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
Příspěvky: 122
Registrován: pát 10. črc 2009 7:21:39
Bydliště: JN69PJ

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

Příspěvek od OK1MHK » sob 17. zář 2011 19:55:08

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
Příspěvky: 1077
Registrován: pát 06. bře 2009 10:24:01
Jméno: Milan
Bydliště: JN79TX
Kontaktovat uživatele:

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

Příspěvek od OK1MX » sob 17. zář 2011 22:20:03

OK1MHK píše: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
Příspěvky: 3
Registrován: pát 16. zář 2011 22:13:40
Jméno: Karel

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

Příspěvek od ok1uhu » pon 19. zář 2011 2:22:04

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
Příspěvky: 1077
Registrován: pát 06. bře 2009 10:24:01
Jméno: Milan
Bydliště: JN79TX
Kontaktovat uživatele:

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

Příspěvek od OK1MX » pon 19. zář 2011 8:58:45

ok1uhu píše: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
Příspěvky: 122
Registrován: pát 10. črc 2009 7:21:39
Bydliště: JN69PJ

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

Příspěvek od OK1MHK » úte 20. zář 2011 8:29:13

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