Co se týče HIP, HIT a HIL jedná se o zařízení, která byla vyvíjená více než před 10ti lety. (Zkuste si někdo prosím udělat upgrade 10let staré věci, kde se mnoho věcí vykouřilo z hlavy, moho se postrácelo (tedy zejména jde o dokumentaci od Karla DNH, kterou si vedl především v hlavě, papírově se nedohledalo témeř nic)) Jakýkoli zásah do FW není tedy tak jednoduchý, jak se zdá a udělat nějakou změnu znamená znovu nastudovat celý strom FW. není to tedy otázkou několika minut ale spíše na pár desítek hodin. Tím jsem chtěl říct že nejde o to, že bychom to sabotovali, ale prostě není čas a síla se do této 10let staré věci pustit.

--- *# je tam proto, že # je základní systémový znak, po jehož detekování kterém se umlčují veškeré DTMF kódy. (aby nebylo možné např. jednoduše hackovat sysp PWD, nebo aby to neobtěžovalo když si někdo chce říct o hodiny. Echolink přišel až po té, neměli jsmě skleněnou kouli abychom tušili, že ho bude používat pro rozpojení.
--- Alfa znaky bych zásadně nedoporučoval. Mnoho zařízení má jen dialer 1234567890#* Jakmile se do toho začnou montovat ABCD, tyto lidi odříznete.
--- Co se týče problému CTCSS při odpípnutí pokusíme se toto odstranit, vzhledem k výše uvedeným problémům nejsem schopen slíbit termín.

Jelikož už není z čeho dělat a v podstatě ani nemám převaděč, ne kterém bychom mohli nový FW zkoušet nepočítáme s dalším vývojem Platformy HIx2000. Připravuje se nová verze na jiné HW platformě, kde by výše popsané problémy již měli být vyřešené.

Zdravím. Přes tyto skutečnosti bych se přece jenom silně přimlouval o vyvinutí snahy o změnu FW ohledně # konvence. Působí to opravdu problémy a kolize. Echolink nastoupil za ty roky v plné síle a trochu zapomínáme na cizince projíždějící přes naši středoevropskou zemičku.

Jako provozovatel neHIPového převaděče se standardně nastaveným Echolinkem slyším důsledky této anomálie prakticky denně na rádiu. Tedy ze strany tuzemských uživatelů, kteří to pojali chybně jako standard. Ale opačné vyznění problému slyším i na spojených linkách na převaděče typu HIP.

Absence A-B-C-D tlačítek na DTMF mikrofonech bych se tolik neobával, udělal jsem průzkum mezi mými rádii a nemá je pouze muzeální DTMF mikrofon Motorola, přesto připouštím, že může být řada TCVR takto nevybavených. Má je ale už i např. mé Alinco DJ-G5 z roku 1997. Například s tlačítkem C počítá i ovládání Echolinku a jistě by to tvůrci této sítě nekomponovali do povelů, kdyby si byli vědomi nemožnosti využití u většiny uživatelů.

Co se týká nemožnosti vyzkoušet úpravu FW na nějakém HIPu, tak tuším že Pavel OK4PS bude mít po upgrade OK0Z na Motorola/Zetron technologii na nějakou dobu u sebe doma HIP a jistě by byl svolný k testu firmware.

Když se chce, tak to jde.

Uprava stavajiciho FW by byla urcite vhodna, i na OK0Z je nekdy ze strany uzivatelu boj s rozpojenim EchoLinku. Uzivatel vlastne ani mnohdy netusi jake je prevadecove zelezo a ze HIP ma nestandardni ukoncovaci sekvenci.

Kazdopadne jak pise Bronek, jelikoz prave je v behu uprage OK0Z z HIPu na Motorola prevadec, tak budu mit k dispozci u sebe doma minimalne 1ks HIPu pro pripadne otestovani nového FW. Staci se jen ozvat.

