[ath9k-devel] Ath9k: changing regulatory domain

[ath9k-devel] Ath9k: changing regulatory domain

[Adrien Decostre]

Hello all,

 I am quite new to the ath9k driver and I am currently trying to use this
driver for an access point on the 5GHz band.

The problem is that my card has a regulation domain set to WORA_WORLD 0x6A
which prevents the card to do active probing on any 5GHz channel. I tried
setting different country codes but this does not improve the situation, so
I suspect that the limitation comes from the regulatory domain.

So I am now looking to a way to adapt the reg_domain on the EEPROM of the
Wifi card. On some posts, I found references to the ath_info tool to modify
the reg_domain on the EEPROM but I did not even manage to install this tool
yet.

So, would someone know any other method to adapt the reg_domain?

 Thanks in advance for any answers or advices.

Best regards
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ath9k.org/pipermail/ath9k-devel/attachments/20110411/e917d645/attachment.htm 

[ath9k-devel] Ath9k: changing regulatory domain

[Luis R. Rodriguez]

On Mon, Apr 11, 2011 at 03:33:05AM -0700, Adrien Decostre wrote:
> Hello all,
> 
> I am quite new to the ath9k driver and I am currently trying to use this
> driver for an access point on the 5GHz band.
> 
> The problem is that my card has a regulation domain set to WORA_WORLD 0x6A
> which prevents the card to do active probing on any 5GHz channel. I tried
> setting different country codes but this does not improve the situation, so I
> suspect that the limitation comes from the regulatory domain.
> 
> So I am now looking to a way to adapt the reg_domain on the EEPROM of the
> Wifi card. On some posts, I found references to the ath_info tool to modify
> the reg_domain on the EEPROM but I did not even manage to install this tool
> yet.
> 
> So, would someone know any other method to adapt the reg_domain?
> 
> Thanks in advance for any answers or advices.

Changing your EEPROM is not allowed by regulatory agencies and may require
you to recalibrate your card to conform to different regulatory domains (CTLS).
Because of this this is not something we support today for the end user to do.

  Luis

[ath9k-devel] Ath9k: changing regulatory domain

[Peter Stuge]

Luis R. Rodriguez wrote:
> > I am quite new to the ath9k driver and I am currently trying to
> > use this driver for an access point on the 5GHz band.
> > 
> > The problem is that my card has a regulation domain set to
> > WORA_WORLD 0x6A which prevents the card to do active probing on
> > any 5GHz channel.
..
> Changing your EEPROM is not allowed by regulatory agencies

It is not allowed by *some* regulatory agencies. So far I've been
told that this is USA and Japan.

It's stupid, so personally I would have no problem changing the
EEPROM regulatory domain regardless.


> and may require you to recalibrate your card to conform to
> different regulatory domains (CTLS).

This is an important piece of the puzzle. If the card doesn't have
calibration data for 5GHz I guess it might actually not be useful
even if the EEPROM reg domain is changed.


> Because of this this is not something we support today for the end
> user to do.

I think that's very understandable. But we users in the community can
of course experiment at our own risk. It would be interesting to get
into the details of calibration. I think a first step is to start
looking at if and how cards with more restricted reg domains in
EEPROM are calibrated for the restricted spectrum.


//Peter

[ath9k-devel] Ath9k: changing regulatory domain

[Adrian Chadd]

On 13 April 2011 02:42, Peter Stuge <peter@stuge.se> wrote:


> It is not allowed by *some* regulatory agencies. So far I've been
> told that this is USA and Japan.
>


> It's stupid, so personally I would have no problem changing the
> EEPROM regulatory domain regardless.
>


> > and may require you to recalibrate your card to conform to
> > different regulatory domains (CTLS).
>
> This is an important piece of the puzzle. If the card doesn't have
> calibration data for 5GHz I guess it might actually not be useful
> even if the EEPROM reg domain is changed.




> I think that's very understandable. But we users in the community can
> of course experiment at our own risk. It would be interesting to get
> into the details of calibration. I think a first step is to start
> looking at if and how cards with more restricted reg domains in
> EEPROM are calibrated for the restricted spectrum.
>

 Well, a non-5ghz card won't have 5ghz data in it.

The channel edges can be investigated by perusing the eeprom data - ctlIndex
and ctlData. You can then see what the TX power calibration code is doing in
those areas.

