Разъёмы для антенн R52Hn

Привет! Хотел уточнить — если мы вместо карты R5H используем карту R52Hn, можно ли просто использовать цепь 0 и подключить антенну к MMCX-разъему J4? Это значит, что MMCX-разъём J5 останется свободным. Можно ли так безопасно сделать? С уважением, Марк.

Проверь, какие у тебя настройки страны, какие настройки диапазонов и также список сканирования.

Я подключил R52Hn к 433UAH (где уже есть R52n и XR9), и когда попробовал сканирование диапазона, он обнаружил всего 2 или 3 точки доступа поблизости. С другой стороны, R52n видит больше 50 (я использую только 2.4 ГГц). Если посмотреть на уровень шума в статусе, R52n показывает -107 дБм, а R52Hn колеблется от -115 дБм до -75 дБм. RB433UAH работает на ROS 4.16. Где-то на форуме читал о том, что на определённых версиях ПО X у R52Hn странные показания уровня шума. Поэтому я собрал X86 с RC 5.10, и там уровень шума был постоянно -115 дБм, с антенной или заглушкой на цепи 0. У меня есть другие R52Hn на старых платах WRAP (X86), которые работают на 4.16, и там тоже -115 дБм, даже после замены карт R52n для сравнения. Пока что не хочу ставить на 433 RC 5.10. Когда пробовал RC 5.09, интерфейс R52n зависал 4-5 раз на 15 минут каждый за один день. Замечу, что на версиях 4.X эта система работала бесперебойно и без проблем 14 месяцев подряд. Кстати, все клиенты (50 штук) — NS2 Loco, 20 дБм, а R52n работает на стандартной мощности. Большинство TX/RX сигналов отличается на 6…10 дБ, и, думаю, R52n около 20 дБм. Может, это просто глюки в измерениях? На 20 дБм с обеих сторон сигналы должны примерно совпадать. Не знаю, ошибка ли это UBNT RSL или что-то ещё. В любом случае, эти показания уровня шума (-75/-115) — это баг в софте или что? С уважением.

Если честно, не помню, включал ли я периодическую калибровку в таком тестовом режиме. Но помню, что изменения в NF-значениях наблюдались каждые пару секунд, туда-сюда. Возможно, включение этой функции помогает устройству стабилизироваться на реальном значении, а не держать такие исходные данные (например, цифровой AGC, если он есть, с диапазоном 50%, который управляет схемой RSL, и это исходное значение меняется только при периодической калибровке). Я даже пытался снизить мощность R52Hn до 5 дБм на минуту (как AP Bridge) и переключился на диапазон 5 ГГц, потому что хотел проверить, не перегружается ли LNA каким-то внеполосным сигналом. Другие источники шума могут быть — это часы и линии данных 433UAH, XR9, R52n вокруг и так далее, но я не думаю, что они влияют на IF, так как, как я понимаю, это нулевой IF-трансивер. Но вот в что я не верю — что R52Hn может быть более чувствительным к таким внеполосным помехам, чем R52n. Все эти тесты проводились либо с секторной антенной, либо с подключением MMCX к N-pigtail через загрузочные резисторы Hewlett Packard 50 Ом (хорошо работают до 26 ГГц). Полагаю, тот же терминатор можно оставить на цепи 1, если её не используешь, потому что RF-переключатели дают изоляцию 20–30 дБ только при правильном завершении. Позднее лабораторные тесты показали исправный R52Hn при подключении к приёмной антенне, направленной на AP примерно в 300 метрах, те же tx/rx сигналы, что и у клиента 411AR. Ладно, попробую снова в ближайшие дни, несмотря на то, что этот 433UAH — уже промышленный образец. Думаю, на нём стоит примерно версия v5.x. Есть около 60 клиентов на NS2 Loco, кроме одного, у которого временно стоит CPE Engenius ESR1221. Возможно, именно этот ESR всё портит. Было 4 заморозки с интервалом примерно в час: сам роутер не зависал, все клиенты оставались подключены, но трафик на интерфейсе WLAN падал до нуля на 10–15 минут и потом сам восстанавливался. На XR9 и ETH вообще без изменений, всё работало. Лог был полный сообщений, связанных именно с этим ESR CPE. Я не включал отладку, потому что ESR временный. Видел такое один раз, когда решил дать одному клиенту-ноутбуку доступ к удалённому AP (WRAP, с установленными X86, R52n и R52Hn). Через 30 минут AP подвис. Повторил 4–5 раз, чтобы удостовериться, и чтобы избежать этого, пришлось скрыть SSID и удалить соответствующий профиль сети на этом мобильном устройстве. Сейчас уже 120 дней без проблем. Ни NF, ни зависаний на X86 с версией v5.10 не наблюдается. С уважением.

Привет! Можно тогда считать, что на карте R52N J2 — это chain0, а J3 — chain1? С уважением!