ESP32-WROOM-32D EN55014 FCC Part 15 B
-
- Posts: 23
- Joined: Wed Apr 10, 2019 1:26 pm
ESP32-WROOM-32D EN55014 FCC Part 15 B
Dear colleagues,
I am working on a commercial device that has the ESP32-WROOM-32D module inside. So far, in terms of the functionalities and performance, the module kick ass Nothing to complain about. But there is a problem when it comes to the EMC testing, and how I see it now, I have a couple of 80 MHz harmonics, and one (319.63 MHz) gives me a headache.
I have read in the datasheets and manuals for the ESP32 that U0TXD needs around 499 Ohms (470 Ohms) in series in order to suppress the harmonics. Which seems to be quite correct, if you need a UART at all.
Link: https://www.espressif.com/sites/default ... nes_en.pdf
Section: 2.1.8 UART
In my case, I don't need UART and especially not during the EMC testing, and unfortunately, I don't have the opportunity to put the 499 Ohms resistor in series (I would put the 499 Ohms resistor to the GND) so I need to think about another approach. By the way, even though I don't need UART, still we have some debug messages there on 115200 baud rate, on the line which is pulled up to 3.3V via 10K resistor, on the line which is around 25mm long.
How does this sound to you? -> I would configure UART0 pins to GPIO, Outputs, and put them to logical 0 (LOW). That way, using low-side internal MOSFETs, the "harmonics" would go directly to the GND plane instead of radiating to the U0TXD line. Do you feel that I could reduce that 1.1dB of overshoot?
Many thanks to all who read this!
Regards
Marko
I am working on a commercial device that has the ESP32-WROOM-32D module inside. So far, in terms of the functionalities and performance, the module kick ass Nothing to complain about. But there is a problem when it comes to the EMC testing, and how I see it now, I have a couple of 80 MHz harmonics, and one (319.63 MHz) gives me a headache.
I have read in the datasheets and manuals for the ESP32 that U0TXD needs around 499 Ohms (470 Ohms) in series in order to suppress the harmonics. Which seems to be quite correct, if you need a UART at all.
Link: https://www.espressif.com/sites/default ... nes_en.pdf
Section: 2.1.8 UART
In my case, I don't need UART and especially not during the EMC testing, and unfortunately, I don't have the opportunity to put the 499 Ohms resistor in series (I would put the 499 Ohms resistor to the GND) so I need to think about another approach. By the way, even though I don't need UART, still we have some debug messages there on 115200 baud rate, on the line which is pulled up to 3.3V via 10K resistor, on the line which is around 25mm long.
How does this sound to you? -> I would configure UART0 pins to GPIO, Outputs, and put them to logical 0 (LOW). That way, using low-side internal MOSFETs, the "harmonics" would go directly to the GND plane instead of radiating to the U0TXD line. Do you feel that I could reduce that 1.1dB of overshoot?
Many thanks to all who read this!
Regards
Marko
-
- Posts: 9757
- Joined: Thu Nov 26, 2015 4:08 am
Re: ESP32-WROOM-32D EN55014 FCC Part 15 B
Sounds like something that's at least worth trying.
-
- Posts: 23
- Joined: Wed Apr 10, 2019 1:26 pm
Re: ESP32-WROOM-32D EN55014 FCC Part 15 B
From your experience, do you know where can I expect that 80MHz harmonics to radiate from, which pins?
Regards
Marko
Regards
Marko
-
- Posts: 9757
- Joined: Thu Nov 26, 2015 4:08 am
Re: ESP32-WROOM-32D EN55014 FCC Part 15 B
I don't have any experience myself there, but I think it was only on the Tx pin of UART0. I'm not sure if the noise follows the pin that Tx is connected to, or if it's something that is specific to that chip pad or not, though. I can ask around, but it's probably quicker to just run some experiments if you already have the gear there.
-
- Posts: 23
- Joined: Wed Apr 10, 2019 1:26 pm
Re: ESP32-WROOM-32D EN55014 FCC Part 15 B
I have read that the main cause of the mess is the TXD0 because of its location and the near proximity to the 40MHz crystal. I guess that it is due to the way of the in-module routing. And in addition to this, I think that the problem is in a specific pad since it's a non-muxible interface (UART0).
I should get the EMC pre-compliance testing equipment soon, in the next couple of days probably, but until then we need to try our luck with this approach since we don't have thank gear.
Please if you are able, ask your colleagues or friends if they had a similar problem. In the meantime, I will share my results.
I should get the EMC pre-compliance testing equipment soon, in the next couple of days probably, but until then we need to try our luck with this approach since we don't have thank gear.
Please if you are able, ask your colleagues or friends if they had a similar problem. In the meantime, I will share my results.
-
- Posts: 9757
- Joined: Thu Nov 26, 2015 4:08 am
Re: ESP32-WROOM-32D EN55014 FCC Part 15 B
I asked around, it looks like the 80MHz actually is generated when the UART is outputting something. According to my colleague, disabling the TxD0 output and not connecting anything there should get rid of the harmonics. Not sure if it's still applicable to your situation, but he also mentioned that adding some decoupling of the 3.3V supply as indicated in the picture can help getting rid of 80MHz harmonics.
-
- Posts: 23
- Joined: Wed Apr 10, 2019 1:26 pm
Re: ESP32-WROOM-32D EN55014 FCC Part 15 B
We had another pre-check and what we did is turning off the UART0 interface, TX line is configured as GPIO output and put to LOW. The resistor of 470 Ohms is put between TX and GND just in case but it is not needed generally.
Anyway, no improvement what so ever, the signals are all the same as in the previous pre-check.
I will receive the spectral analyzer tomorrow so I will be able to find what is the cause of the problem.
Anyway, no improvement what so ever, the signals are all the same as in the previous pre-check.
I will receive the spectral analyzer tomorrow so I will be able to find what is the cause of the problem.
-
- Posts: 9757
- Joined: Thu Nov 26, 2015 4:08 am
Re: ESP32-WROOM-32D EN55014 FCC Part 15 B
Strange... some 80MHz noise is to be expected, as more-or-less all the peripherals use that as a base clock, but it should be within limits.
-
- Posts: 23
- Joined: Wed Apr 10, 2019 1:26 pm
Re: ESP32-WROOM-32D EN55014 FCC Part 15 B
It's me again. So this might be a problem that others can face too with the ESP32-WROOM. The frequency of 320MHz is here to stay, for now, it's visible on communication lines, on the PCB, on the wires. It radiates all over the place, somewhere more, somewhere less.
Just to check whether is due to my board or the esp32, we used the esp32 dev module and saw the same 320MHz frequency which comes from the internal clock source.
Now the question is, what should be done on the firmware level to reduce the power of the emissions, to slow down or control in some way the PLL and clocks inside. The module is shielded but any line connected to the module will help radiate the 320MHz and other harmonics (400MHz, 480MHz...).
Just to check whether is due to my board or the esp32, we used the esp32 dev module and saw the same 320MHz frequency which comes from the internal clock source.
Now the question is, what should be done on the firmware level to reduce the power of the emissions, to slow down or control in some way the PLL and clocks inside. The module is shielded but any line connected to the module will help radiate the 320MHz and other harmonics (400MHz, 480MHz...).
-
- Posts: 23
- Joined: Wed Apr 10, 2019 1:26 pm
Re: ESP32-WROOM-32D EN55014 FCC Part 15 B
Hi guys, me again...
So, since we have the required equipment now, we were able to detect and locate those harmonics.
The source of the emissions is GPIO lines configured as OUTPUT, period (regardless of the frequency). I believe that other signal lines (such as communication) would also be a source of the unwanted emissions, but I have put the low-pass filters (ferrite + cap) on those lines which are high-speed communication. So the lines that are properly filtered are not a problem, only a GPIO OUT which are bare-naked.
Rule of thumb: Regardless of the type of the output signal (SPI, I2C, UART, GPIO OUT), never let MCU drive directly. Put an adequate filter to achieve better signal integrity and to prevent unwanted emissions.
How we solved it through the firmware: The first line of defense is to try to decrease the drive strength of the pin. By default it is 20mA, but it can go as low as 5mA. The second line of defense is to configure the lines as inputs with appropriate internal pull resistors. Of course, this can not be applied every time, it works only for the low-speed (low-frequency) signals such as ON/OFF control.
My low-filter: esp32 pin -> ferrite 220R@100MHz - cap to GND 33pF...
All the best
So, since we have the required equipment now, we were able to detect and locate those harmonics.
The source of the emissions is GPIO lines configured as OUTPUT, period (regardless of the frequency). I believe that other signal lines (such as communication) would also be a source of the unwanted emissions, but I have put the low-pass filters (ferrite + cap) on those lines which are high-speed communication. So the lines that are properly filtered are not a problem, only a GPIO OUT which are bare-naked.
Rule of thumb: Regardless of the type of the output signal (SPI, I2C, UART, GPIO OUT), never let MCU drive directly. Put an adequate filter to achieve better signal integrity and to prevent unwanted emissions.
How we solved it through the firmware: The first line of defense is to try to decrease the drive strength of the pin. By default it is 20mA, but it can go as low as 5mA. The second line of defense is to configure the lines as inputs with appropriate internal pull resistors. Of course, this can not be applied every time, it works only for the low-speed (low-frequency) signals such as ON/OFF control.
My low-filter: esp32 pin -> ferrite 220R@100MHz - cap to GND 33pF...
All the best
Who is online
Users browsing this forum: Chevelle and 98 guests