DaddyTorque

Прошу закрыть тему, т.к. больше не актуально. Отправил модуль обратно китайским братьям по разуму без проверки.

Купил через eBay модуль TDS2CMAX для своего осциллографа TDS2024. С установленным модулем мой осциллограф не включается. Хотел бы проверить, в чём причина, в модуле или в осциллографе. Если есть у кого любой осциллограф TDS (1000 или 2000 серии) либо модуль TDS2CMAX - отзовитесь пожалуйста (а лучше смсните на 8 909 5889379). Это актуально только ближайшие дня 3. Т.к. мне надо этот модуль отправить на замену. Неохота его посылать, если причина в осциллографе, а не в модуле. Update: я территориально нахожусь в Санкт-Петербурге, готов подъехать в любое место города в любое время с осциллографом и модулем, чтоб выяснить причину неисправности путём установки заведомо исправного модуля в мой осциллограф или моего модуля в чужой осциллограф, который предполагается считать заведомо исправным.

К сожалению, интересует не только модуль. Умножать весь массив на фазосдвигающие коэффициенты займёт практически столько же времени (если не больше) сколько и сдвигание массива перед тем, как делать БПФ. Я думал, может трюк есть, вот и спросил... сейчас понял, что трюка нет :( Ничего не понял. То, что я делаю, у нас называют БПФ с перекрытием (можно сказать, наверно, что оно и есть скачущее). Если даже циклический буфер больше по размерам, чем разрядность БПФ, всё равно рано или поздно в этом циклическом буфере данные завернут через край: 6 7 8 _ _ _ _ _ _ _ _ 1 2 3 4 5 И тогда никак... Можно сделать вот так вот (циклический буфер остаётся, но к нему добавляются уши слева и справа): _ _ _ _ 6 7 8 1 2 3 4 5 _ _ _ _ и можно тогда так сделать: _ _ _ _ 6 7 8 1 2 3 4 5 6 7 8 _ (чтоб получить непрерывную последовательность), но для этого надо слева и справа от буфера хранить "уши" суммарного размера равного размеру буфера - что для меня неприемлемо.

Думал об этом... тогда придётся по два раза копировать, да и памяти много потребуется... (у меня достаточно специфическое приложение - количество параллельных каналов около 1000, разрядность БПФ от 1024 до 16384 (меняется в зависимости от режима работы)), вобщем хотелось именно сэкономить на использовании цикличности одного буфера. С этим проблем как раз нет, хотя копирование и идёт по DMA, но манипуляция с полученными данными запускается когда одна пересылка закончилась, и заканчивается до того, как начнётся следующая... В любом случае спасибо... что-нить буду думать.

Суть проблемы: данные приходят постоянно, над ними надо делать БПФ, естественно, делать его надо с перекрытием. Как хотелось бы решить: данные класть в циклический буфер, чтоб не заниматься их постоянным перетаскиванием в начало буфера по мере обработки старых. Дополнительное пожелание: Хотелось бы делать БПФ на том же циклическом буфере, но ни одна из имеющихся функций, реализующих БПФ, не поддерживает возможность работы с массивами данных, которые wrap-ятся в конце буфера на его начало. Подозрения: 1) Операция сдвига данных во временном домене на тау - есть свёртка с дельта-функцией от тау, а свёртка во временном домене эквивалентна умножению в частотном. 2) Циклические буферы и БПФ - очень часто используются в ЦОС. Раз штатные функции FFT не позволяют работать с циклическими буферами - может это и не нужно? Вопрос: Можно ли как-то сделать БПФ над данными вида 6 7 8 1 2 3 4 5 (цифрами обозначены моменты времени, т.е. видно, что данные закругляются) не переставляя местами части (1 2 3 4 5) и (6 7 8), и при этом получить тот же результат? Я понимаю, что чтоб получить тот же результат, надо домножать на вектор фазосдвигающих коэффициентов, который и будет соответствовать Фурье образу нашей дельта-функции, но может можно как-нибудь смухлевать и обойтись без умножения? Например, подсунуть какую-нибудь сдвинутую twidle-таблицу ?

поясню ещё... то, что строится и нарисовано - это не совсем ДН, т.к. направление компенсации антенны тоже меняется с изменением направления прихода сигнала - это скорее диаграмма отклика.. не знаю, как правильно это назвать. И ещё там перепутано, надо делать mesh(X,Y,Z). Но это не суть важно, важно, что код пригоден для формирования 3d диаграмм направленности.

