Выбран неправильный канал связи, версия 6.6.77.

Выбран неправильный канал связи, версия 6.6.77., UniFi Network

richb-hanover

Guest

21.05.2025 21:24:00

Я уже три года успешно использую Unifi Nanobeams (NBE-5AC-Gen2-US) и Mesh sticks (UAC-AP-M) в небольшом заведении, где оказывают услуги гостеприимства. У меня Nanobeam установлен на одной из наших небольших кают, направленный на LAP-GPS на расстоянии примерно ста ярдов. Дизайн такой, что Nanobeam питает цепочку Mesh sticks: от каюты Cherry к каюте Applewood к каюте Fernwood. Mesh stick на Applewood находится примерно в 60 футах от Cherry; Fernwood находится примерно в 100 футах от Mesh stick на Applewood. Видимость между UAC-AP-Ms (Cherry к Applewood, и Applewood к Fernwood) прямая — без листвы. Между концами (Fernwood и Cherry) немного листвы. Такая конструкция хорошо работала в прошлом году. Но в этом году, когда я открываю территорию, у меня много проблем. Mesh sticks работают на версии 6.6.77. Fernwood часто выбирает каюту Cherry в качестве своего uplink, хотя они находятся примерно в 150 футах друг от друга, даже несмотря на то, что сигнал от нее намного слабее, чем от Applewood. Вот пример списка Uplink сигналов с Fernwood. На момент скриншота Fernwood выбрал связь с Cherry, хотя сигнал от Applewood на 20 dBm сильнее. (Это иногда случается даже тогда, когда я установил Applewood в качестве приоритетного uplink.) Мой вопрос: Как я могу этого предотвратить? Есть ли другие настройки, которые я не проверил/не рассмотрел? Большое спасибо.

pgrey

Guest

22.05.2025 17:49:00

Ну, я думаю, было бы лучше, если бы это тоже настроено с PtMP/PtP, но если это работает с mesh backhaul, и они стабильны теперь, когда вы явно указали Mesh-Parent(s), то, похоже, это работает уже какое-то время. Моя одиночная настройка Mesh-Parent никогда не меняется, но у меня 5GHz радио на выделенных каналах, поэтому оно не может переместиться, если я не переключусь на Auto Channel (оптимизация), по крайней мере, так было какое-то время назад (в какой-то момент можно было просто заблокировать связь Parent-Child, но это исчезло какое-то время назад, из-за настройки приоритетов 1-го и 2-го). Третий, четвертый и так далее каюты в этой mesh-настройке получат очень низкую пропускную способность, просто к сведению. 1/4 от Cherrywood в том, что, как я думаю, Fernwood, и надеюсь, это последний прыжок и там достаточно пропускной способности (остальные каналы ссылаются обратно на Cherry или Apple, где PtP-связь имеет полную пропускную способность или 1/2). Вполне возможно, что причина, по которой контроллер пытается связаться с CherryWood из Fernwood, заключается в том, что он также видит оптимизацию как лучшую, чем 2 mesh-прыжка. Cherrywood = полная PtP (пропускная способность)Applewood = 1/2 PtP (через Cherry)Fernwood = 1/4 PtP (через Cherry, Apple)...?

gregorio

Guest

22.05.2025 15:00:00

Набросок неплохой, но лучше было бы использовать обзор со спутника сверху. Так мы сможем увидеть, как сильно деревья влияют, например, от Applewood до LAP или между Applewood и Cherrywood. Рад слышать, что всё было стабильно ночью. Держите нас в курсе, если что.

richb-hanover

Guest

22.05.2025 10:29:00

Я думаю, ты прав, что мне стоит создать отдельную тему для обсуждения пробивания линий сквозь деревья. (У меня нет времени перестраивать инфраструктуру – гости уже подъезжают.)Две вещи:Вот набросок участка. Три домика – зеленые, пурпурный цвет показывает места крепления маш-стиков и линию видимости; бирюзовый – это Nanobeam -> LAP-GPS линк.Есть небольшая хорошая новость. Связь была стабильна всю ночь – когда я посмотрел утром, она была именно такой, как я и хотел. (Я задал приоритет uplinks нужному родителю, прежде чем ушел вчера вечером.)Надеюсь, uplinks останутся на месте, и это будет отличный сезон! Спасибо еще раз за твои мысли.

gregorio

Guest

22.05.2025 01:32:00