Milane, jsem zvědav, jak se poperete s těma Ericssonama. Mě to nedalo a zprovoznil jsem jeden přijímač. Ty helicaly na vstupu se musi zašroubovat úplně nadoraz, ale i tak to bylo tupý jak poleno. Nechápu, proč je u všech těchdle věcí na vstupu nejdřív tranzistor BFG135 ( byť pracuje s větším Ic ) a až za ním 3x helical "band" filtr - proč to nedělaj obráceně?
Pak jsem zjistil, ze je za 1 MF ještě nějaké řízení zisku tak jsem to vyřadil a citlivost se zvedla na rozumnou hodnotu okolo 0,4 microV pro 10db dle SINAD (testováno na dlouho necejchovanem Stabilocku 4010). Nevim, jaký vliv má na citlivost úroveň signálu z přeladěného VCO, ale před přeladěním tam bylo 2,8V a po přeladěni o 20 MHz níže už jen 1,1V a nejde to napěti nijak zvednout. Podle mě špatné poměry na tom SAW rezonátoru, výměnou kondu u něj spadlo Q a tim i napětí . Asi by měl bejt ten SAW delsi...
Jestě zkusim injektovat signál do 1 směšovace rovnou z generu a v úrovni , jako to bylo před přeladěnim, jestli bude citlivost lepši. Bohužel jsem nezkusil změřit citlivost jestě před přeladěním na origoš kmitočtu a mám jen jeden modul a ten už jsem rozkuchal . V každém případě to jestě udělám, abych věděl, jestli má smysl se nějak snažit tu citlivost dohonit.

Už i tak se mi ale zdá ten modul z BD28 obvodově lepší - minimalne 1 MF filtr vypadá jako filtr 🙂 v Eriku je to krystal s "pacičkou" uprostřed aneb v rámci globalizace se asi na drahejch věcech začalo šetřit. Hi. ( Erik přišel až po BD28 , pak se dávaly BD34, kde je prijímač až na 1 směšovač v podstatě shodnej s BD28 i když už jen jako samostatnej modul SRI.

Co se tyce echolinku a HIPu..
Ja osobne s tim problem nemam, krome jiz drive mnou uvedene "chybky".
Ono staci totiz par drobnosti, ktere tyto problemy eliminuji..
Co se tyka odpadu CTCSS - na ridici signal linkovaciho radia, oznacme ho BUSY, staci povesit elyt s odpovidajici hodnotou, popripadne jeste pres odpor, aby podrzel BUSY tak o sekundu dele seply. Tim se sice trochu protahne i nabeh echolinku, ale nekdy to je i zadouci..
Co se tyce odpojeni.. V OK uz je to *# opravdu velmi zazite. A vetsina uzivatelu s tim nema problem.
Pro cizince je nekolik snadnych moznosti, jak toto osetrit..
a) propagace a popis Linku nebo Rptru na internetu - spousta lidi, pokud nekam jede, obvykle hleda moznosti spojeni dopredu.
b) uvest v info.txt tuto anomalii.
c) nastavit vhodne timeouty. Spousta sysopu je tam nema. Asi neumi cist nebo neumi anglicky nebo proste delaji neco, cemu nerozumi. Pak to tak dopada..
d) pokud slysim cizince, jaxe snazi odpojovat a nejde mu to, upozornim ho primo na prevadeci.. Obvykle staci v anglictine. Pokud to neni madar, tak to pochopi.. (pro pripadne anglicky spatne hovorici - * = star, # = hash (čti haš))

Co se tyce odpojeni.. V OK uz je to *# opravdu velmi zazite. A vetsina uzivatelu s tim nema problem.

Je pravda že je to zažité a nemají s tím problém, ten ale nastává pokud se vyskytnou na převaděči se standardně nastaveným Echolinkem. Tam problém je.

Pro cizince je nekolik snadnych moznosti, jak toto osetrit..
a) propagace a popis Linku nebo Rptru na internetu - spousta lidi, pokud nekam jede, obvykle hleda moznosti spojeni dopredu.

Obávám se že většina si maximálně zjistí kde jsou jaké převaděče a zda jsou napojeny do Echolinku. Že by si studovali nějaké odlišnosti a anomálie, pochybuji.

