Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Document high tx power can cause issues #6471

Closed
6 tasks done
devyte opened this issue Aug 30, 2019 · 22 comments · Fixed by #7427
Closed
6 tasks done

Document high tx power can cause issues #6471

devyte opened this issue Aug 30, 2019 · 22 comments · Fixed by #7427
Assignees
Milestone

Comments

@devyte
Copy link
Collaborator

devyte commented Aug 30, 2019

Basic Infos

  • This issue complies with the issue POLICY doc.
  • I have read the documentation at readthedocs and the issue is not addressed there.
  • I have tested that the issue is present in current master branch (aka latest git).
  • I have searched the issue tracker for a similar issue.
  • If there is a stack dump, I have decoded it.
  • 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.

@devyte devyte added this to the 2.6.0 milestone Aug 30, 2019
@earlephilhower
Copy link
Collaborator

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
Copy link
Contributor

ChocolateFrogsNuts commented Sep 1, 2019

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
Copy link
Collaborator Author

devyte commented Sep 1, 2019

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
Copy link
Contributor

@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
Copy link
Collaborator Author

devyte commented Sep 1, 2019

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

@JAndrassy
Copy link
Contributor

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
Copy link
Contributor

Further info available... see my post
#6366 (comment)

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

@readmodifywrite
Copy link

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
Copy link
Contributor

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

@devyte devyte self-assigned this Oct 15, 2019
@devyte
Copy link
Collaborator Author

devyte commented Oct 29, 2019

@JAndrassy said:

I will try to reproduce it

ping?

@JAndrassy
Copy link
Contributor

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 devyte modified the milestones: 2.6.0, 2.7.0 Nov 6, 2019
@devyte
Copy link
Collaborator Author

devyte commented Nov 6, 2019

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

@JAndrassy
Copy link
Contributor

JAndrassy commented Nov 6, 2019

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
Copy link
Collaborator Author

devyte commented Nov 6, 2019

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
Copy link
Contributor

@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
Copy link
Contributor

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
Copy link

@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
Copy link
Contributor

@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
Copy link

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
Copy link
Contributor

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 :-)

dirkmueller added a commit to dirkmueller/sensors-software that referenced this issue Nov 14, 2019
Until we can update the Arduino core 2.6.0 (which is hopefully soon)
with the newer xtensa toolchain, it seems the best bet is to
reduce wifi sleeping. Also high transmit power can interfere with
the flash reading which can cause instability.

esp8266/Arduino#5998 (comment)
esp8266/Arduino#6471
@JAndrassy
Copy link
Contributor

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
Copy link
Contributor

Tech-TX commented Mar 6, 2020

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

6 participants