Alex_2015

Будет очень сильно отличаться реальность от модели, если добавить симметрирующее устройство в реальности? Я отрисовал универсальную модель, в которой пошагово проверяю изменения выходных характеристик от размеров. Надо наверно сравнить работу модели с симметрирующим устройством и без него. Раньше антенны делал, но столь высоко по частоте не забирался. И делал сугубо по наитию и теоретическим познаниям. Измерять было нечем и как-то работали.

Нет. В базовой версии, по которой были изготовлены два образца, были отрисованы только микрополосковая линия и вибраторы. Кабель и прочее появилось позже. Сейчас отрисован цилиндр с внешним диаметром, равным диаметру экранной оболочки кабеля. Пока модель меня не очень радует. Пытаюсь выжать максимум из модели и из образцов.

Немножко не так. Кабель обеспечивает симметрию токов в плечах антенны, если он проложен вдоль микрополоска. В "объемных" антеннах это обеспечивается прокладкой кабеля внутри одной из труб собирательной линии. Но факт наличия кабеля изменяет ширину микрополоска и тем самым изменяет волновое сопротивление собирательной линии. Потому с другой стороны необходим "холостой" кабель или пруток того же диаметра, что оплетка кабеля. Смысл в том, что антенна логопериодическая априори симметричная, как и любой симметричный вибратор, из которых она набрана. А кабель коаксиальный несимметричен по определению. Потому и необходимо симметрирующее устройство.

Под симметрирующим устройством я имею ввиду "кабель вдоль собирательной линии" и то, что с ним связано. А модель с кабелем я сделал после и для стеклотекстолита. Пока результаты не очень.

По поводу различий возможно. Моделировал без кабеля и симметрирующего устройства. Здесь даже спорить не буду. Но слишком сильно от модели отличается. По кабелю имел ввиду, что измерял КСВ с разъёмами и затухание в кабеле могло привести к более низкому измеренному КСВ, чем есть у разъемов. По отчетам интересно, но не актуально. Суть в том, что считал модель почти 24 часа при обычных 8-10. Проблема в том, что значения размерных параметров модели я задаю через OptionDesign. В том числе и ширину микрополоска. Была задана 9,876мм. Считала около 9 часов. Изменил значение переменной на 9,674мм. Считала 24 часа и результат выдала для 9,876 и 9,674, хотя 9,876 была до того обновлена на 9,674. Значит 9,876 она где-то сохранила.

Измерил я КСВ разъёмов на микрополоске. Получилось очень плохо. В верхнем пике до 4 достает. На кабеле могло быть лучше, потому, как измерял на кабеле длиной около 3 м (делал для подключения антенны к источнику). Заказал у http://mirradio разъемы, которые под кабель 402 и до 11 ГГц. Хочу верить, что ситуация улучшится. Возник вопрос по HFSS. Пробую моделировать антенну в попытках найти оптимальный результат и столкнулся с интересной особенностью. Считала почти сутки. Параметры модели задаю через DesignVariable и изменил ширину микрополоска. В результате просчтиала и для старого размера, и для нового. Где она старые размеры сохранила, как сделать, чтобы она их сразу забывала и в расчетах использовала только текущие. На вскидку не нашел.

Спасибо. Была такая мысль. А какую длину микрополоска сделать, чтобы однозначно проверить идею. КСВ кабеля я измерял. Оно меняется от частоты условно говоря, по синусоиде, и в пиках поднимается до 1,25 в максимуме

День добрый всем. Не уверен, в каком из разделов открыть тему, но пока здесь. Решил окунуться в новую для меня тему в СВЧ антенны. Рассчитал и изготовил два экземпляра логопериодической антенны на диапазон 650-8000 МГц. Смоделировал предварительно в HFSS. По результатам все пристойно, КСВ в норме во всем диапазоне. Но на практике выше 3 ГГц КСВ растет до, примерно, 4 на верхней рабочей частоте. КСВ измеряю при помощи двухпортового анализатора ARINST VNA-DL 1-8800 MHz https://kroks.ru/shop/network-equipment/arinst-vna-dl-1-8800-mgcz-nastolnyj-dvuxportovyj-vektornyj-analizator-czepej/. Антенна изготовлена на материале ФАФ-4. Под него и расчет велся. Подскажите, как исправить ситуацию с ростом КСВ, в каком направлении копать.