b) uvest v info.txt tuto anomalii.

Tento infotext se zobrazuje pouze při připojení přes Echolink terminál. Přes rádiovou cestu se to neuplatní a právě tu řešíme. V terminálu si to odpojím kliknutím myši.

c) nastavit vhodne timeouty. Spousta sysopu je tam nema. Asi neumi cist nebo neumi anglicky nebo proste delaji neco, cemu nerozumi. Pak to tak dopada..

Souhlas. Timeouty obecně musí být i bez tohoto problému.

d) pokud slysim cizince, jaxe snazi odpojovat a nejde mu to, upozornim ho primo na prevadeci.. Obvykle staci v anglictine. Pokud to neni madar, tak to pochopi.. (pro pripadne anglicky spatne hovorici - * = star, # = hash (čti haš))

Dělám to stejně, upozorním anglicky, polsky v případě SP, často jim to odpojím manuálně za ně. Je to ale hloupá činnost, pokud je upozorním na tuto odlišnost, většinou se dočkám spíše rozpačité nechápající reakce. Do vysvětlování proč to tak někde v OK máme, se raději nepouštím.

Omlouvám se, že nereaguji tak rychle, jsem na dovolené, momentálně jsme přejeli z Francie do Německa a k počítači se dostanu jen k večeru na chvíli.

Co se týče ABCD, také jsem si dělal průzkum a hodně lidí v mém okolí používá právě Motoroly či jiná profi rádia, kde na MIC ABCD nejsou. Pakliže existuje nějaké technické řešení, které bude fungovat a nebude nikoho omezovat, budu ho prosazovat. Používání ABCD není NEZBYTNĚ NUTNÉ, proto nevidím důvod jeho použitím vyřadit tuto skupinu lidí.

Důvody, proč se nechci vrtat v FW HIP jsem zde popsal, nicméně i když to dost zabrzdí jiné činnosti zkusíme se na to podívat. Každopádně převrtávat celou logiku ovládání se mi vůbec nechce. Znáte to... změníte jednu věc a rozsype se 10 ostatních, a nerad bych aby se třeba SW začal z ničeho nic kousat. Zaměříme se ne dva problémy, první je to co popisoval ZO, druhý by se dal řešit tak, že by nedocházelo k umlčování DTMF ihned jakmile to zaslechne # ale až následující znak. To znamená, že # jakožto první znak by prošel vždy a Echolink by se dal shodit.

to MHK: Důvody, proč jsme si vybrali to co jsme si vybrali jsem Ti říkal osobně a stále platí. Jakmile se ukáže že tudy cesta nevede, vždy je možné jít na BD28, je to ale o 10let starší koncepce. Parametrově v originálním provedení jsou zcela srovnatelné a to ať jde o citlivost, tak o odolnost. Z hlediska funkčnosti nabízí Erik mnohem více. Uvidíme, jestli se povede udělat opakovatelně přeladění tak aby nedošlo k degradaci. Snadnější cestou je možné se vydat vždy...

Jo, abych nezapomněl, nezbytnou podmínkou jak jsem již jednou psal je mít k dispozici 1ks funkčního HIPa, naslepo se to nedá dělat. Jestli ho tedy PS vysvobodí a dodá, můžeme zkusit ty úpravy FW.

Milane, dekujeme za msg.
Chtel bych se primluvit, pokud davate dohromady novou hw platformu (HIP3000 ?), bude jeji soucasti i :
1) interni duplexer...viz jako mam na OK0BEZ ?
2) interni PC mikroprumyslova platforma .... treba Alix po Echolink a pripadne i pro APRS ?

