UBNT Rocket M...

[Kaja]

Tak stale to nechapu.
Pokud se bavite o MASTER+nekolik SLAVE na jednom stozaru, tak predpokladam, ze GPS synchronizaci bude mit jen ten MASTER. Nebo se pletu?

Neprijde mi totiz moc logicke, aby u clusteru slozeneho ze 4 rocketu na stozaru, ktere jsou na sobe zavisle pomoci Master/Slave byl GPS prijimac v kazdem rocketu.
Pokud maji problem s sirenim GPS synchrobnizace po ethernetu, tak proc ji nesiri po nejakem dvoudratu, ktery bude propojovat vsechny Slave Rockety na stozaru s Mastrer Rocketem.
Takto to ma treba Motorola (bud pomoci separatniho dvoudratu a nebo je to "primichano" do RJ45 vedle DAT a POE).

K.





----------------------------------
AirSync - kazde zariadenie (Rocket M5GPS) ma v sebe GPS prijimac, exeterny konektor na GPS antenu. Jedno zariadenia na stoziary bezi ako Master, ostatne ako Slave.
----------------------------------

[andreas4all]

Tak stale to nechapu.
Pokud se bavite o MASTER+nekolik SLAVE na jednom stozaru, tak predpokladam, ze GPS synchronizaci bude mit jen ten MASTER. Nebo se pletu?

Neprijde mi totiz moc logicke, aby u clusteru slozeneho ze 4 rocketu na stozaru, ktere jsou na sobe zavisle pomoci Master/Slave byl GPS prijimac v kazdem rocketu.
Pokud maji problem s sirenim GPS synchrobnizace po ethernetu, tak proc ji nesiri po nejakem dvoudratu, ktery bude propojovat vsechny Slave Rockety na stozaru s Mastrer Rocketem.
Takto to ma treba Motorola (bud pomoci separatniho dvoudratu a nebo je to "primichano" do RJ45 vedle DAT a POE).

K.

pomocou GPS sa prijima iba cas.
teraz ide moja domnienka >> Master urci, kedy sa maju zariadenia prepnut (urci napr. casove ramce podla aktualneho vytazenia seba sameho). slave si stiahne tabulku, kedy sa bude prepinat RX/TX cez ethernet.

[hapi]

docela mě zajímá efektivita tohodle způsobu komunikace. Přijde mi že rychlost se musí mezi sektory na jednom kanále dělit a časovat něco na různých kanálech smysl nemá takže se nabízí otázka, jestli neni lepší použít větší šířku sektoru pro stejnej počet klientů bez GPS a podstatnější úsporu HW prvků. Tak nějak tohle řeší NV2 který asi ukazuje trend kdy poteče do bot opět UBNTu a mikrotik bude mít na vrch. Tak jako tak, obě technologie budou zvyšovat latenci.

[soooc]

docela mě zajímá efektivita tohodle způsobu komunikace. Přijde mi že rychlost se musí mezi sektory na jednom kanále dělit a časovat něco na různých kanálech smysl nemá takže se nabízí otázka, jestli neni lepší použít větší šířku sektoru pro stejnej počet klientů bez GPS a podstatnější úsporu HW prvků. Tak nějak tohle řeší NV2 který asi ukazuje trend kdy poteče do bot opět UBNTu a mikrotik bude mít na vrch. Tak jako tak, obě technologie budou zvyšovat latenci.

Efektivita - 3 sektory, soucet byl kolem 160Mbit v MIMO 2x2 v 20MHz kanalu. Latence kolem 15ms pri plne zatezi.

Casovani na ruznych kanalech ma taky cenu, protoze jak vime, karticky nevysilaji uplne presne Takze takhle lze treba dat 5500 a 5520 vedle sebe.

[Kaja]

Zatim se tu mluvi jen o synchronizaci APcek na jenom stozaru.
Ale co treba synchronizace nekolika sajtu v oblasti? Umi to AirSync?

Pokud ano, slo by na 4 frekvencich (4 sekrory na sajtu) pokryt treba cele mesto. Nedochazelo by tak ani k ruseni sousednich sajtu.

Toto umi synchronizace na Motorole Canopy.

Takze kdo vite, odpovezte. Umi to synchronizovat i nekolik sajtu v oblasti?

K.

[soooc]

Zatim se tu mluvi jen o synchronizaci APcek na jenom stozaru.
Ale co treba synchronizace nekolika sajtu v oblasti? Umi to AirSync?

Pokud ano, slo by na 4 frekvencich (4 sekrory na sajtu) pokryt treba cele mesto. Nedochazelo by tak ani k ruseni sousednich sajtu.

Toto umi synchronizace na Motorole Canopy.

Takze kdo vite, odpovezte. Umi to synchronizovat i nekolik sajtu v oblasti?

K.

O tomhle tam mluvili, ale presne se nevymackli - napis jim, oni to nejak zvladnou implementovat

[dantasik]

docela mě zajímá efektivita tohodle způsobu komunikace. Přijde mi že rychlost se musí mezi sektory na jednom kanále dělit a časovat něco na různých kanálech smysl nemá takže se nabízí otázka, jestli neni lepší použít větší šířku sektoru pro stejnej počet klientů bez GPS a podstatnější úsporu HW prvků. Tak nějak tohle řeší NV2 který asi ukazuje trend kdy poteče do bot opět UBNTu a mikrotik bude mít na vrch. Tak jako tak, obě technologie budou zvyšovat latenci.

