no more 802.11n connection since 2.6.0 #7965
Comments
|
Really a firmware problem? My 8266 modules connect well with 2.7.4:
|
|
that's why I'm asking for advice! for me there is something that has changed with the passage of 2.6.0 |
|
You can try with other/older firmware version in the IDE menu: And if possible do it with the current source code. There are three ways for doing so: |
|
so: with the nonos-sdk versions "2.2.1 + 100", "111", "113", "119" I am connected to the router in 802.11g. I did not find where is to configure the version of the nonos-sdk for the lolin? |
|
Well that's interesting ! This menu is disabled for non generic boards.
I think 1) is the easiest. |
|
yes i will do that, thanks on the other hand, how to know which version of nonossdk is used when precisely a non generic card is used? |
|
It's the same one as the default value (= the first) for the generic board. You can also read its (default when not overwritten by menu selection) value in (which is |
|
Indeed interesting your experience with the different SDK releases, because I´m using V 119 (including some Wemos D1 Mini as generic 8266 to change SDK version). Have to tried deleting WiFi settings during flash? |
i test this, with generic, v119, and erase sketch +wifi settings... and 802.11g too |
|
I can confirm it. 2.6 and later can't use n-mode at all. "Core":"2_7_4","SDK":"2.2.2-dev(38a443e)" - G-mode, no MCS value "Core":"2_5_1","SDK":"2.2.1(cfd48f3)" - N-mode indicated by "MCS 6" |
|
Could it be that OpenWRT only advertises a limited set of HT MCS modes and the ESP only supports a different subset? |
|
I've tested 802.11n with default configuration, single channel bandwidth, no limitations or restrictions for specific MCS, etc... same board with the same code (just a simple WiFi connect) is able to connect to the same WiFi AP with an old core and unable with a recent one. |
|
Can not reproduce. Core 2.7.4 |
|
have tested with new 3.0.0 arduino esp8266 |
|
Tried with core 3.0.0 connects in mode 11n Core 2.7.4 connected to a OpenWRT device |
Those logs are from ESP and they lie. It reports mode n but connects as mode g actually. And yes, I confirm, with Core 3.0.0 it's the same issue - no mode N. My guess it is related to SDK 2.2.2, not Arduino core. |
|
So you're telling me that if I configure the access point to only allow 802.11n clients, it is impossible to connect to an access point using current builds based on SDK 2.2.2? My MAC address of an ESP: FC:F5:C4:8B:71:60 Mikrotik AP it is connected to:
I will now set it to 'n' mode to see.... Set to connect via "n" mode: WiFi Connection: 802.11n (RSSI -55 dBm) TX rate is > 54 Mbps, so this can't be "g". As a test, the WiFi mode is set to "2GHz-only-N" (cleared the password field for the screenshot) As you can see, the same node is connecting just fine. |
|
where do you find the nonos sdk 2.22 ? |
|
|
yes, that is exactly what I see. Need to make sure that b/g modes are completely disabled. Pls, test it carefully if possible. That issue seems very tricky. |
|
I don't know how to see what MCS's are used. So to me it looks like it is working in "n" mode. The table you posted seems odd, as it does share the "2GHz-only-N" option along with the "b/g/n" options. Here the settings of the Wlan adapter: |
So by default it always connects in G mode for you, right? And you have to switch it to N with
It's from the official doc, I guess that GUI and CLI might have some syntax differences. I used CLI with Mikrotik's quite some time ago, do not have it now unfortunately. |
|
Yep, I made it configurable to what mode should be used to start with and as a fallback it switches to "n" mode after set number/time of failed attempts. |
|
I've played around with wifi_set_phy_mode(PHY_MODE_11N); not that it changed anything. For the SDK 2.2.1 it works as expected, for 2.2.2-git (arduino core >2.5.1) it makes no difference - MCS and WMM is not available and it does not connects at all in GreenField mode. Maybe it is AP hardware specific, but the fact is the same ESP board with the same user code works differently depending on on build env. @TD-er BTW, I've noticed that your settings screenshots contains 2GHz-only-N and WMM disabled at the same time. This is completely wrong, for HT rates in N mode WMM is mandatory if I remember WiFi 4 specs correctly. Not sure if it should even work at all in greenfield mode without WMM. This is a ESP client build with SDK 2.2.1 and AP in greenfield N mode |
|
It does connect in mode "n". Because we had issues with routers only supporting mode "n". |
|
I have also been having significant WiFi issues in 2021. scandone |
this is a major problem I am having. |
|
the funny things is that the latest Asus firmware upgrade prevent my ESP8266 devices from connecting on 802.11G, |
|
Maybe the latest firmware now has some default setting which makes the AP effectively "n-only" ? |
|
Please try with another unit too, preferrably also from a different vendor. Given channel 6 is right "in the middle", I wonder what results you may see on channel 1. |
|
@TD-er I tried the DLink on channels 1, 6, 11 (band edges and center); it worked perfectly on channels 1 and 6 but very poorly on 11. At some point I'll try working my way up the channels to see if it degrades gradually as the frequency increases. I have tested with two access point brands: DLink and Ubiquiti with the same results. I have a few other old APs around and will try them too. I'm interested in whether the problem is environmental which is why I was curious about others' experiences. If anyone else is experiencing poor connectivity, I'd be very interested in knowing what WiFi channel they are connecting on and if changing the AP to a lower channel fixes the issue. |
|
OK, so the antenna seems to be de-tuned to a lower frequency. If this theory is correct, you will gradually see that channel 6 will become worse and with the cup closer to the antenna even channel 1 will loose connectivity. Now the 'fun' part... I know the boards I have here within reach, all work perfectly fine on channels 1, 6 and 11, as those were the channels I've been using for a long time. But maybe you can make these tests a lot simpler by either using some AP which allows to show you the RSSI of the connected client, or make some kind of setup using an ESP32 and an ESP8266. Doing this on each channel can give you some info on whether the signal is indeed less per channel and maybe also test to see if sending at a lower TX power makes a (surprising) difference. |
|
Thanks for confirming that you are not seeing problems on channel 11 @TD-er; that's both good to know, and a bummer; my failure scenario is 100% reproducible on the two ESP8266 units with two different access points: simply shifting to channel 11 causes massive comms problems; I'd hoped it was a good clue. It is extremely unlikely that a poorly matched/tuned antenna is my issue; the fact that the problem occurs even with the ESP12F module is 1m or less from the AP with extremely strong RSSI (around -41dBm) suggests otherwise; a poorly matched antenna would reduce signal strength. At some point I'll sack an ESP12F module and do some antenna tests properly with the VNA, but the antenna is still pretty low on my list of suspects. A more likely scenario is a strong nearby interferer. Are there receiver specs for the ESP8266 (things like ACR or IP3?) I guess it's time to grab a spectrum analyzer and see what things look like around 2462MHz...I'll report back after doing that. |
|
You shouldn't be so close to the AP. One other thing you might want to try... |
|
I have two ESP8266 test units; one is far and one is very close; their behavior is identical and solely dependent on the AP channel; I don't think it's receiver overload; if it were, the behavior wouldn't happen only on channel 11. I grabbed a field analyzer (and also took the opportunity to test a new toy: a Tiny SA Ultra just to see how closely they'd agree and am reasonably pleased with the results!). The displays are on max hold (obviously); marker 1 is on WiFi channel 1, marker 2 is on WiFi channel 11, and marker 3 is at 2.48MHz. The spectrum is somewhat noisy, and I do occasionally see signals near channel 11, but nothing steady, so I think my local interference theory doesn't hold up. Next up is trying software changes: wipe flash, roll back to earlier core. |
|
FWIW- router firmware is often a mess too. Our customers generally have issues with ASUS routers and mesh routers/APs. When we've gotten enough reports of a router not working, we've gone out and bought that specific router and connected our device without issue. Rate selection is router-dependent and can be pretty complex (just googling about it). Here's a page from cisco about it at a high level. Seems likely that the SDK doesn't implement N correctly or is missing some feature. And in both the case of ESP8266 and the router/ap, it's also possible that reported or configured settings don't always translate to what's going on underneath. I've never been able to reproduce the "not connecting" issue with any router / ESP / configuration, but hopefully if someone can, we can find golden SDK version that works in the most cases. |
That isn't just "likely" it has already been proven. I'm still using |
Changing the channel doesn't seem to fix the issue for me. I tried several from the full range of 1 to 13 which is available here and all are unreliable for the ESP8266, while ESP32 works fine. Distance to the AP or TX power doesn't seem to matter. I suspect the signal from the ESP is out-of-spec in some way, which makes it difficult to receive for some wifi chips. Maybe it could be analysed with an SDR. |
|
One thing I did at some point suspect is the stability of the used crystal. So I did try to estimate this stability by keeping track of the time wander I need to correct when updating via NTP. Maybe the crystal frequency is also affected by fluctations in the (3V3) voltage? |
|
FWIW, I also tried different power supplies, increasing the voltage up to the maximum of 3.6V, even adding an extra ceramic cap on the board (and confirmed with a scope that the drop on wifi activity decreased), but it didn't seem to make a difference. One thing I noticed, but not really sure if real, is that it gets worse over time as the ESP is powered on. It seems to be more likely to succeed at connecting on the first attempt when cold. |
|
Buy a few more esp8266. Troubleshooting with just 2 samples is not enough. As TD-er already mentioned there is a high chance that you have "just" bad hardware |
|
What I meant is that the quality of the used crystal in the ESP module (or on some boards next to the ESP chip) may be sub-par. |
|
I was testing with 7 ESP8266, bought at least at three different times from different suppliers (although probably all from ebay). There is a large variance in the observed RX and TX signal between them, but they all seem to impacted by this incompatibility with some of my (Mediatek-based) APs. Maybe it's the APs fault, I don't know, but everything else I have ever used with them worked fine. I wanted to stop running extra APs just for the ESPs, that's why I was looking for a fix. There doesn't seem to be one, so I'll probably switch to ESP32. |
|
WRT power: in my scenario, the ESP8266 power source is USB through an LDO with 200uF of output buffering and both a 22uF and 100nF ceramic at the power input pin to the module. Power is never going to get much cleaner than that. WRT crystal stability: the spec for 802.11b is 25ppm and 20ppm for g/n. I see the same connectivity problems in b/g/n modes. Crystals have three main sources of error: manufacturing tolerances, temperature, and aging. Many manufacturers of RF gear measure the crystal error at manufacture and store (and compensate in software) for that error to offset manufacturing tolerances. All of my testing for this thread has been done indoors where temperature varies very little; aging effects are usually small. I have good (DOCXO) HP counters (and a rubidium standard I can slave them to if needed) so I can measure the crystal accuracy (via a buffered hw timer output) if we have reason to suspect it, but we'd still need to know whether and how manufacturing tolerances are being compensated. The AIThinker module documentation has a bit more in the RF specs including ACR. They spec a 10ppm xtal: https://docs.ai-thinker.com/_media/esp8266/docs/esp-12f_product_specification_en.pdf At this point, I'm most interested in learning more about the RF calibration; is anyone familiar with that? Exactly what is being calibrated (and against what standard?) For reference: As I've continued testing, connectivity remains perfect on channel 6 but awful at the band edges. |
|
@Jason2866 I have more than 200 samples to work with; they all behave the same. Moreover, this same complaint is littered throughout virtually every ESP8266 discussion group and forum; there is no reason to think that I have "just" bad hardware and need to try more (and if I do, then there is a much larger quality problem). @mlichvar can you tell us more about the variance you are seeing between RX and TX? |
|
I was monitoring the RX signal level reported by the AP and the ESP. I tried to put them in the same position and orientation. For the five ESP-01s modules I have the ESP and AP levels were: -67 -77, -80 -79, -79 -80, -84 -91, -78 -82. More than 20dB between the best and worst, but all had the issue with the AP not receiving a large fraction of the transmissions. |
|
@dalbert2 My intention was to shade light on the hardware which has an major aspect here. It is a complicated issue. For example i have zero problems with any of my esp8266 devices in my wlan (6 APs from different vendors, most of them comercial business APS) Mode N works too, since my APs accepts to connect without WMM active |
|
@Jason2866 , it would be very helpful to know which ESP8266 devices you are using and which APs. Having some information about what works reliably would be great. Thanks! |
|
In my experience, boards using the Espressif castellated modules have the least problems. Typically the ESP-12F modules, but also the DoIot-ESP12S modules. |
|
Thanks @TD-er , I am only using ESP12F modules (for ESP8266) |
Most of the are NodeMCU with ESP-12F modules, some with bare esp8266 on it and Wemos Mini Clones with replaced 3.3V LDO (with a 500mA one). Lancom and BintecElmeg APs ( Bintec APs controlled via a WLAN Controller) and two Xiaomi 4A Gigabit flashed with OpenWRT |
Temperature effects can vary widely: https://datasheet.datasheetarchive.com/originals/library/Datasheet-081/DASF0020692.pdf I don't know much about Wifi but in our case even 1ppm drift was almost too much for a 915MHz radio, but we have tight requirements for that. In the beta of our 1st gen product we used to have to manually calibrate crystals for a radio module since they used cheap crystals that not only varied widely within a single batch, but would also have "dead zones" where drift PPM would spike in a certain/small temperature range and couldn't be modeled easily to calibrate, so those had to be tossed. AIThinker and so-on don't specify what crystal exactly they use or where they source it, so it's going to be all over the place. 20 ppm tolerance is pretty high, but cheaply sourced crystals can also be pretty bad.
If you can get repeated results with multiple modules, multiple APs, and multiple environments, and other devices are fine on those channels, that would be quite interesting. |
|
@someburner thanks; I understand crystal temperature/mfgr/aging tolerances and how to compensate for them. I have been designing outdoor, battery-powered wireless mesh water and gas utility meters that operate in the 902-928MHz band for nearly 20 years with almost a million devices in the field so I understand the challenges of frequency stability (especially over temperature) and how to compensate for them. Unfortunately, I have no visibility into what is being done by EspressIF in this regard and am interested if anyone else knows. The specific crystal tolerance requirements for WiFi were stated in a prior comment (20ppm and 25ppm depending on wifi flavor). Also mentioned earlier, the AI Thinker ESP12F modules I'm using indicate that they contain 10ppm crystals which are well within tolerance. Usually such crystals are 10ppm/10ppm (mfgr/temp tolerance). Crystal tolerance requirements depend on the bandwidth and modulation scheme: WiFi b/g subcarriers are 312.5kHz wide and the PHY is designed to accommodate automatic frequency correction, so WiFi should be more tolerant of temperature-induced crystal drift than most narrow-band 915MHz FSK systems of the sort you are probably using. A good overview of the 802.11b/g PHY is here: https://www.wirelesstrainingsolutions.com/understanding-ofdm-part-2-refresh/ As you surely know (but adding here for others who might be interested), increasing receiver sensitivity with low data-rate FSK requires increasingly narrow bandwidth (to keep increasing SNR). The narrower the bandwidth, the tighter the crystal tolerance required and at some point it becomes impractical. Newer modulation schemes (notably LoRa) avoid this and achieve very high sensitivity at low data rate using wide (125kHz and 500kHz) channels, eliminating the need for very tight crystal tolerances and achieving huge link budgets in many low data rate applications. However, as I also mentioned, the tests I've been doing recently are being conducted entirely indoors so there is very little temperature variation. Moreover, whether manufacturing, temperature, or aging, crystal tolerance issues would likely affect all channels equally; so crystal drift seems unlikely to explain the frequency (channel) specific problems and intermittent behaviors I am seeing with the ESP8266 (and that I am not seeing with other devices). I've monitored the wifi spectrum for a while too and it is pretty quiet so the issue doesn't appear to be local interferers (which is not to say that out of band interferers couldn't still be causing problems). However, as of now, this still feels like a software problem to me and the title of this thread suggests software as well. |
|
Thanks for the link! Was looking for something like that. I wasn't suggesting it wasn't a hardware problem (in our experience, it is extremely rare to be a hardware problem unless subjected to extreme environmental stresses or physical damage), but rather that in some cases I could see there being a big enough PPM to where certain ESP/router combos don't work very well. And found a paper about activity dips which is what I was referring to. Like you say, the crystals should be within tolerance, but without knowing the source of these crystals it could be worse than specified. I agree this sounds like a software problem. I haven't witnessed channel-specific problems myself but I've also never really audited that across our fleet. |
Well, shit. This has been my needle in the haystack. I noticed today that none of my ESP8266 devices were able to connect using 802.11n and everything was falling back to 802.11g. As soon as I added |
Basic Infos
Platform
Settings in IDE
Problem Description
sketch is "Udp NTP Client" included with release core.
I recently noticed that I had 802.11n and 802.11g devices on my network.
and I noticed that those which were connected in 802.11n are old modules on which I did not make any change in their codes and which were compiled with a core version lower than 2.5.0 (2.4.2 for the majorities)
I therefore put the supplied program "Udp NTP Client" and I tested with different versions of the cores, starting from 2.4.2.
up to version 2.5.1 included, it appears in 802.11n on the wifi router of my box.
except since version 2.6.0 until the last 2.7.4, it appears in 802.11g ...
do you have any idea why?
The text was updated successfully, but these errors were encountered: