wifi problems, for the hundredth time

Message

Gregor54321 · #51 Post by **Gregor54321** » 19 Oct 2022, 22:03

my device is "Sonoff Basic R2 V1.0 (2017-10-11)"

TD-er · #52 Post by **TD-er** » 20 Oct 2022, 00:13

Gregor54321 wrote: ↑19 Oct 2022, 22:03 my device is "Sonoff Basic R2 V1.0 (2017-10-11)"

You know that by posting this, someone is now digging through lots and lots of boxes....

ThomasB · #53 Post by **ThomasB** » 20 Oct 2022, 00:23

You know that by posting this, someone is now digging through lots and lots of boxes....

Yes, there's a lot of boxes. But I found it!

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

- Thomas

TD-er · #54 Post by **TD-er** » 20 Oct 2022, 00:48

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

TD-er · #55 Post by **TD-er** » 20 Oct 2022, 00:51

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.

ThomasB · #56 Post by **ThomasB** » 20 Oct 2022, 01:45

That's for sure not the latest build of that PR.

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 easy to test, by setting the max. TX power to something like 10 and then check that checkbox.

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

TL;DR: Better results this time. Congrats on fixing this, been a long fight.

Anything else you need me to try?

- Thomas

TD-er · #57 Post by **TD-er** » 20 Oct 2022, 10:58

ThomasB wrote: ↑20 Oct 2022, 01:45 [...]

Anything else you need me to try?

- Thomas

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

)

TD-er · #58 Post by **TD-er** » 20 Oct 2022, 16:32

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.

ThomasB · #59 Post by **ThomasB** » 20 Oct 2022, 17:46

Yep, try to have way less troubles when moving than we had.

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.

So I finally can start unboxing and sorting my stuff in my lab (makes it sound more official)

I'm looking forward to that day.

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.

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.

- Thomas

TD-er · #60 Post by **TD-er** » 20 Oct 2022, 17:53

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

ThomasB · #61 Post by **ThomasB** » 20 Oct 2022, 18:31

Well maybe you could "celebrate" your 1000'th post a bit.

Yoo-hoo!

Now at 1001.

About the Truman show reference.... Is it about having loads of viewers for the house? (not calling them "potential buyers")

I wish. My Truman Show experience is a classic dark comedy; I suspect my show is getting very high ratings.

- Thomas

Gregor54321 · #62 Post by **Gregor54321** » 24 Oct 2022, 08:47

@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!

TD-er · #63 Post by **TD-er** » 24 Oct 2022, 08:59

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.

Gregor54321 · #64 Post by **Gregor54321** » 24 Oct 2022, 15:26

Code: Select all

git remote add -f ESPEasy-TDer https://github.com/TD-er/ESPEasy.git

in the local repositories directory did the trick...
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.

TD-er · #65 Post by **TD-er** » 24 Oct 2022, 15:32

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.

Gregor54321 · #66 Post by **Gregor54321** » 24 Oct 2022, 16:22

Gregor54321 wrote: ↑24 Oct 2022, 15:26 Runs smooth (2% loss) on the S-B R2 V1 testboard.

0,05% after 13k pings...

Gregor54321 · #67 Post by **Gregor54321** » 31 Oct 2022, 12:04

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!

TD-er · #68 Post by **TD-er** » 31 Oct 2022, 13:12

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

TD-er · #69 Post by **TD-er** » 31 Oct 2022, 17:49

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.

ThomasB · #70 Post by **ThomasB** » 31 Oct 2022, 18:23

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.

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.

- Thomas

TD-er · #71 Post by **TD-er** » 31 Oct 2022, 21:24

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.

TD-er · #72 Post by **TD-er** » 01 Nov 2022, 00:48

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.

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

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)

ThomasB · #73 Post by **ThomasB** » 01 Nov 2022, 01:08

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.

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.

- Thomas

TD-er · #74 Post by **TD-er** » 01 Nov 2022, 01:40

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

TD-er · #75 Post by **TD-er** » 01 Nov 2022, 01:44

too late... the lights have turned off.
Have to go to bed now

ThomasB · #76 Post by **ThomasB** » 01 Nov 2022, 02:22

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

TD-er · #77 Post by **TD-er** » 01 Nov 2022, 12:54

Cool

TD-er · #78 Post by **TD-er** » 01 Nov 2022, 14:38

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.

ThomasB · #79 Post by **ThomasB** » 01 Nov 2022, 21:39

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.

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.

