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

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á...

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.

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.

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.

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

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

Když je tam DSQ, tak je to zapojené v podstatě tak, jak psal Karel UHU, t.j. NF nesquelchované jde do CTCSS modulu který dokáže hledat přítomnost subtónu nezávisle na tom v jakém stavu je ASQ. ASQ u HIPu má dynamicky proměnnou hysterezi. Aktuální hystereze záleží na tom, v jakém konkrétním stavu se převaděč nachází. Pakliže určitou dobu nebyl na vstupu žádný signál, je hystereze velká a je potřeba aby i vstupní signál byl o určité úrovni po určitý čas. Když je třeba stanice s mobilefektem, tak se výrazně zmenší. Toto překonání hystereze z jednoho stavu do druhého udělá i nakopnutí log. 1 od CTCSS modulu. Velmi zjednodušeně řečeno, v režimu dual SQL CTCSS modul přebije zavřený ASQ a jakoby ho přestaví na citlivější nastavení. Všechno je to poladění těch timerů.

Nicméně i HIPy pšoukají jsou li jen pod CTCSS, je to odvislé od toho, jak rychle je schopen modul poslat log. 0 při výpadku subtónu.

Bohužel amatérské TRX veskrze neposílají "reverze burst" což je škoda, protože tím se dá pšoukání krásně eliminovat i bez použití zpožďovací linky. Jinak jeden poznatek z doby kdy jsem ji testoval. Měl jsem dost mizernej CTCSS modul a vyhodnocoval tak 200ms na spodních tóneh. Jakmile jsem ji nastavil na 250ms tak při použití některých TRX, které dokázaly rychle přejít z TX na RX člověk slyšel poslední slabiku toho co povídal... je to dost strašné, protože to evokuje pocit, že s někým dubloval.

Jinak nápad že by převeděč měl reagovat na hromadu (všechny CTCSS) mi nepřijde moc dobrý. Už teď je na převaděčích pusto prázdno, člověk je rád, že když se tam někdo ozve, tak ho může zavolat. Tento princip vyloženě podporuje "skupinkování" amatérů kdy Pepa zásadně mluví jen s Frantou, Jirka pouze s Tondou a Marie nedá nikomu. Jakmile se začnou zavírat ještě pod různé CTCSS, ztratí převaděč totálně svůj smysl, t.j. možnost komunikace mobilních stanic. Laďa přijede z Moravy do Prahy, uslyší hovor, slušně pozdraví, bude chtít zanavigovat či jen popovídat a ani Franta, ani Jirka, ani Pepa, ani Tonda, natož pak Marie se mu neozve... protože ho neuslyší a on těžko bude v autě scannovat jaký že CTCSS má použít.

Jako zajímavá myšlenka mi přijde vyslání telegrafem kmitočtu CTCSS po písknutí 1750 i bez použití subtónu.

Jinak nápad že by převeděč měl reagovat na hromadu (všechny CTCSS) mi nepřijde moc dobrý. Už teď je na převaděčích pusto prázdno, člověk je rád, že když se tam někdo ozve, tak ho může zavolat. Tento princip vyloženě podporuje "skupinkování" amatérů kdy Pepa zásadně mluví jen s Frantou, Jirka pouze s Tondou a Marie nedá nikomu. Jakmile se začnou zavírat ještě pod různé CTCSS, ztratí převaděč totálně svůj smysl, t.j. možnost komunikace mobilních stanic. Laďa přijede z Moravy do Prahy, uslyší hovor, slušně pozdraví, bude chtít zanavigovat či jen popovídat a ani Franta, ani Jirka, ani Pepa, ani Tonda, natož pak Marie se mu neozve... protože ho neuslyší a on těžko bude v autě scannovat jaký že CTCSS má použít.

Já to myslel tak, že převaděč reaguje na skupinu třeba 30 subtónů , ale na výstupu produkuje vždy jen jeden jediný. Tedy nejde pak dělat selekce, jak jsi popsal a výhoda tohodle systému je, že nemusím hledat ten správný subtón. Prostě použiju nějaký ... Ovšem vyvstává další problém s hromadným nasazením takového řešení. Prostě převaděče, které se překrývají nemohou oba použít takové řešení 🙁

Jako zajímavá myšlenka mi přijde vyslání telegrafem kmitočtu CTCSS po písknutí 1750 i bez použití subtónu.

Ale napadlo mě, že pro nahození by šlo použít krom těch 1750 Hz, i jakýkoliv subtón, pak ( dejme tomu po nastaveném krátkém čase a odvysílání telegrf. info o CTCSS ) už jen jediný - vlastní převaděči.

Ahoj vespolek,

myšlenka o tom, že by RX převaděče reagoval na any-PL mi už nějakou dobu v hlavě taky ležela, ale v současné době nějak nemám čas na hraní ... nicméně mi to přijde jako rozumné, především ve spojení s jedním PL na výstupu. Úvaha o tom, že si člověk musí v autě "vyscannovat" PL talkgrupy je sice pravdivá, ale za současného stavu, pokud si člověk nevyscannuje PL vstupu převaděče, tak je ouplně bez šance. Další výhody:

- skupinový detektor PL jde udělat velice jednoduše analogově (např. filtr+NE567)
- generátor PL na výstupu a dávač telegrafu jde udělat velice jednoduše levným procesorem (např. 89c2051, Attiny...)
- detektor 1750Hz je rovněž jednoduchý (např. filtr + NE567)
- na informaci o PL a CALL převaděče jde použít hlasový modul za pár korun, nahazovaný 1750.
- dovybavení libovolného kecadla bez PL (pokud ještě někdo nějaké takové provozuje) pro režim anyPL spočívá opět v pár běžně dostupných součástkách za pár korun. (např. NE555, 567 atd.)

O SW realizaci nemluvě.

73, UHU.

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.

Ja jsem byl docela uspesny na mape aprs.fi. Vsechno tam urcite nebude, ale lepsi nez dratem do oka a je to takove nejrychelejsi a nejprehlednejsi reseni. Skoda jen, ze nejdou filtrovat typy objektu (nebo to aspon ja neumim).