Наткнулся на эту ветку, пытаясь построить ДН для своей антенны... в итоге построил таким образом: dia_sq = dia .* conj(dia); [u,V] = meshgrid((hor_begin*pi/180:hor_step*pi/180:hor_end*pi/180),(ver_begin*pi/180:ver_step*pi/180:ver_end*pi/180)); X = dia_sq .* cos(V) .* cos(U); Y = dia_sq .* cos(V) .* sin(U); Z = dia_sq .* sin(V); figure(2); mesh(X,Z,Y); поясняю: dia - это сетка комплексных значений где орты сетки это углы по горизонтали и вертикали. соответственно, dia_sq это аналогичная сетка мощностей с разных направлений дальше из полярных трёхмерных координат переходим в декартовые трёхмерные и строим mesh. На всякий случай привожу полную функцию (хотя там есть ещё другие функции, которые здесь не буду приводить) function f=directive_pattern_vert_hfa_3d(freq, hor_begin, hor_end, hor_step, ver_begin, ver_end, ver_step) antenna = init_antenna_def(); LO_FREQ_LIM = antenna.lo_freq_limit; HI_FREQ_LIM = antenna.hi_freq_limit; antenna.beams_count = 1; antenna.elevation = 0; elevation_grid = (ver_begin:ver_step:ver_end)'; azimuth_grid = (hor_begin:hor_step:hor_end)'; elevation_steps_count = size(elevation_grid, 1); azimuth_steps_count = size(azimuth_grid, 1); dia = zeros(elevation_steps_count,azimuth_steps_count); bin = convert_freq_to_bin(freq, 12207, 2048); freq = convert_bin_to_freq(bin, 12207, 2048); progress_bar(sprintf('frequency corrected to %f to be equal to closest bin\n',freq), 0, 0); for j = (1:1:azimuth_steps_count); azimuth = azimuth_grid(j); antenna.beams(1) = azimuth*pi/180; for i = (1:1:elevation_steps_count); progress_bar('', (i-1)+elevation_steps_count*(j-1), azimuth_steps_count*elevation_steps_count); elevation = elevation_grid(i); signal_time = sim_signal_hfa(freq, 1, 0, -azimuth*pi/180, elevation*pi/180, antenna ); signal_freq = FftTime(antenna, signal_time, '', LO_FREQ_LIM, HI_FREQ_LIM); clear signal_time; spectrum = sim_antenna3d_direct_beam_forming(signal_freq, antenna, bin); dia(i,j) = spectrum(bin); end end fprintf(1,'\n'); figure(1); surf(azimuth_grid, elevation_grid, dia.*conj(dia)); title(sprintf('direct transform, f=%f Hz',freq)); dia_sq = dia .* conj(dia); [u,V] = meshgrid((hor_begin*pi/180:hor_step*pi/180:hor_end*pi/180),(ver_begin*pi/180:ver_step*pi/180:ver_end*pi/180)); X = dia_sq .* cos(V) .* cos(U); Y = dia_sq .* cos(V) .* sin(U); Z = dia_sq .* sin(V); figure(2); mesh(X,Z,Y); f = dia; на рисунке моя диаграмма в 3d:

Ситуация такая: начал разбираться с проектами-примерами для STM32VL-Discovery отладочной платы. В них по умолчанию в Project->Options->Linker->Config->Linker Configuration File установлена галочка Override default и границы ROM и RAM установлены совсем нетипичные для МК, который стоит на этой плате. Попробовал создать новый проект, галочку Override default ставить не стал, но в файле main.c объявил массив char-ов длиной 10000. И тоже скомпилилось без ошибок (при том, что памяти там (оперативной) всего 8Кбайт). Вопрос: знает ли IAR что-нибудь о микроконтроллере который он использует (я выбирал при создании проекта, что использую МК STM32F100xB - это должно однозначно говорить компилятору о количестве памяти на борту). Просто хочется понять, IAR расчитан, что я знаю что делаю и можно смело оверрайдить дефолтные настройки значениями взятыми из даташита, или просто я чего-то не догнал, а умный ИАР всё предусмотрел и не надо туда вообще лезть?

А может подскажете ещё: почему-то st-link, который по идее на плате (STM32L-Discovery) есть, не распознаётся нормально виндой. В Device Manager-е в Other device-ах вопросительный знак (с воскл. значком) с надписью STM32 STLink. Установил уже и st-link utility и st-tools. Есть файл STLinkUSBDriver.dll, но для него нет inf файла, без него не устанавливается... Что посоветуете?

Спасибо большое... как раз только только нашел, хотел отписаться, что нашел, а вы опередили, в любом случае, спасибо.

Пытаюсь освоить платку STM32L-Discovery. Скомпилил исходники того, что на ней залито по умолчанию, хочу прошить, нужна, как я понимаю, ST-LINK utility. Но найти её не удалось. Ответы, типа "ищи на сайте STMicroelectronics" не подходят, т.к. уже искал и нашел там только мануал на эту ST-Link utility. Драйвера или утилиты самой там не было. Если не трудно, запостите ссылку пожалуйста.

