Tool/software:
I have tested the latest CC33xx FW release 1.0.0.8, but AntGain_2_4GHz setting in cc33xx-conf.bin configuration file still doesn’t affect to CC330x WLAN TX Power at all. I have tested both default configuration (0x00) and maximum AntGain value 0x3C (7.5dB), but conducted TX power is exactly the same with both settings, when testing with the calibrator tool in continuous TX mode with the following commands:
ifconfig wlan0 down calibrator wlan0 plt power_mode on calibrator wlan0 cc33xx_plt tune_channel 1 0 0 calibrator wlan0 cc33xx_plt set_manual_calib -tx 1 calibrator wlan0 cc33xx_plt set_tx -default 0 calibrator wlan0 cc33xx_plt set_tx -preamble_type 1 -phy_rate 1 -tx_power 30 calibrator wlan0 cc33xx_plt start_tx
Test was repeated on several channels and data rates.
This isn't documented anywhere, but it is possible its use is dependent on the reg_domain setting. Try setting this to the value for ETSI (2) and see if it has any impact.
I've been begging TI for months to provide documentation on how these parameters interact, to no avail. Perhaps if more of us make the request it will help...
Thanks for the tip, this really seems to work!
So setting AntGain_2_4GHz alone doesn't affect at all, but if RegDomain is set to 1 (FCC) or 2 (ETSI), then AntGain_2_4GHz configuration works as expected.
It still seems to me that this has to be a bug, as the AntGain_2_4GHz was working before without changing RegDomain and it really doesn't make sense to me why these settings would work only together. I hope this will be fixed in the coming releases, but in the mean time it's good to have this workaround.
I think the reason it depends on reg_domain is because some parameters are measured as EIRP in some configurations and as conducted in others. Antenna gain is important in different ways depending on domain and type of measurement. So I don't think it is a bug, but intended behavior. But it isn't documented, so who knows...
Hello Kaisa,
Sorry for the late response on this.
Dean is correct, this parameter only changes the TX power output when configuring Reg domain FCC or ETSI.
This is because the measurement in FCC and ETSI certification is radiated, where antenna gain plays an important role. Where as no reg domain (world wide) the measurement is normally conducted, so antenna gain has no affect.
Regards,
Jonathan
In my experience, US is typically a conducted measurement and limit. Antenna gain doesn't come into play until it exceeds 6dBi, at which point power must be reduced by 1dB for each dB of gain over 6dB.
Based on that, I would not expect the firmware to modify output power based on antenna gain unless the gain exceeded 6dBi in the US. Can you comment on this?
Hi Dean,
Your first statement is correct, FCC is typically conducted measurement and according to the spec antenna gain needs to be compensated after 6dBi.
However the CC33xx firmware also restricts or changes the tx power output based on antenna gain because of spurious emissions in the restricted bands. Higher antenna gain will effect the spurious emissions from the CC33xx and it may cause a FCC emission test violation.
The best thing to do is always to use the predefined INI conf file for FCC or ETSI which TI has provided in the Simplelink Wifi Toolbox.
Regards,
Jonathan
Thanks, that makes sense.
One more question - what is the TI definition of "World Wide"? In what scenarios would you expect this to be used?
Asking because there is no actual WorldWide regulatory domain, although many countries follow FCC or EU/ETSI requirements to some degree. Sometimes WW is intended to be a least common denominator setting that would allow a device to be shipped to any of a particular set of countries (including US and EU).
What is TIs intention for this setting?
Hi Dean,
Normally from other documentation I have seen World wide means to appeal to the least common denominator, or has the most restrictions.
However when I mentioned WW in my earlier answer in this thread I meant without restrictions. I realize my language is a little confusing here, but I will try to make it as clear as possible:
There are 3 conf files that appear in the ini-composer folder in the SimpleLink WiFi Toolbox, one for FCC, one for ETSI, and one which is unrestricted. This unrestricted one is what I call WW.
Hopefully this clears things up.
Thanks,
Jonathan
Hi Jonathon,
Perhaps that is the confusion. The RegDomain/phy.reg_domain setting in the conf file is documented to be "World Wide" when set to zero.
What is the intended use of phy.reg_domain=0? In what scenarios should a conf file be configured with that setting?
If it is intended to be used in unrestricted configurations (basically only test), "World Wide" seems like an incorrect description - maybe change it to "Unrestricted" to eliminate the confusion?
Thanks!
Hi Dean,
Yes I agree that is confusing, we are still updating our documentation to correctly explain this.
When reg_domain = 0 the idea is that the CC33xx will appeal only to IEEE Wi-Fi standards, meaning the standards that every Wi-Fi device needs to meet, independent of additional regulatory domain restrictions. That's why its called WW in our conf file. The use for this parameter is if you want to have the device transmit without restrictions on specific channels.
When defining reg_domain to be 1 or 2 (FCC or ETSI) there are more restrictions on top of the IEEE standards.
Hope this clears things up.
Regards,
Jonathan
Hi Jonathan,
thank you for explanations. I hope this information will be added to your documentation as well. It would be also good to have a warning in the Simplelink Wifi Toolbox mentioning that the AntGain is only effective if RegDomain is set to ETSI or FCC. I still don't fully understand why you have chosen this kind of approach, as the AntGain is by default 0x00 and if someone chooses to change that, it's usually expected to work without any extra tricks (at least I did).
Could you still clarify the differences between RegDomains ETSI and FCC?
Best regards,
Kaisa
Hi Kaisa,
Yes I agree with you completely, we will document this either in a dedicated app note or in the existing documentation.
The reason why AntGain parameter only changes the tx power set by firmware in FCC or ETSI modes is because TI does not want to restrict tx power if it doesn't have to.
In the reg_domain=0 case (unrestricted) AntGain does not decrease the tx power in firmware. This is so that any user can set max tx power and have an antenna with any gain, benefiting from max EIRP. In this case the firmware does not need to know what antenna is connected to it, there are no additional restrictions which the firmware needs to own in order to pass certification, like FCC and ETSI.
In the case of reg_domain FCC or ETSI, the firmware needs to know what antenna gain is connected to the RF output, because the gain will directly effect certain parameters required for certification. For example, in ETSI certification there is a requirement for Max EIRP spectral density, which will not pass if you connect an antenna with gain that is too high. The firmware needs to know what gain is connected so that it can lower the tx power from the IC.
The differences between reg_domain ETSI and FCC are the tx power restrictions across certain channels and rates. You can see the full PowerLimitArray in the various ini files and compare the exact power limits there if you are interested.
Hope this clears things up.
Regards,
Jonathan
Hi Jonathan,
I checked the predefined INI conf files for ETSI and FCC, but since the power limitations in these are made by PowerLimitArray as you mentioned, I still don't understand what is that the actual RegDomain setting is made for? How does that setting affect and what's the difference between RegDomain=1 (FCC) and RegDomain=2 (ETSI)?
Best regards,
Kaisa
Hi Kaisa,
There are some additional internal PHY settings besides what you see in the INI which are dependent on the reg_domain parameter. These are internal configurations that I am unable to share with you, but they enable the device to keep datasheet level performance (except for max tx power) while passing the relevant certification.
Regards,
Jonathan