There's some more subtle things though, especially for 5ghz where the range
of frequencies differs quite a bit. In 2ghz mode, there's only a couple of
channels either side of the range which are/aren't allowed based on where
you are, but 5ghz frequencies are a lot more varied.

There's calibration data programmed into the card which control the actual
TX power curve (and power amplifier biases for the AR9160) for a given
frequency; and it's possible that your card won't have information for the
whole possible range of 5ghz frequencies. The driver code interpolates all
of the TX power calibration curve values (and their equivalent when doing
open-loop TX calibration, just to be complete here) and these interpolated
values may be very wrong if the card frequency is too far away from what's
been calibrated.

The same is true for 2ghz but the cards I've seen have calibration data for
say, channels 1, 6 and 11; the relevant code just interpolates between those
as needed. Channel 13 in Japan would likely also be calibrated, but I don't
have a Japan 2ghz card to see.

The only way to check is to hook it up to a spectrum analyser and check. You
may be distorting without even knowing it. :-)


Adrian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ath9k.org/pipermail/ath9k-devel/attachments/20110413/ed747376/attachment-0001.htm 

[ath9k-devel] Ath9k: changing regulatory domain

[Adrien Decostre]

Adrian, Peter and Luis,

Thanks for your answers.

Just 1 more question for curiosity.
Would it be more acceptable by regulatory agencies to specify the reg_domain
to use when loading the driver?

For example, in "ath_reg_init", the reg_domain would be hard-coded (this was
just a quick test to see how it works):
  reg->current_rd=ETSI1_WORLD

There is nothing changed in the EEPROM so I don't think this would break the
module certification.

Best regards

On Wed, Apr 13, 2011 at 1:16 AM, Adrian Chadd <adrian@freebsd.org> wrote:

>
>  On 13 April 2011 02:42, Peter Stuge <peter@stuge.se> wrote:
>
>
>> It is not allowed by *some* regulatory agencies. So far I've been
>> told that this is USA and Japan.
>>
>
>
>> It's stupid, so personally I would have no problem changing the
>> EEPROM regulatory domain regardless.
>>
>
>
>> > and may require you to recalibrate your card to conform to
>> > different regulatory domains (CTLS).
>>
>> This is an important piece of the puzzle. If the card doesn't have
>> calibration data for 5GHz I guess it might actually not be useful
>> even if the EEPROM reg domain is changed.
>
>
>
>
>> I think that's very understandable. But we users in the community can
>>
>> of course experiment at our own risk. It would be interesting to get
>> into the details of calibration. I think a first step is to start
>> looking at if and how cards with more restricted reg domains in
>> EEPROM are calibrated for the restricted spectrum.
>>
>
>  Well, a non-5ghz card won't have 5ghz data in it.
>
> The channel edges can be investigated by perusing the eeprom data -
> ctlIndex and ctlData. You can then see what the TX power calibration code is
> doing in those areas.
>
> There's some more subtle things though, especially for 5ghz where the range
> of frequencies differs quite a bit. In 2ghz mode, there's only a couple of
> channels either side of the range which are/aren't allowed based on where
> you are, but 5ghz frequencies are a lot more varied.
>
> There's calibration data programmed into the card which control the actual
> TX power curve (and power amplifier biases for the AR9160) for a given
> frequency; and it's possible that your card won't have information for the
> whole possible range of 5ghz frequencies. The driver code interpolates all
> of the TX power calibration curve values (and their equivalent when doing
> open-loop TX calibration, just to be complete here) and these interpolated
> values may be very wrong if the card frequency is too far away from what's
> been calibrated.
>
> The same is true for 2ghz but the cards I've seen have calibration data for
> say, channels 1, 6 and 11; the relevant code just interpolates between those
> as needed. Channel 13 in Japan would likely also be calibrated, but I don't
> have a Japan 2ghz card to see.
>
> The only way to check is to hook it up to a spectrum analyser and check.
> You may be distorting without even knowing it. :-)
>
>
> Adrian
>
>
> _______________________________________________
> ath9k-devel mailing list
> ath9k-devel at lists.ath9k.org
> https://lists.ath9k.org/mailman/listinfo/ath9k-devel
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ath9k.org/pipermail/ath9k-devel/attachments/20110415/095d1e2e/attachment.htm 

[ath9k-devel] Ath9k: changing regulatory domain

