• Система автоматизации с открытым исходным кодом на базе esp8266/esp32 микроконтроллеров и приложения IoT Manager. Наша группа в Telegram

Не всегда видит пропажу AP

sharikov

Active member
USDK.
Автоподключение Station в RTL не всегда срабатывает, стал проверять:
AP - usb свисток Zyxel G-202

Тест 1:
Выдергиваю питание AP или отключаю устройство в диспетчере устройств - в RTL перестают поступать WIFI_EVENT_BEACON_AFTER_DHCP и через какое-то время возникает событие Disconnect что запускает процесс автоподключения
лог:
Код:
RTL8195A[Driver]: no beacon for a long time, disconnect or roaming
wifi_indication(1): Disconnection indication received
[HEAP Wrn]tcm_alloc(1608) - freeSpace(112)!
auto reconnect ..
Тест 2:
Перевожу usb свисток в режим Station - в RTL перестают поступать WIFI_EVENT_BEACON_AFTER_DHCP однако в этом случае событие Disconnect не возникает и RTL находится в состоянии Connected бесконечно. Сканирование показывает что AP в эфире на самом деле нет. Поскольку Disconnect никогда не возникает автоподключение не запускается.
Лога нет потому что не происходит вообще никаких событий.
Андроид в такой же ситуации работает нормально - через 3-4 секунды отключается и убирает AP из списка доступных.

Если после теста 2 перевести усб свисток снова в режим AP RTL отключается и подключается заново:
Код:
RTL8195A[Driver]: sta recv disassoc reason code(6) sta:00:19:cb:30:82:da
wifi_indication(1): Disconnection indication received
[HEAP Wrn]tcm_alloc(1608) - freeSpace(112)!
auto reconnect ...
Почему в тесте 2 не возникает Disconnect после пропажи BEACON ?
Может быть AP перед изменением режима что-то сообщает подключенным клиентам ? Если так то как это обнаружить?
Необходимо отследить потерю AP неважно по каким причинам она произошла.
 

pvvx

Активный участник сообщества
Перевожу usb свисток в режим Station - в RTL перестают поступать WIFI_EVENT_BEACON_AFTER_DHCP однако в этом случае событие Disconnect не возникает и RTL находится в состоянии Connected бесконечно.
Т.е. USB свисток неправильно работает? Во первых он обязан послать сообщение disconnect клиентам и т.д., а затем уже переключиться...
Возможно ваш свисток отвечает на "probe request", после переключения из режима AP в станцию :)

Лучше проверяйте путем выхода из зоны связи AP (кастрюлей или ещё чем :) ).
 
Последнее редактирование:

sharikov

Active member
Похоже проблема серьезнее.

RTL не может подключиться к точке доступа если она включена позже модуля.
Модуль стартует, не находит AP и начинает переподключения с таймаутом 10 сек.
Код:
auto reconnect to HOMEAP...

RTL8195A[Driver]: set ssid [HOMEAP]
wifi_indication(14): No Assoc Network After Scan Done
wifi_indication(1): Disconnection indication received
wifi_indication(4): WIFI_EVENT_SCAN_DONE
Через несколько минут включаю AP. Модуль при переподключениях не видит включившуюся AP.
AP работает, андроид коннектится. Иногда модуль все-таки подключается но потом отключается с сообщением
[inline]RTL8195A[Driver]: no beacon for a long time, disconnect or roaming[/inline]
И далее цикл автоподключений.

При смене режима с RTW_MODE_STA на RTW_MODE_STA_AP сразу же находит. Думаю что это потому что при смене режима wifi полностью отключается wifi_off().

Видимо придется при отсутствии подключения к AP периодически делать wifi_off().

Сижу и думаю сколько там еще багов которые полезут у клиентов ???
 

pvvx

Активный участник сообщества
Сижу и думаю сколько там еще багов которые полезут у клиентов ???
У них клиентов туча в Китае, даже книжки писаны, но всё поверхностно - уровень Arduino. У других производителей WiFi-SoC, если без NDA, ситуация не лучше, а хуже в плане большей закрытости. Только из-за этого, в отличии от других модулей, на RTL мне удалось исправить всё что мне надо было. Есть ещё подвисшие нерешенные там темы, но на них просто (пока) нет времени...
Клиентский уровень с софтом выпускает к примеру RAK - попробуйте свою ситуацию на нем - на его готовых прошивках...
Через несколько минут включаю AP. Модуль при переподключениях не видит включившуюся AP.
Смотрите опции сканирования - их там три.
Используемая работает плохо, т.к. мал интервал сканирования на канале. Запатчите :)
 
Последнее редактирование:

sharikov