I ten nejlevnejsi originalni prevadec Yaesu VXR-7000 ( http://www.vertexstandard.com/lmr/Repeaters/VXR-7000 ) stoji "nekrestanske" penize...cili i pro me invalidniho duchodce je to nedostupne. Tudiz otazka treti zni, zda-li cenova relace tohoto noveho rpt bude podobna jako u HIP2000 nebo bude o neco drazsi (zkus prosim odhadnou plus minus cenovou relaci) ?

Mam jeste jednu otazku. Mam drobny problem s prevadecem HIP2000 (asi by to chtelo premerit a pripadne doladit "civky"), je mozny u Vas v OMX servis? Ci primo u tebe?
Nevim, kdo po Karlovi prevzal servis a tak jsem bezradny.

73! Martin

1) ne - Solidní duplexer který chodí dobře pro 7,6 MHz pro segment 430-440 (nemyslím přelaďované PROFI určené původně někam na 460 a odskok 10MHz) stojí 5000 a více, což je více než cena původního HIPu. Je to tedy věc každého, kolik chce do duplexeru investovat, kdo má peníze ať si ho koupí, kdo má magickej šroubovák a kouzelný ruce ať si ho udělá třeba z vodovodního potrubí s náklady 0.

2) ne - Cílem je co nejvyšší spolehlivost a malá spotřeba a nízké náklady. Všude se fláká VF, sem tam statika. Alix nebo jakákoli platforma by to zbytečně prodražila a snížila MTBF.

Pro Echolink (APRS) budou připraveny interface, součástí nebudou.

Pokoušíme se o to, aby cena byla obdobná jako u HIP2000. Zatím je ale předčasné o tom spekulovat. Vše musí jít v krocích, je připravená hrubá koncepce, zatím se pracuje na její realizovatelnosti a nakonec bude muset přijít finanční rozvaha. Je možné, že na základě finanční rozvahy se bude muset jít zpět na změnu koncepce... dokud se nenajde všeobecně schůdné řešení. Proto zatím nechci ani spekulovat o detailech, protože je vše zatím na vodě. S tím samozřejmě souvisí i současná doba, volného času je čím dál méně HIP2000 se vyvíjel skoro rok a bylo nás na to víc.

Mam jeste jednu otazku. Mam drobny problem s prevadecem HIP2000 (asi by to chtelo premerit a pripadne doladit "civky"), je mozny u Vas v OMX servis? Ci primo u tebe?
Nevim, kdo po Karlovi prevzal servis a tak jsem bezradny.

73! Martin

Abych mohl říct, jestli Ti jsem schopný pomoci, musíš specifikovat lépe závadu. "drobný problém" mi nic neříká, jediné co mi to asociuje je jeden případ, kdy mi byl doručen HIP, kde se ho pokoušel majitel "doladit" na větší citlivost zřejmě hasákem (totálně zničené vstupní cívky vyměňované kondy, potrhané spoje) a díra v PA modulu (trimr výkonu nadoraz) A začalo to úplně stejně.... Mám drobný problém... tak že tudy ne....

To znamená :
a) podmínkou je, že se v tom nikdo neryl
b) musím znát jednoznačně popis závady (např. citlivost je 5uV, nebo max výkon 50mW...)

Díky tomu, že si Karel DNH nevedl žádnou dokumentaci (všechno měl v hlavě) není až tak jednoduché hrabat se v již rozhrabané věci.

Zaměříme se ne dva problémy, první je to co popisoval ZO, druhý by se dal řešit tak, že by nedocházelo k umlčování DTMF ihned jakmile to zaslechne # ale až následující znak. To znamená, že # jakožto první znak by prošel vždy a Echolink by se dal shodit.

Milane díky za nadějnou informaci. Myslím že tato úprava by to vyřešila.

Jo, abych nezapomněl, nezbytnou podmínkou jak jsem již jednou psal je mít k dispozici 1ks funkčního HIPa, naslepo se to nedá dělat. Jestli ho tedy PS vysvobodí a dodá, můžeme zkusit ty úpravy FW.

Už jsem s ním mluvil a určitě bude pro tyto testy k dispozici, jakmile se namontuje nový OK0Z.

Milane, dekuji za info.
Tu zavadu nechci resit pred operaci hlavy, kterou mam naplanovanou nekdy na prelom srpna/zari.
Eventualni opravu prevadece budu resit az po operaci.
Az se k tomu dostanu, tak ti napisu co to dela/nedela.
Do prevadece se nikdo mimo Karla nehrabal.