есть две матрицы 8 х 2048. (фактически каждая - это 2048 векторов) нужно получить вектор из 2048 компонент, в котором каждая компонента является результатом скалрярного произведения соответствующих векторов длины 8 из двух исходных матриц. Код A1.1 A1.2 A1.3 ... A1.2048 A2.1 A2.2 A1.3 ... A2.2048 .......................... A3.1 A3.2 A3.3 ... A3.2048 B1.1 B1.2 B1.3 ... B1.2048 B2.1 B2.2 B1.3 ... B2.2048 .......................... B3.1 B3.2 B3.3 ... B3.2048 ================== Ax.1*Bx.1,.... Ax.2048*Bx.2048 Такой результат можно получить, сделав diag(A' * B ) но обидно считать произведение таких больших матриц, когда в итоге от этого произведения возьмется только диагональ. Есть у кого-нибудь идеи, как это можно сделать без циклов и избыточных вычислений ? Догадался сам. Делается это очень просто: C = sum(A .* B); по сравнению diag(A * B) экономия получилась у меня порядка 60 раз.

Есть очень хороший сайт (сам недавно для себя открыл) dsplib.ru там много статей. По вопросу: для АМ не нужно преобразование Гильберта, просто обычная АМ приводит к расширению спектра в 2 раза. Вы получаете справа и слева от несущей боковые полосы, равные по ширине полосе исходного (модулирующего) сигнала. Объяснить это можно так: когда вы рассматриваете просто какой-то сигнал, он у вас вещественная функция от времени. При рассмотрении вещественного сигнала в частотном домене происходит вот что: допустим рассматриваем функцию cos(t). Она будет представлена такой суммой: cos(t) = 0.5*cos(t) + 0*sin(t) + 0.5 * cos(-t) + 0*sin(-t) Если рассматриваем sin(t), то он раскладывается в: sin(t) = 0*cos(t) + 0.5*sin(t) + 0*cos(-t) - 0.5*sin(-t) в любом случае вещественный сигнал всегда рассматривается как полусумма соответствующих сигналов с положительной и отрицательной частотой (аргументы t и -t) - отрицательные частоты ведь ничем не хуже положительных, поэтому имея какое-то колебание логичнее всего его рассматривать как полусумму соотв. колебаний отрицательной и положительной частоты. Пока наш сигнал не модулирован (т.е. baseband не перенесён, т.е. занимаемая им полоса начинается от 0) - мы этих отрицательных частот не видим. Но как только мы переносим baseband (например, с помощью модуляции), эти отрицательные частоты вылезают во всей красе. Преобразование Гильберта обычно используют для получения SSB (single-side band) сигнала - т.е. АМ сигнала с одной боковой полосой. SSB нужен потому, что частотный ресурс дорог и хочется использовать доступный диапазон частот максимально эффективно (т.е. не хочется тратить 10 кГц для передачи полезного сигнала шириной 5 кГц). Тут есть еще один момент: лучше всего забыть о вещественных числах при работе с DSP. Применяя комплексные числа вы получаете следующее преимущество: глядя на вещественную синусоиду вы можете только сказать, что колесо (ротор генератора или что либо еще) крутится с такой-то частотой, глядя на то же колебание, записанное в комплексном виде, вы можете еще и сказать, в какую сторону крутится колесо (потому что вы смотрите на него с двух взаимно-перпендикулярных направлений) - иногда это важно (например, частота вращения колеса 5 оборотов в секунду, если вы повышаете частоту вращения колеса на 100 оборотов в секунду, то если изначально частота была 5, то вы получаете 105, а если изначально была -5, в результате будет 95), а глядя на косинусоиду - разницы между 5 и -5 не видно! Извините, что пишу прописные истины, но вдруг полезно будет...

С этим разобрался... не буду вдаваться в подробности... Изначальная проблема с массивом из float-ов. Я думал, что он не инициализируется, потому, что он у меня нулями отображался. Потом поставил массив из int-ов, но забыл дотрассировать до начала main-а. Потом разобрался. Всё инициализируется, но проблема тем не менее в том, что float-ы в случае если выбрать формат float отображаются просто нулями, если выбрать формат IEEE float, то числами, но не теми, которые были заданы при инициализации, при этом, одинаковые исходные числа отображаются одинаковыми некорректными числами (см прикреплённые файлы). Проверяю в симуляторе. Но компилирую под TMS320C4x.

В Code Composer 3x/4x при попытке просимулировать выполнение программы, почему-то все глобальные массивы видятся либо как заполненные числом 0x80000000 либо мусором. Из-за чего такое может быть? (пробовал уже и #pragma DATA_SECTION добавлять... не помогает, очевидно, какая-то хитрость). Поясню, массивы инициализировал, а не только объявлял. Пособите, если кто знает, пожалуйста.