FCC problem - Spectrum analyzer shows unwanted transmission when startup

[DreeOlee]

I started a topic here: http://bbs.espressif.com/viewtopic.php?f=6&t=8949&p=19044#p19044

They advised me to place a topic also over here, so for the record:

The problem is that the module shows a lot of unwanted transmissions during start-up, causing the FCC certification to fail.

As the attachment shows, the transmissions are unexpected and not inside the FCC regulations. According the FCC, transmissions outside the blue lines are not allowed.

I'm using the ESP-WROOM-02 module.
Latest SDK (also tried previous versions)
Even deleted every WiFi SDK link, without success
Try starting up with WiFi disabled, no success
Tried different power supplies, no success
The phenomenon is also visible during a restart from deep sleep
After restart, so from the first line of the initialization/setup(), I have full control without issues.

At this moment I'm out of ideas how to solve this problem. I expect it's a ESP hardware issue, but not sure.

Important to know:

• It happens only at startup. Just a fraction of time, after that there is no problem. The time is that short, that the spectrum analyzer not always captures the signal.

• The problem occurs before the user_rf_pre_init. I commented everything out in the user_rf_pre_init, user_init and the init_done. The problem is still there.

[DreeOlee]

Is there anyone who can help me with this?

[kriegste]

I am sure Espressif will try this ASAP.

As for us users, the fewest personally own such a spectrum analyzer. I wish I had one.

Are you 100% positive this is no issue with your power supply? I mean switching on might produce some kind of noise that gets emitted by the antenna. I personally doubt this, but one never knows...
Maybe add some "big ass" ceramic capacitors as close as possible to the module just for a test?

[DreeOlee]

Just added a "big ass" elco (1000uF) without result. As I also mentioned in the first post, I tried already a few power supplies without any difference.

Thanks anyway for thinking along

[DreeOlee]

I did a full flash erase, after that, the problem was gone.

So I think the problem is in the API (not accessible software for me) Only if my perspective is well approached, of course.

For my understanding, is this the correct architecture?

---

User application

SDK

API

physical layer

If this is the architecture, than I think the problem is in the API compiled bin files.

Is there someone who can help me with this?

[kriegste]

Do you have a backup of the faulty image? So you could find out what part of it was the cause?

Besides your application (and maybe custom data), in the image there is at least 1. a boot loader, 2. default RF data and 3. the wireless settings (along with some init data).

Since you re-flashed the RF data and your application before without success, I suspect the cause to be in the stored wireless settings.

[kriegste]

SoftAP channel is stored in this part of the image, too. Maybe it was set to 13 or 14. It is not well documented what really happens at the start

[FayeY]

Hi, we provided an FCC firmware on our website, ESP8266 Certification and Test, which has already passed the FCC certification.
And please test it after startup, the behavior during startup should not be a part of the FCC certification.
Thanks.

[DreeOlee]

@kriegste : I have a *.bin file. How can I split-up the download so I could find out what part is causing the problem?
Default SoftAP channel is set to 1 in the SDK that I can reach. If that's the case, than only 1 spike should appear in the analyzer. As you can see in the picture, that's not the case

[DreeOlee]

@FayeY : I totally disagree with your opinion about the FCC certification. My product is now 3 times rejected for the FCC certification by TÜV Rheinland. The say, for FCC WiFi 2,4Ghz, it is NOT allowed to transmit any data above 2483,5 Mhz.
In the first place they can live with it if it stays with starting up, but because the problem also occurs after returning from deepsleep (also with radio off), this makes it a user case and this problem must be solved.

After startup I don't have any problems as I have been written in my first post.

I did try the Certification test before without success, I will try this again now to make sure I didn't missed anything.

[DreeOlee]

Same problem with the FCC certification test software

[FayeY]

Hi, are you using your own application for the FCC certification?
Could you use our FCC bin instead for the FCC certification? We have many customers who have already passed the FCC certification with our FCC bin.
I think maybe because that our FCC bin does not call the deep sleep, and also the deep sleep is not a must-have function for the FCC certification.
Thanks.

[DreeOlee]

NO - The last picture is WITH the FCC bin. No custom software
NO, deepsleep is not a must have funtion, but no transmitting outside the specifications is a must have function.

So your conclusion is, if you want to have a FCC certificate on an application, don't use the deepsleep functionality ?

[FayeY]

If you have to use the deep sleep, you can try system_deep_sleep_set_option(2) before calling system_deep_sleep(), it may solve your problem. Thanks.

[DreeOlee]

I tried that also. Even with setting 3 (RF_DISABLED) but without success

[DreeOlee]

Is there somehow the possibility to get the source code of the API-compiled libraries ?

[kriegste]

@FayeY

d62e5a7

It says there is a "frequency spectrum mask". Maybe through this it is possible to deactivate all channels above 11?

[DreeOlee]