[Adrian Chadd]

Again from what I understand the problem is, is that the channels that have
been calibrated (including the channel edges and per-frequency TX power
limits) may be specific to the regulatory domain.

I can't really say much more without spending more time surveying various
NICs (including the increasing number I have here) and see exactly what the
story is. But without adequate research, I can't really say with authority
what is/isn't going on. I can just say what -may- be going on.

HTH,



Adrian

On 15 April 2011 19:01, Adrien Decostre <ad.decostre@gmail.com> wrote:

> Adrian, Peter and Luis,
>
> Thanks for your answers.
>
> Just 1 more question for curiosity.
> Would it be more acceptable by regulatory agencies to specify the
> reg_domain to use when loading the driver?
>
> For example, in "ath_reg_init", the reg_domain would be hard-coded (this
> was just a quick test to see how it works):
>   reg->current_rd=ETSI1_WORLD
>
> There is nothing changed in the EEPROM so I don't think this would break
> the module certification.
>
> Best regards
>
> On Wed, Apr 13, 2011 at 1:16 AM, Adrian Chadd <adrian@freebsd.org> wrote:
>
>>
>>  On 13 April 2011 02:42, Peter Stuge <peter@stuge.se> wrote:
>>
>>
>>> It is not allowed by *some* regulatory agencies. So far I've been
>>> told that this is USA and Japan.
>>>
>>
>>
>>> It's stupid, so personally I would have no problem changing the
>>> EEPROM regulatory domain regardless.
>>>
>>
>>
>>> > and may require you to recalibrate your card to conform to
>>> > different regulatory domains (CTLS).
>>>
>>> This is an important piece of the puzzle. If the card doesn't have
>>> calibration data for 5GHz I guess it might actually not be useful
>>> even if the EEPROM reg domain is changed.
>>
>>
>>
>>
>>> I think that's very understandable. But we users in the community can
>>>
>>> of course experiment at our own risk. It would be interesting to get
>>> into the details of calibration. I think a first step is to start
>>> looking at if and how cards with more restricted reg domains in
>>> EEPROM are calibrated for the restricted spectrum.
>>>
>>
>>  Well, a non-5ghz card won't have 5ghz data in it.
>>
>> The channel edges can be investigated by perusing the eeprom data -
>> ctlIndex and ctlData. You can then see what the TX power calibration code is
>> doing in those areas.
>>
>> There's some more subtle things though, especially for 5ghz where the
>> range of frequencies differs quite a bit. In 2ghz mode, there's only a
>> couple of channels either side of the range which are/aren't allowed based
>> on where you are, but 5ghz frequencies are a lot more varied.
>>
>> There's calibration data programmed into the card which control the actual
>> TX power curve (and power amplifier biases for the AR9160) for a given
>> frequency; and it's possible that your card won't have information for the
>> whole possible range of 5ghz frequencies. The driver code interpolates all
>> of the TX power calibration curve values (and their equivalent when doing
>> open-loop TX calibration, just to be complete here) and these interpolated
>> values may be very wrong if the card frequency is too far away from what's
>> been calibrated.
>>
>> The same is true for 2ghz but the cards I've seen have calibration data
>> for say, channels 1, 6 and 11; the relevant code just interpolates between
>> those as needed. Channel 13 in Japan would likely also be calibrated, but I
>> don't have a Japan 2ghz card to see.
>>
>> The only way to check is to hook it up to a spectrum analyser and check.
>> You may be distorting without even knowing it. :-)
>>
>>
>> Adrian
>>
>>
>> _______________________________________________
>> ath9k-devel mailing list
>> ath9k-devel at lists.ath9k.org
>> https://lists.ath9k.org/mailman/listinfo/ath9k-devel
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ath9k.org/pipermail/ath9k-devel/attachments/20110415/77e71f5c/attachment.htm 

[ath9k-devel] Ath9k: changing regulatory domain

[Peter Stuge]

Adrien Decostre wrote:
> Would it be more acceptable by regulatory agencies to specify the
> reg_domain to use when loading the driver?

I can just guess. I think this could keep you safe wrt. modifying the
hardware, but as Adrian explained there is still a risk that
calibration data for the channels that you have "unlocked" is so
wrong that the hardware will violate emission regulations.


//Peter

[ath9k-devel] Ath9k: changing regulatory domain

[Larry Vaden]

