Re: [ath9k-devel] Capture all transmissions with monitor interface
On Tue, Dec 04, 2012 at 07:43:40PM +0100, Julien Herzen wrote: >Hello, > >I'm sending traffic from a node A to a node B, and I'm capturing traffic >sent by node A, at node A itself, using a monitor interface. I'm doing >this on lossy links, where many re-transmissions occur. It seems, however, >that each packet sent by A is captured only once (with our without retry >bit set). Is there a way to capture _all_ transmissions done by A? No, packets automatically generated by HW i.e. retries, acks, rts/cts is not visible for the software. Only solution is to use node C in monitor mode next to node A. > >I'm using AR9220 on Alix boards with kernel 2.6.32.27. > >Thanks! > >Julien Best wishes, Alex. ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] Fixing the rate and rate relationship to OFDM
Hi, If you able to add small piece of code to the driver, you can do the following: Construct a single aggregate with desired parameters, NoAck bit set and 1 retry count in the first retry series. Link last descriptor of the aggregate to the first and drop this bomb into any TX queue. The aggregate should be in accordance with the 802.11n, i.e. contain <64K of data+delimeters+FCS and be 4ms or shorter. In case when no other signals in the medium this gives you 100% transmit time except the small silence periods required by the standard. But IMO, measuring TX power with a SA is not the best way. Using a much cheaper power meter set up to measure on first 16us of each packet (preamble) is better. It allows you to get a valid result with single packet shot. About modulations used in 11n: MCS Modulation 0,8,16 BPSK 1,2,9,10,17,18 QPSK 3,4,11,12,19,20 QAM16 5,6,7,13,14,15,21,22,23 QAM64 52 subcarriers in 20MHz bandwidth and 108 in 40MHz. Regards, Alex. ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] Fixing the rate and rate relationship to OFDM
Hi Adrian, You talking about real continuos signal like sine wave? I do not understand why it needed. The method I'd offered is in full accordance with the 802.11 standard (and FCC I think) until CCA mechanism is not shut down. But I agree what this kind of flood generator is terrible in the air. Hi John, I'd asked our RF engeneers who do FCC sertification tests. They agree - SA power measurements are complex, slow and imprecise. But this methods is defined by FCC specifications. Best regards, Alex. ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] Fixing the rate and rate relationship to OFDM
Hi Adrian, On Sat, Mar 30, 2013 at 06:27:53AM -0700, Adrian Chadd wrote: >Yup. Either is kinda frightening though! Even a back-to-back frame >transmission with CCA disabled is bordering on unhappiness. Yeah! Although it is all nothing compared to 1kW microwave oven or 500kW weather radar. :) >IIRC, there's ETSI requirements that tones are generated to test centre >frequency accuracies. I thought that the FCC had those too? I think yes in some way. I ask the authoritative people at the morinig they did both procedures. >Adrian Best regards, Alex. ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] Fixing the rate and rate relationship to OFDM
On Sat, Mar 30, 2013 at 09:03:24PM +0600, Alex Hacker wrote: > I think yes in some way. I ask the authoritative people at the morinig they > did both > procedures. Sorry, I wanted to say: I ask the authoritative people at the monday. They breeze through both procedures. Best regards, Alex. ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] Fixing the rate and rate relationship to OFDM
On Sat, Mar 30, 2013 at 06:27:53AM -0700, Adrian Chadd wrote: >IIRC, there's ETSI requirements that tones are generated to test centre >frequency accuracies. I thought that the FCC had those too? >Adrian I'd asked the RF boys. Nobody can recall exactly, they do it more than two years ago, but they did it with MXA Signal Analyzer which measures frequency error. They do not spent too much time on it beacuse if you have 5ppm quartz generator then the precision of carrier frequencies is guaranteed by design. Most problems in ETSI is out-of-band radiation pattern which it defines in absolute values in contradistinction to FCC. Regards, Alex. ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] ath9k greenfield mode support
Hi, I can not disclose any details about it here, but the equipment based on AR92xx and AR93xx chips supporting GF is available on the market. I redirect any questions to the Atheros and Qualcomm. I can only acknowlege what this feature increase the throughput up to 8% and makes a traffic "invisible" to a convetional 802.11abgn equipment. Regards, Alex. On Mon, Apr 15, 2013 at 07:22:30AM -0700, Adrian Chadd wrote: > Nope, and nope! > > No greenfield-HT support. You can just disable letting non-n clients > associate, but that isn't really "greenfield." > > > adrian > > On 15 April 2013 07:06, Daniel Wunderlich wrote: > > Hi all, > > > > i am analysing a AR9380 chipset to get a feeling about the performance in > > different modes and configurations. I know that some wireless cards offer > > the possibility to setup a greenfield mode to transmit in 802.11n only. > > > > The ath9k does not contain any line of code with this functionality. Does > > the AR9380 chipset support GF-mode? If so, is there any intention to > > implement this in ath9k driver? > > > > Thanks in advance, Daniel > > > > ___ > > ath9k-devel mailing list > > ath9k-devel@lists.ath9k.org > > https://lists.ath9k.org/mailman/listinfo/ath9k-devel > ___ > ath9k-devel mailing list > ath9k-devel@lists.ath9k.org > https://lists.ath9k.org/mailman/listinfo/ath9k-devel -- ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] [OpenWrt-Devel] ath9k: Deaf when setting rxchainmask
Hello, Some combinations of masks is restricted for AR92xx series. See the ar9003_hw_set_chain_masks(), it allows any value for rx/tx chain masks for AR93xx chips. It is claimed the QCA9558 should support it at least at HW level. Alex. ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] ath9k: set 5/10 MHz supported channels
Hello, I can sign up on this. Yes, all HT rates works in 5/10 MHz bandwidth. More than that, it actually works in virtually any bandwidth with only different symbol times (longer or shorter than 4us). Lapsus linguae: I still can't get it working on AR93xx series chips. Best wishes, Alex. ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] ath9k: set 5/10 MHz supported channels
Thank you Adrian. Yes I know, but I can not get it working with AR9390 (enterprise) chip too. :( Alex. ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] ath9k: set 5/10 MHz supported channels
Hello, I'm not ath9k developer, obviously I work with Atheros and QCA chips in non open source conditions, so I havn't a code to publish. What I can do for you it is a several hints about HW. Yes, you are in the right way, 5/10 MHz bandwidth controlled by AR_PHY_MODE register and changes the PLL frequency. In the code I see what almost all required work is already done. You should dig yourself into the higher layers of code to understand how to do it at the user level. At the end I should say that these bandwidths is not conform to IEEE802.11 and ETSI/FCC policies so it actually illegal. Alex. ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] [OpenWrt-Devel] ath9k: Deaf QCA9558 when setting rxchainmask
Thank you Sujith. Probably I understood the following patch in a wrong way.
Felix removed all chain masks checking. If the mask 5 is invalid, how about
the mask 4 and 6?
Regards,
Alex
commit 24171dd92096fc370b195f3f6bdc0798855dc3f9
Author: Felix Fietkau
Date: Sun Jan 20 21:55:21 2013 +0100
ath9k_hw: fix chain swap setting when setting rx chainmask to 5
Chain swapping should only be enabled when the EEPROM chainmask is set to 5,
regardless of what the runtime chainmask is.
Cc: sta...@vger.kernel.org
Signed-off-by: Felix Fietkau
Signed-off-by: John W. Linville
diff --git a/drivers/net/wireless/ath/ath9k/ar9003_phy.c
b/drivers/net/wireless/ath/ath9k/ar9003_phy.c
index 8290edd..3afc24b 100644
--- a/drivers/net/wireless/ath/ath9k/ar9003_phy.c
+++ b/drivers/net/wireless/ath/ath9k/ar9003_phy.c
@@ -588,30 +588,17 @@ static void ar9003_hw_init_bb(struct ath_hw *ah,
void ar9003_hw_set_chain_masks(struct ath_hw *ah, u8 rx, u8 tx)
{
- switch (rx) {
- case 0x5:
+ if (ah->caps.tx_chainmask == 5 || ah->caps.rx_chainmask == 5)
REG_SET_BIT(ah, AR_PHY_ANALOG_SWAP,
AR_PHY_SWAP_ALT_CHAIN);
- case 0x3:
- case 0x1:
- case 0x2:
- case 0x7:
- REG_WRITE(ah, AR_PHY_RX_CHAINMASK, rx);
- REG_WRITE(ah, AR_PHY_CAL_CHAINMASK, rx);
- break;
- default:
- break;
- }
+
+ REG_WRITE(ah, AR_PHY_RX_CHAINMASK, rx);
+ REG_WRITE(ah, AR_PHY_CAL_CHAINMASK, rx);
if ((ah->caps.hw_caps & ATH9K_HW_CAP_APM) && (tx == 0x7))
- REG_WRITE(ah, AR_SELFGEN_MASK, 0x3);
- else
- REG_WRITE(ah, AR_SELFGEN_MASK, tx);
+ tx = 3;
- if (tx == 0x5) {
- REG_SET_BIT(ah, AR_PHY_ANALOG_SWAP,
- AR_PHY_SWAP_ALT_CHAIN);
- }
+ REG_WRITE(ah, AR_SELFGEN_MASK, tx);
}
/*
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] AP Limitation because of ATH9K_HTC_MAX_STA
QCA stated the firmware source can be opened for the "selected customers". We need to know who and how select the customers. Can the open source community be included in this category? Something hints me what it never happens. :( ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] AP Limitation because of ATH9K_HTC_MAX_STA
No problem... We only need to disassemble a bunch of xtensa code and hack it whithout any support as always, as before. :) ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] AP Limitation because of ATH9K_HTC_MAX_STA
Sorry for the offtopic Sujith, we talk about QCA9880 firmware. Regards, Alex. ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] AP Limitation because of ATH9K_HTC_MAX_STA
Open source community is a biggest of the biggest customers, isn't it? It is a huge market, I speak about millions of gadgets and plastic boxes working under some sort of Linux or BSD. Adrian, did you told something like that when worked for QCA? But IMO the reason is different. QCA prefers to close any access to a hardware, especially to non-standard PHY/Radio features. The same role be played by HAL in older Atheros chips. Sorry for the offtopic again, initially I wanted to leave only a small note to the Ben's post. We need to move this discussion to the ath10k-devel list. Regards, Alex. ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] [PATCH] ath9k: Fix IQ calibration
Hello, On Tue, Jan 14, 2014 at 01:25:17PM +0530, Sujith Manoharan wrote: > + if (i2_p_q2_a0_d1 > 0x1000) > + i2_p_q2_a0_d1 = -((0x1fff - i2_p_q2_a0_d1) + 1); While the 'i2_p_q2_a0_d1 = (iq_res[2] & 0xfff)' the condition 'i2_p_q2_a0_d1 > 0x1000' is always false. Regards, Alex. ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
[ath9k-devel] Zero write to AR_WA on ar9300 reset.
I'd found that the WARegVal field of ath_hw structre which are used to avoid reading the AR_WA reg while chip asleep is used before initialization in ath9k_set_reset_reg(). So that on ar9300 the AR_WA reg is zero written when the ath9k_set_reset_reg() is first called from __ath9k_hw_init(). The WARegVal is read back later, bits 14 and 17 are set. So this variable do not hold initial AR_WA reg value but just bits 14 and 17. I do not know the required behaviour but it looks like mistake. ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] Zero write to AR_WA on ar9300 reset.
I'm sorry just looking in 2.6.38 kernel. I see this is fixed in 2.6.39. Thank you! ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] Sparklan WPEA-121N AR9382 168c:abcd
Adrian Chadd wrote:
> Is there an easy way to get an EEPROM/OTP contents dump in ath9k?
For AR93xx you can try to use the following script:
#!/usr/bin/perl -w
my $debugPath = '/debug/ath9k/phy0';
sub RegGet($)
{
open(F,">$debugPath/regidx") or die("Unable to open $debugPath/regidx.");
printf(F "0x%x\n",shift());
close(F);
open(F,"$debugPath/regval") or die("Unable to open $debugPath/regval.");
local $val = ;
$val =~ s/\s+$//g;
close(F);
return hex($val);
}
sub EepromRead($)
{
RegGet(0x2000 + ((shift()/2) << 2));
while ((RegGet(0x4084) & 0x5) != 0) {}
return RegGet(0x4084);
}
for (local $addr = 0; $addr < 0x400; $addr += 2)
{
printf("\n%04x:",$addr) if ($addr%16 == 0);
local $val = EepromRead($addr);
printf(" %02x %02x",$val >> 8,$val & 0xff);
}
printf("\n");
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] More on signal and noise
On Mon, May 02, 2011 at 02:46:06PM -0700, Eduard GV wrote: > Hi all, > > Just three questions. I need per-packet SNR information and my first > guess was to inspect "last_signal" from debugfs. Values range from -30 > to -60. last_signal file should contain signal (dBm) of last received > frame (from sta_info.h), right? That explains values obtained. But... > > 1) This value is computed as signal=ATH_DEFAULT_NOISE_FLOOR + > rx_stats->rs_rssi, which is confusing me. It would be explained if > rs_rssi is actually SNR (not RSSI) measured in dB. Am I wrong? > > 2) Why is NOISE_FLOOR fixed to -95 (dBm?). Noise varies randomly, e.g. > noise reported by iw survey dump vary from -91 to -101 dBm. > > 3) By the way, what do rs_rssi_ctlX and rs_rssi_extX (-1 < X < 3) measure? > I'd spent some time trying to understand how these chips do the RSSI and noise measurements and attempt to shortly explain my vision of this process. Actually these chips unable to measure absolute signal level in dBm. This is because of amplifiers in radio are implemented in CMOS technology. Real gain of such gain stages are unpredictable and varies with temperature. Instead this CMOS technology gives a simple way to realize stable gain step independrnt from the temperature. So that Atheros chips can give as a valid SNR which is incorrectly called RSSI in descriptor status fields. The value of noise reported by "iw survery" is meaningless. This value obtained from a maximum gain set by free running AGC within short period of time and then substracted by baseband DSP from gain locked on packet's preamble. This process is described in much details in Atheros' patent US 7,245,893 B1. Very interesting document, should I say. I'm also impressed with 55 claims at the end. Now how the absolute RSSI is calculated in ath9k. Instead of using meaningless noisefloor it adds predefined value of -95 dBm to each SNR measured in baseband. I will try to guess how this value are calculated. The basic equation for calculating noise power at the antenna input is: Pn = k*T*F*B. Where: k - Boltzmann constant, T - input noise temperature, F - noise factor of the receiver and B - the bandwidth. The temperature variation is less then 1dB within working range 250..330K, so can be ignored. If we assume T = 300K, F = ~2 for LNAs used in Atheros reference boards, we got the following values: 166 fW = -98dBm in 20MHz bandwith and 331 fW = -95 dBm in 40 MHz bandwith. The value -95 programmed in ath9k is valid reference noise level for 40MHz, but for 20MHz it should be lowered by 3dB. This difference in measured RSSI can be easily shown in monitor mode observing signal level from 20MHz station. When monitor node is switched between HT20 and HT40 the RSSI will change by 3dB. ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] More on signal and noise
Yes, the AR5416 and so on chips uses the same Athersos CMOS technology and same principle of RSSI/noise measurements. The noise calibration is the process of periodic measuring minimum received power in channel, averaging it and writing back to HW. This averaged value is then used by HW to calculate SNR (rs_rssi). This valie analogues to AR92xx measured in dB to unknown (temperature dependent) reference, not mW. The fact that NF value on ath5k chips is near the real dBm noise level should not lead to conclude that it is the same, it is incorrect. Have a nice day! ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] More on signal and noise
On Fri, May 06, 2011 at 10:06:07AM +0600, Alex Hacker wrote: > Yes, the AR5416 and so on chips uses the same Athersos CMOS technology and > same principle of RSSI/noise measurements. Sorry, I mean AR52xx/AR5413 chips. ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
[ath9k-devel] MCS16-MCS19 HGI.
I found that MCS rates 16-19 HGI not present in rate tables. Which cause of its absence? ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] MCS16-MCS19 HGI.
On Fri, May 13, 2011 at 05:18:37PM +0530, Mohammed Shafi wrote: > this is my theory, it may be wrong, > all those rates in the rate table are marked as invalid and also they > are HT20 rates. also not hardwares support HT20 SGI > we have this check > if (AR_SREV_9287_11_OR_LATER(ah) || AR_SREV_9271(ah)) > pCap->hw_caps |= ATH9K_HW_CAP_SGI_20; > > so may be to avoid the rate control algorithm selecting those rates > this might had be done. Yes, I know that the AR9280 does not support SGI rates in HT20 mode. I'm not about this little bit. The current ath9k rate table in rc.c contains 3 spatial streams rates (MCS16-MCS23) for newer three chain AR93xx chips. This table includes information about MCSs 16-23 SGI and 20-23 HGI but not MCSs 16-19 HGI this is true for HT20 and HT40. Yes, some of these rates marked as invalid but present. I can not explain this fact for myself. May be Senthil baboo can help me? Best regards, Alex. ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] MCS16-MCS19 HGI.
On Fri, May 13, 2011 at 07:45:32PM +0600, Alex Hacker wrote: > This table includes information about MCSs 16-23 SGI and 20-23 HGI but not > MCSs 16-19 > HGI this is true for HT20 and HT40. Oh sorry, SGI = normal (long) guard interval here. ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] AR9285 MSI
I have one currently installed on my PC, but do not have much time to experimenting with MSI. If you tell me exactly what I should do to enable it I'll report the results. On Thu, May 19, 2011 at 12:33:29PM +0800, Sucheta ROY wrote: > Hi, > > I would like to know on what basis it is said AR9380 should work with MSI.I > am aware that ath9K Linux driver does not support MSI by default. As you are > suggesting that certain changes need to be incorporated in the driver. What > all suggestion I received in previous mail I incorporated but could not make > AR9285 work, although it exposes MSI capability structure and cat > /proc/interrupts show pcie_msi interrupt in the table. So I am afraid whether > the same would happen for AR9380! > > If anybody is having that card, and can make a quick check by enabling > MSI,that will be of great help. I don't have the card at this moment. If it > is ensured that the card works with MSI I will plan to buy one. > > Thanks and Regards, > Sucheta ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] AR9380 MSI
On Thu, May 19, 2011 at 04:35:59PM +0800, Sucheta ROY wrote:
> Hi,
>
> I believe you have AR9380 card installed in your PC?
>
> You have to build your kernel with CONFIG_PCI_MSI option enabled.
> "CONFIG_PCI_MSI" Depends on: PCI [=y] && ARCH_SUPPORTS_MSI [=y]. Also you
> have to include
> int pci_enable_msi(struct pci_dev *dev) function in pci.c file of ath9k.
> This function should be called before the driver calls request_irq().With a
> successful call the device will be switched from pin-based legacy interrupt
> mode to MSI mode. The dev->irq number will be changed to a new number which
> represents the message signaled interrupt.
>
> Also can you please let me know PCI Vendor Id/Device Id of this card ie
> AR9380?
>
> Thanks in advance for your support.
>
> Regards,
> Sucheta
The results I got below. If I do something wrong advise me what I should do.
--- pci.c.old 2011-05-19 17:59:59.0 +0600
+++ pci.c 2011-05-19 18:00:14.0 +0600
@@ -221,6 +221,9 @@
/* Will be cleared in ath9k_start() */
sc->sc_flags |= SC_OP_INVALID;
+printk("pci_enable_msi=%d.\n",pci_enable_msi(pdev));
+printk("pdev->irq=%d.\n",pdev->irq);
+
ret = request_irq(pdev->irq, ath_isr, IRQF_SHARED, "ath9k", sc);
if (ret) {
# cat /proc/interrupts
dev_err(&pdev->dev, "request_irq failed\n");
CPU0 CPU1
0:393 2628 IO-APIC-edge timer
1: 35884 676360 IO-APIC-edge i8042
4: 45 262178 IO-APIC-edge serial
8: 1 0 IO-APIC-edge rtc0
9: 0 0 IO-APIC-fasteoi acpi
14: 0 0 IO-APIC-edge ata_piix
15: 0 0 IO-APIC-edge ata_piix
16: 30197 110785854 IO-APIC-fasteoi uhci_hcd:usb5
18: 0 0 IO-APIC-fasteoi uhci_hcd:usb4
19: 173216 10744489 IO-APIC-fasteoi ata_piix, uhci_hcd:usb3
20: 191379417133 IO-APIC-fasteoi eth0
23: 776135 27633305 IO-APIC-fasteoi ehci_hcd:usb1, uhci_hcd:usb2
42: 0 0 PCI-MSI-edge ath9k
NMI: 0 0 Non-maskable interrupts
LOC: 527052638 535023710 Local timer interrupts
SPU: 0 0 Spurious interrupts
PMI: 0 0 Performance monitoring interrupts
IWI: 0 0 IRQ work interrupts
RES:30268013065734 Rescheduling interrupts
CAL: 14585 15117 Function call interrupts
TLB: 78368 128713 TLB shootdowns
TRM: 0 0 Thermal event interrupts
THR: 0 0 Threshold APIC interrupts
MCE: 0 0 Machine check exceptions
MCP: 2981 2981 Machine check polls
ERR: 1
MIS: 0
# lspci -vvn
02:00.0 Class 0280: 168c:0030 (rev 01)
Subsystem: 168c:3112
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B-
Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- GSI 16 (level,
low) -> IRQ 16
May 19 17:51:00 hacker kernel: ath9k :02:00.0: setting latency timer to 64
May 19 17:51:00 hacker kernel: ath9k :02:00.0: irq 42 for MSI/MSI-X
May 19 17:51:00 hacker kernel: pci_enable_msi=0.
May 19 17:51:00 hacker kernel: pdev->irq=42.
May 19 17:51:00 hacker kernel: ath: EEPROM regdomain: 0x0
May 19 17:51:00 hacker kernel: ath: EEPROM indicates default country code
should be used
May 19 17:51:00 hacker kernel: ath: doing EEPROM country->regdmn map search
May 19 17:51:00 hacker kernel: ath: country maps to regdmn code: 0x3a
May 19 17:51:00 hacker kernel: ath: Country alpha2 being used: US
May 19 17:51:00 hacker kernel: ath: Regpair used: 0x3a
May 19 17:51:00 hacker kernel: ieee80211 phy1: Selected rate control algorithm
'ath9k_rate_control'
May 19 17:51:00 hacker kernel: Registered led device: ath9k-phy1::radio
May 19 17:51:00 hacker kernel: Registered led device: ath9k-phy1::assoc
May 19 17:51:00 hacker kernel: Registered led device: ath9k-phy1::tx
May 19 17:51:00 hacker kernel: Registered led device: ath9k-phy1::rx
May 19 17:51:00 hacker kernel: ieee80211 phy1: Atheros AR9300 Rev:3
mem=0xf864, irq=42
May 19 17:53:59 hacker kernel: do_IRQ: 0.120 No irq handler for vector (irq -1)
May 19 17:53:59 hacker kernel: do_IRQ: 1.120 No irq handler for vector (irq -1)
May 19 17:53:59 hacker kernel: do_IRQ: 1.120 No irq handler for vector (irq -1)
May 19 17:54:06 hacker kernel: device wlan0 entered promiscuous mode
Does not work.
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] More on signal and noise
On Tue, May 17, 2011 at 05:04:49PM -0700, Eduard GV wrote: > Understood, big thank you. > > However, the noise floor shouldn't take only thermal noise into > account. Man-made noise could raise the noise floor more than 6dB in > the congested 2.4GHz band (in the 5GHz band it should be lower). Yes, in Atheros' scheme it raise the NF and lowers RSSI values same manner. External noise shouldn't affect absolute RSSI level but it does. > By the way, I join the popular demand for having access to CSI data! By muself I don't believe what BF can sufficiently advance link quality. TxBF is implemented in AR9390 chip, but with only 3 antennas it can raise RSSI by less then 4.5dB, this is not a revolution. ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] More on signal and noise
On Fri, May 20, 2011 at 12:46:12PM +0800, Adrian Chadd wrote: > > Yes, in Atheros' scheme it raise the NF and lowers RSSI values same manner. > > External noise shouldn't affect absolute RSSI level but it does. > > Well, if the noise is constant, and RSSI is "relative" signal strength > indicator, why wouldn't it? It is depending on what the RSSI acronym means. :) I'd accustomed that it means Receive Signal Strength Indicator. The madwifi (if I don't miss) never gives an absolute RSSI so havn't such problems. Contrary in ath9k RSSI is absolute power of signal on receiver antenna input which by definition can not depend on noise floor. But due to noise floor measurement method used in baseband it does. > Adrian Best wishes, Alex. ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] AR9380 MSI
Hello, On Fri, May 20, 2011 at 05:30:27PM +0800, Sucheta ROY wrote: > Hi, > > Whatever you have done looks OK to me. Can you please let me know: > 1. #define AR_PCIE_MSI and #define AR_PCIE_MSI_ENABLE part in reg.h file. #define AR_PCIE_MSI(AR_SREV_9300_20_OR_LATER(ah) ? 0x40a4 : 0x4094) #define AR_PCIE_MSI_ENABLE 0x0001 The kernel version is 2.6.38.4. > 2. lspci -xxx capture. 02:00.0 Network controller: Atheros Communications Inc. AR9300 Wireless LAN adaptor (rev 01) 00: 8c 16 30 00 03 04 10 00 01 00 80 02 08 00 00 00 10: 04 00 ae fe 00 00 00 00 00 00 00 00 00 00 00 00 20: 00 00 00 00 00 00 00 00 00 00 00 00 8c 16 12 31 30: 00 00 ad fe 40 00 00 00 00 00 00 00 0a 01 00 00 40: 01 50 c3 5b 00 00 00 00 00 00 00 00 00 00 00 00 50: 05 70 85 01 0c 30 e0 fe 00 00 00 00 79 41 00 00 60: 0f 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 70: 10 00 02 00 00 87 28 00 10 20 09 00 11 5c 03 00 80: 40 00 11 10 00 00 00 00 00 00 00 00 00 00 00 00 90: 00 00 00 00 10 00 00 00 00 00 00 00 00 00 00 00 a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > Also from PCI Vendor ID/Device Id, I see you have AR9300 in your PC instead > of AR9380. In my imagination it the same. Actually AR9380 Rev 2.2 is the first commercially available MIMO 3x3 chip. Or I'm be quite wrong? By the way, after loading the modified driver I reverse changes and install original driver module, but it does not work with same error. MSI in PCI is still enabled and I should to reboot my PC to have it back again. > Regards, > Sucheta With best regards to you too, Alex. ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] AR9380 MSI
I'd not work with MSI and our Atheros based hardware do not require it. I only have a AR9380 based card and done some tests on standard PC for Sucheta ROY. I haavn't much knowlege how the MSI is processed in Linux kernel, but it seems not working with AR9380 without some special setup in hardware. Really don't understand how MSI can correlate with scan results... Best regards, Alex. On Wed, Jun 29, 2011 at 08:56:06PM +0200, Matevz Langus wrote: > Hello, > > I have tried the same thing as you did on Freescale P1020 processor (Power > architecture) using 2.6.39.1 and I am getting some results when performing > scanning. > Before enabling MSI in ath9k pci.c, I newer got any scan results. But now > when enabled I am getting at least 1 network very often. > > However it seems the operation is not very stable. I can not connect to the > AP. > > Have you made any progress on this one? > I got an answer from Atheros guys, they use INTA by default. And also looking > at defines AR_PCIE_MSI and AR_PCIE_MSI_ENABLE I got a question: who is using > that defines? It seems like nobody??? > > regards, > Matevz Langus ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] AR9380 - Transmit power control per packet
I test the TPC in our own propiertay driver (not ath9k) with AR9380. It works likewise previous Atheros chips. I think this is not a HW problem, probably EEPROM power limit. Currently have no time to experiment with ath9k (should complete AR93xx support in my own driver ASAP). On Fri, Jul 08, 2011 at 11:24:25AM +0200, Robert Budde wrote: > Does nobody have a clue about the problem? Reproducing the issue is totally > easy: Just set the AR_PHY_POWER_TX_RATE_MAX_TPC_ENABLE bit in the > AR_PHY_POWER_TX_RATE_MAX register and write a tx-power to the packet > descriptor - it won't work! Is nobody at Atheros bothered by the fact that > transmit control per packet is obviously not working with their latest > product on the market? > > Best regards, > Robert > > ___ > ath9k-devel mailing list > ath9k-devel@lists.ath9k.org > https://lists.ath9k.org/mailman/listinfo/ath9k-devel > > ___ > ath9k-devel mailing list > ath9k-devel@lists.ath9k.org > https://lists.ath9k.org/mailman/listinfo/ath9k-devel ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] AR9380 - Transmit power control per packet
Oh sorry, let me take last words back. Robert is right it does not work with AR9380. Power control mechanism does not depend on AR_PHY_POWER_TX_RATE_MAX_TPC_ENABLE bit. The AR_PHY_POWER_TX_RATE_MAX register contains a different value 0x00367044 on AR9380 and 0x007f on older chips. On Fri, Jul 08, 2011 at 05:27:22PM +0600, Alex Hacker wrote: > I test the TPC in our own propiertay driver (not ath9k) with AR9380. It works > likewise previous Atheros chips. I think this is not a HW problem, probably > EEPROM power limit. Currently have no time to experiment with ath9k (should > complete AR93xx support in my own driver ASAP). > > On Fri, Jul 08, 2011 at 11:24:25AM +0200, Robert Budde wrote: > > Does nobody have a clue about the problem? Reproducing the issue is totally > > easy: Just set the AR_PHY_POWER_TX_RATE_MAX_TPC_ENABLE bit in the > > AR_PHY_POWER_TX_RATE_MAX register and write a tx-power to the packet > > descriptor - it won't work! Is nobody at Atheros bothered by the fact that > > transmit control per packet is obviously not working with their latest > > product on the market? > > > > Best regards, > > Robert > > > > ___ > > ath9k-devel mailing list > > ath9k-devel@lists.ath9k.org > > https://lists.ath9k.org/mailman/listinfo/ath9k-devel > > > > ___ > > ath9k-devel mailing list > > ath9k-devel@lists.ath9k.org > > https://lists.ath9k.org/mailman/listinfo/ath9k-devel > ___ > ath9k-devel mailing list > ath9k-devel@lists.ath9k.org > https://lists.ath9k.org/mailman/listinfo/ath9k-devel ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] AR9380 - Transmit power control per packet
On Mon, Jul 11, 2011 at 10:39:46PM +0800, Adrian Chadd wrote: > Have you just manually tried setting the relevant register using the > debug register read/write setup? > The TPC code is written aproximately 2 years ago in our propiertary AR5416/AR92xx driver which I currently adopt for AR9300. For AR5416/AR92xx chips it works fine. > Or when you set bit 6 in 0x993c, bit 6 doesn't stay set? Yes, exactly the following are happens: REG_WRITE(0X993c,0x7f); REG_READ(0X993c) -> 0x00367044; REG_WRITE(0X993c,); REG_READ(0X993c) -> 0x007f; > adrian Best regards, Alex. ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] AR9380 - Transmit power control per packet
Yes, the EEPROM power calibration is implemented (oh excuse me, retyped from ath9k :). Any way power detector calibration can not be a reason, so plain (not per packet) power control is works as expected. Best regards, Alex. On Mon, Jul 11, 2011 at 08:51:48PM +0530, Mohammed Shafi wrote: > On Mon, Jul 11, 2011 at 8:43 PM, Alex Hacker wrote: > > On Mon, Jul 11, 2011 at 10:39:46PM +0800, Adrian Chadd wrote: > >> Have you just manually tried setting the relevant register using the > >> debug register read/write setup? > >> > > The TPC code is written aproximately 2 years ago in our propiertary > > AR5416/AR92xx driver > > which I currently adopt for AR9300. For AR5416/AR92xx chips it works fine. > > I think this module has to be taken into acoount ar9003_eeprom.c ? > > static int ar9003_hw_power_control_override(struct ath_hw *ah, > int frequency, > int *correction, > int *voltage, int *temperature) > > > > > > >> Or when you set bit 6 in 0x993c, bit 6 doesn't stay set? > > > > Yes, exactly the following are happens: > > REG_WRITE(0X993c,0x7f); > > REG_READ(0X993c) -> 0x00367044; > > REG_WRITE(0X993c,); > > REG_READ(0X993c) -> 0x007f; > > > >> adrian > > Best regards, > > Alex. > > ___ > > ath9k-devel mailing list > > ath9k-devel@lists.ath9k.org > > https://lists.ath9k.org/mailman/listinfo/ath9k-devel > > > > > > -- > shafi ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] AR9380 - Transmit power control per packet
On Mon, Jul 11, 2011 at 11:23:18PM +0800, Adrian Chadd wrote: > If the pre-AR9003 TPC code in question was public and in > ath9k/mac80211, I'd consider give getting it going on the AR9300 a > shot. I've been meaning to tinker with these NICs for a while. > > (hint. :) > > > Adrian Of coarse it's a way. But you know, customers wants more and more power and higer speeds... I beleave what Atheros do not ignore the possibility to sell severak thousands modern chips. :) Best regrads, Alex. ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] AR9380 - Transmit power control per packet
I found the cause of TPC malfunction. As I assumed early, usage of AR_PHY_POWER_TX_RATE_MAX register in AR9380 is incorrect. The following lines should be removed from ar9003_phy.h file. These registers does not exists: --- ar9003_phy.h.orig 2011-03-30 16:25:00.0 +0600 +++ ar9003_phy.h2011-07-12 12:53:30.0 +0600 @@ -733,9 +733,6 @@ #define AR_PHY_TXGAIN_FORCED_TXBB1DBGAIN 0x000e #define AR_PHY_TXGAIN_FORCED_TXBB1DBGAIN_S 1 -#define AR_PHY_POWER_TX_RATE1 0x9934 -#define AR_PHY_POWER_TX_RATE2 0x9938 -#define AR_PHY_POWER_TX_RATE_MAX0x993c #define AR_PHY_POWER_TX_RATE_MAX_TPC_ENABLE 0x0040 #define PHY_AGC_CLR 0x1000 #define RFSILENT_BB 0x2000 The AR_PHY_PWRTX_MAX register should be used instead. This register currently do not hold MAX_RATE_POWER value, but 6th bit controls the TPC enable. Now all works as expected for AR9380. Best regards, Alex. ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] 802.11n PCI-E 300Mbps with AP mode?
In addition to Adrian's words. If you occasionaly found a PCI-E card it is very possible what it will be a miniPCI-E module already installed into adapter. :) Best regards, Alex. On Thu, Jul 14, 2011 at 08:00:45AM +0800, Adrian Chadd wrote: > On 14 July 2011 07:42, Grant wrote: > >> Again, anything with an AR9280 on board will be fine. Some of the > >> antenna arrangements though are a bit .. special. > > > > I'm told this one fits the bill: > > > > http://www.tp-link.com/products/productDetails.asp?pmodel=TL-WN951N > > > > It is said to have a AR5008 chip. Can anyone confirm that this card > > works in AP mode? > > The AR5008 series stuff will "work", but not well. Ath9k doesn't focus > on AR5008 support. > > An adapter card isn't a big deal; the underlying interface for > PCIe/mini-PCIe is the same (ie, "PCIe".) > The adapter cards are just a PCIe socket<->mini-PCIe socket converter. > > The nice thing about going the adapter route is you get access to a > much larger set of wireless NICs out there. :) > > > Adrian ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] Ubiquity SR71-E: direct probe timed out
Really boys, it's unbelievable story! We works with Atheros based cards for years, our RF engenners have spectrum analyzers connected to these cards continuously. I'd just ask him - nobody never see any out of band interference from these cards except the pci-e carrier at 2.5 and 5.0 GHz. So I'm shure that the issue lies somewhere else, not in RF plane. About antennas. Of coarse any object in the anntenna near field causes a distortion of gain/directivity and SWR so that the system performance can degrade. Anyway passive antenna system can not be source of out of band interference. With best regrads, Alex. On Mon, Aug 01, 2011 at 10:22:53AM +0800, Adrian Chadd wrote: > On 1 August 2011 03:27, Grant wrote: > >> I bet there's some RF leaking out, either from the TX, or maybe the > >> PLL/clock. > > > > I wonder why the two antennas on a single card don't interfere with each > > other? > > That's a question for the RF/baseband engineers, who likely know more > about it than I do. > > But having antenans too close to each other can cause interference. I > remember reading an article or two on the near field effects of > antennas that are too closely spaced; some digging may pull up further > clue. > > >> Unfortunately it's the kind of thing you can only diagnose with a > >> sensitive spectrum analyser. > >> > >> I had that problem with a box w/ two (high powered) NICs in 2ghz mode, > >> and I only discovered this issue with a spectrum analyser. I found > >> that there was enough RF leaking in/out of the u.fl connectors and > >> (cheap) cable that it started counting as interference. > > > > Which spectrum analyzer do you use and are you happy with it? > > When I had access to one, the Agilent N9912A served me pretty well. > They're just all very expensive and not really in the realm of "toys" > for free software guys doing this (mostly) for free. > > On the flip side, you can get some atheros-based NICs that output > basic spectral analyser type information - check out > http://www.metageek.net/products/wi-spy/ for an example. > > > A quick question. My small, cheap, freebie wifi antennas work on > > 2.4Ghz and 5Ghz. Why are more expensive antennas stated to work only > > with one frequency or the other? > > Again an RF engineer would know better, but I bet it's because cheap > ones are like 0 or 1 dBi gain and the antenna element is small enough > to provide ok gain and SWR at both wavelengths. > > > > Adrian ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] Ubiquity SR71-E: direct probe timed out
Important exeption is the channel sidebands and baseband filters fall-off. You sholdn't use adjacnt channels for different networks. At least 40MHz gap should be left between H20 channels, and as much as 80MHz between HT40+ and HT40- channels. On Mon, Aug 01, 2011 at 11:19:03AM +0600, Alex Hacker wrote: > Really boys, it's unbelievable story! We works with Atheros based cards for > years, our RF engenners have spectrum analyzers connected to these cards > continuously. I'd just ask him - nobody never see any out of band interference > from these cards except the pci-e carrier at 2.5 and 5.0 GHz. So I'm shure > that > the issue lies somewhere else, not in RF plane. > About antennas. Of coarse any object in the anntenna near field causes a > distortion of gain/directivity and SWR so that the system performance can > degrade. Anyway passive antenna system can not be source of out of band > interference. > > With best regrads, > Alex. > ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] Ubiquity SR71-E: direct probe timed out
Hi, Adrian! Yeah, the Ubiquity is young company trying to get his place on the market. So that they like to overdrive Sirenza RF PAs to impermissible levels. This leads to raising unwanted emission in adjacent channels, but I don't believe that they have a fake FCC certificate. :) Another issue with Ubiquity cards is the absence of output RF filters, so it can emit some 2nd (>4.8GHz) and 3rd (>7.2 GHz) harmonics when work at high power. BTW the SR71 specification claims 26dBm at MCS0 and only 19dBm at MCS7. Anyway if you do not use adjacent channels it is should not be a big problem (except for the neighbouring networks of course). Best regards, Alex. On Mon, Aug 01, 2011 at 05:07:36PM +0800, Adrian Chadd wrote: > I've also noticed that there's sometimes quite noticable differences > in how "clean" the output is from various NICs. > > Eg, when pushing the SR-2 or SR-71A at max power, versus the Unex DNMA > series high power NICs. The Unex ones are much, much cleaner. > > > Adrian > > > On 1 August 2011 16:31, Alex Hacker wrote: > > Important exeption is the channel sidebands and baseband filters fall-off. > > You > > sholdn't use adjacnt channels for different networks. At least 40MHz gap > > should be left between H20 channels, and as much as 80MHz between HT40+ and > > HT40- channels. > > > > On Mon, Aug 01, 2011 at 11:19:03AM +0600, Alex Hacker wrote: > >> Really boys, it's unbelievable story! We works with Atheros based cards for > >> years, our RF engenners have spectrum analyzers connected to these cards > >> continuously. I'd just ask him - nobody never see any out of band > >> interference > >> from these cards except the pci-e carrier at 2.5 and 5.0 GHz. So I'm shure > >> that > >> the issue lies somewhere else, not in RF plane. > >> About antennas. Of coarse any object in the anntenna near field causes a > >> distortion of gain/directivity and SWR so that the system performance can > >> degrade. Anyway passive antenna system can not be source of out of band > >> interference. > >> > >> With best regrads, > >> Alex. > >> > > ___ > > ath9k-devel mailing list > > ath9k-devel@lists.ath9k.org > > https://lists.ath9k.org/mailman/listinfo/ath9k-devel > > ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
[ath9k-devel] Important misprint in ar9003_phy.h
I think it looks like misprint which can lead to incorrect calibration process. --- ar9003_phy.h.orig 2011-08-01 09:53:05.0 +0600 +++ ar9003_phy.h2011-08-02 13:47:07.0 +0600 @@ -850,7 +850,7 @@ #define AR_PHY_TPC_11_B1 (AR_SM1_BASE + 0x220) #define AR_PHY_PDADC_TAB_1 (AR_SM1_BASE + 0x240) #define AR_PHY_TX_IQCAL_STATUS_B1 (AR_SM1_BASE + 0x48c) -#define AR_PHY_TX_IQCAL_CORR_COEFF_B1(_i)(AR_SM_BASE + 0x450 + ((_i) << 2)) +#define AR_PHY_TX_IQCAL_CORR_COEFF_B1(_i)(AR_SM1_BASE + 0x450 + ((_i) << 2)) /* * Channel 2 Register Map Best regrads, Alex. ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] 'Superchannel'?
On Thu, Aug 25, 2011 at 07:40:03AM +0800, Adrian Chadd wrote: > On 25 August 2011 00:26, Alex S. wrote: > >> > > >> > This may not be applicable if the amateur licence he has permits him > >> > to transmit on these frequencies. > >> > > > > Exactly. According to the FCC it's OK for us to modify stuff to work on the > > amateur bands. Which in this case there is a band that starts below the > > frequency of channel 1 and is shared with unlicensed devices up to the > > frequency of channel 4 or so. > > I think the best thing to do is engage some of the Atheros developers > directly, rather than on the mailing list. > > Since you have a licence to tinker with this kind of stuff, you're > allowed to, but this may give others (who don't have an amateur > licence) the same idea. :) > > Adrian Hello everybody, Yeah, some people (like U.. teens) sell this idea on the open market. :) Actually you need only a half of hour to find that synth VCO can QSY 2272..3000 (11g) and 3500..6400 (11a). This is a 'Secret de Polichinelle'... 73! Alex Hacker. ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] 'Superchannel'?
On Fri, Aug 26, 2011 at 09:18:47PM -0400, Jerald A DeLong wrote: > I would also be very interested in this discussion. > Jerry, KD4YAL Hi Jerald, Obviously Alex shows bizarre behavior - hi got a full support from important persons (do not including myself) and disappear. So please tell us about your project and I try to renew the correspondence. 73! Alex Hacker. ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] Maximum Radio Limit?
On Fri, Aug 26, 2011 at 11:27:26AM -0700, Galen wrote: > Provided that enough PCIe ports are available, along with sufficient memory > and CPU, is there any limit to the number of radios that can be supported by > ath9k and mac80211? Are there any design bottlenecks in the software that > would be problematic in the context of a system with 100s of ath9k radio > modules from being active simultaneously? > > -Galen Hi Galen! What you trying to build? This is a military or intelligence project? :) Such crazy platform should be expensive, thousands of USD I think. Regards, Alex. ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] Possible over driving AR9106, how to detect?
On Thu, Sep 08, 2011 at 07:42:19AM -0400, Daniel Smith wrote: > For us we can reliably recreate it when we have high gain reception > (70+ dB) combined with a high incoming frame rate. I am wondering if > (and the reason for the post) the RF front-end is being over driven. > Therefore not a bug that can be fixed in software but just a > limitation of the hardware that needs to be acknowledged and dealt > with appropriately. Not sure about AR9106 but for AR9160 or AR92xx chips the RSSI of 70dB (it should be around -25dBm at antenna input) is not suffcient to overdrive radio. Such signal levels or more is very common in our lab tests without any issues. Regards, Alex. ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] Wireless Card
On Thu, Sep 15, 2011 at 09:31:31AM +0100, David Goodenough wrote: > On Thursday 15 Sep 2011, Alex Hacker wrote: > > pci-e 3 antenna > that finds me lots of pcie wireless adapters, but no mini-pci to pcie > converters. May be we are speaking about different eBays? :) I see a PCI-E adapters ONLY for this search. It's priced arount 8 USD. Regards, Alex. ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] Wireless Card
On Wed, Sep 14, 2011 at 07:10:01PM +0100, David Goodenough wrote: > Can you provide a pointer to one of these. I tried searching ebay for > a minipci to pcie adapter and got zero items found. Try to search "pci-e 3 antenna". Regards, Alex. ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] (no subject)
I think no any modifcations of the driver code are required. If your card has MIMO capability (based on AR9160, AR9220, AR9280, AR9380 or AR9390 chips) you need to set RX/TX chain masks to 1 and connect your antenna to the fisrst chain connector. For the long links you need to adjust coverage class value. Maximum distance limited by hardware is about 50km for 20MHz and 25km for 40MHz bandwidth. Regards, Alex. ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] (no subject)
On Sat, Sep 17, 2011 at 07:25:36PM +0530, subham das wrote: >Hello Alex, >Can you please describe a little about RX/TX chain masks setting to 1, and >about the maximum distance that you told was with reference to which >antenna or nic card. > The chainmasks are limit set of antennas used for RX and TX, both settings can be changed in debugfs 'ieee80211/phyX/ath9k'. The distance limit is all Aheros cards property due to maximum setting for the ACK timeout. It can be set with 'iw phy distance ' command. Of course, you need a high gain antenna to achieve long range communication. Regards, Alex. ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] (no subject)
On Sun, Sep 18, 2011 at 02:39:06PM +0800, Adrian Chadd wrote: > On 18 September 2011 14:32, Alex Hacker wrote: > > > The chainmasks are limit set of antennas used for RX and TX, both settings > > can be > > changed in debugfs 'ieee80211/phyX/ath9k'. The distance limit is all Aheros > > cards > > property due to maximum setting for the ACK timeout. It can be set with > > 'iw phy distance ' command. Of course, you need a high > > gain antenna > > to achieve long range communication. > > Just as a side-point; hasn't someone come up with a way of just doing > software-based delayed ACK with Linux/FreeBSD, and ignoring the > hardware-driven RTS/CTS/ACK retry stuff? > > Adrian We do it in our propiertary driver, obviously not in FreeBSD or Linux. Longest link we are tested in Australia is 74km it work well. Regards, Alex. ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] Can't associate with a particular AP
Hi guys! There is a two APs with the same ESSID on the same frequency. The first has a signal level 10 times lower then the second one. The AR9285 equipped PC is more sensetive or has better antenna then others. It tries to connect to very weak neighboring AP with probably invalid key. I don't know why wpa_suppicant prefer incorrect AP but IMO it is not a driver issue. Simpliest solution is to select different ESSID for your AP. Regards, Alex. ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
[ath9k-devel] External LNA gain.
Hellow all, Does anybody knows how the xlnaGainCh field in EEPROM modal header should be used to achieve a correct AGC behaviour? This values is always programmed in a card's EEPROM but not used in ath9k driver, except in the debug code. How the AGC can get into account the external LNA gain? Is the some default values programmed by initvals? Best regards, Alex. ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] External LNA gain.
Hello Adrian, If you asking about chipset. I found that chips >= AR9220 do not use external LNA bypass, switching the on-chip LNA instead. But I see that ath9k never use xlnaGainCh. How the AR5416 works in this case? Best regards, Alex. On Thu, Dec 08, 2011 at 10:24:34AM +1100, Adrian Chadd wrote: > On 7 December 2011 22:08, Alex Hacker wrote: > > Hellow all, > > Does anybody knows how the xlnaGainCh field in EEPROM modal header should be > > used to achieve a correct AGC behaviour? This values is always programmed in > > a card's EEPROM but not used in ath9k driver, except in the debug code. How > > the AGC can get into account the external LNA gain? Is the some default > > values > > programmed by initvals? > > Which board? > > > Adrian > ___ > ath9k-devel mailing list > ath9k-devel@lists.ath9k.org > https://lists.ath9k.org/mailman/listinfo/ath9k-devel -- With best wishes, Aleksey Shevkov. Infinet Wireless Ltd. +7-343-253-1533 (ext. 1658) +7-499-940-9350 (ext. 1658) +7-902-266-7135 http://www.infinetwireless.com Thu Dec 8 15:39:11 YEKT 2011 ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] External LNA gain.
Really? So you at the dark side of the moon, you too? :) Regards, Alex. On Thu, Dec 08, 2011 at 09:13:04PM +1100, Adrian Chadd wrote: >Ask me after wednesday. Ill be working at atheros. :) > >Adrian ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] Spectral Scan in ath9k
Hi, It's easy to get raw FFT data from the card, but then some cryptoanalytic work should be done in MathLab. Actualy I'm busy (lazy) man... will wait for open information which Adrian promised. :) I beleave the open source community can implement these features better than MicroTik did it. Best regards, Alex. On Sat, Mar 24, 2012 at 03:53:40PM -0700, Adrian Chadd wrote: > On 24 March 2012 08:50, Saulo Queiroz wrote: > > Hello, > > > > I intend to use ath9k to perform some tests on demodulated FFT samples. > > I found out the definition #define AR_PHY_SPECTRAL_SCAN > > 0x9910 /* AR9280 spectral scan configuration register > > but since I am a beginner in the ath9k, I have no idea about using it to > > achieve my goal. > > > > I really would be very grateful if some can provide me with informations > > that help me to access such data in the code. > > Hi, > > People keep asking about spectral scan, bah. :-) > > There are some plans afoot to try and get this stuff opened and > documented. Like anything, it's more complicated than "just provide > register details", as it's not as easy as just flipping on some bits > and getting FFT samples. > > > > Adrian > ___ > ath9k-devel mailing list > ath9k-devel@lists.ath9k.org > https://lists.ath9k.org/mailman/listinfo/ath9k-devel -- ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] Spectral Scan in ath9k
On Thu, May 31, 2012 at 07:58:11AM -0300, Saulo Queiroz wrote: >Alex, >I'm really new in the ath9k code. >May you give at least soure-code-related key words about that? >What should I look for in the code to get raw FFT? >Then, what may you point a reference about what procedure should be >performed in mathlab to decoded it? >thanks Hi Saulo, It's too long to describe all required code in detail but in short you need to do the following. 1. Enable receiving of radar pulses in AR_RX_FILTER register. 2. Set some values in AR_PHY_SPECTRAL_SCAN. Do not miss both AR_PHY_SPECTRAL_SCAN_ENABLE and AR_PHY_SPECTRAL_SCAN_ACTIVE bits. 3. Catch the rx descriptors with phy error 5 (on ar92xx) or 38 (on ar93xx). You get several packets around 1500 bytes long with FFT data. About MatLab it is joke of course, but it can be helpful in data analysis. :) For my eye it looks like series of radar pulses. Best wishes to you, let me know if you found something. Alex. > >On 30 May 2012 07:25, Alex Hacker wrote: > > Hi, > > It's easy to get raw FFT data from the card, but then some > cryptoanalytic work > should be done in MathLab. Actualy I'm busy (lazy) man... will wait for > open > information which Adrian promised. :) I beleave the open source > community can > implement these features better than MicroTik did it. > > Best regards, > Alex. > On Sat, Mar 24, 2012 at 03:53:40PM -0700, Adrian Chadd wrote: > > On 24 March 2012 08:50, Saulo Queiroz wrote: > > > Hello, > > > > > > I intend to use ath9k to perform some tests on demodulated FFT > samples. > > > I found out the definition #define AR_PHY_SPECTRAL_SCAN > > > 0x9910 /* AR9280 spectral scan configuration register > > > but since I am a beginner in the ath9k, I have no idea about using > it to > > > achieve my goal. > > > > > > I really would be very grateful if some can provide me with > informations > > > that help me to access such data in the code. > > > > Hi, > > > > People keep asking about spectral scan, bah. :-) > > > > There are some plans afoot to try and get this stuff opened and > > documented. Like anything, it's more complicated than "just provide > > register details", as it's not as easy as just flipping on some bits > > and getting FFT samples. > > > > > > > > Adrian > > ___ > > ath9k-devel mailing list > > ath9k-devel@lists.ath9k.org > > https://lists.ath9k.org/mailman/listinfo/ath9k-devel > -- > ___ > ath9k-devel mailing list > ath9k-devel@lists.ath9k.org > https://lists.ath9k.org/mailman/listinfo/ath9k-devel > >-- >Saulo Jorge bq >- >"In theory, there is no difference between practice and theory, in >practice there is" >-- Someone > > References > >Visible links >. mailto:hac...@epn.ru >. mailto:ssaulojo...@gmail.com >. mailto:ath9k-devel@lists.ath9k.org >. https://lists.ath9k.org/mailman/listinfo/ath9k-devel >. mailto:ath9k-devel@lists.ath9k.org >. https://lists.ath9k.org/mailman/listinfo/ath9k-devel > ___ > ath9k-devel mailing list > ath9k-devel@lists.ath9k.org > https://lists.ath9k.org/mailman/listinfo/ath9k-devel -- ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] Spectral Scan in ath9k
On Thu, May 31, 2012 at 12:19:08PM -0700, Adrian Chadd wrote: > Argh, there's more to it.. :-) > > For AR9160 and later, you can enable the FFT bit in one of the radar > registers and you'll get some FFT reports for longer radar pulses. > It's enabled by default in the code that we've committed to ath9k and > FreeBSD HAL. > > Spectral scan mode is related but different (and not in AR9160.) > > So for longer pulses, you'll get RADAR payload (phyerr code = 5) which > may just have the pri/ext pulse duration and some config info, or it > may have a series of FFT reports first. That's just for radar stuff > though, it's not spectral scan. > > That's why he mentioned code = 5 or code = 38. > > > Adrian Hi Adrian. Yes, I'm thinking same way. You right, some additional information required. But for guys who have an interest and time to do some reverse engineering we give a starting point. :) Just another more clear hint for them. Look into published DFS code (it's low level part) and HW radar filter parameters in AR_PHY_RADAR_* registers. Best regards to you, Alex. ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
