RTL_TCP под Linux ARM. Некоторые наблюдения.

Автор: Administrator вкл. . Опубликовано в RTL-SDR

За некоторое время использования RTL_TCP на Orange Pi PC 2, настроенного несколько ранее , выплыла следующая проблема - периодически наблюдались «заикания» аудио потока при прослушивании в полосе обзора более 1МГц, очень редко бывали на 1МГц и менее. Это происходило то чаще, то реже, напоминало потерявшиеся пакеты из цифрового аудио потока, пропущенные части слов говорящего, сопровождающиеся некими короткими щелчками или, когда во время просмотра спутникового ТВ, тучи плотно закрыли небо, картинка на экране иногда рассыпается, а звук сопровождается редкими «дерганьями», в некоторой степени похожими на капель.

Такой «эффект» указывал на потерю части информации в канале связи (в данном случае подключение LAN через свитч, сервер и клиент на одном столе). Для поиска сути проблемы менял свитч со 100Мбит на 1Гбит, патч-корд, сетевую карту компьютера – не помогло. Догадка пришла при созерцании светодиодов сетевого интерфейса PC2 – они говорили о скорости подключения в 100мбит, в то время как сам LAN-порт гигабитный и подключен в гигабитный свитч. А драйвер-то, видать, не умеет на гигабите работать! Может и на 100мбит он криво работает? Ядро-то 3.10, а в интернете на ядро версии 3.х как-то встречал нелестные отзывы в плане совместимости с железом.

Достал Orange Pi One, использовавшийся для прочих экспериментов, и решил проверить на нем. На нем уже был образ «Armbian_5.59_Orangepione_Debian_stretch_next_4.14.65.img», настроил сервер rtl-tcp, как описывал ранее - заикания и затыки ушли даже при полосе обзора в 2 МГц. Процессор ARM 32-битный и драйвера нормально работают, но из-за всего одного USB-порта на данной плате, пришлось применять пассивный USB-HUB для подключения свистка и запитки конвертера, что повлекло за собой нестабильность работы конструкции (иногда «2838 Realtek Semiconductor Corp. RTL2838 DVB-T» отсутствовал в выводе по команде «lsusb»). Вопрос частично решился толстенным кабелем USB 3.0 и уже полностью - добавлением инжектора 5В (пассивный USB-HUB стал активным). Инжектор остался со времен подключения 3G-модемов к MikroTik. Гнездо питания очень тонкое и проще оказалось его заменить, нежели покупать штекер.

 

 

 

Теперь заметил, что при ширине полосы менее 1МГц панорама идет рывками, звук тоже, пользоваться невозможно. Но при полосе 1МГц или более – все супер! Поразмыслив, вспоминаю такой нюанс с шириной полосы у RTL-SDR - если она менее 1МГц, то появляются какие-то сигналы (причем реальных станций АМ и прочих реально существующих источников) в тех местах, где их 100% нет, т.е. происходит какое-то наложение. Это я замечал ранее и при подключении свистка напрямую к компьютеру по USB. Т.е. при полосе 250кГц я наблюдал вещалку в середине участка 20м радиолюбительского диапазона, или ломовой сигнал от загоризонтного радара, но переключив полосу на 1МГц (или более) именно на этих же частотах становилось чисто, только что бывшие там вещалка или радар - отсутствовали. Конкретно для SDRSharp наложения сигналов нет начиная с частоты семплирования равной 0,900001 MSPS.

Скриншоты сделаны с применением синего свистка и конвертера HFUC-125 v.4.1. При ширине полосы обзора в 250кГц очень хорошо видны вещательные АМ-станции на участке от 14,100 – 14,300 МГц, а в реальности их там быть вовсе не должно и нет.

 

 

 

Меняю ширину полосы на 1МГц, ползунком «Zoom» подгоняю масштаб примерно до 250кГц видимой полосы (для удобства восприятия и сравнения) – а нету вещалок! Ни на тех же частотах, ни вблизи.

 

 