On Fri, Apr 15, 2011 at 9:53 AM, Peter Stuge <peter@stuge.se> wrote:
> Adrien Decostre wrote:
>> Would it be more acceptable by regulatory agencies to specify the
>> reg_domain to use when loading the driver?
>
> I can just guess. I think this could keep you safe wrt. modifying the
> hardware, but as Adrian explained there is still a risk that
> calibration data for the channels that you have "unlocked" is so
> wrong that the hardware will violate emission regulations.

Peter and Adrian,

If this post is essentially asking to peek behind Atheros' kimono,
please disregard this post.

Is there any chance that the only diff between any two units is likely
to be the mac address and the regdomain?

IOW, do we know for certain whether the entire set of data required
for compliance in every country is stored on each and every chip?

kind regards/ldv
-- 
Larry Vaden, CoFounder
Internet Texoma, Inc.
Serving Rural Texomaland Since 1995
We Care About Your Connection!

[ath9k-devel] Ath9k: changing regulatory domain

[Peter Stuge]

Hi Larry,

Larry Vaden wrote:
> Is there any chance that the only diff between any two units is
> likely to be the mac address and the regdomain?

There's a chance, but I don't know how likely it is. I guess it
depends on how close a given adapter design is to the reference
design provided by Atheros. Also I think it depends on the workflow
for the adapter designers wrt. to the EEPROM. Ie. I could imagine
that there is a reference design with suggested calibration data, but
I also expect that simply manufacturing that design with zero changes
in two different production plants may give slightly different
behavior from the units.


> IOW, do we know for certain whether the entire set of data required
> for compliance in every country is stored on each and every chip?

Nope. This is what I meant would be good to gather information about,
with a tool that can preferably also decode EEPROM contents.


//Peter

[ath9k-devel] Ath9k: changing regulatory domain

[Larry Vaden]

On Fri, Apr 15, 2011 at 1:08 PM, Peter Stuge <peter@stuge.se> wrote:
> I could imagine
> that there is a reference design with suggested calibration data, but
> I also expect that simply manufacturing that design with zero changes
> in two different production plants may give slightly different
> behavior from the units.

Hi Peter,

I know there's a possibility that you have used up most of your clue
sticks before I came on the OpenWrt scene and your reorder is yet to
arrive, but if you've got one more clue stick, please hit me with it
and help me understand.

e.g., are you talking about variances in an analog portion of the
radio that might occur at two different production plants?

kind regarads/ldv

[ath9k-devel] Ath9k: changing regulatory domain

[Peter Stuge]

Larry Vaden wrote:
> > I also expect that simply manufacturing that design with zero changes
> > in two different production plants may give slightly different
> > behavior from the units.

(I don't know if the difference would be big enough to actually be
significant though.)


> e.g., are you talking about variances in an analog portion of the
> radio that might occur at two different production plants?

Right, e.g. different methods or materials while fabricate the PCBs
would give different results, maybe to the point where calibration
data would be needed, maybe not. I don't know the details of the
calibration at all. It could also be much more coarse, in which case
we eager EEPROM patchers would be in much better shape. :)


//Peter

[ath9k-devel] Ath9k: changing regulatory domain

[Larry Vaden]

On Fri, Apr 15, 2011 at 1:30 PM, Peter Stuge <peter@stuge.se> wrote:

> I don't know the details of the
> calibration at all. It could also be much more coarse, in which case
> we eager EEPROM patchers would be in much better shape. :)

Perhaps, at least for Ubiquiti radios, Country Code "Compliance Test"
is what some might be looking for?

[ath9k-devel] Ath9k: changing regulatory domain

[Larry Vaden]

On Fri, Apr 15, 2011 at 1:30 PM, Peter Stuge <peter@stuge.se> wrote:
> I don't know the details of the
> calibration at all. It could also be much more coarse, in which case
> we eager EEPROM patchers would be in much better shape. :)

Peter, now that I've had more time to think about it, MikroTik treats
the issue as a revenue enhancement called a Super Channel license.

[ath9k-devel] Ath9k: changing regulatory domain

[Larry Vaden]

On Fri, Apr 15, 2011 at 1:08 PM, Peter Stuge <peter@stuge.se> wrote:
>
>> IOW, do we know for certain whether the entire set of data required
>> for compliance in every country is stored on each and every chip?
>
> Nope. This is what I meant would be good to gather information about,
> with a tool that can preferably also decode EEPROM contents.

