Replies: 11 comments 12 replies
-
2.5.0 was the version with SDK pre-3 and many users reported problems with WiFi. 2.5.1 reverted to SDK 2.2.2. |
Beta Was this translation helpful? Give feedback.
-
@JAndrassy Yep, the file was changed, but not its value. |
Beta Was this translation helpful? Give feedback.
-
Moved to a discussion since it's not really a bug and more of a discussion on how to hack the rf calibration bits... |
Beta Was this translation helpful? Give feedback.
-
Yep, calling delay() with at least 50 - 100 msec right after each WiFi related call dramatically improves WiFi performance and stability. What I did observe was that some nodes were running perfectly well with older SDK (< 2.5, not 100% sure whether all 2.4.x versions were acting the same), but no longer able to connect using any newer SDK unless you firmly press your thumb on the antenna. What I think is also happening on the newer SDKs is that the WiFi stack/code isn't completely cleared or initialized when you turn off the WiFi radio or get disconnected. About the memory consumption by LWIP and WiFiClient based objects... Another issue with setting up a WiFi connection is that it is quite sensitive to being forced to handle traffic before the connection is fully established. I also got the impression these bugs are a very timing critical issue. |
Beta Was this translation helpful? Give feedback.
-
About the de-tune of the antenna's. With badly tuned antenna's you also will have a different current and voltage distribution. So -to me- it makes sense the antenna will heat up as there is power injected into it which isn't radiated away as RF. But as I said, with the 'standard' castelated ESP-12E/F/S modules it isn't likely the antenna will have a mismatch. Anyway, you could try to test a bit with changing the TX power. |
Beta Was this translation helpful? Give feedback.
-
I do have 2 different VNA's, but I don't see how I could possibly measure the antenna resonance frequency and/or impedance using those with PCB trace antennas. Right now I can't perform measurements on those specific 'problematic' units as I have no idea in which box they are. |
Beta Was this translation helpful? Give feedback.
-
I should do more digging and less speculating. I've attached some relevant links at the end, but the EspressIF datasheets seem very light on RF details; I've found nothing to indicate minimum VSWR requirements, max RF input levels, or much else in the way of receiver specs (IP3, etc.); my google-fu seems to be failing me; are you aware of any detailed RF specs for the SOC? Apparently, some past module printed antennae have been sub-optimal. The ESP12E was revised to 12F and apparently the only change was the PIFA itself (which is described as "better optimized")...which lends credence to your belief that there are antenna match problems with some modules. The FCC test report for the AIThinker ESP12F module has no conducted emission measured above +16.4dBm (i.e. they're not transmitting at max power). Also of note is that the module is mounted with the antenna off the edge of the carrier PCB (no FR4 beneath it at all). If it's only one or two modules, it might not be worthwhile, but if you are seeing this with many, it might be worth removing the shield and then the ESP8266 SOC from a board, attaching a short piece of micro-coax to the input to the antenna matching network (e.g. for the ESP12E or F you would attach it to the pads for L2 in the matching Pi network and then set your VNA measurement plane at the there), then replace the shield with the micro-coax running out the end opposite the antenna. Obviously it would depend on the module you're using, it would be some time/work, and the result wouldn't be perfect, but it would certainly be interesting to sweep the antenna for S11 around 2.4GHz and also see how well matched it is! I'm going to do some more googling to see if someone has already done this; otherwise, next time I'm working on a dead unit I'll try that and post the results. I still don't suspect RF as the core connectivity issue in my case due to strong RSSI and the intermittent nature of the problem: when it works, it works perfectly, when it doesn't work, it won't connect to the AP at all despite very strong RSSI seen in WiFi scan, and the only thing changing between these states is run time. However, as my time permits, I'll dig into that and try to make some measurements suggested above. Some possibly useful links:
|
Beta Was this translation helpful? Give feedback.
-
Could you try #8858 (comment) and see if it has any effect? |
Beta Was this translation helpful? Give feedback.
-
@dalbert2 Thanks for checking. |
Beta Was this translation helpful? Give feedback.
-
After some changes, connections to the AP have been perfect for more than 24 hours: it connects the first time, every time. I'm going to back out the changes one at a time to find out what did it, but I strongly suspect it was changes made on the router:
It's possible it was a code change, but they were small:
|
Beta Was this translation helpful? Give feedback.
-
I'm building using the default current Arduino core from PlatformIO: Core:3.1.1 SDK:2.2.2-dev(38a443e) LWIP:2.1.3 I initially was having trouble with the units connecting to Ubiquiti non-mesh APs. Before joining this thread, I tried to isolate the problem so I set up an older D-Link b/g/n AP (DIR-645) on my desk dedicated to serving ESP8266 testing; the problem persisted and the D-Link unit is what I've been testing with since then. Since the last round of changes, I've just let it run to see if the problem re-asserts, but so far it's gone >42 hours working like clockwork with the ESP8266 connecting to the AP and dumping data every 15 minutes. There are no retries on connection whereas before it often took many retries to connect and even when connected, the ESP8266 would sometimes end up with an APIPA address (DHCP failed), or HTTPS connection failure. It looks very much like there were severe problems with the communications link and one of the changes resolved it. I am going to stop the tests at 48hrs and start backing out changes one at a time to see which made the difference. |
Beta Was this translation helpful? Give feedback.
-
Basic Infos
Platform
Settings in IDE
Problem Description
I do have a module here which does work well with a build of ESPEasy of 2019/02/26, but not on later builds. (core 2.4.2)
Symptoms are:
After lots and lots of debugging I found out that the specific board seems to have an antenna which is not matched very well to the WiFi frequency.
If I hold the board between thumb and index finger on either the begin or end of the PCB antenna trace, the node suddenly starts answering to pings.
This means the resonance frequency of the antenna is too high.
N.B. the antenna also feels warm.
A user sent me this board, which is part of a larger batch which all show the same symptoms.
Normally I would toss this away as it is clearly something wrong in the antenna tuning.
However, on core 2.4.2 the board runs fine.
So I wonder if it is possible to fix this in software?
Apparently the RF calibration used in core 2.4.2 was able to adjust parameters a bit further to compensate for this compared to what later core revisions would allow.
While debugging, I noticed quite a few other issues which also may sound very familiar to anyone who has had issues with WiFi since core 2.5.0.
Using very sophisticated tools like my fingers, ping and live RSSI charts in the MikroTik web interface I was able to 'fine tune' the antenna of the board and noticed the following:
These findings were very well reproducible, so I do feel confident it was not just a fluke.
This looks like a lot of ESP devices out there may have antennas which are not optimal and maybe just on the edge of what the RF calibration in core 2.5.0 and later can correct.
N.B. enclosures or presence of other materials close to the antenna can cause an antenna to shift its resonance frequency.
Is there a way to change the RF calibration to allow it to accept a larger range to correct an antenna?
It was working in core 2.4.2, so the ESP is capable of correcting for it.
One part of the code which does seem related is this:
Arduino/cores/esp8266/core_esp8266_phy.cpp
Lines 268 to 277 in 60fe7b4
Is this assumption correct that this may have to do with these symptoms?
Beta Was this translation helpful? Give feedback.
All reactions