Почему прерывается (рвётся) цифровой звук DMR и как это лечить

У цифрового звука есть неприятная особенность: он либо есть, либо его нет. Аналоговая рация на слабом сигнале шипит и хрипит, но речь ещё можно разобрать. DMR ведёт себя иначе — пока всё хорошо, звук чистый, как телефонный, но стоит чему-то сломаться, и голос превращается в «робота», рассыпается на куски и проваливается в паузы. Промежуточного состояния почти нет.

Хорошая новость: причины этого «рваного» звука вполне конкретны и делятся на три слоя — радиочастотный, сетевой и слой приложения/телефона. Если разбираться по слоям, проблема почти всегда локализуется за десять минут. Разберём каждый слой и дадим чёткий чек-лист.

Откуда вообще берётся «робот»

Голос в DMR кодируется вокодером в поток кадров. Кадры идут плотным ритмом — примерно каждые 60 мс — и каждый несёт кусочек речи. Декодер на приёмной стороне восстанавливает звук из этих кадров. Потеряли кадр на радио или в сети — декодеру нечего проигрывать, и он выдаёт тишину, щелчок или артефакт. Несколько потерь подряд — и вы слышите того самого «робота».

Поэтому ключевой вопрос диагностики всегда один: где теряются кадры — на радио или в сети? От ответа зависит всё лечение.

Слой 1. Радиочастота (РЧ)

Самый очевидный подозреваемый. Если рация далеко от хотспота, между ними стена-другая, плохая антенна или рассогласование по КСВ — часть кадров приходит с ошибками и теряется уже на радиоучастке. Симптом — звук рвётся тем сильнее, чем дальше или хуже вы стоите.

Маркер РЧ-проблемы — высокий BER (Bit Error Rate). Если в логах хотспота BER ползёт вверх (единицы процентов и больше), причина почти наверняка на радио. Что проверить:

• уровень сигнала и расстояние до хотспота, переотражения в помещении;
• антенна и КСВ — кривая или «не та» антенна сажает приём;
• уход частоты модема — дешёвые MMDVM-платы плывут по частоте, из-за чего растёт BER даже при близкой рации;
• норму BER и как его читать — см. какой BER считается нормой.

Слой 2. Сеть

А вот здесь начинается самое коварное. Голос идёт от хотспота в сеть и обратно по UDP — протоколу без гарантии доставки. Потерялся пакет — его никто не переотправит, кадр просто исчез. И в отличие от РЧ-проблем, BER при этом будет 0%: радиоучасток-то идеальный, рвётся уже за хотспотом.

Классический и крайне распространённый случай — Wi-Fi power-save на Raspberry Pi. Чтобы экономить энергию, Wi-Fi-адаптер «малинки» по умолчанию умеет засыпать между пакетами. Редкий пинг (ICMP раз в секунду) при этом проходит идеально, и человек делает вывод «сеть в порядке». Но плотный поток DMR-кадров каждые 60 мс адаптер в таком режиме не вытягивает: пока он просыпается, кадры теряются. Итог — рваный звук при нулевом BER и «нормальном» пинге.

Другие сетевые причины:

• джиттер мобильного интернета — на LTE/4G задержка скачет, кадры приходят неровно, буфер не успевает их выровнять;
• перегруженный или слабый Wi-Fi-канал, далеко стоящий роутер;
• проблемы с пробросом и NAT, когда поток идёт криво, — см. хотспот за NAT;
• в целом если хотспот ведёт себя странно, начните с что делать, если хотспот не работает.

Слой 3. Приложение и телефон

Если вы слушаете эфир в приложении-рации на смартфоне, добавляется ещё один источник. Мобильная сеть «дёрганая»: задержка плавает, кадры приходят пачками и с разбросом. Если буфер приёма в приложении тонкий (минимальная задержка ради «живости»), он не успевает сгладить этот разброс — и звук рвётся уже на стороне телефона, хотя сам хотспот и сеть до него в порядке.

Лечится это устойчивым джиттер-буфером: приложение копит небольшой запас кадров (десятки–сотни миллисекунд) и проигрывает их ровно, переживая короткие провалы сети. В приложении DMRhub приём идёт через серверный AMBE-вокодер, поэтому буферизация и сглаживание ложатся на сервер и клиент, а не на саму рацию. Подробнее про работу со смартфоном — DMR-рация в смартфоне.

Как диагностировать: один простой признак

Вся диагностика сводится к тому, чтобы развести РЧ и сеть. Откройте логи хотспота (MMDVMHost их подробно пишет) и смотрите два числа во время приёма:

• BER высокий, потери пакетов низкие → проблема на РАДИО. Антенна, расстояние, КСВ, калибровка частоты.
• BER около 0%, потери пакетов высокие → проблема в СЕТИ. Wi-Fi power-save, джиттер, канал, питание.
• оба в норме, но рвётся только в приложении на телефоне → слой приложения, тонкий буфер на дёрганой мобильной сети.

Этот простой тест экономит часы. Подавляющее большинство жалоб «звук рвётся» при чистом BER упирается именно в сеть, а конкретно — в спящий Wi-Fi на «малинке».

Чек-лист решений

• Проводной Ethernet вместо Wi-Fi. Самое надёжное лекарство для стационарного хотспота: воткнуть кабель и забыть про беспроводные капризы.
• Отключить Wi-Fi power-save на Raspberry Pi, если кабель невозможен. Это снимает львиную долю «сетевых» обрывов при BER 0%.
• Нормальное питание. Просадки по питанию у Pi и модема дают и сетевые сбои, и уход частоты. Хороший БП 5В/3А и качественный кабель — не роскошь.
• Калибровка частоты модема. Убирает РЧ-обрывы и завышенный BER на бюджетных платах.
• Антенна и размещение. Поднять хотспот, поставить адекватную антенну, не прятать в металлический шкаф.
• Стабильный канал для мобильного интернета. Если хотспот висит на LTE — выбирайте точку с ровным сигналом; джиттер лечится только стабильностью канала.
• Устойчивый джиттер-буфер в приложении. Для приёма на смартфоне важнее ровность, чем минимальная задержка.

Итог

Рваный «роботизированный» звук DMR — это потерянные голосовые кадры, и весь вопрос в том, где они теряются. Высокий BER — значит проблема на радио: антенна, расстояние, калибровка. BER около нуля при росте потерь пакетов — значит сеть, и чаще всего это спящий Wi-Fi на Raspberry Pi: пинг проходит, а плотный поток кадров каждые 60 мс — нет. Тонкий буфер в приложении на мобильной сети добавляет свой вклад уже на телефоне. Разведите эти слои по двум числам в логах, пройдитесь по чек-листу — и эфир станет чистым.