Всем спасибо, кто откликнулся. Проблему я решил. Надо было изменить опции для команды checksum, а именно --checksum u32_ielftool_checksum:4,crc=0x04c11db7:Li,0xffffffff;0x08004000-u8_checksum_end+3 Опции Li вместо ir. Тогда расчёт через встроенный аппаратный модуль проца возвращает ноль в качестве результата. Иар версии 7.80. Возможно, в более ранних версиях было по другому https://www.iar.com/support/tech-notes/general/calculate-crc32-as-in-stm32-hardware-v.5.50-and-later/ https://www.cnblogs.com/shangdawei/p/4603924.html

Эту статью я читал. Я пробовал рассчитать контрольную сумму для одного слова (4 байта). Результат оказался верным, но побайтно отзеркаленным. Тут и получается, что не взирая на установку флага r результат остаётся неизменным.

День добрый. Если кто сталкивался, подскажите. Посредством ИАР пытаюсь генерить контрольную сумму прошивки. Генерит, но она не совпадает с той, которую считает аппаратный модуль процессора. Несколько дней искал причину. В конечном счёте не работает перестановка байт при расчёте CRC. Использую в бат файле команду ielftool.exe --fill 0xFF;0x08004000-u8_checksum_end+3 --checksum u32_ielftool_checksum:4,crc=0x04c11db7:ir,0xffffffff;0x08004000-u8_checksum_end+3 --verbose %OUT% %OUT% Так вот, не работает опция r, которая указана после алгоритма ,crc=0x04c11db7. Что и где её может запретить.

Попробовал DeviceIoControl попользовать. Ожидаемого результата не увидел. Видимо не реализована она на уровне драйвера или чтобы она работала правильно, надо что то ещё допилить, но пока не нашёл. А можно ли запрячь драйвер, чтобы он возвращал явном виде о событии Idle в линии данных. То есть об отсутствии данных судить не по отсутствию Rxchar, а чтоб драйвер об этом сообщил. Есть такая программка - Modbus Poll. Вот она как-то умудряется по паузам между сообщениями работать, причём при обработке сообщений, не являющимися в чистом виде Модбасовскими. Вот как она это делает, мне очень интересно.

В моём случае пауза определяется временем опроса драйвера виртуального порта системой. Это время составляет 1 мс. Вот 2 мс это и есть граница. Если система будет загружена выполнением большого количества дополнительных задач, то в таком случае спайки и на 30 мс неожиданностью не станут. Особенность в том, что DeviceIoControl позволяет добавлять в поток дополнительные данные о статусе устройства. Делается это на уровне драйвера, как мне удалось понять. Но повторюсь, информация очень скудная и будет ли в ней прок, хотел посоветоваться со знающими людьми. Может быть и другим интересно будет. Упоминания об использовании этой функции в связке с IOCTL_SERIAL_LSRMST_INSERT находил преимущественно на зарубежных сайтах. У нас как-то об этом не упоминают или ни кто не пробовал с ней работать.

День добрый всем. У меня появилась возможность вернуться к решению задачи о построении сниффера и частично я её решил. 2 мс между посылками в компьютерной программе ловлю на ура. Причём не пришлось повышать приоритеты ни процесса, ни потока. Теперь хочу закрепить результат и поймать паузы менее 2 мс. В связи с чем вопрос - с функцией DeviceIoControl применительно к виртуальному порту кто-нибудь упражнялся. А то на всех ресурсах описание её очень скудное. В выходные попробую реализовать и посмотреть её результат. Но может кто что скажет из опыта работы с ней.