#lag #gnuradio #software-defined-radio
#задержка #gnuradio #программно-определяемый-радио
Вопрос:
Поэтому я перепроектировал беспроводной протокол игрушки RC и написал потоковый график в GNU Radio Companion для воспроизведения команд игрушки.
Блок приемника — это приемник osmocom, а передающее устройство — HackRF One.
Проблема, с которой я столкнулся, заключается в серьезной задержке между нажатием кнопки и реагированием игрушки, которая составляет около 1-2 секунд.
Быстрое нажатие, например, кнопки «вперед» дважды приведет к тому, что игрушка также дважды дернется вперед, примерно через секунду после нажатия. Так что не похоже, что сам график потока медленный. Загрузка процессора также довольно низкая. Это похоже на какую-то проблему с буферизацией.
Я почти уверен, что сам график потока мгновенно реагирует на нажатия кнопок, поскольку отладочные отпечатки появляются одновременно с нажатием / нажатием кнопки, и прямоугольные волны также мгновенно появляются в области графического интерфейса.
Я попытался уменьшить количество буферов HackRF до одного (установив параметры устройства на hackrf,buffers=1 ), но это не помогло.
Я также установил «Максимальное количество выходов» равным 10 для flow graph, и это также не имело значения (я попробовал и некоторые другие значения).). Учитывая, что сигнал появляется в области графического интерфейса намного раньше, чем через 1 секунду, он все равно не должен был работать.
Как я могу уменьшить задержку тогда?
РЕДАКТИРОВАТЬ: я последовал предложению @Manos и попытался настроить частоту дискретизации.
Добавление блока rational resampler с интерполяцией 8 (и соответствующей настройкой частоты дискретизации приемника) И настройки hackrf,buffers=1 делает задержку практически несуществующей.
Однако уменьшение частоты дискретизации моего пользовательского блока до 500 Кб и 16-кратная интерполяция по-прежнему вызывают заметную задержку, возможно, 400-500 мс (все еще не такую значительную, как при 1 М как в источнике, так и в приемнике). Я не уверен, как это исправить. К сожалению, запуск моего пользовательского блока со скоростью 1 М потребляет 100% ЦП и вызывает случайные неполадки.
Комментарии:
1. Если вы удвоите частоту дискретизации, уменьшится ли показанная задержка? Я испытывал некоторые большие задержки с помощью HackRF при низких частотах дискретизации, но не порядка секунд.
2. @Manos: спасибо, я попробовал ваши предложения, и они немного улучшили ситуацию. Я обновил свой вопрос.
3. 1 М не должно быть проблемой в большинстве случаев для новых процессоров. Возможно, вы забыли максимальное количество выходных элементов в небольшом значении? Также мне любопытно, если что-то пойдет не так с планировщиком. Можете ли вы предоставить больше информации о вашем блоке? Это блок синхронизации или общий? Всегда ли генерируются сэмплы или только при нажатии кнопки?
4. @Manos: это блок синхронизации, и он написан на чистом Python (если бы я переписал его на C, 1M, конечно, не было бы проблемой). Он всегда выдает выборки («низкий» сигнал несущей). Как только кнопка нажата, она немедленно начинает выдавать модулированные биты. Вот источник: gist.github.com/WGH-/4c0a18b3bfff9dc97c4602f62ace028d