Вот, следующий скриншот с ползунком «Zoom» в исходном положении, т.е. видимая полоса 1МГц.

 

 

И при ширине полосы обзора в 900кГц вещалок также не наблюдается.

 

 

Я задавал вопрос товарищам и знакомым о природе этого «явления», но внятный ответ найти не смог. Зато вот Дмитрий EW8AX столкнулся с похожим «феноменом», только там ситуация усугубилась еще и особенностями режима direct sampling. Способ решения оказался все также в увеличении ширины полосы обзора до 1МГц. Собственно говоря, получается, что меньше 1МГц полосу выбирать смысла нет, значит можно закрыть глаза на глюки rtl_tcp на этой плате (Orange Pi One) с этим образом armbian. Считаем, что здесь все работает как надо и образ ОС на Orange Pi PC 2, который я считал рабочим после трех неудачных попыток, оказался в итоге крив.

 

Занимаемая ширина канала связи rtl_tcp.

Одним из важнейших параметров удаленного подключения к SDR-приемнику является необходимая ширина полосы пропускания локальной сети (про интернет пока речи нет). На скриншотах ниже можно видеть зависимость скорости потока данных от выбранной ширины полосы обзора панорамы. Также можно обратить внимание на уровень загрузки процессора (замеры проводил еще на OrangePi PC 2) - он ничтожен, по большому счету. Скриншоты всех возможных вариантов показывать не вижу смысла, лишь значимых, остальное – в табличке.

 

Sample Rate Мбит/с, ~
0,25 4,4
0,9 14,4
1,024 17,4
1,4 23,9
1,8 30,4
1,92 32
2,048 34,8
2,4 40,2
2,8 45,7
3,2 52,2

 

 

 

 

Из чего видно, что для подключения к приемнику по локальной сети (LAN) необходимо обеспечить пропускную способность этой сети от сервера до клиента МИНИМУМ мегабит в 18-20, т.к. при ширине полосы обзора в 1МГц скорость потока составляет примерно 17,4 Мбит/сек, и надо еще оставить некий запас для функционирования прочих сервисов и программ на клиентском компьютере. Полосу обзора шириной 250кГц не стоит использовать в принципе, по причине, описанной выше.

Использовать Wi-Fi для этой цели также довольно сомнительная затея, но с рядом оговорок это все же применимо. В любом случае, для подобной задачи лучше однозначно предпочесть ПРОВОД при наличии технической возможности.

В локальной сети это находит применение в виде расположения сервера с приемником вблизи антенны, а клиента на удалении в виде другого этажа или другого здания (частные дома в основном).

Подключаться к такому приемнику через интернет? Если канал интернета может обеспечить СТАБИЛЬНУЮ пропускную способность в 20Мбит/сек, то проблем нет. На практике (на конец 2018 года) это нереальная для достижения скорость для НЕ города, и для большинства 3G-4G подключений как в городе, так и вне его. А такие приемники где хочется поставить? Правильно, – за городом. Вывод – по интернету этот тип серверной части (rtl_tcp) использовать в 99% случаев невозможно.

 

 

Энергопотребление.

Следующее наблюдение связано с логикой работы питания свистка. Будучи подключенным в порт USB, он почти ничего не потребляет. Т.е. это состояние ДО запуска серверной части rtl_tcp.

 

Но стоит запустить управляющую программу и в ней задействовать устройство (свисток), как потребление тока становится равным около 230мА. Кроме того, можно увидеть, что тюнер находится на частоте 100МГц и программа ожидает входящих подключений. При этом еще никто не подключился, и когда подключится – неизвестно, а свисток все это время находится на приеме на частоте 100МГц.

 

 

Подключаемся клиентом. Энергопотребление неизменно.

 

Отключаемся клиентом от сервера. Энергопотребление неизменно.

 

Иными словами, пока процесс rtl_tcp запущен, свисток потребляет 230мА. Даже в режиме ожидания подключений (когда им никто не пользуется) ситуация не меняется. Получается, что он постоянно греется, а не только в моменты его реального использования.

 

 

Прочие статьи про RTL-SDR.