73! Martin

Mam jeste jednu otazku. Mam drobny problem s prevadecem HIP2000 (asi by to chtelo premerit a pripadne doladit "civky"), je mozny u Vas v OMX servis? Ci primo u tebe?
Nevim, kdo po Karlovi prevzal servis a tak jsem bezradny.

73! Martin

Abych mohl říct, jestli Ti jsem schopný pomoci, musíš specifikovat lépe závadu. "drobný problém" mi nic neříká, jediné co mi to asociuje je jeden případ, kdy mi byl doručen HIP, kde se ho pokoušel majitel "doladit" na větší citlivost zřejmě hasákem (totálně zničené vstupní cívky vyměňované kondy, potrhané spoje) a díra v PA modulu (trimr výkonu nadoraz) A začalo to úplně stejně.... Mám drobný problém... tak že tudy ne....

To znamená :
a) podmínkou je, že se v tom nikdo neryl
b) musím znát jednoznačně popis závady (např. citlivost je 5uV, nebo max výkon 50mW...)

Díky tomu, že si Karel DNH nevedl žádnou dokumentaci (všechno měl v hlavě) není až tak jednoduché hrabat se v již rozhrabané věci.

Tak jen další info, ten vstupní helical v mém modulu z Erika je při šroubech nadoraz v maximu na 441MHz. Nadrátoval jsem k tomu rozmítač a níž to nejde. Kdyby šlo, určitě to bude citlivější. Takže si s tím ještě pohraju. Dobrá informace je, že na originálním kmitočtu je citlivost výborná - cca 0,15MircoV/ pro odstup 10 dB. Jinak se objevil jeden kolega neradioamatér programátor - moc se mu to líbí a chce se zkusit ujmout řízení toho krámu. Když jsem mu nastínil o co jde ( CTCSS, identifikace SQ atd... ) tak že je to prý v poho, že na to stačí jeden chytřejší procesor. No uvidíme, jestli to nezůstane jen u keců, ale už jsem mu psal kuchařku, co by to mělo všechno umět 🙂

Úprava FW do HIPu se stává pomalu realitou. Jako zadání zatím sepíšu body, které vzešly z této diskuse.

1. umožnit průchod znaku #
K tomuto bodu mám jeden námět. Současný stav: Zakázání mutování včetně prvního # kvůli shození Echolinku není ideální. Zároveň není ideální nechat procházet úplně všechny znaky za #, protože by se tím "odrkyla" iniciační sekvence pro heslo a vstup do dálkové konfigurace a kdokoli by si chtěl dát dotaz na hodiny, teplotu... by otravoval pípáním...
Což takhle kdyby se umlčení udělalo od druhého znaku za #. t.j. při vyslání sekvence ##3 by na výstupu byl jen #ticho ticho?

2. přerušení vysílání CTCSS mezi skončením vysílání a odpípnutím
tady se naskýtají dvě řešení:
a) CTCSS se přestane vysílat okamžitě po ztrátě užitečného signálu na vstupu
b) CTCSS bude držet ještě po dobu, než převaděč odpípne.
výhody a nevýhody:
var. a) Echolink, nebo prolinkované převaděče rychleji přejdou z TX na RX t.j. protistrana bude rychleji odpovídat - zvlášť při velkých spožděních u EL, kde jsou propojeny dva převaděče a bude tam tím pádem pípnutí 2x by to bylo dost znát. Nevýhodou tohoto řešení je, že bude-li mít uživatel rádio zavřené pod CTCSS, neuslyší klasické převaděčové odpípnutí.

Prosím vyjádřete své názory jaké řešení byste preferovali, případně jestli by se mělo ještě něco změnit.

(jako bod 3. mne napadá možnost v sysop módu zakázat/povolit voice/morse informace (všechny komandy začínající ##1 - po ##9) třeba na BBF je šulin, kterej vydrží i půl hodiny prudit.)