Сомневаюсь, что пробивать PtMP через деревья – это верное решение. А что насчет Ptp/PtMP между домиками? Локосы недорогие, и если удастся уменьшить количество мешированных AP, то можно будет увидеть заметное улучшение. UDB Sector – это PtMP AP к другим UDB, а не к AP. Эта платформа UDB может работать лучше, чем выделенный мост, потому что она использует WIFI. Это более терпимо к отражениям и вторжениям. Но я предполагаю и воздержусь от каких-либо рекомендаций, пока не увижу визуализацию.

pgrey

Guest

22.05.2025 01:27:00

Возможно, вероятно, будем надеяться? Частота примерно та же, но более направленная, так что, думаю, это зависит от того, насколько сильно что-то загораживает прямой видимости. Я бы создал новую тему, честно говоря, с каким-нибудь названием-ключевыми словами вроде bridge/sector/trees, что-то в этом роде, и, может быть, кто-то, кто уже пробовал/тестировал, смог бы дать более точную информацию. Можно попробовать и по линиям электропередач, хотя по моему опыту, если адаптеры не на той же цепи, это ненамного лучше, чем mesh, кроме как в плане задержки. MoCA был бы ЛОТЧЕ лучше, если есть такая возможность?

Редактирую: Я не совсем уверен, что понимаю про эту штуку с 1000'. Я думал, это чтобы распространить стабильный сигнал (от существующей bridge-настройки) к другим каютам с минимальными потерями. Простая схема и несколько фото, наверное, очень помогли бы здесь.

richb-hanover

Guest

22.05.2025 01:08:00

@gregorio, подумал еще над твоим вопросом: сможет ли Nano пробить примерно 300 метров деревьев/листовы? (Я всегда думал, что для этого нужна прямая видимость - без листвы.) @pgrey, а как думаешь, новая серия UDB сможет пробивать листву? Спасибо!

pgrey

Guest

22.05.2025 00:53:00

Я бы поставил на то, что новая серия UDB будет работать так же хорошо, как mesh, но это просто догадка (основано на опубликованной радиосвязной технике, а не на реальном использовании/развертывании). Если разделить AP по разным группам каналов, то можно добиться дискретной связи, в принципе. Получается какая-то хитрость, и не лучшее решение, но должно сработать, чтобы обойти тот факт, что они не учитывают приоритет Mesh-Parent.

richb-hanover

Guest

22.05.2025 00:47:00

@gregorio Отличный вопрос. У меня нет прямой видимости, чтобы использовать Nanobeams из этих внешних будок к LAP-GPS (там густой лес, за исключением тропы между этими будками). В предыдущие годы мне удавалось "протащить меш" под пологом деревьев. @pgrey Спасибо за эти предложения. Я пробовал настроить приоритет Uplink, но меш-устройство не всегда соблюдало эту настройку (Fernwood переключался на Cherry, даже если уровень сигнала там был намного ниже(!)). Я использую 6.6.77 на меш-устройствах UAC-AP-M; приложение Unifi Network — версия 9.1.120, работающее на Raspberry Pi (использую https://github.com/jacobalberty/unifi-docker версию — работает отлично!).

pgrey

Guest

#10

22.05.2025 00:46:00

Да, я тоже думал спросить то же самое, что и @gregorio, потому что, получается, вы теряете половину сигнала на каждом переходе, что может быть довольно заметно, особенно когда требования к пропускной способности растут. Новый Bridge Pro Sector UDB кажется идеальным решением для этого, с PtMP поддержкой, и он обеспечит гораздо лучший пользовательский опыт.

gregorio Guest	#11 22.05.2025 00:28:00 Я просто спрашиваю, почему вы не используете больше Наносов, чтобы продлить мост от ЛАП напрямую к этим местам?

pgrey Guest	#12 21.05.2025 23:23:00 Можно установить приоритет Uplink для каждого AP. В вашем примере Fernwood -> Applewood, выберите Applewood в качестве P1 и либо Auto, либо Cherry в качестве P2. Вы также можете ограничить, какие APs служат Mesh Parent, хотя это сработает в вашей конфигурации только в том случае, если вы сможете ограничить обслуживающие APs до подмножества. Кстати, у вас очень старый контроллер. Есть ли причина, по которой вы используете 6.x, когда он перешел на 9.x? Недавно развернул UAP-M-Pro на 9.x – всё отлично работало.

Читают тему (гостей: 1)