Smaller WIFI range with Annex32 1.5x

[PeterN]

When using the latest Annex32 1.5x version, I had the impression of a significantly smaller WIFI range than with the same HW but earlier versions. My hardware is standard ESP32-devkit C, M5Stack Atom xxx .
Last somewhat disappointing test was an M5 ATOM lite ESP32pico as a WIFI bound remote sensor in a formerly well reachable location.

To investigate this I flashed two identical M5_ATOM_lite modules today.
One with ANNEX32_CAN_1.49.2 and the other with ANNEX32_CAN_1.51.3_LFS.

Logging the WIFI.RSSI of my own WIFI APs on both modules in different distances gave the same GOOD results in terms of RECEPTION strength.
So I set both modules to AP mode with the SSID name reflecting the Annex version, with the intention of logging their WIFI TRANSMIT power in a few places.
The modules were only 10cm apart but at the same distance from the receiving notebook. The distances to the logging PC were between 50cm and 10m with some walls in between.

This setup now seems to show that the transmitting power of the module with the newer version always seems to be significantly lower than with the older version - namely more than 20dB.
The following image is a combination of three WIFI logger screenshots with only the rows showing the two APs at three increasing distances.

TWO_AP_LOGGING.png

I have no influence on the TX power here, so it appears that an attempt is already being made to log on as a WIFI client with insufficient transmission power.
This is why my modules with the newer firmware often went into AP mode immediately.

All this is not very visible when you are close to the WIFI AP.
But the difference becomes very obvious when the distance is increased and/or the line of sight is not clear of walls.

Can anyone confirm my observations?
Am I missing something?

[PeterN]

Am I really the only one who has noticed this reduction in WIFI range with Annex32 1.5x?

Then I'll probably have to look for other local causes, but I'm at a bit of a loss at the moment.

[BeanieBots]

I'll see if I can reproduce your results.

[BeanieBots]

Hmm.... My tests appear to indicate the opposite!

At a distance of ~15m with an ESP32-WROOM-320 dev-kit at consistant distance & orientation.

Annex32 CAN 1.50.82 LFS RSSI = -35
Annex32 BLE CAN 1.44.2 RSSI = -44

I did not try swapping back to check for consistancy but I was very carefull to ensure consistant orientation and distance.
Just removed from socket, updated firmware and replaced in socket. Then used editor command to put into AP mode.

[PeterN]

This is actually confusing! No difference was one thing to be expected .... but 11dB, on the exact opposite devices!!!?
I'll give it a systematic try. Your installed versions are different from mine.
I will try now with Annex32 1.50 on my first device compared to my previous version 1.51.3. And I will delete the fash memory completely.

Thanks for your night shift!
Your location on the British Isles reminds me of great backpacking times with my wife on the south coast in the 80s

[PeterN]

That is getting even more confusing.
I still have a strange behaving ATOM with 1.51.3 that connects to my WIFI only if being near to the AP.
But It behaves even more strange if connected to the serial console of the Webbased Installer:
----------

I took my ATOM-lite and the Webbased installer ...
... erased it , flashed it with 1.51.6 and with all files selected and a fresh configurations,
I go to a location where my WIFI-AP is not to strong (-70dB)
But directly after flashing the Installer console now shows the ATOM_lite immediately connecting to my WIFI.
GOOD as to see here in line 25:

Code: [Local Link Removed for Guests]

Welcome to Annex RDS Web Installer
ets Jun  8 2016 00:22:57

