- Samsung Galaxy S24 Ultra - ha működik, ne változtass!
- Google Pixel topik
- Honor Magic7 Pro - kifinomult, költséges képalkotás
- Megjelent a Poco F7, eurós ára is van már
- Samsung Galaxy Watch6 Classic - tekerd!
- Realme 9 Pro+ - szükséges plusz?
- iPhone topik
- Poco F6 5G - Turbó Rudi
- Honor Magic5 Pro - kamerák bűvöletében
- Hammer 6 LTE - ne butáskodj!
-
Mobilarena
Xiaomi AX3600 WiFi 6 AIoT Router
Új hozzászólás Aktív témák
-
dchard
veterán
válasz
trance89 #3787 üzenetére
Teljesen világos mostmár, hogy mi a probléma. Onnan nincs visszaút, legalább is TTL soros nélkül biztosan nem. Ha a szar partíciók miatt a bootloader-t felülírta, akkor meg sehogy nincs visszaút.
Számtalanszor leírtam, hogy mi a veszélye a QSDK alapú firmware-eknek, most mindenki láthatja, hogy az eszetlen hekkelés mit eredményez. Biztos voltam benne, hogy nem Robi build-jével van gond, de mostmár legalább bizonyíték is van.
A Bdata partíciót a valódi Openwrt (mostmár így fogok rá hivatkozni) egyébként nem használja, ugyanis a BDF-et fájlból tölti, a kalibrációs adatok pedig az ART nevű particíóról jönnek. Az persze kérdés, hogy a gyári recovery tool-t meg tudja-e borítani az átírkált bdata. Tehát itt van egy tágabb kontextus is.
A 160MHz mostmár elérhető, mellette van egy csomó javítás is. Nekem csak 80MHz-es klienseim vannak, ezért jó volna tesztelő aki AX 160MHz-en tudna tesztelni. A Mesh-t sem ártana kipróbálni. Rendeltem egy AX210-es kártyát, de az még hetek mire ideér.
-
dchard
veterán
válasz
xabolcs #3785 üzenetére
Egyetlen esetben tudok elképzelni olyan bootloop-ot amit a gyári recovery toolal nem lehet helyrehozni: amikor valaki felhekkelte valamelyik QSDK alapú szart a routerére és onnan próbál tovább lépni a valódi openwrt-re. A QSDK alapú hekkelmények ugyanis megávltoztatják a partíciós táblát a routeren, onnan nincs vissza út vgay legalább is nagyon nagyon macerás visszahozni, és nagy az esélye annak, hogy csak TTL sorossal lehet ezt megtenni.
A Robi féle valódi openwrt nem nyúl a router eredeti partíciós táblájához, kizárólag a két rootfs partíciót írja (mtd12 és mtd13), amit a gyái recovery tool vissza is tud állítani. Nincs esély arra sem, hogy mondjuk az ART vagy a Bootloader partíciókba beletörölsz.
Mondjuk az egy jó kérdés, hogy az itt olvasható Bdata partíció hekkelések vajon milyen hatással lehetnek erre, de főként a QSDK alapú firmware-ektől kell óvakodni.
Én az AX6-on rengeteg frissítést elvégeztem már a leírt módszerrel, soha nem volt még hasonló élményem. De nem is használtam korábban QSDK alapú szart, és nem írogattam a bdata partíciót sem.
-
dchard
veterán
válasz
xabolcs #3783 üzenetére
Baden logja tök üres, pont azt a részt nem sikerült neki beraknia ami érdekes lenne, amit berakott ott minden ok. Yume303 logjában is minden van, csak éppen az nem amit ír (bottloop). A logban egy sikeres recovery van, és utána a U-Boot visszaszámlálás, de hol a loop vagy bármi hiba? Nincs se crash se semmi.
Ehhez képest viszont többeknek működik. Ráadásul a boot részhez hónapok óta nem nyúlt senki. Én van hogy anponta 2-3-szor is frissítek, és soha nem volt még olyan, hogy megállt a boot, vagy loop lett volna. Nekem őszintén szólva kicsit gyanús, hogy 2-3 kevéssé tapasztaltnál előjön, de semmi értelmes log nem áll elő ezekből, mindenki másnál meg soha.
-
dchard
veterán
válasz
siemensfun #3781 üzenetére
És TTL sorosod nincs gondolom.
Próbáld meg így: [link]
-
dchard
veterán
válasz
siemensfun #3776 üzenetére
Nade maga a recovery meddig jut el? Nem írsz le túl sok részletet, és ebből kéne kitalálni hogy mi van. Recovery-nél ugye a bottloader TFTP módba billen és onnan húzza be a cuccot. Tehát windows tűzfal sazbáyloknak, IP címeknek stimmelnie kell. Néha arra is szükség van, hogy legyen egy switch a PC és a router között, különben nem jön fel a link elég gyorsan és úgy tűnhet hogy a recovery nem sikerül.
-
dchard
veterán
válasz
siemensfun #3771 üzenetére
Hát az igen fura, mert pontosan ezt raktam ma fel én is, de tökletesen működik.
A gyári állapotot a Xiaomi féle recovery tool-lal lehet a legkönnyebben elérni, onnan lehet újra próbálni. TTL soros nélkül én ezt tenném.
-
dchard
veterán
válasz
siemensfun #3769 üzenetére
Pontosan mit csináltál? És melyik fájlt töltötted fel?
-
dchard
veterán
válasz
siemensfun #3767 üzenetére
Tolhatod szerintem. A Mesh-hez alapvetően más WPAD-t kell felrakni:
root@XAX6:~# opkg remove wpad-basic-wolfssl
Removing package wpad-basic-wolfssl from root...
root@XAX6:~#
root@XAX6:~#
root@XAX6:~# opkg install wpad-mesh-wolfssl
Installing wpad-mesh-wolfssl (2021-05-22-b102f19b-46) to root...
Downloading https://downloads.openwrt.org/snapshots/packages/aarch64_cortex-a53/base/wpad-mesh-wolfssl_2021-05-22-b102f19b-46_aarch64_cortex-a53.ipk
Installing libwolfssl4.8.1.d8795272 (4.8.1-stable-6) to root...
Downloading https://downloads.openwrt.org/snapshots/packages/aarch64_cortex-a53/base/libwolfssl4.8.1.d8795272_4.8.1-stable-6_aarch64_cortex-a53.ipk
Configuring libwolfssl4.8.1.d8795272.
Configuring wpad-mesh-wolfssl.Utána menni fog.
-
dchard
veterán
Akit érdekel, ma estére lesz működő 160MHz-es build OWRT alatt. Egyéb 5.16-ból backportolt patch-ek is bekerünek, de egyelőre nem teljes a lista. Szokás szerint dupla sysupgrade-re van szükség: SCP-vel feltölteni a sysupgrade fájlt a /tmp/ mapppába, majd sysupgrade -c /tmp/sysupgrade.bin. Roouter újraindul, majd ugyanezt megismételni mégegyszer.
-
dchard
veterán
válasz
Black&White #3755 üzenetére
Sajnos egy csomó minden nem került be az 5.15-be, ami ráadásul az új LTS kernel. NÉzd meg ezt: [link]
Minden ami 2021-09-16 után van, az olyan funkció vagy javítás a Wifi driverben, ami jelenleg még nincs benne a Robi féle repo-ban (meg máshol sem). Köztük ott van az "ath11k: add support for 80P80 and 160 MHz bandwidth" nevű patch. Ezek backportolása meglehetősen időrabló. AP-oldalon szerint nem lesz sok gond vele, azt persze érdemes figyelembe venni, hogy az AX3600 és az AX6 is csak 2x2 MIMO módban tud 160MHz-et. -
dchard
veterán
Openwrt oldalon újabb előrelépés: a Qualcomm által kiadott legfrissebb Wifi firmware láthatóan javítja a memória szivárgás kérdését. Egyelőre nem lehet kijelenteni, hogy a probléma megoldódott, de a jelek bíztatóak.
-
dchard
veterán
válasz
siemensfun #3746 üzenetére
"Igmp-t próbáltam, de még az én tudasommal nem életképes.
A mesh-t is próbáltam de még az sem működik hiányzó csomagok miatt."Ezeket kifejthetnéd részletesebben. Az sem világos, hogy hogyan és melyik szolgáltatónál akarsz IPTV-zni. Az IGMP proxy kell kizárólag, és az IGMP snooping-ot be kell kapcsolni, de ez minden openwrt verzióra igaz.
A frissítéssel érdemes óvatosan bánni, többen panaszkodnak hogy csak a második frissítésre sikerül a dlog a webes felületen. Én egyelőre azt ajánlom, hogy a tmp mappába SCP-zd fel a sysupgrade nevű fájlt, majd a "sysupgrade -c /tmp/a_fájl.neve" paranccsal végezd a frissítést.
-
dchard
veterán
válasz
siemensfun #3743 üzenetére
Ha a webes felület nem töltene be ilyenkor, akkor SSH a "dmesg" parancs kimenete is jó.
-
dchard
veterán
válasz
siemensfun #3741 üzenetére
" de a wifi éjszaka teljesen elhalt"
Nálam ilyen kizárólag akkor volt, amikor a a router kifutott a memóriából. Ilyenkor LAN-on lépj be, és a kernel logot másold ki hogy lássuk mi történhetett. Nálam hetek óta nem volt ilyen.
A szabad memória lesz még kevesebb is, simán le tud menni 100MB környékére, de ez normális.
-
dchard
veterán
válasz
siemensfun #3738 üzenetére
Oké, ez bár nem pontos, lehet vele együtt élni. Majd lesz normális bdata erre is. A 160MHz-hez hiányzik még egy patch, tehát ahhoz türelmet kérünk. Azt érdemes tudni egyébként, hogy 160MHz-en ez a wifi chip csak 2x2 MIMO-t tud, és ez igaz a gyári FW-re is természetesen.
Összességében a következő érdekes lépés az lesz, hogy vajon az 5.15 vagy az 5.16 lesz-e a következő LTS kernel. Remélhetőleg az 5.16-os (ha kijön év vége előtt), mert van még egy nagy adag ath11k javítás, ami az 5.15-be nem került be, de már elérhető a kódbázison.
-
dchard
veterán
válasz
siemensfun #3733 üzenetére
Na ez remek. Ha lesz egy kis időd, akkor az "iw reg get" parancs kimenetét másold már be ide légy oly kedves.
Az OPKG nálam működik, webes felületről felraktam az igmpproxy-t, de annyi biztos, hogy ahogy a snapshot továbblép, extra kernel modulok nem lesznek telepíthetőek (érthető okokból), illetve bármi ami ezek függőségeire támaszkodik. Az IGMP proxy pont nem ilyen, de ez szerencse.
A mesh-t én nem próbáltam, mert nincs mivel. Ez egy jó összefoglaló: [link]
A mesh-t egyébként az OWRT-be épített driver támogatja.Hogy van-e valami webes mesh megoldás, azt nem tudom.
-
dchard
veterán
válasz
siemensfun #3730 üzenetére
Nincs benne igmp proxy, de ezt pontosan 1 perc alatt meg tudod tenni azzal, hogy telepíted a webes felületről.
-
dchard
veterán
-
dchard
veterán
SSH hozzáférés kell hozzá, azt mindenki ki tudja guglizni, sokszor volt már róla szó.
Ha megvan az SSH hozzáférés, akkor feltöltöd a /tmp/ mappába a routhernek megfelelő "factory" nevű ubi image-et, például ezt "openwrt-ipq807x-generic-xiaomi_ax3600-squashfs-nand-factory.ubi" (WinSCP és SCP protokol kiválasztása mellett)
Ha ez megvan, akkor a két rootfs-t tartalmazó partícióra beformázzuk a fájl tartalmát:
ubiformat /dev/mtd12 -y -f /tmp/openwrt-ipq807x-generic-xiaomi_ax3600-squashfs-nand-factory.ubi
ubiformat /dev/mtd13 -y -f /tmp/openwrt-ipq807x-generic-xiaomi_ax3600-squashfs-nand-factory.ubiUtána:
nvram set flag_last_success=0
nvram set flag_boot_rootfs=0
nvram commit
rebootÉs már boot-ol is az openwrt.
Ha valakinek nem jön be a dolog, akkor pontosan ugyanígy tud visszaállni is gyárira. Csupán arra van szükség, hogy a gyári firmware fájlból a rootfs-t ki kell szedni, tehát nem a gyári binárist kell beégetni egy az egyben.
Lényeges, hogy ez kizárólag gyári FW-ről garantált. Ha valaki turmányolt QSDK alapú szarral már telerakta a routerét, akkor akár gyárira, akár OWRT-re állni sokkal macerásabb lesz, mivel a QSDK alapú szarok megváltoztatják a gyári partíciós táblát.
-
-
dchard
veterán
válasz
xabolcs #3712 üzenetére
Na kéremszépen, sikerült levadászni az új stabil 2.5.0.1-es wifi firmware-hez tartozó hivatalos BDF file-t. És hála egy kismadárnak, ezt is szét tudjuk szedni és össze tudjuk rakni.
Összehasonlítva a gyári BDF-vel amivel a router jött, a regdb már sokkal jobban néz ki, bár továbbra sem tökéletes. Ezzel már lehet együtt élni azt hiszem. Természetesen mivel a BDF számos kalibrációs adatot is tartalmaz az adott platformhoz, a BDF-eket nem lehet össze-vissza cserélgetni, de így már van esély a normális működésre.
Közben az ath11k is nagy számban kap javításokat, tehát egyre használhatóbb lesz a dolog.
-
dchard
veterán
válasz
xabolcs #3705 üzenetére
Nem hiszem, a szar BDF-ből nem következik, hogy lefelé nem lehet állítani. Ha így van, az a Xiaomi sara lesz. Én elég gyorsan elhagytam a gyári szoftvert, OWRT alatt lehet állítani a teljesítményt mindkét rádión, így nem tudom megmondani, hogy a gyárin hogy működik a dolog. Bár korábban valaki írta, hogy a három fokozat az csak 3-3-3dB csökkentést tesz lehetővé, és ha 30dBm-ből indulunk ki, akkor a minimum power 21dBm, ami máshol általában a maximum, tehát simán lehet, hogy elég neki a minimumra állított gyári SW.
-
dchard
veterán
válasz
xabolcs #3687 üzenetére
Az nem most lesz, hogy kipróbálom. Failsafe módban mind a 3 portot végig próbáltad? Ezt leszámítva ha nem működik, akkor nem működik.
Sajnos jeleneg a legkisebb problémánk is nagyobb a nem működő failsafe-nél. Ha a reset sem működik, az mondjuk kicsit előbbre kerülne a prio listán. Most éppen a 160MHz megreszelése zajlik, de a BDF (vagy ahogy itt hívjátok, a bdata) megjavítása is sokkal előrébb van a listában. Utóbbi a fontosabb.
-
-
dchard
veterán
Hát azért ez messze van a királytól. Most valahogy úgy kell megerőszakolni a dolgot, hogy ha a user EU-s országkódot üt be, akkor is a jó reg domain beállítások menjenek ki. Majd még erőszakolgatom egy kicsit
De azért ebből is fel lehet mérni mekkora szar van a palacsintában a Qualcomm háza táján (a rendes wireless-regdb nem használható, ami meg a BDF_ben van, az úgy szar ahogy...).
-
dchard
veterán
Na, csak hogy megosszam az ömörhírt: két óra szórakozás után rájöttem, hogy hol van elszarva a regdb. A Qualcomm által kiadott firmware konkértan leszar mindent ami nem US country code alatt van. Úgyhogy most azt csináltam, hogy az US country code alatti profilt módosítottam hogy megfeleljen az EU/CEPT és így a magyar szabályozásnak is:
country US: DFS-FCC
(2400 - 2483 @ 40), (6, 24), (N/A)
(5150 - 5250 @ 80), (6, 24), (N/A), AUTO-BW
(5250 - 5350 @ 80), (6, 24), (0 ms), DFS, AUTO-BW
(5470 - 5725 @ 160), (6, 24), (0 ms), DFS, AUTO-BW -
dchard
veterán
Azt kell érteni, hogy itt nem "egy routerről" van szó, hanem a Qualcomm IPQ807x platformájról, amihez lényegében nulla támogatás volt a kernelben, amikor elkezdtük. Ebbe beletartozik a SoC, a perifériák, az ethernet és switch meghajtók, GPIO meghajtók, a firmware és a kalibrációs adatok betöltése, a wifiről már nem is beszélve. És ha ez nem lenne elég, a fospermet kategóriás gyári driverekről már nem beszélve. Tehát ami zajlik az platform fejlesztés, aminek a végén az összes olyan router amiben ez a platform van, támogatva lesz. Nem csak az AX3600 és az AX6, de egyéb routerek is. És tekintve, hogy ez egy jól sikerült SoC, már most látszik hogy egy darabig velünk lesznek ezek az eszközök, és szépen szivárognak le a középkategóriába.
-
dchard
veterán
Tisztelettel válaszolok. Egyetlen platform támogatása sem készült el ennyi idő alatt korábban, tehát nem jelent semmi rosszat. De ha érzed magadban az erőt, nyugodtan beszállhatsz a fejlesztésbe és akkor hamarabb kész lesz.
Meg ugye mi számít késznek? Én hónapok óta használom, és az 512MB profil patch-csel meg a hekkelt BDF-fel teljesen jól működik a dolog. De amikor az egész Qualcomm firmware stack egy rakás szar és a regdb rész úgy nem működik benne ahogy, és ezek zárt forrású részek, úgy azért nem olyan könnyű haladni vele.
A két legnagyobb probléma jelenleg az ath11k memória szivárgás, és a regdb. Előbbit az 512MB patch-csel lehet kezelni, amíg meg nem oldjuk. A regDB problémát 2.4-en sikerült megoldani a BDF módosításával (24dBm 1-13 csatorna), de az 5GHz-es részt még reszeljük, bár a legtöbb csatorna így is rendelkezésre áll 24dBm-mel, működő DFS-sel.
Tehát így állunk. Nálam faszán működik, ha az 512MB-os patch bekerül végre Robi repo-jába, akkor azt tudom mondani, hogy a bátrabbak kezdhetik a tesztelést.
-
dchard
veterán
Még egy kis frissítés: Robi-val rájöttünk, hogy a regulatory db problémákat tudjuk kezelni házon belül: Nálam például AX6-on ez volt a profil gyári BDF-fel:
phy#0 (self-managed)
country HU: DFS-ETSI
(2402 - 2472 @ 40), (N/A, 30), (N/A)
(5170 - 5250 @ 80), (N/A, 30), (N/A), AUTO-BW
(5250 - 5330 @ 80), (N/A, 24), (0 ms), DFS, AUTO-BW
(5490 - 5590 @ 80), (N/A, 24), (0 ms), DFS, AUTO-BW
(5590 - 5650 @ 40), (N/A, 24), (600000 ms), DFS, AUTO-BW
(5650 - 5710 @ 40), (N/A, 24), (0 ms), DFS, AUTO-BWA módosítás után pedig ez lett:
phy#0 (self-managed)
country HU: DFS-ETSI
(2402 - 2482 @ 40), (N/A, 23), (N/A)
(5170 - 5250 @ 80), (N/A, 30), (N/A), AUTO-BW
(5250 - 5330 @ 80), (N/A, 24), (0 ms), DFS, AUTO-BW
(5490 - 5590 @ 80), (N/A, 24), (0 ms), DFS, AUTO-BW
(5590 - 5650 @ 40), (N/A, 24), (600000 ms), DFS, AUTO-BW
(5650 - 5710 @ 40), (N/A, 24), (0 ms), DFS, AUTO-BWA jó hír, hogy mostmár nem vaktában lövöldözünk, hanem pontosan tudjuk szabályozni, hogy melyik csatornán, melyik frekin mekkora adóteljesítmény lehetséges, akár országonként is.
Tehát OWRT alatt a korábbi regdb problémák, nem használható csatornák, össze-vissza DFS idők rövid időn belül a múlté lesznek.
Persze ha valaki arra bazírozik, hogy majd gyártunk 30dBm-es BDF-et fullra kinyitva bárkinek, akkor csalódást kell okozzak. Viszont lesz egy korrekt regdb ami megfelel a szabályozásnak, és az összes legaláisan elérhető csatorna nyitva lesz benne.
-
dchard
veterán
Biztosan nem ugyanaz. Forrás nélkül pedig eleve nem beszélhetünk Openwrt-ről, sem semmiféle opensource megoldásról, ami jellemzően valamelyik gyári firmware házi tákolását jelenti.
Ha érdekel az openwrt, akkor ezt érdemes követni: [link]
Én ezt használom néhány extra patch-csel. Azt ath11k-ban továbbra is ott a leak, de ezzel (legalább is az 512MB-os driver patch után) lehet együtt élni. Továbbra sincs 13-as csatorna 2.4-en, és úgy általában a 30dBm-et el lehet felejteni, de ettől függetlenül frankón működik. IPoE és PPPoE offload vezetéken működik, 1-2% CPU mellett NAT-ol gigabitet PPPoE-n, stabil, nem szórja a csomagokat. Az NSS és a Wifi firmare-ek és több évvel újabbak a gyárinál, ez különsen AX és mesh oldalon sokat segíthet (nekem egyik sincs).
A terv az, hogy ha végre kijön az 5.15-ös kernel (1-2 hét), akkor Hauke megcsinálja a backportot 5.10-re, és akkor lesz egy sokkal jobb állapotú ath11k driverünk mint ami most van. Rengeteg hibát javítottak benne, de hogy konkrétan a szivárgást megszünteti-e, az majd kiderül. Lesz 160MHz is az 5.15 backport-ban.
Röviden: nálam faszán működik, a wifi is stabil, de ha valaki 30dBm-et akar, akkor maradjon a gyárin. Nálam AX6-on 24dBm a max power, de az erősítők amúgy sem tudnak többet az AX6-ban. Ax3600-am nincs, ha valaki felajánl egyet, szívesen kipróbálom azt is (nyilván a wifi része az érdekes, a többi ugyanaz). Egyébként az nagyon látványos, hogy mennyivel hűvösebb a SoC OWRT alatt (mert működik rendesen a freki váltás NSS-en is meg a SoC-on is).
-
dchard
veterán
válasz
trance89 #3372 üzenetére
1.1.19 és az AX6-ból is a legfrissebb elérhető volt az alany. Nyilván nem számítottam rá, hogy 11.4-es NSS és 2.5.0.1-es wifi-t fogok látni, de hogy a bő egy éve megjelent 11.3 és 2.4-es firmware-től is baromi messze vannak, az azért mutatja a probléma komolyságát... Pedig rengeteg hibát kijavítottak benne, főleg ami a mesh-t és az AX rádiókat illeti.
-
dchard
veterán
Csak a poén kedvéért belenéztem a legfrissebb AX3600 és AX6 gyári firmware-ekbe, hát kiábrándító volt. A wifi firmware ezer éves (qca_2.0, most a 2.5.0.1-nél tart a stabil branch), az NSS pedig olyan öreg, hogy még verziót sem ír ki, csak hogy mikor fordították (2020 első negyedév, de ez csak a fordítási dátum és nem inidkálja hogy mikori lehet, mérete alapján minimum 2-3 éves).
-
dchard
veterán
válasz
zelikocc #3110 üzenetére
"Otthoni körülmények között nincs különbség SEBESSÉGBEN a két router között."
Ez maximum akkor igaz, ha egyetlen kliensen nézed. A véleményed pedig e köré épül, holott a háztartások többségében nem egy eszközt kell kiszolgálni.
"És én nem jelviszonyról, meg nyalábformálásról beszéltem, hanem sebességről"
Az nyilván világos, hogy ez a három dolog szorosan összefügg, nem elválasztható.
"Felőlem lehet 100 antennás is ha a sebességben nincs különbség."
De van különbség, nem is kicsi, ez akkor is így lesz, ha nem veszel róla tudomást.
"A mobilhálózatokat meg azért nem kell összehasonlítani a WIFI-vel."
Pontosan ugyanaz az OFDM technológia mind a kettő, és a fejlesztési irány is közel azonos: több antenna az AP/BS oldalon és nyalábformálás, kevesebb antenna a kliens oldalon. Nem véletlenül van így: mert rájöttek, hogy nem egy eszköznek van szüksége még nagyobb sebességre, hanem sok eszköznek kell egyszerre egyenletes sebességet adni. Nagyon is össze lehet őket hasonlítani. Nem is fog ez megváltozni mert, a telefonokban nem fér el értelmesen több antenna, másrészt minden plusz antenna ág jelentősen növeli a jelfeldolgozási igényt --> nő a fogyasztás. Ez is oka többek között annak, hogy a plusz antennék alapvetően az AP/BS oldalon jelennek meg.
"Sajnálom ha úgy tűnik hogy nem értem a szakmám egyik technológiájának működését, ha azt mondom róla hogy felesleges, mert a gyakorlatban nem jelent akkora különbséget amennyivel többe kerül."
A szakmaiságnak pontosan az a lényege, hogy az ember le tudja választani a saját - sok esetben nem reprezentatív - véleményét a technológiai tudásról. Ezt hiányolom, de nincs ebben semmi személyes.
"Persze ha van 200 kliens wifin (azt már nem ilyen játék routerekkel kell kezelni) akkor már van értelme ennek az egésznek"
Reductio ad absurdum. A legtöbb ilyen router (4 antenna 5GHz-en) maximum négy BF irányt tud kezelni (az AX3600 és az AX6 is ilyen), ebből következik hogy maximum 4 kliens megfelelő elhelyzekedése esetén már maximalizáltad a kinyerhető többlet sebességet. Megjegyzem, hogy amikor ilyeneket írsz hogy 200 kliens kell ehhez, abból megint az látszik, hogy nem érted a működését a dolognak, vagy szándékosan túlzol.
"Én nem fikáztam az AX3600-at csupán azt mondtam hogy SZÁMOMRA semmivel sem tud többet."
Nekem nincs AX3600-am, tehát ez az egész hidegen hagy. Az viszont, hogy alapvetően úgy állítod be a több antennás rendszereket ahogyan azt kifejtetted, már annál inkább. Még egyszer: a személyes véleményedet és igényeidet el kell tudni választani a technológiai tényektől. Ha szakdolgozatban írnál le ilyeneket, annak sem lenne jó vége.
-
dchard
veterán
válasz
zelikocc #3107 üzenetére
"És továbbra is minden telefon és minden laptop 2 antennás"
A telefonok döntő többsége egy antennás. A flagship-eket meg 1-2 felső közép kategóriás darabot kivéve.
"Nagyon nagy parasztvakításnak tartom ezeket a hiperszuper sok antennás és sok gigás routereket"
Többször kiderült már, hogy nem érted ennek a technológiának a működését. Ez lehet a kulcs. A router oldalán lévő "sok" antenna nem azért kell, hogy 4x4 meg 8x8 MIMO legyen, hanem azért, hogy a BF tudjon rendesen működni. És ehhez a kliens oldalon nem kell több antenna, pont ez a lényeg. Minél több antenna a router oldalon, annál több és pontosabb nyaláb alakítható ki. SZerinted a mobilhálózatokban minek raknak 32 meg 64 antenna elemet tartalmazó aktív antennákat? A telefonban sosem lesz 32 meg 64 antenna, mert nem fér el benne.
"Egyébként egyetemista vagyok (hálózat spec)"
Hanyad éves, melyik egyetem?
Kicsit olvasgatni kéne még a témában és kevesebbet kinyilatkoztatni.
-
dchard
veterán
válasz
E.Kaufmann #2758 üzenetére
1043ND óta használok OWRT-t, közvetlen környezetmeben van kb. 10 router, különböző hatdvereken, de sosem volt stabilitási problémám, leszámítva azt amikor a hw döglődött. De hogy ne legyek teljesen off topik: az ax3600/ax6 támogatásnál is már csak annyi a probléma, hogy a gyártó által kiadott driver szivárog. Érted, ezt sem az owrt devek baszták el, érdemes volna inkább a gyártót szidni, aki fospermet minőségű tákolmányt ad ki, ezer éves szétpatch-elt kernelre. De nem sok értelme van olyat győzködni erről, aki nem tud különbséget tenni a gyártói SDK, meg a valódi owrt között.
-
dchard
veterán
Ebben annyi sületlenség van, mint amennyit korábban már láthattunk tőled az Openwrt-vel kapcsolatban:
"2. Konnyen lehet, hogy a nagyobb teljesitmennyel zart terben mar akkora interferenciat okoztal sajat magaddal, hogy tobbet art mint hasznal.
3. 5Ghz es 2.5Ghz kozott oriasi kulonbseg van!
Az 5Ghz-es jelek sokkal konyebben visszaverodnek feluletekrol es okoznak karos interferenciat, valamint a targyakba utkozve sokkal jobban elnyelodnek, mint a 2.5Ghz-es jel."A vert jel ezer éve nem okoz interferenciát, a MIMO pontosan ezt használja ki. Nem tudsz saját magaddal interferálni. A cyclic prefix-ről tessék olvasgatni kicsit, meg a soft combining-ról, mert az IRC-ről, meg a precoding-ról.
-
dchard
veterán
A példádban több nagyságrendi tévedés van. A Voyager-rel kapcsolatban elfelejted, hogy a földön nem csak elképesztő méretű (és tökéletesen kihangolt) antenna van, hanem olyan LNA és detektor sor, aminek a vételi érzékenysége önmagában (értsd: az antenna nyeresége nélkül is) világklasszis. Ehhez képest a routeren mondjuk lehyen 3-4dBi nyereségű antenna, a telefonon meg 0dBi körüli. Viszont te 20dBm helyett 30dBm-mel fogod tolni neki a jelet, tehát már aránytalan a két irányod. 3-4dB vs. 10dB különbség. De még egyszer: az antenna nyeresége fix, a kisugárzott teljesítmény az, ami változik. Ha a gyári antennák helyett felraknál teszem azt egy 6-8dBi-s verziót, az arányok akkor sem változnának meg: max teljesítményen továbbra is lenne olyan pont, ahol a telefon hall, a router már nem; csak egyszerűen távolabb lenne. De ettől még ugyanúgy nem lenne értelme full powerrel tolni. De ezt a témát lezárom, aki megértett az megértette, aki nem az nem.
-
dchard
veterán
válasz
Lackooo84 #2744 üzenetére
A router "hangosabb", ezért a telefon képes érézkelni, de mivel a telefonnak jóval kisebb a kimenő teljesítménye, így a router már nem "hallja". A példád úgy helyes, hogy te hangosbeszélővel odakiabálsz mondjuk nekem, de én már csak a saját hangommal válaszolok, így én hallak téged, de te engem már nem.
-
dchard
veterán
válasz
PainKiller69 #2735 üzenetére
Ez tökéletesen szemlélteti az alapvető problémát.
@Rick4:
"egy jó és egy rossz antenna között lesz különbség"
Naná. De itt nem tudsz antennát cserélni, ezért az antenna nyereség adottság, nem változó. Az egyetlen amit változtatni tudsz, az a kimenő teljesítmény. A különböző frekik közötti váltás úgy jön a képbe, hogy a telefon például vételi szint alapján dönt a handover-ről. Ha te feltolod a kimenő teljesítményt, akkor a telefon nem tudja érzékelni, hogy a kapcsolat szar minőségű (nincs uplink) és le kéne váltania 2.4-re.
-
dchard
veterán
Az antenna nyeresége vételi és adási irányban is konstans. Viszont a kimenő teljesítmény nem. Attól hogy tekergeted a kimenő teljesítményt, a vételi oldalad még ugyanolyan szar marad. Ebből adódik a probléma, hogy eltolódik az arány: a kliens hallani fogja az AP-t, de az AP nem fogja hallani a klienst. Az antenna nyeresége a link egyensúlyát nem befolyásolja, hacsak nem raksz fel a kliens oldalra is nagyobbat. És a két kolléga által körülírt probléma pár nappal ezelőttről is pontosan így néz ki. A lefedettség korlátja éppen ezért a kliens és nem a router/AP.
Más:
Az AX3600 mellé elkészült az AX6 támogatás is, mostmár nem kell a board file-okkal mókolni, egyszerűen forgatható saját build AX6-ra is. A legnagyobb probléma egyelőre a Qualcomm által kiadott ath11k driver masszív szivárgása, ha ez megoldódik, akkor kerül be a hivatalos támogatás a master-be.
-
dchard
veterán
Hányszor, de hányszor leírtam már.... A példád rossz, mivel az csak az antenna nyereségre igaz, az adóteljesítményre nem. Attól a routerben lévő LNA nem fog nagyobbat erősíteni a vételi oldalon, hogy emeled az adóteljesítményt. A kolléga jól gondolja: egyoldalúan emelni a link egyik oldalán az adóteljesítményt semmit nem ér. És milyen érdekes, hogy a napokban többen is leírták, hogy hiába látnak kettővel több pucukát, a távoli ponton lévő IP kamera stb. nem működik ettől jobban, mert uplinked az ettől még nem lesz.
-
dchard
veterán
válasz
Nightmare666 #2726 üzenetére
Nagy és nehéz, óccsó shipping ennél fogva kevéssé valószínű. Még ha az ára be is zuhan valaha.
-
dchard
veterán
"Egy ipari hulladek ez az openwrt"
"Ha megoldom az ssh hozzaferest,"
Na akkor döntsük el, hogy openwrt-t használsz (kizárt), vagy a gyári szoftvert szidod, aminek az ég világon semmi köze az openwrt-hez. Ha nincs SSH hozzáférésed, akkor biztosan a gyárit használod, ebben az esetben a QCA-t és a Xiaomi-t lehet szidni, az Openwrt-t hagyd ki ebből. Apropó, eddig nem az volt a mondás, hogy az openwrt csak játékra jó?
A hőmréséklet adatok sensors nélkül is kinyerhetők, de hát ki vagyok én, hogy megmondjam neked a frankót.
-
dchard
veterán
válasz
xabolcs #2659 üzenetére
"Igen, olvastam, hogy ugy tunik, ez nem bug, hanem feature."
Bug az, NSS offload mellett nem jön elő. Őszintén szólva gondoltam erre én is, de Ansuel megelőzött. A tetű QCA képes volt ezt is elszarni... Valamiért azt képzeltem, hogy a Mediatek után bármi jobb lehet, de mostmár világos, hogy "üzleti" alapon mindenki csak trágya kódot tud kiizzadni magából. Ennek elejét kellett volna venni olyan licenceléssel, hogy olyan nincs, hogy valaki ingyér leforkolja több ezer ember évtizedes munkáját, aztán rálapátol egy rakás trágyát, és ezt eladja az ügyfeleknek mint "linux". Kötelezni kellett volna őket, hogy fork helyett szépen csináljanak normális támogatást (vagy fejlesszen saját OS-t), és akkor nem tartanánk itt. De ez már politika.
-
dchard
veterán
Garancia nincs semmire, webes felületről egyelőre nem konfigurálható, mivel a Luciban nincs még AX támogatás. Nálam AX6-on 24dBm a max 5GHz-en, de az erősítők amúgy sem tudnak többet. Azt kéne megnézni, hogy AX3600-on az international és a kínai fw között van-e különbség ami a board file-t illeti. Illetve van probléma a 12-es 13-mas csatorna kiválaszthatóságával (nem választható ki
). De funkcionálisan működik minden. Mesh-t én nem próbáltam (ha akarnám se tudnám).
-
dchard
veterán
válasz
xabolcs #2648 üzenetére
Nyugodtan használhatod. Mivel úgy néz ki, hogy nem memleak van, hanem az ath11k ennyi memóriát kajál meg.
A gyári firmware-ben (igaz ez az ax3600-ra és az ax6-ra is), ezer éves a wifi és az NSS mikrokód is, simán előfordulhat, hogy a fenti gyári értékekhez képest ninnen származik a különbség. Azért láthatod, hogy a 400MB-ból csak 100MB van szabadon, és mindez az ezer éves mikrokódokkal.
-
dchard
veterán
Valaki, akinek van SSH hozzáférése az ax3600-ához, és jópár napja fut már és használja az 5GHz-es rádiót is, legyen már olyan kedves és futassa le a "cat /proc/meminfo" parancsot, és másolja be ide a kimenetét.
Köszi!
-
dchard
veterán
No kérem, működik a PPPoE offload is, 1-2% CPU load mellett NAT-ol 950Mbit-et.
-
dchard
veterán
válasz
trance89 #2596 üzenetére
Hát, a haladás az jó, de az ECM/NSS hivatalos támogatása az biztosan odébb van még. Persze ettől még remekül használható a router, ha pedig így hamarabb kapjuk meg a komplett NSS-t, akkor nem zavar. Valószínűleg a HW támogatás (NSS nélkül) hamar meglesz, az NSS pedig community package-ként lesz elérhető.
Nem győzöm hangoztatni, hogy a QCA megint mit művel a kódbázissal. Megint lehet látni, hogy szó nincs itt a szellemi tulajdon védelméről. Egyszerűen olyan szar minőségű kódot írnak, hogy azt lehetetlenség upstream betolni a kernelbe, mert Torvalds papa pofán röhögné őket, ha ezt a szart megpróbálnák becommit-telni.
-
dchard
veterán
Tlala:
Szintet léptünk, működik az NSS offload IPv4V6-ra a routeren (1-2% CPU load gigabit DL/UL mellett). Kipróbáltam PPPoE-n is, és SW offload mellett ki lehet nyomni belőle a gigabitet PPPoE-n is, az átlagos kihasználtság 50% alatt marad magonként. Ennyi nekem már elég, így beraktam elsődlegesnek és egyelőre tesztelek. A wifi alap profilokat még reszelni kell, de azért kis adjusztálás után jól működnek. Nekem AX kliensem nincs, AC-n jónak tűnik a dolog. A PPPoE NSS offload készül, ha minden jól megy, este már tudom tesztelni.
Szóval azt mondanám, hogy lassan lehet készülni a béta tesztre
-
dchard
veterán
Továbbra is azt mondom, hogy a gyári szoftverre visszaállni megér egy próbát (a tápcserén túl), de azért ha már mindent kipróbáltál és semmi sem segít, azért majd szólj melyik kukába rakod.
Tlala:
OWRT témában érdekesség még, hogy az 512MB RAM-ból csak 376MB látszik, mivel az AX-es mikrokód és az NSS magok mikrokódja ennyi memóriát megkajál (a gyári is), és ebből a maradék 376MB-ból is jellenzően 120-150MB foglalt. Ebből az az általános igazság jön ki, hogy 512MB alatt nem érdemes AX-es routert venni, mert egyszerűen nem fér bele normálisan a működéshez szükséges összes alap szoftver sem, nem hogy egyéb telepített alkalmazások.
-
dchard
veterán
Semmi mókolással nem próbálkoztál, ugye? Ha csak a wifit érinti a probléma, gyanús hogy a hw hibán túl sérülhetett a BDF vagy az ART, ami minden routeren egyedi, ha nem volt róla mentés, nem lehet helyreállítani.
Ami általánosságban jellemző, hogy a kisebb táp hibákra a wifi érzékenyebbe reagál, így ha könnyen nem tudod gariztatni, akkor egy másik táppal még érdemes lehet kipróbálni. A Xiaomi-nak egyébként van valami windows-os szoftvere, amivel lehet egy teljes visszaállítást tolni, ha minden kötél szakad azzal megpróbálnám visszaállítani a firmware-t. De valóban hw gyanús amit leírtál.
-
dchard
veterán
SSH és root kell hozzá, mtd12-13-ra ráformázod az openwrt UBI image-et. Visszafelé pedig úgy lehet majd menni, hogy az mt12-13-ra visszaformázod a gyári UBI image-et. Azt majd kihekkelem a gyári firmware image-ből (nem nagy mutatvány). Nekem eszembe nincs visszaállni, elég jól működik már most is. Pár napig még tesztelem aztán berakom elsődlegesnek. Nem lehet elmondani, hogy mennyire nem fog hiányozni a Xiaomi szar webfelülete
-
dchard
veterán
Úgy tűnik a fiúk csinálják az ECM-et (Qualcomm féle gyorsítás), IP-n már egész jól működik, szét tudja dobni a terhelést 2-3 mag között 15-35%-os terheléssel magonként. Egyeőre IPv4, IPv6, bridge és Wifi offload van a csőben, próbálom nyomni a PPPoE-t, bár ha a tiszta IP-t így ki tudja nyomni, jók az esélyek hogy flow offload mellett kinyomja a PPPoE-t is.
-
dchard
veterán
Na kérem. A BSS survey problémát sikerült javítani, mostmár megy a DFS/ACS ahogy kinéz. Az NAPI probléma is javítva lett, pár száz gigát áthajtottam tiszta IP-n a NAT részen, egyenlőre én nem látok semmi rendelleneset. 1magot megkajál flow offload mellett a NAT, kérdés mi lesz PPPoE-n.
-
dchard
veterán
Egy hét alatt sikerült minden perifériát működésre bírni, elképesztően jó a tempó. Ahogy elnézem a NAT-tal sem lesz gond, ha egy mag minden nélkül kiizzad 600megát, akkor elég lehet a sw flow offload meg a pakcet steering a gigabithez, amíg a srácok beheggesztik az NSS-t. A jelenlegi dev repóban egyébként a wifi firmware is jóval frissebb mint a gyáriban. Ahogy a maradék kis hibákat kireszelik, már állok is át.
-
dchard
veterán
AX6-ra forgattam ma egy saját build-et, kis belenyúlkálásra szükség volt, mert bár a rádió ugyanaz, az BDF file nem egészen az mint ami az AX3600-on volt. Sikerült elindítani a vezetékes részt és mindkét rádiót. A sebességekkel még van némi porbléma, főleg azért mert 1 magon kikoppan a technika 600mega DL-nél (IPoE nem PPPoE), de itt semmilyen gyorsítás nincs, sem packet steering. Valszeg a scaling driver is kehes még, mert azért 1.4GHz-en IP-n ki kéne köpni a 900megabitet.
Amúgy üresjárásban érezhetően sokkal hűvösebb a cucc.
-
dchard
veterán
Ahogy kinéz, haladnak a fiúk elég jó ütemben, sikerült az IoT rádiót is életre kelteni, már csak a hőmérséklet érzékelés és a hozzá kapcsolódó throtling van hátra, minden más működni látszik. Nyilván tartós stabilitás teszt során jöhet még elő bármi, aki a dev topikt olvassa, láthatja hogy a Qualcomm micsoda trágya kódot nyom ki magából... Hiába van forráskód, ha upstream minden szart újra kell implementálni.
-
dchard
veterán
Ha lesz érdemi áttörés, azt akkor majd megosztom. Egyelőre az derült ki, hogy azért nem ment a korábbi próbálkozások során egyszerre a WIFI és a LAN, mivel mindkettő igényli a Qualcomm NSS névre hallgató gyorsítási alrendszerének a működését, ez most a legnagyobb probléma. Hogy ezt elég-e csak inicializálni, vagy effektíve be kell kötni (értsd: használni "kell"), az nagy kérdés.
-
dchard
veterán
Ha valakit érdekel, a két releváns dev újra nekifogott a router (és a platform) openwrt támogatásához, nemegész 1 nap alatt elég sokat haladtak.
-
dchard
veterán
válasz
Black&White #2510 üzenetére
A QSDK-n alapuló hekkelést (amiről szó van semmi köze az OpenWRT-hez) nem nevezném open source-nak. Próbáltam az illetőből aki az említett firmware-t csinálta, kihúzni a forrást, de nem jártam sikerrel... Tehát semmit nem tudunk a tartalmáról azt leszámítva, hogy rengeteg szemét van benne, és többek között ezért a telepítése a gyári fájlrendszer szétrombolásával jár (ebben is eltér a valódi openwrt-től, ahol ez nem fordulhat elő).
-
-
dchard
veterán
válasz
siemensfun #2501 üzenetére
Ugye tudod, hogy újraformázza a flash memóriát és megváltoztatja az MTD struktúrát is? A poén majd akkor jön, amikor a gyári verziót vissza kell állítani bármilyen okból. Vagy kijön a valódi OWRT hozzá. Ezért nem raktam még fel én sem, pedig "igény az vóna rá..."
-
dchard
veterán
válasz
Nightmare666 #2482 üzenetére
Egyszer vettem olcsó 12V/3A-s tápot, de nem bírt kinyomni 2A-t sem. Szétszedtük és a belseje alapján 12V/0.5A-s elektronika volt csak rácímkézték hogy 3 Amper. A korábban már említett MeanWell tápokat tudom ajánlani, a korábbi szívások után én is ilyet vettem, nem is egy működik mostmár évek óta.
-
dchard
veterán
Nálam AC only módban megy az AX6, úgy nem lassul az 5GHz. Lehet neked is ki kéne próbálni AC only módban, hátha közelebb kerülnél a megoldáshoz. Szűrő minden létező rádiós eszközön van, egyrészt így limitálják a vevőre jutó összes teljesítményt (így javítva a vételi érzékenységet), másrészt így akadályozzák meg, hogy hiba esetén sávon kívüli adás történhessen. Nem típus függő
-
dchard
veterán
Ez oké, de pont az a fúrcsa, hogy az AX6 FEM-je gyengébb valamivel, mint az AX3600-é. Persze ne adj isten az is megtörténhet, hogy ha kínai 3600-zal mértek full power-en, akkor nagyon közelről simán széttolhatják a kliens vevő részét, és akkor valamivel szarabb eredményt kapnak. Akárhogy is: ezek nem laboratóriumi mérések, számos oka lehet a különbségnek, ami ráadásul elhanyagolható, és távolról sem biztos, hogy nem mérési hibát látunk.
-
dchard
veterán
válasz
ktommy91 #2409 üzenetére
Az túlzás, hogy semmit nem ad, de maga a teszt (közel térben) nem azt vizsgálta, hogy ezek között mekkora a különbség. OWRT szempontjából nincs különbség az AX6 és az AX3600 között, ha lesz támogatás az egyikhez, lesz a másikhoz is (tök egyforma a kettő). Nálam van SSH AX6-on is, bár én TTL-sorossal csináltam, nem tudom az ismert exploitok valamelyike működik-e rajta, az xqrepack biztosan működik, mert kipróbáltam
-
dchard
veterán
válasz
ktommy91 #2398 üzenetére
Miért ne lehetne? A két említett routerben ugyanaz a rádió van, és a teszt nem is mutat ki érzékelhető különbséget. 50-100megabit ebben a kategóriában szinte semmi, az adódhat a környezetből, vagy a mérést végző személy pozíciójából is (az emberi test különösen ezen a frekvencián nagyon reflektív rádiós szempntból). Az AX3600 nagyobb kimenő teljesítménye (kínaisítás után) nyilván nem tud megjelenni egy ilyen tesztben, mert itt nem elsősorban a lefedettséget vizsgáták, már amennyire látom.
-
dchard
veterán
Azt valaki leírhatná, hogy a router-t magát hogyan lehetne elérni kívülről, mivel hiába forwardoltam be portot akár a webes akár SSH eléréshez, egyik sem akar működni. Természetesen natív elérés érdekel, nem Micloud-os, app-os és egyéb bohózatok
-
dchard
veterán
válasz
morpheus133 #2144 üzenetére
Az igen, nem gondoltam hogy látok még CC-t.
A viccet félretéve: erre lehet mondani, hogy openwrt, de valójában nagyon messze van tőle.
-
dchard
veterán
A frontend chip kivételével (meg a plusz 2.4-es IoT rádiót leszámítva) teljesen ugyanaz. Olyannyira, hogy a legfrissebb firmware-ben ugyanazzal a mikrokóddal indítja el az 5GHz-es rádiót mindkét router. Az utolsó (márciusi) frissítésben elég sokmindent kijavítottak, bár szakadozást én nem tapasztalok az AX6-tal (az is igaz, hogy Wifi5 módban használom mivel nincs AX képes kliensem).
Sajnos továbbra sincs OWRT támogatásban előrelépés.
-
dchard
veterán
válasz
emzeperix #1985 üzenetére
Oké, tehát az az állítás, hogy ahol CN verzióval stabil jó kapcsolat van, ugyanott ugyanazokkal a kliensekkel, ugyanabban a környezetben ha átrakod global verzióra, akkor meg nincs semmi? Ha ilyen tényleg van, és ezt valaki normális A-B teszttel kimérte, akkor az egyetlen magyarázat, hogy global verzióval a router annyival sem ad, amennyivel adhatna (100mW), más műszaki magyarázatot én nem látok. Ez csak bug lehet a global verzióban, vagy a regdb-t szarul csinálta meg a Xiaomi. Tisztán szoftver probléma, mivel a HW ugyanaz. Ez azt jelentené, hogy a global verziót kis túlzással muszály áthekkelni, hogy legalább a 100mW meglegyen. Nehéz elhinni, hogy ez még senkinek nem tűnt fel a gyártó oldalán, mivel rengeteget eladtak az EU-ban is az AX3600-ból.
-
dchard
veterán
válasz
emzeperix #1982 üzenetére
"Csak az antenna-LNA páros jósága miatt jobb a hatótáv?"
Igen. Az antenna ágak száma nagyon lényeges: 1 antenna helyett kettő 3dB javulás (duplázás), 2 helyett 4 antenna megint duplázás, 4 heyett 8 megint duplázás és így tovább. De csak adott frekin, tehát nem azt kell énzni, hogy összesen hány antenna van a routeren, hanem hogy ebből mondjuk hány antenna tartozik az 5GHz-es rádióhoz. Régebii routereknél még az is elófordult, hogy volt rajta 3 antenna, de ebből adni csak kettő adott, a harmadik antenna "csak" diversity volt.
"De akkor miért van az, hogy a global verziós router az ő 29-32 mW-jával csak az "átlag" hatótávot tudja?"
EU/Global verziós routernek tudnia kellene a 100mW-ot (antenna nyereséggel együtt persze), ez a 32mW a router oldalán gyanúsan kevéske. Nálam AX3000-ből kijön az a 21dBm amit a frontend gyártója megad maximumnak, de egy grammal sem több, hiába ír az IW 30dBm-et. Az AX3600 sem tud 1 wattot áganként, ez is közkeletű tévedés, hanem összesen tud 4x250mW-ot a négy antenna ágon összesen (lásd: frontend specifikáció).
Korábban mintha felmerült volna már ez a 30mW körüli kimenő teljesítmény Global verziónál, de az iw list-en kívül nem mutatott még senki hihető mérést ezzel kapcsolatban. Gyorsan átnézve a régiós listákat, nem találtam egyetlen országot sem, ahol 5GHz-en 100mW alatti regulatory limit lenne. De persze miért ne: ha valaki felajánl egy AX3600-at, meg tudjuk mérni a különböző beállításokat spektrum analizátorral
Az AX3000-et már megmértem, azért vagyok ennyire magabiztos
-
dchard
veterán
válasz
emzeperix #1980 üzenetére
Hát persze, mert az AC65P-nek csak három antenna ága van, és az LNA is szarabb benne mint az AX3600-ban. Ez az összességében 2-3dB különbség simán kiadhatja az általad tapasztalt duplázódást. De nem azért, mert 1 wattal ad. Az alap kérdés az volt, hogy van-e különbség az AX3600 CN és EU (vagy global) verziói között. Mivel ugyanaz a HW, a vételi érzékenysége régiótól függetlenül ugyanaz, tehát a kimenő teljesítmény (egyoldalú) felpiszkálása nem fog segíteni senkinek (más router esetén sem fog).
Ha létezik olyan router, aminek az adott frekin 6 vagy 8 antenna ága lenne, annak még jobb lesz a vételi érzékenysége, ergó létezhet akár az AX3600-nál is jobb router, de ennek megint az antenna ágak számához és a frontend chiphez (főleg LNA) van köze, nem a kimenő teljesítményhez. A beamforming is tud nyereséget hozni uplink irányban is, bár ez nagyon környezet függő, míg a diversity combining sokkal kevésbé (máshogy megfogalmazva sokkal nagyobb eséllyel realizálható a diversity nyereség mint a BF nyereség).
-
dchard
veterán
válasz
emzeperix #1978 üzenetére
Nem mondasz hülyeséget, az oksági összefüggésnél van a hiba: a vételi érzékenységet az LNA és az antenna ágak összessége adja. Ez routerek között adhat különbséget, de ugyanazon router CN és EU verziója között nem. Például az AX3000-nek ugyanúgy 4 antenna ága van mint az AX3600-nak, de utóbbiban picit jobb az LNA, ergó annak összességében jobb a vételi érzékenysége. De nem azért mert EU helyett CN régiós, hanem azért mert eleve jobb a frontend chip benne. A telefonokat, és laptopokat nem is tudod "megpiszkálni", mert abban az aksi kímélése miatt eleve csak 32mW-os erősítőket raknak, sehogy nem lehet őket feljebb piszkálni.
-
dchard
veterán
válasz
DonJoee #1976 üzenetére
Akkor még egyszer: attól hogy az adó oldalon növeled a teljesítményt, a routerhez csatlakozó egyik eszközöd sem fog nagyobb teljesítménnyel adni. Tehát hiába ad a routered 20 helyett 25 vagy 30dBm-mel, a klienseket hallani ettől még nem fogja jobban. Csak az e-pénisz fog nőni tőle, hogy 3 pucuka helyett 4 pucukát mutat a telefon vagy a laptop. És tekintve, hogy a laptopok, telefonok még 100mW-tal sem tudnak adni, a limitáció mindig ezen az oldalon lesz, nem pedig a router-nál. Ezt kéne már végre megérteni. 200wattos erősítőt is köthetsz a routerra, attól még uplinked nem lesz, ami a valódi limitáció a WIFI-nél. Az egyetlen eset ahol ennek van értelme, az ha két ilyen router néz egymással szembe mesh-ben. Minden más esetben szimpla önámítás az adásteljesítmény felpiszkálása.
Új hozzászólás Aktív témák
Hirdetés
- Samsung Galaxy S24 Ultra - ha működik, ne változtass!
- exHWSW - Értünk mindenhez IS
- Házimozi belépő szinten
- Kertészet, mezőgazdaság topik
- Milyen légkondit a lakásba?
- Nintendo Switch 2
- Google Pixel topik
- sziku69: Fűzzük össze a szavakat :)
- Formula-1
- Honor Magic7 Pro - kifinomult, költséges képalkotás
- További aktív témák...
- Easun iSolar SMW 11kW Twin Hibrid inverter // Dupla MPPT // BMS // WiFi
- GAMER PC : RYZEN 7 5700G/// 32 GB DDR4 /// RX 6700 XT 12 GB /// 512 GB NVME
- GAMER MSI LAPTOP : 15,6" 144 HZ /// i5 12450H /// 16GB DDR4/// RTX 4050 6GB/// 1TB NVME
- Manfrotto 055 magnézium fotó-videófej Q5 gyorskioldóval
- Sony ECM-W2BT
- BESZÁMÍTÁS! 4TB Samsung 870 EVO SATA SSD meghajtó garanciával hibátlan működéssel
- 123 - Lenovo Legion Pro 5 (16ARX8) - AMD Ryzen 7 7745HX, RTX 4070 (48 hónap garancia!)
- Ikea Eilif Paraván - Asztali elválasztó
- AKCIÓ! Gigabyte H510M i5 10400F 16GB DDR4 512GB SSD GTX 1080Ti 11GB Rampage SHIVA Zalman 600W
- Bontatlan ASUS TUF Gaming F16 FX607JV-QT212 Notebook
Állásajánlatok
Cég: Promenade Publishing House Kft.
Város: Budapest
Cég: PC Trade Systems Kft.
Város: Szeged