wifi problems, for the hundredth time
Moderators: grovkillen, Stuntteam, TD-er
-
- Normal user
- Posts: 24
- Joined: 14 Jan 2022, 20:15
Re: wifi problems, for the hundredth time
my device is "Sonoff Basic R2 V1.0 (2017-10-11)"
Re: wifi problems, for the hundredth time
You know that by posting this, someone is now digging through lots and lots of boxes....
Re: wifi problems, for the hundredth time
Yes, there's a lot of boxes. But I found it!You know that by posting this, someone is now digging through lots and lots of boxes....
Good news, I have success. Has been running for over two hours.
The only oddity is that it does not work (hangs, timeouts) unless I select the "Send With Max TX Power" feature. Device is about 2 meters from the router and RSSI is -37dBm. Max WiFi TX Power is set to -14dBm (tried other values too).
If you have any other tests for me then let me know ASAP (before it goes back into storage).
BTW, here's what I FLASHED:
Code: Select all
Firmware Build: 20221006 - Mega
System Libraries: ESP82xx Core 2843a5ac, NONOS SDK 2.2.2-dev(c0eb301), LWIP: 2.1.2 PUYA support
Git Build: HEAD_a81d6ed
Plugin Count: 47 [Normal]
Build Origin: GitHub Actions
Build Time: Oct 6 2022 21:25:25
Binary Filename: ESP_Easy_mega_20221006_normal_ESP8266_4M1M
Build Platform: Linux-5.15.0-1020-azure-x86_64-with-glibc2.31
Git HEAD: HEAD_a81d6ed
Re: wifi problems, for the hundredth time
That's for sure not the latest build of that PR.
See: https://github.com/letscontrolit/ESPEas ... 3272571904
But that build may still have the funky issue that it may not start the AP when no wifi is configured.
N.B. the "TX power" mentioned by Ton was not what I finally changed in this PR.
What I did change:
- Add 'delay' calls right after changing any WiFi related setting in SDK calls to make sure all is being processed before doing anything else.
- Start the WiFi a bit later after boot.
- Keep track of what's happening and what to expect, so when things happen which I don't expect -> Reset wifi
- Add work-around when some events are missed and then assume they were fired, thus process them.
And maybe the most fuzzy change: Switch to a different binary blob, which was doing the 802.11n connection according to the standards, instead of the other blobs which were recommended to be used.
I know that blob part wasn't the magical fix, but I also got the feeling all my other fixes aren't without this blob thingy.
So consider this to be a fix with a special blob sauce.
We got a new WiFi and we call him/her "Blob". B.Blob
See: https://github.com/letscontrolit/ESPEas ... 3272571904
But that build may still have the funky issue that it may not start the AP when no wifi is configured.
N.B. the "TX power" mentioned by Ton was not what I finally changed in this PR.
What I did change:
- Add 'delay' calls right after changing any WiFi related setting in SDK calls to make sure all is being processed before doing anything else.
- Start the WiFi a bit later after boot.
- Keep track of what's happening and what to expect, so when things happen which I don't expect -> Reset wifi
- Add work-around when some events are missed and then assume they were fired, thus process them.
And maybe the most fuzzy change: Switch to a different binary blob, which was doing the 802.11n connection according to the standards, instead of the other blobs which were recommended to be used.
I know that blob part wasn't the magical fix, but I also got the feeling all my other fixes aren't without this blob thingy.
So consider this to be a fix with a special blob sauce.
We got a new WiFi and we call him/her "Blob". B.Blob
Re: wifi problems, for the hundredth time
Oh and by the way, the fact that you have to select "send with max. TX" to make it work is again rather typical....
The only explanation I can give here is that that antenna is probably so badly tuned, that it can't be heard by the AP when sending at lower power.... Or maybe the quick switching of TX power may be causing this.
That's easy to test, by setting the max. TX power to something like 10 and then check that checkbox.
The only explanation I can give here is that that antenna is probably so badly tuned, that it can't be heard by the AP when sending at lower power.... Or maybe the quick switching of TX power may be causing this.
That's easy to test, by setting the max. TX power to something like 10 and then check that checkbox.
Re: wifi problems, for the hundredth time
Oops, didn't know that. I've re-flashed with ESP_Easy_mega_20221018_normal_ESP8266_4M1M. So hopefully that is the version you need me to test.That's for sure not the latest build of that PR.
I've set Max TX Power to -10dBm. Also have moved the device much further away, RSSI now -62dBm (weak signal). Still works with "Send With Max TX Power" enabled and also works with it disabled. And continues to work after I reboot (tested both warm and cold boot).That's easy to test, by setting the max. TX power to something like 10 and then check that checkbox.
TL;DR: Better results this time. Congrats on fixing this, been a long fight.
Anything else you need me to try?
- Thomas
Re: wifi problems, for the hundredth time
Yep, try to have way less troubles when moving than we had.
It's been 7 months since we moved in and still not all work by the subcontractors (who should have finished before we moved in) is done.
So please try to do better than we did.
And indeed the WiFi battle was long... about 4 years now?
So I finally can start unboxing and sorting my stuff in my lab (makes it sound more official )
Re: wifi problems, for the hundredth time
For those willing to do some more tests...
Just made a fix for ESPEasy not trying to reconnect when the configured AP was not reachable.
Also ESPEasy was not starting an AP right after a factory reset.
Both should be fixed now and can be tested as soon as this test build is ready:
https://github.com/letscontrolit/ESPEas ... 3290438812
While going through the code, I noticed the AP also will not be started if the unit has an uptime of over 5 minutes.
So I'm thinking about what to do when the ESP doesn't have any credentials stored.
I think it is a bit impractical to have to reboot the unit when you're just past this 5 minutes uptime on the initial setup.
Just made a fix for ESPEasy not trying to reconnect when the configured AP was not reachable.
Also ESPEasy was not starting an AP right after a factory reset.
Both should be fixed now and can be tested as soon as this test build is ready:
https://github.com/letscontrolit/ESPEas ... 3290438812
While going through the code, I noticed the AP also will not be started if the unit has an uptime of over 5 minutes.
So I'm thinking about what to do when the ESP doesn't have any credentials stored.
I think it is a bit impractical to have to reboot the unit when you're just past this 5 minutes uptime on the initial setup.
Re: wifi problems, for the hundredth time
Too late for that. So far the process of buying a new home (and selling our old one) has been a disaster. And gets worse each day. My wife is a mess, regrets buying a new house. I'm just numb from it all and have determined that we're starring on a sicker / more twisted version of The Truman Show.Yep, try to have way less troubles when moving than we had.
I'm looking forward to that day.So I finally can start unboxing and sorting my stuff in my lab (makes it sound more official)
I agree, if the STA credentials are missing it would be best to avoid rebooting since a user could be attempting to configure the device.So I'm thinking about what to do when the ESP doesn't have any credentials stored.
I think it is a bit impractical to have to reboot the unit when you're just past this 5 minutes uptime on the initial setup.
- Thomas
Re: wifi problems, for the hundredth time
Ah too bad...
Well maybe you could "celebrate" your 1000'th post a bit.
About the Truman show reference.... Is it about having loads of viewers for the house? (not calling them "potential buyers")
Well maybe you could "celebrate" your 1000'th post a bit.
About the Truman show reference.... Is it about having loads of viewers for the house? (not calling them "potential buyers")
Re: wifi problems, for the hundredth time
Yoo-hoo! Now at 1001.Well maybe you could "celebrate" your 1000'th post a bit.
I wish. My Truman Show experience is a classic dark comedy; I suspect my show is getting very high ratings.About the Truman show reference.... Is it about having loads of viewers for the house? (not calling them "potential buyers")
- Thomas
-
- Normal user
- Posts: 24
- Joined: 14 Jan 2022, 20:15
Re: wifi problems, for the hundredth time
@TD-er: May you can pre-release a patch? Or are you go to push it to a branch I would be able to merge/cherrypick for myself?
Thanks a lot!
Thanks a lot!
Re: wifi problems, for the hundredth time
This is the latest GitHub Actions build for the pull request with these changes: https://github.com/letscontrolit/ESPEas ... 3308241374
(N.B. you need to be logged in at GitHub to download the files from Actions builds)
All changes are in this pull request: https://github.com/letscontrolit/ESPEasy/pull/4285
I am still a bit in doubt about whether to merge it now, or make a new official build of ESPEasy first.
By merging it after the build, it makes it easier to track down any reported issues.
(N.B. you need to be logged in at GitHub to download the files from Actions builds)
All changes are in this pull request: https://github.com/letscontrolit/ESPEasy/pull/4285
I am still a bit in doubt about whether to merge it now, or make a new official build of ESPEasy first.
By merging it after the build, it makes it easier to track down any reported issues.
-
- Normal user
- Posts: 24
- Joined: 14 Jan 2022, 20:15
Re: wifi problems, for the hundredth time
Code: Select all
git remote add -f ESPEasy-TDer https://github.com/TD-er/ESPEasy.git
I didn't not know about the separate Dev-Repo...
Runs smooth (2% loss) on the S-B R2 V1 testboard. I will now reflash my fuse panel.
Re: wifi problems, for the hundredth time
Well it is not really a "dev repo"
It is more like I also force myself to do exactly the same as everybody else needs to do when creating a pull request.
So my repo is just a fork of the letscontrolit/ESPEasy repo and when I make bug fixes of develop a new feature, I just create a new branch on my own fork and when ready to make a pull request, I just push it to GitHub and create a pull request to merge it into the letscontrolit/ESPEasy repo.
It is more like I also force myself to do exactly the same as everybody else needs to do when creating a pull request.
So my repo is just a fork of the letscontrolit/ESPEasy repo and when I make bug fixes of develop a new feature, I just create a new branch on my own fork and when ready to make a pull request, I just push it to GitHub and create a pull request to merge it into the letscontrolit/ESPEasy repo.
-
- Normal user
- Posts: 24
- Joined: 14 Jan 2022, 20:15
Re: wifi problems, for the hundredth time
0,05% after 13k pings...
-
- Normal user
- Posts: 24
- Joined: 14 Jan 2022, 20:15
Re: wifi problems, for the hundredth time
unfortunately in commit 17ba610d "Merge pull request #4285 from TD-er/bugfix/wifi_mode_multiple_times" it does NOT take action.
there is again no connect possible and Ping loss is around 100%.
Commit 5bdfc81b (pull request #4285) merged into 14fb3a2e was fine!
there is again no connect possible and Ping loss is around 100%.
Commit 5bdfc81b (pull request #4285) merged into 14fb3a2e was fine!
Re: wifi problems, for the hundredth time
OK, so this was working fine: https://github.com/letscontrolit/ESPEas ... e6cdc053ce
And this one was bad again: https://github.com/letscontrolit/ESPEas ... 53df535307
Or to put it more in the context of the commits of this PR: https://github.com/letscontrolit/ESPEas ... 85/commits
The commit on Oct 23,2022 was OK
The commit when actually merging it was not.
I will try to get a diff between those commits to see what may have changed in between.
What actual build are you using (which plugins when using a custom build) ?
And this one was bad again: https://github.com/letscontrolit/ESPEas ... 53df535307
Or to put it more in the context of the commits of this PR: https://github.com/letscontrolit/ESPEas ... 85/commits
The commit on Oct 23,2022 was OK
The commit when actually merging it was not.
I will try to get a diff between those commits to see what may have changed in between.
What actual build are you using (which plugins when using a custom build) ?
Re: wifi problems, for the hundredth time
I have looked through all the commits made between these 2 you gave and I can't see any WiFi related code change.
This then means one thing.... the build that appeared 'stable' on those Espressif units was merely a "fluke".
Meaning this seems to be just random whether a build may be stable or not on those units.
I've seen this before, where simply changing a string in the code could make a difference between "stable WiFi" and "horrible WiFi"
Meaning we're back at where we started, meaning some piece of code (no clue what/where) really needs to be aligned in a very specific way or else we might enter such incredibly tight timing restrictions which make the difference between stable and bad connection.
I just feel so incredibly bad right now, as I've spent an incredible amount of time on this only to be set back to where we were about 4 years ago.
This then means one thing.... the build that appeared 'stable' on those Espressif units was merely a "fluke".
Meaning this seems to be just random whether a build may be stable or not on those units.
I've seen this before, where simply changing a string in the code could make a difference between "stable WiFi" and "horrible WiFi"
Meaning we're back at where we started, meaning some piece of code (no clue what/where) really needs to be aligned in a very specific way or else we might enter such incredibly tight timing restrictions which make the difference between stable and bad connection.
I just feel so incredibly bad right now, as I've spent an incredible amount of time on this only to be set back to where we were about 4 years ago.
Re: wifi problems, for the hundredth time
Perhaps you've entered into my Truman Show as this week's guest cast member. The plot centers around unnecessary torture of the show's characters.I just feel so incredibly bad right now, as I've spent an incredible amount of time on this only to be set back to where we were about 4 years ago.
- Thomas
Re: wifi problems, for the hundredth time
I believe so.
Not only about the WiFi stuff, but also the sub-sub-contractors of my house seem to be part of this organized torture as they just sent me some bill for "extra work" which was fixing the stuff they did wrong 8 months ago and still has not been fixed.
Also they sent another document stating they closed the case.
It's close to 9 years that we're working on this frustration.
Not only about the WiFi stuff, but also the sub-sub-contractors of my house seem to be part of this organized torture as they just sent me some bill for "extra work" which was fixing the stuff they did wrong 8 months ago and still has not been fixed.
Also they sent another document stating they closed the case.
It's close to 9 years that we're working on this frustration.
Re: wifi problems, for the hundredth time
OK, I just spent digging through boxes for way over 2 hours and found (finally) the bag with Sonoff basic units.
Flashed the latest source I was working on to it and it was next to impossible to make a proper WiFi connection.
Also accessing it via its AP was nearly unusable as you could not save settings on the tools->Advanced page.
After rebooting/power cycling etc a lot of times, I tried to checkout the mentioned working commit and suddenly the Sonoff started to reply to pings.
N.B. I had not yet compiled anything using the "good" commit.
So there is something funky going on with the timings as it is now running fine.
As you can see, it was first connected to the closest AP, got disconnected after 50-ish seconds and then reconnected to one of the other ones which does have a worse RSSI.
So I will start experimenting with these settings.
At least I now have some units that actually will be capable of (sometimes) misbehave regarding WiFi stability.
One point of attention though is that I did close the Sonoff Basic unit. So it has now some dupont wires and an USB to serial board dangling outside.
The ABS of the enclosure can change the tuning of the antenna.
Oh and I did set the same SSID/key twice, so it would retry to connect a few extra times. (both wifi credential settings)
Flashed the latest source I was working on to it and it was next to impossible to make a proper WiFi connection.
Also accessing it via its AP was nearly unusable as you could not save settings on the tools->Advanced page.
After rebooting/power cycling etc a lot of times, I tried to checkout the mentioned working commit and suddenly the Sonoff started to reply to pings.
N.B. I had not yet compiled anything using the "good" commit.
So there is something funky going on with the timings as it is now running fine.
Code: Select all
14462 : Info : WIFI : AP Mode ssid will be ESP-Easy with address 192.168.4.1
14540 : Info : WD : Uptime 0 ConnectFailures 0 FreeMem 22320 WiFiStatus 0 ESPeasy internal wifi status: DISCONNECTED
19793 : Info : WIFI : Connecting Lurch4 CC:CE:1E:13:B7:58 Ch:1 (-53dBm) WPA2/PSK attempt #2
22804 : Info : WIFI : DHCP IP: 192.168.10.136 (ESP-Easy) GW: 192.168.10.1 SN: 255.255.255.0 duration: 1993 ms
22808 : Info : UDP : Start listening on port 8266
22808 : Info : firstLoopConnectionsEstablished
22812 : Info : WIFI : Connected! AP: Lurch4 (CC:CE:1E:13:B7:58) Ch: 1 Duration: 995 ms
42203 : Info : WD : Uptime 1 ConnectFailures 0 FreeMem 21696 WiFiStatus 3 ESPeasy internal wifi status: Conn. IP Init
72203 : Info : WD : Uptime 1 ConnectFailures 0 FreeMem 21696 WiFiStatus 3 ESPeasy internal wifi status: Conn. IP Init
72210 : Info : WIFI : Disconnected! Reason: '(6)' Connected for 51 s
72313 : Info : WIFI : Connecting Lurch4 CC:CE:1E:13:B7:58 Ch:1 (-53dBm) WPA2/PSK attempt #3
73282 : Info : WIFI : Disconnected! Reason: '(202)' Connected for 950 ms
82324 : Info : WIFI : Connecting Lurch4 3C:37:12:AA:D0:5C Ch:1 (-63dBm) WPA2/PSK attempt #4
88153 : Info : Time set to 1667259443.642
88155 : Info : Current Time Zone: STD time start: 2022-10-30 03:00:00 offset: 0 min
88158 : Info : Local time: 2022-10-31 23:37:23
92435 : Info : WIFI : Disconnected! Reason: '(8)' Connected for 1 m 32 s
92536 : Info : Reset WiFi.
94731 : Info : WIFI : Connecting Lurch4 CC:CE:1E:13:B7:58 Ch:1 (-55dBm) WPA2/PSK attempt #5
94838 : Info : WIFI : Disconnected! Reason: '(8)' Connected for 5 ms
94939 : Info : Reset WiFi.
97133 : Info : WIFI : Connecting Lurch4 CC:CE:1E:13:B7:58 Ch:1 (-55dBm) WPA2/PSK attempt #6
98081 : Info : WIFI : Disconnected! Reason: '(8)' Connected for 5 ms
98082 : Info : WIFI : Set WiFi to OFF
98317 : Info : WIFI : Disconnected! Reason: '(202)' Connected for 951 ms
98529 : Info : WIFI : Disconnected! Reason: '(8)' Connected for 1295 ms
102210 : Info : WD : Uptime 2 ConnectFailures 0 FreeMem 21752 WiFiStatus 6 ESPeasy internal wifi status: DISCONNECTED
107239 : Info : WIFI : Set WiFi to STA
107344 : Info : WIFI : Connecting Lurch4 CC:CE:1E:13:B7:58 Ch:1 (-55dBm) WPA2/PSK attempt #7
108478 : Info : WIFI : DHCP IP: 192.168.10.136 (ESP-Easy) GW: 192.168.10.1 SN: 255.255.255.0 duration: 35 ms
108533 : Info : WIFI : Connected! AP: Lurch4 (CC:CE:1E:13:B7:58) Ch: 1 Duration: 1078 ms
132203 : Info : WD : Uptime 2 ConnectFailures 0 FreeMem 23072 WiFiStatus 3 ESPeasy internal wifi status: Conn. IP Init
162203 : Info : WD : Uptime 3 ConnectFailures 0 FreeMem 22192 WiFiStatus 3 ESPeasy internal wifi status: Conn. IP Init
192203 : Info : WD : Uptime 3 ConnectFailures 0 FreeMem 22192 WiFiStatus 3 ESPeasy internal wifi status: Conn. IP Init
222203 : Info : WD : Uptime 4 ConnectFailures 0 FreeMem 22192 WiFiStatus 3 ESPeasy internal wifi status: Conn. IP Init
So I will start experimenting with these settings.
At least I now have some units that actually will be capable of (sometimes) misbehave regarding WiFi stability.
One point of attention though is that I did close the Sonoff Basic unit. So it has now some dupont wires and an USB to serial board dangling outside.
The ABS of the enclosure can change the tuning of the antenna.
Oh and I did set the same SSID/key twice, so it would retry to connect a few extra times. (both wifi credential settings)
Re: wifi problems, for the hundredth time
That might be an important clue or could be another rabbit hole. Remove the case, confirm the bad behavior, then re-install it, test again. If it works correctly then repeat this sequence several times to ensure it's not just another cruel joke plot by the Truman show.One point of attention though is that I did close the Sonoff Basic unit. So it has now some dupont wires and an USB to serial board dangling outside.
The ABS of the enclosure can change the tuning of the antenna.
- Thomas
Re: wifi problems, for the hundredth time
Well right now it isn't even allowing me to get a stable link.
Tried to flash several builds, reboot, etc.
I will try again performing a complete wipe and then will try to get some sleep.
I have my Hue lamp here in my office set to turn off at a random time between 1:20 and 1:50.
Some would think it is to let criminals with bad intentions think it is to suggest people are still at home.
However I have it to give me some hint to go to bed.
So it may turn off now any moment, meaning I have to hurry
Tried to flash several builds, reboot, etc.
I will try again performing a complete wipe and then will try to get some sleep.
I have my Hue lamp here in my office set to turn off at a random time between 1:20 and 1:50.
Some would think it is to let criminals with bad intentions think it is to suggest people are still at home.
However I have it to give me some hint to go to bed.
So it may turn off now any moment, meaning I have to hurry
Re: wifi problems, for the hundredth time
too late... the lights have turned off.
Have to go to bed now
Have to go to bed now
Re: wifi problems, for the hundredth time
Fingers crossed you have a better day tomorrow.
Sun just went down in my area. So I'll help hand out candy to the kids. No haunted house this year, all the scary props are packed in boxes.
Here's an old video of Skully. He is a regular every Halloween, but this year he's on sabbatical.
https://www.youtube.com/watch?v=Qutzaj3u7WY
- Thomas
Sun just went down in my area. So I'll help hand out candy to the kids. No haunted house this year, all the scary props are packed in boxes.
Here's an old video of Skully. He is a regular every Halloween, but this year he's on sabbatical.
https://www.youtube.com/watch?v=Qutzaj3u7WY
- Thomas
Re: wifi problems, for the hundredth time
OK, have been playing a bit with the Sonoff basic unit.
Preliminary conclusions:
Build does not really seem to make a difference, as it is more like a random timing issue.
Builds which do seem to connect almost immediately and seem to respond to almost any ping, can still be hardly usable because saving settings via the web interface appear to lockup the ESP thus causing a timeout.
Larger pages may load incomplete.
The TX power does seem to have a bigger effect on WiFi stability.
I got a feeling that checking the WiFi RSSI value also has some effect on the WiFi stability.
Connecting to WiFi in STA mode does seem to be faster when in AP+STA mode, so it seems the internal timing of the WiFi radio is slightly off.
When the AP mode is active, the WiFi radio does not go into "radio sleep" mode inbetween WiFi beacon packets (typically every 102.4 msec). When in STA mode, the radio is turned off inbetween these beacon packets.
So it is possible the ESP may need slightly longer to turn on the radio and get stable.
I don't know how critical these timings are and whether the various closed source WiFi blobs may vary in these timings during the WiFi calibration.
Later this evening, I will hook the ESP up to my power profiler unit to get an idea on when the power consumption changes and whether there is some jitter.
Preliminary conclusions:
Build does not really seem to make a difference, as it is more like a random timing issue.
Builds which do seem to connect almost immediately and seem to respond to almost any ping, can still be hardly usable because saving settings via the web interface appear to lockup the ESP thus causing a timeout.
Larger pages may load incomplete.
The TX power does seem to have a bigger effect on WiFi stability.
I got a feeling that checking the WiFi RSSI value also has some effect on the WiFi stability.
Connecting to WiFi in STA mode does seem to be faster when in AP+STA mode, so it seems the internal timing of the WiFi radio is slightly off.
When the AP mode is active, the WiFi radio does not go into "radio sleep" mode inbetween WiFi beacon packets (typically every 102.4 msec). When in STA mode, the radio is turned off inbetween these beacon packets.
So it is possible the ESP may need slightly longer to turn on the radio and get stable.
I don't know how critical these timings are and whether the various closed source WiFi blobs may vary in these timings during the WiFi calibration.
Later this evening, I will hook the ESP up to my power profiler unit to get an idea on when the power consumption changes and whether there is some jitter.
Re: wifi problems, for the hundredth time
Just had a thought. Have you tested your fussy Sonoff Basic R2 using AC power rather than USB power? That is to say, disconnect it from the DEV wiring, safely put it in the plastic enclosure, wire it up for Mains power, and see if the bad behavior goes away.Build does not really seem to make a difference, as it is more like a random timing issue.
Builds which do seem to connect almost immediately and seem to respond to almost any ping, can still be hardly usable because saving settings via the web interface appear to lockup the ESP thus causing a timeout.
Larger pages may load incomplete.
The TX power does seem to have a bigger effect on WiFi stability.
The reason I ask is because I never did this test. And maybe it makes a difference.
- Thomas
Re: wifi problems, for the hundredth time
And another few hours of testing have passed...
I was first testing using one of those "Wemos" USB to serial boards.
These have a linear voltage regulator on board capable of +/- 200 mA continuous.
This setup was giving me quite the bad WiFi experience as described by numerous users over the years when using the Sonoff Basic units.
I also switched back to an older SDK, the 2.2.1 "Legacy" one.
This was initially giving a really horrible WiFi performance, so I decided to erase the flash and flash it again.
It was an improvement, but hardly any better than with the 2.2.2 "March 2019" one that was reported to be "the fix"... upto the next commit.
So now I've taken the unit back to my office. Connected through the same USB to UART board and performed "meh" at best. Incomplete page loading, unable to save settings. The usual.
As promissed, I connected the Power Profiler kit to it, which can also deliver its own output voltage upto 1A.
Used the same dupont wires as before and now it is performing perfectly.
N.B. the same settings, the same flashed firmware and the same environment.
Did power cycle the unit a few times to make sure of what I was seeing.
So it seems to be -as suspected- the power supply.
Or at least the Power Profiler Kit 2 from Nordic is capable of reacting very swiftly to spikes in current.
After all, it is sampling the current (and switching ADC gains and shunts) at 100'000 samples per second. Wouldn't be surprised if this power supply is more stable than just about any lab power supply under a few-100 euro.
With this setup, it is still possible to setup the ESP to give a really bad WiFi experience.
Running in ECO mode is on this one a big no-no, where other ESP boards work perfectly fine. So it still isn't perfect.
Switching TX power is hardly saving energy, but the peaks are absolutely lower as can be seen in the attachment. With TX power set to the max. (17.5 dBm, running in 802.11g mode), the max. power peaks are at 191 mA, where it is max. 119 mA in the selected window (variable TX power)
The responsiveness hardly differed with different TX power settings, as long as it was connected to this Power Profiler Kit.
I will order some Sonoff Basic R2 and R3 units to also test them.
I'm not 100% sure my Basic units are R1 or R2. I know they aren't R3.
Right now I don't believe it really is a software/build issue, but more like a power supply issue.
As I mentioned before, it is very well possible there still is some slight timing variation possible between builds, which can be just enough to trigger these really bad WiFi connections.
However, given the timings are apperently so critical, then aging of capacitors may turn "stable" running units into "unstable" units.
So I'm honestly not sure anymore what to do here.
I was first testing using one of those "Wemos" USB to serial boards.
These have a linear voltage regulator on board capable of +/- 200 mA continuous.
This setup was giving me quite the bad WiFi experience as described by numerous users over the years when using the Sonoff Basic units.
I also switched back to an older SDK, the 2.2.1 "Legacy" one.
This was initially giving a really horrible WiFi performance, so I decided to erase the flash and flash it again.
It was an improvement, but hardly any better than with the 2.2.2 "March 2019" one that was reported to be "the fix"... upto the next commit.
So now I've taken the unit back to my office. Connected through the same USB to UART board and performed "meh" at best. Incomplete page loading, unable to save settings. The usual.
As promissed, I connected the Power Profiler kit to it, which can also deliver its own output voltage upto 1A.
Used the same dupont wires as before and now it is performing perfectly.
N.B. the same settings, the same flashed firmware and the same environment.
Did power cycle the unit a few times to make sure of what I was seeing.
So it seems to be -as suspected- the power supply.
Or at least the Power Profiler Kit 2 from Nordic is capable of reacting very swiftly to spikes in current.
After all, it is sampling the current (and switching ADC gains and shunts) at 100'000 samples per second. Wouldn't be surprised if this power supply is more stable than just about any lab power supply under a few-100 euro.
With this setup, it is still possible to setup the ESP to give a really bad WiFi experience.
Running in ECO mode is on this one a big no-no, where other ESP boards work perfectly fine. So it still isn't perfect.
Switching TX power is hardly saving energy, but the peaks are absolutely lower as can be seen in the attachment. With TX power set to the max. (17.5 dBm, running in 802.11g mode), the max. power peaks are at 191 mA, where it is max. 119 mA in the selected window (variable TX power)
The responsiveness hardly differed with different TX power settings, as long as it was connected to this Power Profiler Kit.
I will order some Sonoff Basic R2 and R3 units to also test them.
I'm not 100% sure my Basic units are R1 or R2. I know they aren't R3.
Right now I don't believe it really is a software/build issue, but more like a power supply issue.
As I mentioned before, it is very well possible there still is some slight timing variation possible between builds, which can be just enough to trigger these really bad WiFi connections.
However, given the timings are apperently so critical, then aging of capacitors may turn "stable" running units into "unstable" units.
So I'm honestly not sure anymore what to do here.
Re: wifi problems, for the hundredth time
Interesting, thanks for the info.
- Thomas
The Basic R2 V1.0 units will be labeled on the PCB. Post a photo.I'm not 100% sure my Basic units are R1 or R2. I know they aren't R3.
Would you mind testing it as described in my previous post? Would be interesting to see test results using AC Mains power vs. USB to UART board power.So I'm honestly not sure anymore what to do here.
- Thomas
Re: wifi problems, for the hundredth time
Based on this video I only have the R1 units.
Re: wifi problems, for the hundredth time
Oh my. That video has me very confused. If you look closely at the video's "R1" Sonoff the PCB is labeled "Sonoff Basic R2 Hardware V1.0."Based on this video I only have the R1 units.
Here's a close-up of my Sonoff Basic R2 Hardware Rev 1. Date code 2017-10-11. It has a ESP8266 with external FLASH. Ignore the extra capacitor, I did some experiments with power supply noise suppression (none of which has helped).
. Also, the "R2" in the video is the updated version that has ESP8285, no external FLASH. Its PCB is labeled as "Sonoff RF R2 Power, V1.0."
Sonoff has labeled both versions as "R2" devices, but with slightly different names. We can thank Sonoff for making this so confusing.
TL;DR: I suspect you have a Sonoff Basic R2 V1.0 (the bad child), not a Sonoff RF R2 Power R2 V1.0 (the good child).
- Thomas
Re: wifi problems, for the hundredth time
I just opened all of them... or at least all I have managed to find in my boxes.
No CE marking on the enclosures.
Already have a R2 version in my shopping basket on a very dangerous website: https://www.tinytronics.nl/shop/nl/plat ... 66-esp8285
Looks like they are the R1 versions?
No CE marking on the enclosures.
Already have a R2 version in my shopping basket on a very dangerous website: https://www.tinytronics.nl/shop/nl/plat ... 66-esp8285
Re: wifi problems, for the hundredth time
Yours look just like my "Sonoff Basic R2" but are missing the useful silkscreen text. Instead, the PCB on yours only says "Sonoff."
My best guess is that we have the same board. It's the one that is the spawn of Satan.
- Thomas
My best guess is that we have the same board. It's the one that is the spawn of Satan.
- Thomas
Re: wifi problems, for the hundredth time
Yep looks like these are indeed the same.
According to our friends at Tasmota, the Basic R2 really differs from the older one.
https://tasmota.github.io/docs/devices/ ... f-basic-r2
I do remember back in the day when I just started using those Sonoff units, some of them didn't even have extra solder on the power traces to make them slightly more "powerful".
The "Basic" units I have here, all have this solder on the traces, but I'm not sure whether this solder was added by iTead or done it myself.
According to our friends at Tasmota, the Basic R2 really differs from the older one.
https://tasmota.github.io/docs/devices/ ... f-basic-r2
I do remember back in the day when I just started using those Sonoff units, some of them didn't even have extra solder on the power traces to make them slightly more "powerful".
The "Basic" units I have here, all have this solder on the traces, but I'm not sure whether this solder was added by iTead or done it myself.
Re: wifi problems, for the hundredth time
I took another one from that bag of Sonoff Basic ones and flashed it to see how its wifi stability will be.
And this one is working just fine. No problems at all.
So there seems to be a difference among units even though their PCBs seem to be exactly the same.
So I need to keep track of the "bad one".
And this one is working just fine. No problems at all.
So there seems to be a difference among units even though their PCBs seem to be exactly the same.
So I need to keep track of the "bad one".
Re: wifi problems, for the hundredth time
Hmm, that's not good. Maybe this is a silicon revision issue? Check the laser etched text on the ESP8266 chips and compare the two devices.
- Thomas
- Thomas
Re: wifi problems, for the hundredth time
The one with good WiFi performance:
The one I tested all day with flaky WiFi performance: Manuf: week 49/2016
There seems to be 1 week difference in manufacture week.
Manuf: week 48/2016
The one I tested all day with flaky WiFi performance: Manuf: week 49/2016
There seems to be 1 week difference in manufacture week.
Re: wifi problems, for the hundredth time
Well this does not seem to be the reason for the issue. Perhaps the problem is due to component tolerance issues.There seems to be 1 week difference in manufacture week.
Just to be clear, this "good" Sonoff Basic R2 V1.0 board always works reliably, regardless of the firmware?
- Thomas
Re: wifi problems, for the hundredth time
"always" is maybe not the correct term as I only flashed 2 builds on it ("minimal" and "custom")
Re: wifi problems, for the hundredth time
Will later test to see how this one performs.
But it is indeed a completely different unit.
This one has the flash pins next to the LED as can be seen on the photo.
And it even has them labelled at the bottom in the silkscreen.
Re: wifi problems, for the hundredth time
That "Sonoff Basic" is the version with the Sonoff RF R2 Power PCB. I have a couple and they do not exhibit the WiFi issue.Just arrived, the ordered Sonoff basic R2.
But because of their cost reduced ESP8285 chip they are limited to 1MB firmware builds. And one of the GPIO pin pads has been removed. Not a fan.
- Thomas
Re: wifi problems, for the hundredth time
I did take another look and indeed it states RF power on the silkscreen.
Anyway, it is an ESP8285, which I still needed to test to see if the run-time detection of ESP8285 is now working fine.
Anyway, it is an ESP8285, which I still needed to test to see if the run-time detection of ESP8285 is now working fine.
Re: wifi problems, for the hundredth time
I've been thinking about this a bit. I wonder if this "random" build stability issue is being caused by the compiler's optimization features.This then means one thing.... the build that appeared 'stable' on those Espressif units was merely a "fluke".
Meaning this seems to be just random whether a build may be stable or not on those units.
I've seen this before, where simply changing a string in the code could make a difference between "stable WiFi" and "horrible WiFi"
For example, the optimizer can introduce odd behavior on code that is not written with care. One example involves reading hardware addresses/registers. If the address isn't declared as volatile the optimizer may decide to omit a new read. This is just one example; optimization does a lot of magic things that can vary with minor changes to code.
So as an experiment, disable optimization and see if that results in stable WiFi operation. If it does then that means someone wrote some WiFi code that confuses the optimizer.
- Thomas
Re: wifi problems, for the hundredth time
That's exactly what I've been saying for years.
A very simple example is reading from flash.
This has to be done per 32 bits, so if something isn't 32-bit aligned, you introduce some extra delay.
Some classes even act different when being accessed on aligned data or not aligned data.
Copying a flash string only adds upto 2 extra reads and then upto 3 byte copies per read.
But having a pointer to an unaligned member may appear as a bigger impact in performance simply because they may occur more frequently, but also that such code may use a larger chunk of the memory assigned to run the code and thus need flash access more often. (similar to what you mention as 'volatile' flagged members)
Some users also report that "debug" builds work fine, where "release" builds failed.
A very simple example is reading from flash.
This has to be done per 32 bits, so if something isn't 32-bit aligned, you introduce some extra delay.
Some classes even act different when being accessed on aligned data or not aligned data.
Copying a flash string only adds upto 2 extra reads and then upto 3 byte copies per read.
But having a pointer to an unaligned member may appear as a bigger impact in performance simply because they may occur more frequently, but also that such code may use a larger chunk of the memory assigned to run the code and thus need flash access more often. (similar to what you mention as 'volatile' flagged members)
Some users also report that "debug" builds work fine, where "release" builds failed.
Re: wifi problems, for the hundredth time
Yesterday, we made quite some progress in build reliability.
Jason2866 from the Tasmota team, pointed out that PlatformIO may sometimes show irregular behavior when it isn't set to "strict" on searching for libraries.
As a simple example; in the Actions builds Ton noticed one of the envs was quite a bit larger (and thus failing) compared to the build on his computer. After this change, the build was again fine.
Also we had some reported issue on ESP32 builds with Neopixel plugin, but this seems also to be fixed by this.
I just did some tests on my "Sonoff basic units from Hell" as someone tends to name them
These units work now just fine.
Just as a proof, the exact build as is running on my nodes here:
https://www.dropbox.com/s/jqscg63wdeoxz ... C.bin?dl=0
I did test it with limited TX power, but also with max. TX power.
With and without "Eco mode" enabled.
It is powered via an USB to UART module, thus far from optimal.
The Sonoff is in its own enclosure.
So I believe this library dependency finder option in PlatformIO may have caused way more havoc than we can imagine, but I'm glad it now seems to be a reliable build env. again.
Jason2866 from the Tasmota team, pointed out that PlatformIO may sometimes show irregular behavior when it isn't set to "strict" on searching for libraries.
As a simple example; in the Actions builds Ton noticed one of the envs was quite a bit larger (and thus failing) compared to the build on his computer. After this change, the build was again fine.
Also we had some reported issue on ESP32 builds with Neopixel plugin, but this seems also to be fixed by this.
I just did some tests on my "Sonoff basic units from Hell" as someone tends to name them
These units work now just fine.
Just as a proof, the exact build as is running on my nodes here:
https://www.dropbox.com/s/jqscg63wdeoxz ... C.bin?dl=0
I did test it with limited TX power, but also with max. TX power.
With and without "Eco mode" enabled.
It is powered via an USB to UART module, thus far from optimal.
The Sonoff is in its own enclosure.
So I believe this library dependency finder option in PlatformIO may have caused way more havoc than we can imagine, but I'm glad it now seems to be a reliable build env. again.
Re: wifi problems, for the hundredth time
That is fantastic news. Hopefully the "strict" directive is the final fix to our multi-year frustration. Extra hugs to @Jason2866 for sharing it.Yesterday, we made quite some progress in build reliability.
Jason2866 from the Tasmota team, pointed out that PlatformIO may sometimes show irregular behavior when it isn't set to "strict" on searching for libraries.
I just added "lib_compat_mode = strict" to my ESP32 FM radio project. I don't need random bugs, so tricks like it are good to include. BTW, the radio project's firmware size did not change which indicates the proper libs were previously used. That's a relief -- avoids unnecessary hair pulling reactions.
- Thomas
Re: wifi problems, for the hundredth time
Yep, my hairline has also receded quite a lot since I started working on ESPEasy.
The grey color, which seems to be outgrowing the nr. of black hairs cannot be attributed to these WiFi issues, since that's hereditary. It is a well known fact, grey hair is inherited from your offspring.
The grey color, which seems to be outgrowing the nr. of black hairs cannot be attributed to these WiFi issues, since that's hereditary. It is a well known fact, grey hair is inherited from your offspring.
Re: wifi problems, for the hundredth time
It is a well known fact, grey hair is inherited from your offspring.
Who is online
Users browsing this forum: Google [Bot] and 3 guests