rst:0x1 (POWERON_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
configsip: 188777542, SPIWP:0xee
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:DIO, clock div:1
load:0x3fff0030,len:1184
load:0x40078000,len:13160
load:0x40080400,len:3036
entry 0x400805e4
Annex initializing...
module Type 0 Display 255 SD_Card 0
OK
No SD cards found. Reverts to LittleFS

Annex32 CAN 1.51.6 LFS 
(C) ciccioCB 2022
Personal use only, commercial use strictly prohibited

Chip revision 1 Freq 240
STARTING
Connecting to NELAN1_2.4GHz
....
Connected to NELAN1_2.4GHz
IP address: 192.168.0.165
NETBIOS enabled.
You can now connect with http://M5-ATOM

BUT ... If I now disconnect the webbased console and restart the ATOM (still located at the very same place)! it does not find the WIFI anymore and goes to AP-mode as now to see in line 25.
I can see this behavior in any OTHER serial monitor (the Annex Web Terminal or the Annex-Toolkit ) this way:

Code: [Local Link Removed for Guests]

Welcome to Annex WEB Terminal
ets Jun  8 2016 00:22:57

rst:0x1 (POWERON_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
configsip: 188777542, SPIWP:0xee
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:DIO, clock div:1
load:0x3fff0030,len:1184
load:0x40078000,len:13160
load:0x40080400,len:3036
entry 0x400805e4
Annex initializing...
module Type 0 Display 255 SD_Card 0
OK
No SD cards found. Reverts to LittleFS

Annex32 CAN 1.51.6 LFS 
(C) ciccioCB 2022
Personal use only, commercial use strictly prohibited

Chip revision 1 Freq 240
STARTING
Connecting to NELAN1_2.4GHz
..................................................
Switched to AP Mode M5-ATOM
IP address: 192.168.4.1

This "changing to AP-mode" behavior now stays even with the ATOM connected only to a powerbank, as long as I stay at the distant location with the weak WIFI.

But a miracle happens if I reconnect the ATOM again to the Webbased installers serial console:
Now the ATOM immediately connects as a client to my WIFI-AP !!!!!! ... as long as I do not change the serial monitor.
But if I now connect to an other serial monitor and do a reset it will go only to AP-Mode again.
Back to the Webbased installers console ... ATOM will connect again as WIFI-Client at the same location.

I can reproduce this behavior after resets and powerdown as long as I stay a at the distant location away from my AP where the signal was in the -70dB range.
As soon as I am near to the AP, the ATOM will always immediately connect to my WIFI.

A short while, I had the thought that this behavior has to do with the module being forced to AP-Mode when RX is connected to TX at startup. But there is no direct connection.

So it still remains that the range of a possible client connection of my modules with annex 1.5x seems to be smaller now - but is better if the module is connected to the webbased console.
Very strange!!

And all this disappears if I go back to Annex 1.49.2 with the same module, that then connects in any case as a WIFI client at the same distant location.

[BeanieBots]

I've not posted anything yet because I've not done any varification but I think there is something quirky going on with 1.5x.
I think (have not proved) that some functions only work when connected to a console.
ie behaviour is different with/without a serial connection????
Your results have an implication along the same lines.
Unfortunately I won't be able to dabble further for a few days.
Try your tests from the same location but swap the USB cable between [data] and [power only] to see if it has any effect.

P.S. In the 80's I was spending a lot of time in the Hartz Mountains. How ironic!

[Electroguard]

I have also been experiencing some strange wifi problems.
Sometimes I am unable to reconnect to a module which I have only just been connected to.
This even applies to some newly flashed devices, which appear to flash ok, then may not show in the SSID list after a reboot... sometimes even with TX/RX shorted to reboot to 192.168.4.1

When unable to connect, the only available action is to re-flash again, perhaps specifying a different static IP.
Which sometimes works for esp32's for a while, but not for esp8266's because the online flasher does not have the option to pre-configure esp8266 IP's.

So I have a growing pile of assorted devices which I cannot use.
Then perhaps a day or two later I may pick one from the pile to try again, and be surprised by it connecting straight away.
The happiness doesn't usually last long though, because it usually disappears again a few reboots later.

Added to that is another quirk whereby some devices may interact with each other using UDP, but I cannot connect to them by browser.
Another quirk is that my Sentry server reboots and autoruns nightly, and all its attached hardware capabilities still function, but it does not respond to UDP requests, or respond to ping. And I cannot connect by browser to try to do anything about it - so just have to keep fingers crossed for the mo.
I have tried to flash a suitable replacement, but they keep disappearing before I can edit the program suitable to be autorun.

My linux computer is the only thing non-annex on my isolated subnet, and all annex devices are assigned staic IP's with the default gateway pointing to the router, which pings ok and is visible in an Angry IP scan, even though some other devices are not.

I wiped the ARP table on my computer, which sped things up but did not fix any problems.
Rebooting the router can clear things for a few hours, but the weirdness returns.
The fact that some of the invisible devices may re-appear a day or two later seems suspiciously like the router clearing disused entries.
So my next step is to configure a replacement router, although probably won't get a chance until the weekend.


Conclusion:
Perhaps my problems are just coincidental bad luck... but I am beginning to suspect that mDNS may be messing with the router.
If a replacement router does not fix things, I may have to add another router and subnet just for all essential pre-mDNS devices (esp8266's etc).
Perhaps the only way to be sure whether or not mDNS could be to blame for any wifi weirdness, would be an option to disable it.
Don't know when the weirdness started happening, but it was definitely after S3-VGA was introduced, so was about when mDNS was first mentioned.
I don't use windows, and mDNBS didn't work on my system when I tried it, but perhaps all mDNS clients automatically have contact with the router.
Already chased many shadows, so may be barking up the wrong tree again, but is actually encouraging to know I'm not the only one having wifi weirdness.

[PeterN]

Many thanks to everyone for the feedback

Maybe part of the problem comes from the router (tables), another part may be due to the fact that the ESP8266 and ESP32 have a somehow limited IP stack that can only handle a limited number of connections. The unloved substitute for a good garbage collection could then be a forced regular restart. Unless the problems take on the unpleasant dimensions described by Robin

But I have the idea that my problems come from a lack of TX power under certain circumstances ... but also have an idea to overcome this phase by a forced client reconnect with the TX power now set to maximum.

I'll put some more time into research tomorrow - oops - today is already tomorrow here



PS for beanieBots: From the Harz mountains you have a very good view to the east
Did you have a radiofrequency task there?

[BeanieBots]

I'm wandering too if things might be related to mDNS. Timing could just be coincidental.
Something to be explored deeper.

P.S. PeterN,
All my RF stuff was UK based but I did have some fun with those towers!