The reason I ask is because I never did this test. And maybe it makes a difference.

- Thomas

TD-er · #80 Post by **TD-er** » 01 Nov 2022, 21:58

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.

: Sonoff Basic, TX power resp. 10 dBm, variable, 17.5 dBm; 2022-11-01 21_47_46-Power Profiler v3.5.2_ C094D66D7725.png (176.85 KiB) Viewed 49689 times

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.

ThomasB · #81 Post by **ThomasB** » 01 Nov 2022, 22:20

Interesting, thanks for the info.

I'm not 100% sure my Basic units are R1 or R2. I know they aren't R3.

The Basic R2 V1.0 units will be labeled on the PCB. Post a photo.

So I'm honestly not sure anymore what to do here.

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.

- Thomas

TD-er · #82 Post by **TD-er** » 01 Nov 2022, 22:26

Based on this video I only have the R1 units.

ThomasB · #83 Post by **ThomasB** » 01 Nov 2022, 23:33

Based on this video I only have the R1 units.

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."

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

: Sonoff Basic R2 V1.; sonoffBasicR2V1.jpg (422.83 KiB) Viewed 49679 times

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

TD-er · #84 Post by **TD-er** » 01 Nov 2022, 23:45

I just opened all of them... or at least all I have managed to find in my boxes.

: Sonoff Basic R1; IMG_20221101_234143742_HDR.jpg (1.27 MiB) Viewed 49673 times

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

ThomasB · #85 Post by **ThomasB** » 01 Nov 2022, 23:57

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

TD-er · #86 Post by **TD-er** » 02 Nov 2022, 00:21

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.

TD-er · #87 Post by **TD-er** » 02 Nov 2022, 01:56

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".

ThomasB · #88 Post by **ThomasB** » 02 Nov 2022, 02:17

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

TD-er · #89 Post by **TD-er** » 02 Nov 2022, 10:48

The one with good WiFi performance:

: Sonoff Basic with excellent WiFi performance; Good Sonoff Basic.jpg (441.91 KiB) Viewed 49630 times

Manuf: week 48/2016

The one I tested all day with flaky WiFi performance:

: Sonoff Basic with "meh" WiFi performance; Flaky Sonoff Basic.jpg (457.9 KiB) Viewed 49630 times

Manuf: week 49/2016

There seems to be 1 week difference in manufacture week.

ThomasB · #90 Post by **ThomasB** » 02 Nov 2022, 17:38

There seems to be 1 week difference in manufacture week.

Well this does not seem to be the reason for the issue. Perhaps the problem is due to component tolerance issues.

Just to be clear, this "good" Sonoff Basic R2 V1.0 board always works reliably, regardless of the firmware?

- Thomas

TD-er · #91 Post by **TD-er** » 02 Nov 2022, 19:01

ThomasB wrote: ↑02 Nov 2022, 17:38 [...]
Just to be clear, this "good" Sonoff Basic R2 V1.0 board always works reliably, regardless of the firmware?

- Thomas

"always" is maybe not the correct term as I only flashed 2 builds on it ("minimal" and "custom")

TD-er · #92 Post by **TD-er** » 03 Nov 2022, 14:42

: Sonoff Basic R2; IMG_20221103_143749151_HDR.jpg (820.75 KiB) Viewed 49552 times

Just arrived, the ordered Sonoff basic R2.
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.

ThomasB · #93 Post by **ThomasB** » 03 Nov 2022, 14:54

Just arrived, the ordered Sonoff basic R2.

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.

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

TD-er · #94 Post by **TD-er** » 03 Nov 2022, 15:45

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.

ThomasB · #95 Post by **ThomasB** » 03 Nov 2022, 16:51

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"

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.

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

TD-er · #96 Post by **TD-er** » 04 Nov 2022, 00:30

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.

TD-er · #97 Post by **TD-er** » 08 Nov 2022, 12:37

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.

ThomasB · #98 Post by **ThomasB** » 08 Nov 2022, 20:41

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.

That is fantastic news. Hopefully the "strict" directive is the final fix to our multi-year frustration. Extra hugs to @Jason2866 for sharing it.

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

TD-er · #99 Post by **TD-er** » 08 Nov 2022, 21:01

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.

ThomasB · #100 Post by **ThomasB** » 08 Nov 2022, 21:06

It is a well known fact, grey hair is inherited from your offspring.

Who is online