Smaller WIFI range with Annex32 1.5x

[PeterN]

One of the mysteries seems to be solved.
An ATOM echo with 1.51.3 works after erasing and slow flashing with full power and now reacts to wifi.power X
But X only seems to be effective if it is in [ -1,2,5,7, 8.5, 11,13,15,17,19, 19.5] ?
I'm sure I'll sleep better now!

[cicciocb]

Have a look here :
https://www.esp32.com/viewtopic.php?t=17727

What I do in the code is multiply the value entered by 4 and give to the function.

[PeterN]

Hello Francesco,
just to show you (and me) that I'm not hallucinating

This is a screen capture showing the WIFI strength of the WIFI-AP "ATOM" of my M5_ATOM_ECHO with Annex32 1.51.3. There is no autostart code running.

At the beginning of the video you can see the running ATOM without serial connection. The AP signal is weak, although the device is very close to the notebook.
Then I connect to the serial monitor of the toolkit and restart the ATOM.
After the restart, there is still only a weak WIFI signal from the AP.
Now I close the serial monitor of the toolkit and open a serial connection to the console of the web-based installer.
And voila! The ATOM reboots and the signal is now much stronger!
... but the next reboot without the web-based console connected brings us back to the weak default signal.
http://neufeld.bplaced.net/VIDEO/2023-1 ... -22-05.mp4

2023-12-15-18-22-05.mp4

What am I doing wrong? What makes the start of the web-based console different from the start with the toolkit console? Is the ATOM possibly briefly put into download mode and then comes back with a different WIFI power value? Very strange, isn't it?

[BeanieBots]

Sorry for having dropped out for a while but health took a bad turn. (got me out of a lot chores!)
Back home and doing well now so I'll have another play and see if I can find out any more.
Just to recap, do you only see the issue when in AP mode or does it happen in STA as well?

[PeterN]

Thanks BeanieBots!

Hope you are well again now and ready for a hopefully good new year.

I had the issue in STA and AP mode but especially with M5 ATOM modules.

CiccioCb has recently updated the version, change log and the help file (Thank you Francesco!!) and added (much more than) two features to Version 1.51.8

- Command WIFI.POWER value
- Included an error message ("BAD VALUE") in case of bad value given
- Implemented a new function to get the current WiFi power
- pow = WIFI.POWER

I will try again asap with this new version and report back.

[BeanieBots]

Thanks, seems a lot has been going on while I've been away.
Got a lot of catching up to do!
Got some more ESP based toys on their way from China, so looking forward to playing in the new year.

[BeanieBots]

Just tried 1.51.7 on an S3.
Moved it from USB power to battery pack.
Set to AP mode using direct command from editor. WIFI.APMODE "NAME", "password"
It switched ok and the wifi.power command behaved as expected. RSSI very good even at WIFI.POWER 2 (~5m distance)
However, it did not use the name provided (just the default name), nor did it set a password. I'm sure this worked OK in earlier versions.

EDIT: Just read the manual again. "Password must be at least 9 characters". Works OK when you follow the instructions

[Electroguard]

..Which again leads me to suspect the possibility that mDNS may be interfering with the routing tables of my local slave AP router and wifi repeater.

Just some feedback about all the router-related network problems I was suffering towards the end of last year.
After seeing mention of the latest Annex being down-graded to a Windows-only version of mDNS, I upgraded all my recently added devices, and all the weird network problems disappeared without needing any router changes.

[BeanieBots]

I've had a similar experience but I'm not convinced the 'odd' happenings were all Annex related.
I was also having issues with other networked devices such as Rpi. I think there might have been a period of agressive port scanning around Xmas time.

[Electroguard]

Well, that is pretty clear evidence that it was the previous version of Annex mDNS causing the problems.
Because my router weirdness only occurred on my isolated Annex subnet (uses multiple routers) after adding VGA devices.
My separate internet subnet (also using multiple routers) never had any problems.
Whereas your Annex devices evidently must be sharing bandwidth with your internet traffic... giving you the double whammy of increased Xmas network traffic compounding the problems caused by Annex mDNS router weirdness.
The router weirdness all went away since upgrading the VGA devices to the latest version of Annex, which evidently now uses a Windows-only mDNS.
All's well that ends well, it's just history now.