I know that Ubiquiti radios have a Country Code selection available
called "Compliance Test" which, per my best guess, is essentially an
out-out filter on available frequencies and my guess is therefore that
the data for all countries is available, I dunno.

regards/ldv

[ath9k-devel] Ath9k: changing regulatory domain

[Adrian Chadd]

On 15 April 2011 23:18, Larry Vaden <vaden@texoma.net> wrote:


> Peter and Adrian,
>
> If this post is essentially asking to peek behind Atheros' kimono,
> please disregard this post.
>
> Is there any chance that the only diff between any two units is likely
> to be the mac address and the regdomain?
>
> IOW, do we know for certain whether the entire set of data required
> for compliance in every country is stored on each and every chip?
>

No idea. I'm just saying I don't know for certain. I have EEPROM dumps, I've
just not sat down and investigated that.

As Luis has said however, the US (and Japan?) regdomain requires that card
domains aren't modified. I don't understand the exactness of the situation,
but as I've said, it's likely that merely ignoring/overriding the regdomain
is grounds for breaking the rules.



Adrian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ath9k.org/pipermail/ath9k-devel/attachments/20110416/afacd015/attachment.htm 

[ath9k-devel] Ath9k: changing regulatory domain

[Larry Vaden]

On Fri, Apr 15, 2011 at 11:22 PM, Adrian Chadd <adrian@freebsd.org> wrote:
> On 15 April 2011 23:18, Larry Vaden <vaden@texoma.net> wrote:
>
>>
>> Peter and Adrian,
>>
>> If this post is essentially asking to peek behind Atheros' kimono,
>> please disregard this post.
>>
>> Is there any chance that the only diff between any two units is likely
>> to be the mac address and the regdomain?
>>
>> IOW, do we know for certain whether the entire set of data required
>> for compliance in every country is stored on each and every chip?
>
> No idea. I'm just saying I don't know for certain. I have EEPROM dumps, I've
> just not sat down and investigated that.
>
> As Luis has said however, the US (and Japan?) regdomain requires that card
> domains aren't modified. I don't understand the exactness of the situation,
> but as I've said, it's likely that merely ignoring/overriding the regdomain
> is grounds for breaking the rules.

Adrian,

Me thinks a lot of our differences in point of view is that, IIRC, you
use the miniPCI cards in your development work and we have used the
integrated units since 2006.

Further, one who immediately loads 3rd party firmware onto an
integrated unit may miss this:

<http://www.ubnt.com/wiki/AirOS_5.3> says, in part:

[quote]
Country Code: Different countries will have different power levels and
possible frequency selections. To ensure device operation follows
regulatory compliance rules, please make sure to select your correct
country where the device will be used. The channel list, output power
limits, IEEE 802.11 and Channel Spectrum Width modes will be tuned
according to the regulations of the selected country. Additionally,
please consult the compliance guide for further explanation of
international compliance requirements.
[/quote]

IMHO, said devices are mostly a reference design provided by Atheros.

Remember me trying to say here a couple a weeks ago something about
"guilt by association."  One can't take on the country code of the AP
one is associating with and be certain that one is in compliance.

kind regards/ldv
-- 
Larry Vaden, CoFounder
Internet Texoma, Inc.
Serving Rural Texomaland Since 1995
We Care About Your Connection!

[ath9k-devel] Ath9k: changing regulatory domain

[Adrien Decostre]

Peter, Adrian,

Thanks a lot for these fast answers and important precisions about this
calibration issue.

Best regards


On Fri, Apr 15, 2011 at 4:53 PM, Peter Stuge <peter@stuge.se> wrote:

> Adrien Decostre wrote:
> > Would it be more acceptable by regulatory agencies to specify the
> > reg_domain to use when loading the driver?
>
> I can just guess. I think this could keep you safe wrt. modifying the
> hardware, but as Adrian explained there is still a risk that
> calibration data for the channels that you have "unlocked" is so
> wrong that the hardware will violate emission regulations.
>
>
> //Peter
> _______________________________________________
> ath9k-devel mailing list
> ath9k-devel at lists.ath9k.org
> https://lists.ath9k.org/mailman/listinfo/ath9k-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ath9k.org/pipermail/ath9k-devel/attachments/20110415/628545ba/attachment-0001.htm