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.
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
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
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
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
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
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.
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
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
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 n...@openwrt.org
Date: Sun Jan 20
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
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
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 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.
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
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
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,
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
series of radar pulses.
Best wishes to you, let me know if you found something.
Alex.
On 30 May 2012 07:25, Alex Hacker hac...@epn.ru 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
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
:
On 7 December 2011 22:08, Alex Hacker hac...@epn.ru 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
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
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
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
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
On Sun, Sep 18, 2011 at 02:39:06PM +0800, Adrian Chadd wrote:
On 18 September 2011 14:32, Alex Hacker hac...@epn.ru 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
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
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
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
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
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
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
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
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
the Unex DNMA
series high power NICs. The Unex ones are much, much cleaner.
Adrian
On 1 August 2011 16:31, Alex Hacker hac...@epn.ru wrote:
Important exeption is the channel sidebands and baseband filters fall-off.
You
sholdn't use adjacnt channels for different networks. At least
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 emailgr...@gmail.com
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.h
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
:
On Mon, Jul 11, 2011 at 8:43 PM, Alex Hacker hac...@epn.ru 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
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
, 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
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.
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)
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
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
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
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
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
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) ||
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
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
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
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
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
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
55 matches
Mail list logo