Who can tell me what is inbetween the SDK and the Physical hardware?

I really think there is the problem.

[DreeOlee]

Is this source code available ?

[someburner]

@DreeOlee

I emailed them before and the answer was "nope".

[DreeOlee]

To exclude the PCB design, I bought the ESP8266MOD from AI-THINKER with FCC ID: 2ADUI ESP-12
This module shows exactly the same problem.

Hopefully I will receive today the ESP-WROOM-32. Than I can try that one also.

[someburner]

@FayeY - I looked for esp_init_data_default.bin inside the FCC binary- your FCC test binary uses esp_init_data_default v05 it appears. And the pdf barely talks about param3 at all for gain setting.

@DreeOlee

it's possible that the noise you're seeing at startup is due to RFCal sector r/w operations. In my experiments, the SPI flash seemed to be what generates the most noise. You could probably narrow down whether it is noise generated by flash or not by using rboot and setting the BOOT_DELAY_MICROS option. Then you could see clearly if it is a hardware thing or if the noise comes later (after the boot delay). You could also modify esptool's stub flasher to accept custom commands. This would allow you to call ROM functions like ets_enter_sleep, Cache_Read_Disable and so-on interactively to figure it out. If I had the equipment to do it I would test, but I don't.

[kriegste]

Or, to see if it's the SPI flash, you could simple try
spi_flash_read
spi_flash_erase_sector
spi_flash_write
with some data, too.

[wally4u]

@DreeOlee I agree with you regarding the FCC regulation, you should never have anything above 2.4Ghz. If the spectrum picks it up, it means that it spots it over several passes.
Personally, I find it odd that @FayeY states to use FCC bin, for testing. It should pass with the stock nonOS firmware. What is different between the FCC / stock firmware?

[DreeOlee]

PROBLEM SOLVED !!!!

I've had contact with Espressif. They solved the problem in their library.

At startup, the chip runs a calibration routine around 4 channels. The highest channel calibration routine is now removed from the software because it is not necessary for FCC. The picture now looks like this:

So for everyone who needs FCC certification, replace the original libphy.a file for the one in the zipped attachment.
libphy.zip

Espressif thanks for your suppport !

[kriegste]

Very nice!! :D Will this be part of the official (master branch) of the SDK eventually?
I almost overlooked this since the issue was closed so fast...

[DreeOlee]

I hope so, I don't have control over that process.

I did some tests, and this library file is also necessary for EU (CE) certification. The highest channel calibration is for channel 14 and not used in US or EU. I believe Japan uses this, but not sure.

I think channel 13 needs a bit less power for certification. The Bandwidth of the signal can cause trespassing the allowed maximum frequency. I will get back on this after certification.

[wally4u]

Good to hear!
NBs can be a pain especially with this kind of issues. Although explainable, they just don't care what the cause is..
+1 for adding this into the master branch(es)!

[kriegste]

The question is, do we need this calibration at channel 14(?) at all!? Well, if yes, then there should be an API to enable/disable it or (better) the already existing wifi_set_country should make the needed settings in the calibration as well.

[rojer]

@FayeY can you confirm that these changes will be integrated into the SDK? and preferably keep the issue open until they are?

[FayeY]

Hi, sorry that since our next release is almost ready, so these changes will NOT be in our next release. But we will integrate it into the latest master SDK, and after full test, it will be added in the next-next release.
Thanks.

[Alexis-Polegato]

Hello @DreeOlee , I may have an issue very similar to yours in my application case. When you say that your problem is solved, you mean that you don't have anymore the callibraton on the 4th channel which was above the limit of 2483,5 Mhz but you still have the calibration on the 3 other channels, right ?

@FayeY Following this issue, would it be possible to completly deactivate this process at startup to avoid any unwanted transmission (Typically in a case where I would like to turn ON my ESP8266 without turning ON the Wifi ?

[DreeOlee]

@Alexis-Polegato that's right.
The calibration cycle is that short (few nano seconds) that it doesn't interfere with an application.
Why would you disable this calibration cycle?

[Alexis-Polegato]

In my application, I periodically turn ON the ESP for monitoring purpose. But at that moment, I don't necessarily need to connect to Wifi so I would like to avoid turning ON the Wifi (even for calibration).
For this application, I would like to pass another Certification which is the RTCA DO-160, which does not allow me to use WIFI during the monitoring period. And so, I don't want to have any undesired transmission.

[kriegste]

Is there a plan or some kind of road map when the new libphy.a gets integrated into the official SDK?

[kriegste]

Hello?

[FayeY]

Hi, sorry for the late reply, would you like to use our latest ESP8266 RTOS SDK which is ESP-IDF style? The new RTOS SDK will be more active than nonOS SDK.

[kriegste]

Does that mean this SDK is abandoned and bugs will no longer be fixed? We'd like to read an official statement on this.