Arduino: Document high tx power can cause issues

[devyte]

Basic Infos

• [x] This issue complies with the issue POLICY doc.
• [x] I have read the documentation at readthedocs and the issue is not addressed there.
• [x] I have tested that the issue is present in current master branch (aka latest git).
• [x] I have searched the issue tracker for a similar issue.
• [x] If there is a stack dump, I have decoded it.
• [x] I have filled out all fields below.

Platform

• Hardware: All
• Core Version: All
• Development Env: All
• Operating System: All

Settings in IDE

• Module: Wemos D1 mini Pro

Problem Description

Issue #6366 turned out to be high tx power causing weird behavior. Lowering tx power achieved stability.

This issue is meant to track documenting that.

[earlephilhower]

This sounds like more a question for the board maker than something on Arduino related. I think #6366 might just have gotten unlucky with either power supply, board builders, or a wonky lot of silicon. I've not seen it repro'd outside of his report.

[ChocolateFrogsNuts]

I think it was more of a design choice by the board builders - smaller board vs higher TX power.
Switching to an external antenna also resolved the issue - ie moving the antenna further from the chip allowed it to operate at full TX power with no issues.

I think it's worth documenting as this won't be the last tiny board with an ESP chip on it - there are at least 3 variants/versions of this same sized board from the same manufacturer.

Mind you given there are several issues on esp8266.com with weird behaviour similar to what I saw it probably should be raised there too. Might help a few people out.

[devyte]

There is also the ESP-7. Old, but I've seen a few around.
In any case, my intent is to have the symptoms captured and workaround described. There are a lot of whacky cheapo boards out there, I wouldn't be surprised that some of the connectivity issues we've seen reported here could have been addressed by reducing Tx power. Also, the suggestion came from users, which makes me think it's a bit of wisdom already floating around in the community => worth solidifying into text.

[jandrassy]

@devyte, it was my original idea. It is not floating around. I am not an expert on esp8266, but close to be one :-) I spent many hours reading the docs and playing with the esp8266.

[devyte]

Even better, from a user's practical experience.
@jandrassy since it was your wisdom, would you like to do the writeup?

[jandrassy]

Even better, from a user's practical experience.
@jandrassy since it was your wisdom, would you like to do the writeup?

I will try to reproduce it first. I think I encountered this problem in past more then once with different boards/modules but I didn't investigate it then. And the relation of this problem to calibration and the RF settings area initialization.

[ChocolateFrogsNuts]

Further info available... see my post
https://github.com/esp8266/Arduino/issues/6366#issuecomment-534337146

Basically it appears to be a cheap flash chip issue and dropping the flash frequency to 26mhz is likely the preferred fix.

[readmodifywrite]

Note that the default tx power is set to maximum (20.5 dbm), however, 802.11n on the 8266 is only spec'd to 17 dbm.

[ChocolateFrogsNuts]

@readmodifywrite interesting point, and unsurprisingly close to the figure my testing pointed to as being stable :-)

[devyte]

@jandrassy said:

I will try to reproduce it

ping?

[jandrassy]

I didn't have time first, but now I go over problems I had with esp8266 in last two years and investigate them with RF TX power as one of potential causes.
Yesterday I found a bug in WiFiLink firmware sketch which made the firmware behave strange since arduino.org coders created it. And it was a simple char array overflow in SoftAP SSID creation. So no WiFi problem.
Today Robotdyn D1 R2 with external antenna option is on schedule.

[devyte]

This seems to still need more testing by @jandrassy, pushing back.

[jandrassy]

still work in progress while parallel experimenting with RTOS IDF. my Robotdyn D1 R2 with external antenna option has a very bad performance with trace antenna. but it doesn't crash. only can't connect. but it has a good power regulator. my hypothesis right now is that problem of @ChocolateFrogsNuts was a not strong/fast enough power source combined with improper antenna.

[devyte]

The crashes should be fixed since a while.
The can't connect issue where reducing Tx power helps is what I'm interested in for this issue. If you can't reproduce I'll just close.

[jandrassy]

@ChocolateFrogsNuts had crashes while trying to connect and reducing RF TX power helped

my next test would be if reducing the TX power allows using a week power source on which the esp8266 crashes if connecting without limiting TX power

[ChocolateFrogsNuts]

My crashes were at some random point, generally within an hour of connecting, but often within a few minutes - so not caused by the actual connect, but presumably by TX in general.
It's unlikely to have been a weak power supply as it continued even with a 5 amp regulated bench supply feeding over 6V to the onboard 3.3v regulator - unless it was the 3.3v regulator that was faulty (except it happened on at least 3 boards). Also moving the antenna further from the chip seemed to stop it happening,

Worth testing with a deliberately weak power source though... I could have had a bad batch of regulators.

[readmodifywrite]

@ChocolateFrogsNuts How much capacitance do you have on the ESP power pin? Do you have an oscilloscope to get a power trace?

The transmission at full power is an extremely fast transient. The upstream power supply won't be able to respond in time. Capacitance is the only way to supply that burst of energy.

[ChocolateFrogsNuts]

@readmodifywrite a 470uF electrolytic right at the board didn't make any difference.
I do have an old 15MHz analog scope - but I didn't bother given the cap wasn't helping anyway, and I doubt it's fast enough for me to see the transient on the CRT.

[readmodifywrite]

You might need some ceramics as well, electrolytics have higher inductance. I'm running a 22 uF ceramic with a 17 dbm output power - works great.

[ChocolateFrogsNuts]

Looking back at this post I did have a 22uf ceramic on the 3.3v.

By the time I got to here I had it worked out and tests showed up to 17.5dbm as being stable, and that switching to the external antenna connection let it run at 20.5dbm.

You may have noticed from the size of that thread there was a heck of a lot of testing went into determining just what was going on :-)

[jandrassy]

So I borrowed a workbench power supply and experimented with limited current. The power supply was not very fine, no mA precision, it displayed amperes with two decimal places. But I could set it to limit the current on edge. Some boots crashed with stack dump, some run, connected to AP and downloaded data. I used an esp-01S module.

The result of many experiments with setOutputPower and setPhyMode ended with a sketch based on the EarlyDisableWiFi example. It always crashed at boot. I guess it crashed on RF calibration done by SDK at start. It needed more current to boot if the module was placed in a metallic box. I could not get it to crash on connection to AP. If the boot didn't crash, then it connected to AP and downloaded data.

[Tech-TX]

I had a problem in (September?) where max RF power caused two clone D1 Mini modules to run erratically (they were only ~3 cm apart). Dropping the power to 10dBm solved it. Both were run from a common 5V 3A PSU, so the noise was potentially transmitted through the 5V rail or GND as current spikes.

The FCC cert for the AI Thinker modules was at 17dBm, if memory serves.

@jandrassy I have an improved version of igrr's WiFi disable here, if it helps in the future. It reduces the boot current as much as possible with the current git and SDK.