Re: [OpenWrt-Devel] Fix TX power handling
> I've stumbled across problems with the transmission output power of OpenWrt > routers quite often. > E.g. https://bugs.openwrt.org/index.php?do=details_id=1289=4 > which I still have to look into in greater detail. > OpenWrt's handling of TX power, antenna and PA gains needs to be revised > thoroughly. > There is a iw patch in OpenWrt that is being used for setting the antenna > gain. > There was one try of nbd to upstream this change in 2013: > https://www.spinics.net/lists/linux-wireless/msg111944.html > I'd like to make some things clear here and hope that there will be a new > attempt to getting this upstreamed. > First EIRP is by definition ERP + antenna gain - cable loss. > And ERP is radio chip output + PA chip gain - (board's signal path loss which > is likely > irrelevant due to golden device calibration). > If there is a regulatory limit of the antenna gain that (whyever) means that > no antennas > with a higher gain are allowed - this does not really make sense. > It certainly does not mean that you can exceed the EIRP > by the antenna gain as this would reduce the definition of EIRP to absurdity. > If the regulatory domain values aren't plausible (because why in the world > should > there be a limit to the antenna gain when there is a EIRP limit already?), > we should not work around that, because otherwise nobody will see the mistake > - > It is a problem of the regdb then, which likely needs to introduce a new > regulatory > definition for maximum ERP and maximum antenna gain for affected regions, > which > would still don't really make sense, but maybe laws are just weird in this > regions. > Second e.g. most TP-Link routers don't use the ART's antenna gain field. > Instead they use the TX gain field (which should have been used for defining > an > external PA chip's gain instead). I assume that they did it to circumvent > problems > with the regdb... > Finally some device's (Ubiquiti XM/XW) external PA chip gain is defined in > stock > firmware depending on the subvendor device ID of the radio chip. > These definitions are being defined in: > https://git.openwrt.org/?p=project/iwinfo.git;a=blob;f=hardware.txt > I've filed a patch which adds all PA gains of Ubiquiti XM/XW devices to > iwinfo which > I've extracted from the stock firmware, but it seems to be ignored until now: > https://www.mail-archive.com/openwrt-devel@lists.openwrt.org/msg46175.html > AFAIK OpenWrt does not make use of these values, yet leading to a much higher > EIRP than allowed if these values are not manually adjusted. > Thus to my best knowledge what has to be done is: > 1. add options for external PA gain in iw and nl80211 code > 2. display antenna gain and PA gain in iw > 3. check if ath9k code sets PA gain and antenna gain correctly and > if not, fix it > 4. for devices whose PA gain does not seem to be defined in ART like > Ubiquiti XM/XWs, add a hotplug script to OpenWrt that sets >the correct PA gains from iwinfo using iw. > 5. for devices whose antenna gain neither seems to be defined in ART's >antenna gain nor it's TX gain field, add a hotplug script to OpenWrt >that sets the correct antenna gains manually on a model basis using iw. > 6. take measurements to check if the ERP meets expectations > 7. upstream all these changes and make regdb developers aware > I'd like to do this by myself, but I don't have time for it. > Still I can help with the measurements etc. > If someone feels capable of doing this, this would be a great improvement > and help OpenWrt to keep a stand against vendor locking. > Regards, > Vincent Wiemann A few discussion points, although I would have to learn a lot to be capable of implementing. Not going to happen anytime soon. 1) Here is a chart of the max xmit power permissible with US FCC part 15 regulations by channel. This chart assumes negligible internal antenna feed line loss: https://www.scc-ares-races.org/mesh/doc/WiFi_Part_15_Power_Limits_v150424.pdf 2) The antenna array gain seems to be the reverse perspective? Isn't the power split based on the count of physical antennas -- there isn't a power setting per xmit chain, correct? 2 antennas, the power is split on the 2. 3 antennas, the power is always split on the 3, ... For MCS0, all antennas transmit same signal and add up to total power radiated. If the specs of a 2 antenna device say the max xmit power is 25dBm, we set 25dBm with iw, then 22dBm is transmitted going to each antenna. (-3dB is half power). Each antenna chain has its own Power Amp (PA)? 3) Reduced power with increased MCS rates? An inspection of the UBNT specs show a decline in max xmit power as MCS rates increase. I understand this is due to keeping linearity in the PA. To contain hardware costs there is a sacrifice of dynamic range of the signal the PA can amplify. As rates go up, it needs more dynamic range and when going out of linearity, we start seeing increasing out of channel energy,
Re: [OpenWrt-Devel] [PATCH] ath79: Add SUPPORTED_DEVICES for Archer C7 v1/v2
Adrian- I have a C7V2 and can do some testing on it if you'd explain exactly what you're looking for... I don't quite follow what is needed in the above thread. Something about looking at PCI paths before and after an upgrade from one version to another... Camden On Mon, Apr 22, 2019 at 4:45 AM wrote: > Hi all, > > > -Original Message- > > From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org] > > On Behalf Of David Bauer > > Sent: Sonntag, 21. April 2019 15:19 > > To: Christian Lamparter > > Cc: Adrian Schmutzler ; openwrt- > > de...@lists.openwrt.org; Tomasz Maciej Nowak > > Subject: Re: [OpenWrt-Devel] [PATCH] ath79: Add SUPPORTED_DEVICES for > > Archer C7 v1/v2 > > > > Hello Christian, > > > > On 21.04.19 14:17, Christian Lamparter wrote: > > > Hello David, > > > > > > On Sunday, April 21, 2019 11:42:52 AM CEST David Bauer wrote: > > >> On 20.04.19 20:59, Christian Lamparter wrote: > > >>> On Wednesday, April 17, 2019 3:45:52 PM CEST Adrian Schmutzler wrote: > > The identifier for both devices is "archer-c7" on ar71xx, set here: > > > > https://github.com/openwrt/openwrt/blob/master/target/linux/ar71xx/ > > base-files/lib/ar71xx.sh#L348 > > > > https://github.com/openwrt/openwrt/blob/master/target/linux/ar71xx/ > > base-files/lib/ar71xx.sh#L511 > > > > Signed-off-by: Adrian Schmutzler > > --- > > target/linux/ath79/image/generic-tp-link.mk | 2 ++ > > 1 file changed, 2 insertions(+) > > > > diff --git a/target/linux/ath79/image/generic-tp-link.mk > > b/target/linux/ath79/image/generic-tp-link.mk > > index 6853f12341..db1eabd420 100644 > > --- a/target/linux/ath79/image/generic-tp-link.mk > > +++ b/target/linux/ath79/image/generic-tp-link.mk > > @@ -70,6 +70,7 @@ define Device/tplink_archer-c7-v1 > > DEVICE_TITLE := TP-Link Archer C7 v1 > > DEVICE_PACKAGES := kmod-usb-core kmod-usb2 kmod-usb-ledtrig- > > usbport kmod-ath10k-ct ath10k-firmware-qca988x-ct > > TPLINK_HWID := 0x7501 > > + SUPPORTED_DEVICES += archer-c7 > > endef > > TARGET_DEVICES += tplink_archer-c7-v1 > > > > @@ -79,6 +80,7 @@ define Device/tplink_archer-c7-v2 > > DEVICE_TITLE := TP-Link Archer C7 v2 > > DEVICE_PACKAGES := kmod-usb-core kmod-usb2 kmod-usb-ledtrig- > > usbport kmod-ath10k-ct ath10k-firmware-qca988x-ct > > TPLINK_HWID := 0xc702 > > + SUPPORTED_DEVICES += archer-c7 > > >>> In case of the v2, I think there's still the problem that a straight > > >>> up upgrade from ar71xx to ath79 will affect the 5GHz ath10k wireless > > >>> because it now has a new device path and hence a new default > > >>> configuration (where the card is > > >>> disabled) is created. > > >> > > >> I recall upgrading my OCEDO Koala (which uses the same 9558/9880 > > >> combo) from ar71xx to ath79 and the PCIe path being consistent on both > > platforms. > > >> > > >> This however might have changed in the meantime, so someone should > > >> probably confirm this with a real C7. > > > > > > On my C7 v1 with a QCA9880v2 the ar71xx installation back in > > > 2018-08-17 looked like this: > > > > > > config wifi-device 'radio0' > > > option type 'mac80211' > > > option country 'DE' > > > option channel 'auto' > > > option hwmode '11g' > > > option path 'platform/qca955x_wmac' > > > option htmode 'HT20' > > > option disabled '0' > > > option txpower '10' > > > > > > config wifi-device 'radio1' > > > option type 'mac80211' > > > option channel '52' > > > option country 'DE' > > > option hwmode '11a' > > > option path 'pci:01/:01:00.0' > > > option htmode 'VHT80' > > > option disabled '0' > > > option txpower '14' > > > > > > vs ath79 (today): > > > > > > config wifi-device 'radio0' > > > option type 'mac80211' > > > option country 'DE' > > > option channel 'auto' > > > option hwmode '11g' > > > option path 'platform/ahb/ahb:apb/1810.wmac' > > > option htmode 'HT20' > > > option disabled '0' > > > option txpower '10' > > > > > > config wifi-device 'radio1' > > > option type 'mac80211' > > > option channel '52' > > > option country 'DE' > > > option hwmode '11a' > > > option path 'pci:00/:00:00.0' > > > option htmode 'VHT80' > > > option disabled '0' > > > option txpower '14' > > > > > > so the path changed from "pci:01/:01:00.0" to
Re: [OpenWrt-Devel] Fix TX power handling
On 4/29/19 8:24 PM, Matthias Schiffer wrote: This is just the factor of 1/2/3/4 (approximated) in dB: 10^0.0 = 1 10^0.3 ≈ 2 10^0.5 ≈ 3 10^0.6 ≈ 4 I've seen these numbers being used in WLAN drivers to account for the antenna array gain, so at least this part of the TX power computation might already be working as expected. Kind Regards, Matthias On 4/30/19 12:39 AM, Vincent Wiemann wrote: Hi Matthias, thank you for the hint. That's funny, because someone from the German Federal Network Agency said that when radios have multiple antennas, the aggregated EIRP of the antenna array must not exceed the EIRP limits of a single antenna, but I've assumed this is done in hardware and not in software. Can you hint me to the source for this lookup table? Regards, Vincent Wiemann On 29.04.2019 08:50, Matthias May wrote: On 25/04/2019 17:54, Vincent Wiemann wrote: First EIRP is by definition ERP + antenna gain - cable loss. Hi Small detail: Don't forget the antenna array gain. So EIRP as: Antenna Port Power + Antenna Gain + Antenna Array Gain - Cable Loss The Array Gain as a simple lookup table: 1 Antenna: 0 2 Antennas: 3 3 Antennas: 5 4 Antennas: 6 BR Matthias A concern could be a simple count of antennas may over estimate EIRP and reduce enabled power below what is allowed. A cheap example of simple diversity, only one antenna is used for TX based on which of the other antennas RX the best connection to a client (gain=0). Even with beam forming, a few antennas may be included in TX phased array and others RX monitors. - Eric ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Fix TX power handling
This is just the factor of 1/2/3/4 (approximated) in dB: 10^0.0 = 1 10^0.3 ≈ 2 10^0.5 ≈ 3 10^0.6 ≈ 4 I've seen these numbers being used in WLAN drivers to account for the antenna array gain, so at least this part of the TX power computation might already be working as expected. Kind Regards, Matthias On 4/30/19 12:39 AM, Vincent Wiemann wrote: > Hi Matthias, > > thank you for the hint. That's funny, because someone from the German Federal > Network Agency > said that when radios have multiple antennas, the aggregated EIRP of the > antenna array must not exceed the > EIRP limits of a single antenna, but I've assumed this is done in hardware > and not in software. > > Can you hint me to the source for this lookup table? > > Regards, > > Vincent Wiemann > > > On 29.04.2019 08:50, Matthias May wrote: >> On 25/04/2019 17:54, Vincent Wiemann wrote: >>> First EIRP is by definition ERP + antenna gain - cable loss. >> >> Hi >> Small detail: Don't forget the antenna array gain. >> >> So EIRP as: >> Antenna Port Power >> + Antenna Gain >> + Antenna Array Gain >> - Cable Loss >> >> The Array Gain as a simple lookup table: >> 1 Antenna: 0 >> 2 Antennas: 3 >> 3 Antennas: 5 >> 4 Antennas: 6 >> >> BR >> Matthias >> > > ___ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/mailman/listinfo/openwrt-devel > signature.asc Description: OpenPGP digital signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Fix TX power handling
Hi Matthias, thank you for the hint. That's funny, because someone from the German Federal Network Agency said that when radios have multiple antennas, the aggregated EIRP of the antenna array must not exceed the EIRP limits of a single antenna, but I've assumed this is done in hardware and not in software. Can you hint me to the source for this lookup table? Regards, Vincent Wiemann On 29.04.2019 08:50, Matthias May wrote: > On 25/04/2019 17:54, Vincent Wiemann wrote: >> First EIRP is by definition ERP + antenna gain - cable loss. > > Hi > Small detail: Don't forget the antenna array gain. > > So EIRP as: > Antenna Port Power > + Antenna Gain > + Antenna Array Gain > - Cable Loss > > The Array Gain as a simple lookup table: > 1 Antenna: 0 > 2 Antennas: 3 > 3 Antennas: 5 > 4 Antennas: 6 > > BR > Matthias > ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] ath79: Remove NAND targets as no available drivers
Updating this patch as likely still valuable for v19 WIP on master edited for Linux 4.19 and ath79 spi-nand suggests that support will be possible after ath79 master moves to Linux 4.19 Jeff From 7bd39bc01d8b0a03e796268f06f99b5a65fc353a Mon Sep 17 00:00:00 2001 From: Jeff Kletsky Date: Mon, 28 Jan 2019 08:25:52 -0800 Subject: [PATCH] ath79: Remove NAND targets as no available drivers At this time, there are no drivers for NAND flash for ath79. Remove the only present ath79 NAND target, GL.iNet AR300M, as it will not boot due to lack of a suitable NAND driver. From openwrt-devel on 2019-01-25 The upstream SPI NAND framework is available in 4.19. As for raw nand driver for AR9344/QCA9558, the ar934x-nfc driver isn't ported to ath79 yet. From https://github.com/openwrt/openwrt/pull/1428 on 2018-11-26 (In reference to patches trying to support the GL.iNet AR300M NAND without using the spi-nand as it not present in Kernel 4.14) Please re-spin the patch as soon as we have kernel 4.19 support. The approach was already NAK'ed upstream and I don't see much gain in adding the hack if the next major kernel in OpenWrt will provide a suitable solution. --- target/linux/ath79/image/nand.mk | 15 ++- 1 file changed, 2 insertions(+), 13 deletions(-) diff --git a/target/linux/ath79/image/nand.mk b/target/linux/ath79/image/nand.mk index eee419194b..91873ef007 100644 --- a/target/linux/ath79/image/nand.mk +++ b/target/linux/ath79/image/nand.mk @@ -1,13 +1,2 @@ -define Device/glinet_gl-ar300m-nand - ATH_SOC := qca9531 - DEVICE_TITLE := GL-AR300M (NAND) - DEVICE_PACKAGES := kmod-usb-core kmod-usb2 kmod-usb-storage kmod-usb-ledtrig-usbport - KERNEL_SIZE := 2048k - BLOCKSIZE := 128k - PAGESIZE := 2048 - VID_HDR_OFFSET := 512 - IMAGES += factory.ubi - IMAGE/sysupgrade.bin := sysupgrade-tar - IMAGE/factory.ubi := append-kernel | pad-to (KERNEL_SIZE) | append-ubi -endef -TARGET_DEVICES += glinet_gl-ar300m-nand +# No NAND drivers available for the ath79 target at this time +# (January, 2019) -- 2.11.0 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Fix TX power handling
On 25/04/2019 17:54, Vincent Wiemann wrote: > First EIRP is by definition ERP + antenna gain - cable loss. Hi Small detail: Don't forget the antenna array gain. So EIRP as: Antenna Port Power + Antenna Gain + Antenna Array Gain - Cable Loss The Array Gain as a simple lookup table: 1 Antenna: 0 2 Antennas: 3 3 Antennas: 5 4 Antennas: 6 BR Matthias ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
