Синхронизация исходных блоков USRP — несколько устройств B2xx

Я пытаюсь создать синхронизированный исходный блок usrp в gnu radio, состоящий из нескольких устройств B210 USRP. Язык: С++.

Из того, что я нашел, мне нужно:

  • Создайте несколько экземпляров multi_usrp_sptr, так как для каждого B210 требуется одно, а несколько устройств B210 не могут быть адресованы с помощью одного sptr.
  • Использовать внешние источники частоты и PPS — опция, которую можно выбрать из блока или задать программно
  • Синхронизируйте перенастройку для достижения повторяемого фазового смещения между узлами — этого можно добиться с помощью API синхронизированных команд https://kb.ettus.com/Synchronizing_USRP_Events_Using_Timed_Commands_in_UHD
  • Синхронизируйте потоки примеров, используя свойство time_spec issue_stream cmd

Проблема в том, как мне вставить эти синхронизированные команды и установить time_spec потока в радиоблоке GNU или библиотеках gr-uhd?

Я заглянул в папку gr-uhd, где находился приемник/исходный код, и нашел функции, которые можно изменить. К сожалению, я не знаю, как скопировать или экспортировать эту библиотеку, чтобы внести эти изменения, а затем скомпилировать, чтобы вставить мои пользовательские блоки в GNU Radio, потому что gr-uhd, похоже, встроен и скомпилирован при установке GR. Я пытался справиться, а затем сделать библиотеку, но это не так - не удалось. Должен ли я добавить свой собственный исходный блок через gr_modtool и вставлять только те команды, которые мне нужны? Совместимость с uhd и его функциями, кроме добавления нескольких строк, была бы выгодна, чтобы не писать исходники с нуля.

пожалуйста, порекомендуйте

Изменить
Экспериментальная блок-схема, основанная на предложении Маркуса Мюллера:
Экспериментальный процесс синхронизации USRP


person Marcin_Wachowiak    schedule 17.07.2020    source источник


Ответы (2)


Проблема в том, как мне вставить эти синхронизированные команды и установить time_spec потока в радиоблоке GNU или библиотеках gr-uhd?

Для приемника USRP: добавьте в потоки теги, содержащие словари с правильным временем выполнения команды. В документах GNU Radio API есть информация о том, как должны выглядеть эти словари. Поле time — это то, что вам нужно установить с соответствующим значением.

Для источника USRP: используйте set_start_time в блоке uhd_usrp_source; используйте те же самые словари, описанные выше, для выдачи таких команд, как настройка, настройка усиления в скоординированное время.

person Marcus Müller    schedule 23.07.2020
comment
Большое спасибо, за совет. Если я правильно понял, мне нужно создать dict из пар: команда — значение, а затем выдать их в usrp. К сожалению, я не нашел никаких блоков для создания или редактирования диктов (используя GR 3.7), поэтому мне нужно было бы добавить свой собственный блок или вместо этого упаковать их в вектор? Я попытался создать примерную блок-схему, чтобы проверить, так ли это должно выглядеть? Скриншот добавлен в основной вопрос - person Marcin_Wachowiak; 25.07.2020

Я пытался найти правильный способ синхронизации USRP с помощью тегов. Есть несколько проблем, с которыми я столкнулся в этом подходе:

  1. Временные команды требуют знания текущего момента времени, что делается через usrp.get_time_now(), даже если бы я попросил USRP предоставить время через теги, мне пришлось бы каким-то образом извлечь его из вывода. (создайте какой-нибудь цикл и правильное срабатывание) (источник: https://kb.ettus.com/Synchronizing_USRP_Events_Using_Timed_Commands_in_UHD) или, может быть, планировать все не относительным образом — используя абсолютные значения вместо смещений. Я видел способ регулярно сбрасывать значение времени для каждого PPS (устанавливать его на 0,0), и, возможно, тогда установка времени команд в диапазоне 0,0-1,0 была бы приемлемой. Тогда цикл чтения и вставки времени в команды тоже был бы избыточен.
  2. Я не нашел способа создавать диктовки в GR через блоки, чтобы сделать решение масштабируемым (без написания нескольких строк кода в текстовом поле) или писать блок OOT.
  3. В конце концов, так мало информации, чтобы сказать, какое решение является наиболее подходящим (PDU, события, теги все еще актуальны в GR?), а документации так мало, что после некоторой рассылки я решил добавить простой класс который наследуется от основного файла top_bock.py и после создания экземпляра top_block вызывает несколько функций для синхронизации устройств. Такое решение не самое гибкое, и родительский класс top_block.py приходится вызывать через наследующий, но он обеспечивает простой программный интерфейс.

Скоро на всякий случай добавлю пример кода, используемого при наследовании класса.

Если есть более изящное, динамичное или масштабируемое решение, сообщите мне об этом или укажите источники.

person Marcin_Wachowiak    schedule 27.07.2020