NV2 je zatim tezce v pocatku. Ja to testil teda na ptp kvuli Nku pac jinde nemam odvahu a pri prenuti na NV2/nstreme to zkaplo ani nemrklo na Rc2. Pockam na dalsi verzi. Ale zatim v tomhle MK ujel vlak nehlede na to ze si mysilm ze budou resit spis to ze jim nechodi FW a nejsou schopny vydat fungujici verzi RoS jako takovou ktera ma hlavne routovat a ne nejaky NV2 na to maji dle me moc malo casu.

[pcwifi]

a zkusils ver. 5rc3 ? nasypal jsem to zkusebne na RB433 na stole a v modu nv2 + nstreme se to kupodivu nesesypalo nutno podotknout, ze jsem jen zkousel chovani a propustnost se starsimi kartami UB5 (AP bridge > Station WDS), nemam cas to zatim kam jinam vrznout... uspech je ze to i nabootovalo ok, rc1 i 2 rady skapaly na nejakem kernel error a konec,nutno vyrazit ze stavy natvrdo...

PW

[ppp76]

docela mě zajímá efektivita tohodle způsobu komunikace. Přijde mi že rychlost se musí mezi sektory na jednom kanále dělit a časovat něco na různých kanálech smysl nemá takže se nabízí otázka, jestli neni lepší použít větší šířku sektoru pro stejnej počet klientů bez GPS a podstatnější úsporu HW prvků. Tak nějak tohle řeší NV2 který asi ukazuje trend kdy poteče do bot opět UBNTu a mikrotik bude mít na vrch. Tak jako tak, obě technologie budou zvyšovat latenci.

Efektivita - 3 sektory, soucet byl kolem 160Mbit v MIMO 2x2 v 20MHz kanalu. Latence kolem 15ms pri plne zatezi.

Casovani na ruznych kanalech ma taky cenu, protoze jak vime, karticky nevysilaji uplne presne Takze takhle lze treba dat 5500 a 5520 vedle sebe.

Takhle to chodilo na predvadecce? a ted jeden malej dotaz ... meli to tam spojeny ty zarizeni vzduchem nebo zas meli tu habaduru jako loni ze to meli spojeny kabelama ty apcka ???protoze ve chvili kdy spojim apcka kabelama mam laboratorni podminky skoro ... a to se to pak ukazujou vysledky

[hapi]

no já nevim ale asi hodinu 9 klientů jelo na NV2 + nstreme na 5.0b6 a neni problem. Já chápu že skušenější si to poladí a ty co to neřeší a označeji za nefunkčí jdou do UBNTu.

Tak jako tak, ty zařízení se museji o pásmo dělit i když jsou kanálově vedle sebe takže se děleji i o přenosovou rychlost. Logicky to jinak nejde a papír od canopky taky neni "čistota sama". Jasně, nedochází k rušení sektorů mezi sebou ale dochází ke sdílení!!

[Kaja]

Canopy a sdileni:

Ale tam k zadmenu zasadnumu sdileni nedochazi.
Zakladni finta je v tom, ze vsechn APcka mohou vysilat najednou (i kdyz jsou na blizkych kanalech). Casovani urcuje jen to, ze v dany casovy interval vsechny AP vysilaji a v jiny casovy okamzik zase vsechny prijimaji (a tim je sousedni AP nerusi svym silnym signalem).

V podstate strasne jednoduchej princip.
Toto lze pomoci Master-Slave a kabelove proopjky udelat v ramci stozaru i bez GPS.


K.

[soooc]

Zkousel uz nekdo ROcket M5 fw5.3 beta? Je tam zajimavy upgrade:

- New: Low TX power mode for Rocket M5/Rocket M2

To by vypadalo, ze jde vypnout zesilovac - a ze by 0 dB bylo na svete

[miract]

Zkousel uz nekdo ROcket M5 fw5.3 beta? Je tam zajimavy upgrade:

- New: Low TX power mode for Rocket M5/Rocket M2

To by vypadalo, ze jde vypnout zesilovac - a ze by 0 dB bylo na svete

A kolik lidi si myslis, ze to z tech 30dB co tam maji ted prepnou na 0dB?

[ppp76]

Ja tipuju na jedno procento kdyz skenuju u nas kdo ma ubnt raketu tak mi to div neustreli antenu kolik do teho prazej a nejak tu je velkej ubytek holubu ... oni maj skoro nepodelany anteny ja na nich mam uz kopce sracek

[soooc]

Zkousel uz nekdo ROcket M5 fw5.3 beta? Je tam zajimavy upgrade:

- New: Low TX power mode for Rocket M5/Rocket M2

To by vypadalo, ze jde vypnout zesilovac - a ze by 0 dB bylo na svete

A kolik lidi si myslis, ze to z tech 30dB co tam maji ted prepnou na 0dB?

Tak ja si nedelam iluze - jen pro mistni neverici - toto zarizeni je schopno splnovat VO Takže Rocket M5 + RocketDish neznamena automatickou korist pro ČTÚ.