03-10-2014, 08:44 PM
Miałem zamiar wczoraj rozpocząć krucjatę przeciwko subtonowi, ale czasu nie starczyło...
Chciałbym w formie pisemnej przedstawić pod rozwagę swoje argumenty przeciwko stosowaniu CTCSS na naszym przemienniku.
Jest to i pewnie zawsze będzie z racji wysokości umiejscowienia anteny przemiennik lokalny - typowo powiatowy.
Więc nie grozi nam, że ktoś kto zapragnie porozmawiać na przemienniku katowickim będzie słyszany jednocześnie na naszym.
Więc po co blokować przemiennik CTCSS-em?
Ktoś przejeżdżający sporadycznie przez powiat teraz musi oprócz częstotliwości pamiętać o załączeniu właściwego CTCSS.
Niekoniecznie musi wiedzieć jaki ton tu jest stosowany i niekoniecznie musi mu się chcieć grzebać w menu radia.
Gdyby przemiennik pracował bez subtonu to taki gość wszedł by bez względu czy ma i jaki ma subton załączony.
Więc po co blokować przemiennik CTCSS-em?
Przy podniesionej propagacji Koledzy skaczą po kanałach przemiennikowych i testują czy coś się otworzy.
Jak w powyższym przykładzie muszą pamiętać, że jest tu CTCSS i przeprogramować radio, aby wejść.
Nie liczmy na to, że nasz SR5MM będzie tak popularny i Koledzy z SP2 czy SP7 masowo wpiszą ten przemiennik do pamięci radia wraz z ustawieniami dotyczącymi subtonu.
Czyli nacisną PTT, obecnie przemiennik nie otworzy się, więc przestroją się na inny kanał.
Co może zniweczyć szansę na ciekawą łączność na przemienniku, a potem może i na kanale simpleksowym.
Więc po co blokować przemiennik CTCSS-em?
Kiedyś przemiennik bardzo długo pracował bez CTCSS i nie było żadnych konfliktów z innymi przemiennikami.
Teraz w nowej lokalizacji też kilka dni pracował bez CTCSS i nie było żadnych zakłóceń przemysłowych na wejściu.
A tego najbardziej bałem się z racji sąsiedztwa (PKP, WLAN-y) - na szczęście jest spokój.
Więc po co blokować przemiennik CTCSS-em?
Ekipa opiekująca się obecnie przemiennikiem poza decyzją o załączeniu nie wiadomo po co CTCSS ustawiła subton 127,3Hz
Bo pobliska Warszawa tak ma...
Tylko jest problem - część osób, które chciałby cały czas słuchać na SR5MM słyszy ten subton - nieprzyjemne dudnienie.
Na dłuższą metę to wkurza i to mocno, co przyczynia się do mniejszej aktywności na i tak mało obleganym przemienniku.
Chodzi chyba o to, aby wszyscy z całego powiatu chętnie na nim "parkowali", a nie tylko ci którym nie buczy?
Więc po co blokować przemiennik CTCSS-em?
Blokada tonowa odbiornika może spowodować problemy z wejściem czy też ciągłością relacji w przypadku stacji o słabym sygnale.
Czyli bardzo odległe, czy stacje mobilowe czy Koledzy w terenie z radiotelefonami ręcznymi.
Przy słabym sygnale przemiennik nie będzie w stanie rozpoznać subtonu i zamknie się ponieważ subton jest nadawany z duuużo mniejszą dewiacją niż normalna modulacja. Gdyby nie było CTCSS zwykła blokada SQL jeszcze by pozwoliła na łączność.
Więc po co blokować przemiennik CTCSS-em?
Sugestie sprzed kilkunastu lat odnośnie zalecenia stosowania określonych tonów CTCSS były jedynie zaleceniami i sam ich autor (SP6LB) przyznał, że ten system nie sprawdził się.
Obecnie to operatorzy odpowiedzialni sami decydują jaki subton zastosować i czy w ogóle CTCSS jest niezbędny.
Mam wrażenie, że w przypadku naszego przemiennika doszło do nieporozumienia - dawno nieaktualne zalecenia ktoś zinterpretował jako bezwzględny nakaz załączenia CTCSS. Gdyby tak było to UKE w zezwoleniu jasno by to określiło.
A jestem pewny, że nie ma tam słowa o konieczności zastosowania subtonów.
Więc po co blokować przemiennik CTCSS-em?
Proponuję przywrócić pierwotną konfigurację przemiennika (stan w jakim zdałem go do klubu w ubiegłym roku) czyli po prostu wgrać zapewne zachowany plik z tamtą konfiguracją - była ona wynikiem wielu prób i ulepszeń, a nie klikania na oślep.
Potem poobserwujemy ze 2-3 tygodnie działanie przemiennika i aktywność na nim - zwłaszcza dalszych stacji.
Jak będą jakieś problemy to może dopiero wówczas pomyślimy o CTCSS!
Chciałbym w formie pisemnej przedstawić pod rozwagę swoje argumenty przeciwko stosowaniu CTCSS na naszym przemienniku.
Jest to i pewnie zawsze będzie z racji wysokości umiejscowienia anteny przemiennik lokalny - typowo powiatowy.
Więc nie grozi nam, że ktoś kto zapragnie porozmawiać na przemienniku katowickim będzie słyszany jednocześnie na naszym.
Więc po co blokować przemiennik CTCSS-em?
Ktoś przejeżdżający sporadycznie przez powiat teraz musi oprócz częstotliwości pamiętać o załączeniu właściwego CTCSS.
Niekoniecznie musi wiedzieć jaki ton tu jest stosowany i niekoniecznie musi mu się chcieć grzebać w menu radia.
Gdyby przemiennik pracował bez subtonu to taki gość wszedł by bez względu czy ma i jaki ma subton załączony.
Więc po co blokować przemiennik CTCSS-em?
Przy podniesionej propagacji Koledzy skaczą po kanałach przemiennikowych i testują czy coś się otworzy.
Jak w powyższym przykładzie muszą pamiętać, że jest tu CTCSS i przeprogramować radio, aby wejść.
Nie liczmy na to, że nasz SR5MM będzie tak popularny i Koledzy z SP2 czy SP7 masowo wpiszą ten przemiennik do pamięci radia wraz z ustawieniami dotyczącymi subtonu.
Czyli nacisną PTT, obecnie przemiennik nie otworzy się, więc przestroją się na inny kanał.
Co może zniweczyć szansę na ciekawą łączność na przemienniku, a potem może i na kanale simpleksowym.
Więc po co blokować przemiennik CTCSS-em?
Kiedyś przemiennik bardzo długo pracował bez CTCSS i nie było żadnych konfliktów z innymi przemiennikami.
Teraz w nowej lokalizacji też kilka dni pracował bez CTCSS i nie było żadnych zakłóceń przemysłowych na wejściu.
A tego najbardziej bałem się z racji sąsiedztwa (PKP, WLAN-y) - na szczęście jest spokój.
Więc po co blokować przemiennik CTCSS-em?
Ekipa opiekująca się obecnie przemiennikiem poza decyzją o załączeniu nie wiadomo po co CTCSS ustawiła subton 127,3Hz
Bo pobliska Warszawa tak ma...
Tylko jest problem - część osób, które chciałby cały czas słuchać na SR5MM słyszy ten subton - nieprzyjemne dudnienie.
Na dłuższą metę to wkurza i to mocno, co przyczynia się do mniejszej aktywności na i tak mało obleganym przemienniku.
Chodzi chyba o to, aby wszyscy z całego powiatu chętnie na nim "parkowali", a nie tylko ci którym nie buczy?
Więc po co blokować przemiennik CTCSS-em?
Blokada tonowa odbiornika może spowodować problemy z wejściem czy też ciągłością relacji w przypadku stacji o słabym sygnale.
Czyli bardzo odległe, czy stacje mobilowe czy Koledzy w terenie z radiotelefonami ręcznymi.
Przy słabym sygnale przemiennik nie będzie w stanie rozpoznać subtonu i zamknie się ponieważ subton jest nadawany z duuużo mniejszą dewiacją niż normalna modulacja. Gdyby nie było CTCSS zwykła blokada SQL jeszcze by pozwoliła na łączność.
Więc po co blokować przemiennik CTCSS-em?
Sugestie sprzed kilkunastu lat odnośnie zalecenia stosowania określonych tonów CTCSS były jedynie zaleceniami i sam ich autor (SP6LB) przyznał, że ten system nie sprawdził się.
Obecnie to operatorzy odpowiedzialni sami decydują jaki subton zastosować i czy w ogóle CTCSS jest niezbędny.
Mam wrażenie, że w przypadku naszego przemiennika doszło do nieporozumienia - dawno nieaktualne zalecenia ktoś zinterpretował jako bezwzględny nakaz załączenia CTCSS. Gdyby tak było to UKE w zezwoleniu jasno by to określiło.
A jestem pewny, że nie ma tam słowa o konieczności zastosowania subtonów.
Więc po co blokować przemiennik CTCSS-em?
Proponuję przywrócić pierwotną konfigurację przemiennika (stan w jakim zdałem go do klubu w ubiegłym roku) czyli po prostu wgrać zapewne zachowany plik z tamtą konfiguracją - była ona wynikiem wielu prób i ulepszeń, a nie klikania na oślep.
Potem poobserwujemy ze 2-3 tygodnie działanie przemiennika i aktywność na nim - zwłaszcza dalszych stacji.
Jak będą jakieś problemy to może dopiero wówczas pomyślimy o CTCSS!