How to make RF calibration behave like in core 2.4.2?

[TD-er]

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: other
• Core Version: [latest git hash or date]
• Development Env: [Platformio]
• Operating System: [Windows]

Settings in IDE

• Module: [Generic ESP8266 Module]
• Flash Mode: [dio]
• Flash Size: [4MB]
• lwip Variant: [v1.4|v2 Lower Memory|Higher Bandwidth]
• Reset Method: [nodemcu]
• Flash Frequency: [40Mhz]
• CPU Frequency: [80Mhz]
• Upload Using: [SERIAL]
• Upload Speed: [115200] (serial upload only)

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:

• Able to connect to AP
• Most of the time it is able to receive an IP
• Hardly any IP traffic is possible (pings do not even get answered)
• Access point kicks off node after set timeout in AP (On a Mikrotik you can extend this, so I am sure it is the AP that kicks off the node)

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:

• RF calibration can correct the tuning if the antenna is somewhat in the acceptable range when starting. -> RSSI values are significantly higher on the AP, compared to when reconnecting with fingers on the antenna after boot.
• By slightly moving my fingers or changing pressure I could change responsiveness of the web UI and ping times.
• Reducing TX power does lower temperature of antenna, but also "tuning" using my fingers. (no crashes or other strange issues by the way caused by RF reflected signals back into the ESP)

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

	// freq_correct_en
	// bit[0]:0->do not correct frequency offset, 1->correct frequency offset.
	// bit[1]:0->bbpll is 168M, it can correct + and - frequency offset, 1->bbpll is 160M, it only can correct + frequency offset
	// bit[2]:0->auto measure frequency offset and correct it, 1->use 113 byte force_freq_offset to correct frequency offset.
	// 0: do not correct frequency offset.
	// 1: auto measure frequency offset and correct it, bbpll is 168M, it can correct + and - frequency offset.
	// 3: auto measure frequency offset and correct it, bbpll is 160M, it only can correct + frequency offset.
	// 5: use 113 byte force_freq_offset to correct frequency offset, bbpll is 168M, it can correct + and - frequency offset.
	// 7: use 113 byte force_freq_offset to correct frequency offset, bbpll is 160M , it only can correct + frequency offset.
	/*[112] =*/ 0,

Is this assumption correct that this may have to do with these symptoms?

[JAndrassy]

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.
core_esp8266_phy.cpp was changed from C to CPP in 2.5.0

[TD-er]

@JAndrassy Yep, the file was changed, but not its value.
What I meant with the suggested setting is, would it be possible to tell the RF calibration to correct for these symptoms by changing this byte to allow for using a frequency offset?