Deactivate IEEE 802.11n standard on WiFi chipset (if possible)

[belveder79]

I have done a lot of investigation into the OpenBeken basic software with different routers, and lots of people have problem, particularly with battery-driven devices, that the time to connect to the network is very long. In my case it does not work at all in some 50% of the cases, draining the devices to be empty sometimes within days or weeks at max.

I have a very powerful setup, MX4000 Linksys Mesh, and I found that the real problem is the IEEE 802.11n part of the chipset. This works fine with Tasmota, but messes up entirely on the OpenBeken platforms, no matter if CB3S, CBU and others... it is consistent.

Deactivating the IEEE 802.11n standard on the WiFi solves the issue immediately, tested with Light Switches, Door Sensors, Water Leakage Detectors. Everything starts working like a charm, as soon as the WiFi is on IEEE 802.11b/g only.

To me this means that the claimed IEEE 802.11n compatibility (or better, some incompatibility) on the OpenBeken chipset is causing the real issue. I also tested with a GLMango Travel router and with some Netgear Routers in office - same story.

I am not into the code, but it would be a real milestone for usability if the IEEE 802.11n standard could be somewhat disabled by flag in the software, or in case there is a bug with that, this would be fixed.

See description also here.

[openshwprojects]

There is something: https://github.com/search?q=repo%3Aopenshwprojects%2FOpenBK7231T%20802.11n&type=code Do you have a device setup with UART programmer connected to test new build?

[belveder79]

Yes I have an uart programmer and also the app to flash, but I have no ability to build it (don't know where to disable the n without breaking it)

[openshwprojects]

I can build it for you, but it may require several tries on your side. Do you have T or N device?

[belveder79]

All of them are N.

Can you tell me how to build it? Is it just the template build command?

openshwprojects @.***> schrieb am Do. 15. Feb. 2024 um 20:39:

I can build it for you, but it may require several tries on your side. Do you have T or N device?

— Reply to this email directly, view it on GitHub https://github.com/openshwprojects/OpenBK7231T_App/issues/1087#issuecomment-1947111905, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAA3R4AJVSV3A2IQ7SNPTGLYTZP5JAVCNFSM6AAAAABDJ5CPQWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSNBXGEYTCOJQGU . You are receiving this because you authored the thread.Message ID: @.***>

[belveder79]

I managed to create my own dev build from current master by disabling this flag

https://github.com/openshwprojects/OpenBK7231T/blob/12c68122b61da686df8b77a6577857ac05b55cbf/platforms/bk7231t/bk7231t_os/beken378/app/config/sys_config.h#L15

unfortunately still no luck - does not connect to network...

[openshwprojects]

what does the TX2 log output say?

[belveder79]

Will report back asap… on travel right now…

openshwprojects @.***> schrieb am So. 18. Feb. 2024 um 13:35:

what does the TX2 log output say?

— Reply to this email directly, view it on GitHub https://github.com/openshwprojects/OpenBK7231T_App/issues/1087#issuecomment-1951302851, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAA3R4DIVRUDBRWNJONX57TYUHYPTAVCNFSM6AAAAABDJ5CPQWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSNJRGMYDEOBVGE . You are receiving this because you authored the thread.Message ID: @.***>

[belveder79]

Hi, I captured a log and stopped logging after a minute or so:

log_bgn.txt

It goes on like this forever (well, until the emergency deep sleep kicks in)

[belveder79]

bump... any idea? I mean the log actually looks good... I just have no idea why it fails to connect...

[giedriuslt]

But nobody is running g only these days, everybody has g/n at least. And it works fine for most. I wonder what causes this incompatibility