Функция GNU Radio general_work ()

У меня проблемы с использованием general_work функция для блока, который принимает вектор в качестве входа и выводит сообщение.

Блок является своего рода демодулятором. На самом деле это прекрасно работает, если я отправляю некоторые данные после и после (периодически).

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

Как я понимаю, речь идет о структуре буферизации и планировщика GNU Radio, но я не мог понять, как предоставить этому блоку возможность обрабатывать все символы кадра, которые я отправил, не ожидая другого Рамка.

Например, допустим, у моего кадра 150 символов. Планировщик вызывает мой general_work работать два, три или четыре раза (я не знаю, как он определяет количество вызовов для моего general_work).

Однако, он останавливается, скажем, на символе # 141 или 143. Каждый раз, когда я запускаю его, он останавливается на другом номере символа. Если я отправляю другой кадр, он завершает обработку оставшихся элементов (символов) в своем буфере.

Кто-нибудь знает, как я могу сказать планировщику не ждать, пока другой кадр завершит оставшиеся элементы в своем буфере из ранее отправленных данных.

Прежде всего, спасибо за ваши советы. Фактически, я учусь на протоколе канального уровня и его реализации с использованием SDR для моей дипломной работы. Поскольку я не эксперт по DSP, мне нужен слой Wi-Fi (трансивер). Итак, я решил использовать модуль OOT, проект «802.11 a / g / p Transceiver», разработанный Bastian Bloessl, который доступен на https://github.com/bastibl/gr-ieee802-11.git. Он предоставил пример потокового графа (wifi_loopback.crc) для имитации трансивера. Кстати, помимо самого приемопередатчика (DSP), он также разработал некоторую часть проблем канального уровня для 802.11, таких как кадрирование и контроль ошибок. В примере потокового графа блок «Message Strobe» используется как своего рода прикладной уровень для периодического производства данных и отправки их в блок, называемый «OFDM MAC», который имеет 4 порта сообщений (app_in, app_out, phy_in и phy_out ). В этом блоке необработанные данные, поступающие из «строба сообщения», инкапсулируются путем добавления заголовка и информации FCS. Затем инкапсулированные данные отправляются (phy_out) в иерархический блок, называемый «Wifi PHY Hier», для выполнения некоторых проблем DSP, таких как скремблирование, кодирование, перемежение, отображение символов и модуляция и т. Д. В некотором смысле данные преобразуются в сигнал и принимается одним и тем же блоком («Wifi PHY Hier»), и обрабатывается противоположный процесс, такой как дескремблирование, декодирование и т. д. И он передает декодированный кадр в блок «OFDM MAC» (phy_in). Если вы запустите этот потоковый граф, все нормально. Я имею в виду, что данные, отправленные «Message Strobe», получены правильно.

Однако, поскольку я пытаюсь реализовать своего рода протокол канального уровня, мне нужна некоторая обратная связь от пункта назначения к источнику, такая как сообщение ACK. Итак, я решил начать с реализации простой остановки&протокол ожидания, что источник отправляет сообщение, и ожидание подтверждения от получателя, DATA -> ACK -> DATA -> ACK … и так далее. Для этого я создаю простой исходный блок, который отправляет только одни данные, и жду сообщения ACK для отправки других данных. Данные, которые я создаю с помощью моего исходного блока, совпадают с данными, полученными с помощью «Message Strobe». Когда я заменил блок «Message Strobe» своим исходным блоком, я понял, что что-то не так, потому что я не мог получить свои данные. Итак, я проследил за своими данными, чтобы выяснить, какой шаг вызывает эту ситуацию. Нет проблем с процессом передачи. В процессе приема я обнаружил проблемный блок, который находится в блоке «Wifi PHY Hier» и является последним блоком перед тем, как этот иерархический блок передает свои данные в блок «OFDM MAC». Этот проблемный блок, который называется «OFDM Decode MAC», имеет два порта. Порт вывода — это порт сообщения, а порт ввода — сложный вектор. Итак, я рассмотрел код этого блока, особенно его функцию general_work (). Для моих конкретных тестовых данных, чтобы правильно завершить свою работу, он должен использовать 177 элементов для вывода на «OFDM MAC». Тем не менее, он прекращает потреблять предметы после 172 предметов потребления. Я переопределяю метод Forecast () и устанавливаю ninput_items_required [0] = 177. Но в этом случае ничего не происходит, потому что, как я понимаю, планировщик никогда не видит 177 элементов во входном буфере. Как вы сказали, это потому, что блок («Сигнал декодирования OFDM»), который записывает во входной буфер этого блока, производит 172 элемента.

Я еще не углублялся в подробности, но интересным моментом является то, что, когда я отправляю вторые данные (во время выполнения) по истечении определенного периода, не дожидаясь подтверждения, оставшиеся 5 элементов первых отправленных мной данных расходуются тем или иным способом. и правильно принят блоком «OFDM MAC». И теперь вторые данные находятся в той же проблемной ситуации, что и предыдущие данные. Если я отправлю третьи данные, вторые также будут получены правильно. Я действительно смущен. Как это может быть ?