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

Question

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

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

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

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

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

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

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

---

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

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

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

Answer 1

Я быстро прокомментирую ваш текст, а затем посоветуйте ниже:

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

Этот блок, с точки зрения потока проб, раковина . Вы обнаружите, что при использовании sink в качестве типа блока в gr_modtool вы получите sync_block, что означает, что вам нужно будет только реализовать work, а не general_work и forecast.

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

Итак, это здорово!

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

Это звучит как ваш блок фактически не принимают потоки образцов, но блоки. Это либо работа для

• передачи сообщений (так что ваш блок не будет иметь не входного потока, просто сообщение порта) или
• маркированных поток блоков.

Звучит как второй для меня.

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

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

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

Это не решение - это, вероятно, куски, в которых символы записываются во входной буфер вашего блока. Вы не имеете, чтобы потреблять все эти (или любые из них), если ваш блок не может выдавать выходные данные с указанным вводом. Просто сообщите GNU Radio, сколько предметов было израсходовано (в случае блока синхронизации это неявно сделано с возвращаемым значением, в случае с general_work вам может потребоваться вручную вызвать consume - еще одна причина для изменения типа вашего блока!).

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

Это звучит как ошибка в вашем алгоритме, а не в GNU Radio. Может быть, ваш буфер ввода просто заполнен или, возможно, блок, который записывает в него, просто не предоставляет больше данных?

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

Планировщик не ждет; как только будут обрабатываться данные, он мгновенно «разбудит» ваш блок и попросит его обработать элементы.

Answer 2

Я достиг Бастиана, парня, который разработал этот модуль OOT. Он сказал, что причина проблемы - это разновидность проблемы. Если после «Wifi PHY Hier» используется блок под названием «Packet Padding2», который может быть найден в другом модуле OOT, который также был разработан им, используется для определения значения параметра Pad Tail этого блока, проблема решена.