Active member
У других производителей WiFi-SoC, если без NDA, ситуация не лучше, а хуже в плане большей закрытости.
Драйвер wifi у RTL закрыт и наличие исходников Freertos и Lwip тут не помогает. wifi_connect() в итоге сводится к вызовам ioctl() к закрытому драйверу. Драйвер линукс похож но не полностью соответствует амебовскому.

Подключение не работает из-за включенного режима энергосбережения.
Я для снижения нагрева модуля перешел на 83МГц и добавил
[inline]release_wakelock(~WAKELOCK_WLAN);[/inline]
что снизило среднее потребление с 23 до 4 мА.
Видимо сканирование работает неправильно при включенном энергосбережении. Наверное недоделано.
Если убрать release_wakelock подключается. Если на лету менять переменную wakelock отладчиком будет либо подключаться либо нет.

Есть ещё подвисшие нерешенные там темы, но на них просто (пока) нет времени...
Вот именно что нет времени а нерешенные темы все копятся и копятся.
Работоспособность wifi как бы должен обеспечить производитель чипа.

Смотрите опции сканирования - их там три.
Используемая работает плохо, т.к. мал интервал сканирования на канале.
Я это заметил. Опять же не хватает времени.
 

pvvx

Активный участник сообщества
Драйвер wifi у RTL закрыт и наличие исходников Freertos и Lwip тут не помогает. wifi_connect() в итоге сводится к вызовам ioctl() к закрытому драйверу. Драйвер линукс похож но не полностью соответствует амебовскому.
Для WiFi драйвера (его библиотек версии 3.5) вложены все хидеры к каждой процедуре и используемых в нем структур, включая описания аппаратных регистров. Управление драйвером стандартное - через ioctl из Линух, или аналогично Андроиду. Такой набор позволяет заменить или изменить любую процедуру.
Полные исходники WiFi дают только при подписи NDA и то не всем :) В итого у RTL имеем максимальный комплект, которого нет у других производителей WiFi SoC "для простого смертного".
Подключение не работает из-за включенного режима энергосбережения.
А наверно и не должно. Не думаю, что все опции должны проверяться при вызове в самом драйвере - это задача пользователя включить или переключить на необходимые для данного запроса к драйверу.
И что вы хотите "со временем", если на RTL вcего 3 аборигена, включая вас, меня и ..., которые копают что-то там и выкладывают в общий доступ занимаясь им в ограниченное время для хобби? :)
По соотношению с другими WiFi SoC, учтя это (а не тысячи-человеко-часов для примера с ESP, так и не достигшие хотя-бы полных хидеров к процедурам WiFi и описания алгоритмов их сипользования) и так слишком всё быстро строится.
К примеру, т.к. копаюсь счас с USB UVC, залез в данные дрова в лунихе - там бардак ещё хуже. Большинство имеющихся у меня USB-Web-камер не работают в стандартных дистрах :) Но на RTL уже удалось их заставить как-то работать и выдавать поток, но пока есть другие беды - нестабильности, т.к. Ameba точила дрова под свою камеру и свой dev-kit...
 
Последнее редактирование:

sharikov

Active member
Для WiFi драйвера (его библиотек версии 3.5) вложены все хидеры к каждой процедуре и используемых в нем структур, включая описания аппаратных регистров.
Сейчас актуален SDK 4.0b а хидеры от 3.5 к нему не подходят. Т.е по факту хидеров нет.

Проблему с автоподключением решил отключив IPS:
Код:
 case RTW_MODE_STA:
                ret = wifi_run_st();
                wext_set_lps_dtim(WLAN0_NAME, 2);
                wext_enable_powersave(WLAN0_NAME, 0, 1);
release_wakelock(~WAKELOCK_WLAN) остается.
Энергосбережение включается только после подключения к AP, при поиске сети работает непрерывно.
 

pvvx

Активный участник сообщества
Сейчас актуален SDK 4.0b а хидеры от 3.5 к нему не подходят. Т.е по факту хидеров нет.
По факту вообще ничего никогда нет и не бывает. При покупке модуля к нему в пакетик не вложено ничего :) Найдите и подправьте к 4.0. - это промежуточная версия и не используется в текущих Arduino и MBED, созданная для слияния Бетки к серии "Z". На 4.0. пока нет USB дров, а прямое включение либ от версии Arduino или MBED не работает.
LPS и IPS влиять не должны. У одной задается таймаут до green режима в сек если нет активности WiFi, а вторая - спящий режим с переключением уже типа соединения с пропуском beacon. Значит достаточно сдернуть/возобновить счет тайм-аута при сканировании, а не отключать...
Wakelock с маской в 4.0 нет. Это моё дополнение для совместимости с 3.5. Скопом, в одном запросе их переключать удобнее...
 
Последнее редактирование:
Сверху Снизу