zi4rox

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

Предполагается, что это случайные фазовые сдвиги. Генерируется это дело так: a = rnorm(); b = rnorm(); // нормальные распределения VK = a + ib; Далее VK прогоняется через фильтр. От VK остается: Затем берется XC = ОДПФ(P), и мнимая часть от всего этого XC = Im(XC) и получается: Да, так и есть. Шум генериться как: a = rnorm(); b = rnorm(); // нормальные распределения noise = a + ib;

Имеется антенная решетка, на которую падает сумма 3 (j=3) плоских волн wk[ aj fj - амплитуда/частота волн; L = 1024; k = 0 .. L-1 ] Все это дело принимает антенная решетка (sk - принятый сигнал) - с аддитивным нормальным шумом noise все понятно и неприятностей он не доставляет, а вот как отфильтровать фазовые помехи XCk ? Изменяется фаза так: Пожалуйста, прошу - подскажите метод фильтрации этих самых фазовых искажений, куда смотреть и что искать?

Всё понял, нашел ещё в Гоноровском целая глава с математикой есть. Спасибо за быстрые ответы!

Подскажите толковой литературы, с хорошим описанием и математикой по кепстральному анализу и задачам решаемым с его помощью. Заранее благодарен!

Задача (общее): Устройство для очистки речевого сигнала от шума (адаптивная фильтрация) Необходима схемотехническая реализация и код для тмс + по возможности реализация в железе За более подробной информацией в личку на форуме, или же на @почту: [email protected] * Если есть возможность, укажите сразу приблизительные сроки/стоимость работ

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

Есть задача и желание разобраться и освоить работу c TMS320. Первый заход в поисковики и форумы - выдал примерную картину для меня: "обсуждения каких-то конкретных проблем есть, решения есть - но такое ощущение что все как бы сразу уже умеют работать с ними, а начального уровня нигде не увидел". Для освоения данных процессоров есть простая задача: сделать на базе тмс320 цифровой фильтр н-ого порядка. Первый вопрос который сразу же задал себе - чем и как программировать, среда разработки и т.п. Вообще куча вопросов (потому что опыта работы с ними нет вообще, есть большой опыт проектирования девайсов на авр - там то инфы было завались). Надеюсь что поможете добрым словом, и данный тред будет полезен таким же новичкам 1. Среда разработки Ну тут вроде все прозрачно, почти все упоминания сводятся к Code Composer Studio. Вроде все хорошо тут и на си кодится ) 2. Программатор Вот здесь у меня оооочень большие вопросы и сомнения. Схем программаторов как таковых не нашел вообще нигде, на форумах у всех есть тестовые-платы которые стоят очень много и заводские программаторы-эмуляторы, которые стоят ещё дороже. Единственное что нашел так это Olimex TMS320-JTAG программатор-эмулятор + на форуме по нему отзывы тоже разношерстные. В общем я очень сильно задаюсь вопросом - как прошивать-то?. Или я действительно оплошался, наивно полагая что заказав сэмпл проца с техаса и спаяв/купив дешевый программатор можно начать работать? 3. Какой проц взять? Из вашего личного опыта - с каким семейством проще начать работу и изучение? Пока склоняюсь, что надо заказывать TMS320FC28xx - исходя только из тех соображений, что именно их можно прошивать бюджетным программатором от Olimeх. 4. Примеры, схемы И ещё один нюанс который не очень нравиться - почти нет схем, примеров проектов на данных процах. Все юзают отладочные платы, которые мне не под силу достать. Хоть парочку бы простеньких реализаций, посмотреть обвязку, как программить и подключать - хоть что-то. В даташите тоже ооочень скудно. Так что вот, пока смотрю как на большой черный ящик, у которого приоткрыл крышку - но пока все равно ничего не видно. Но желание осилить это дело есть - прошу добрых людей направить в нужную сторону и помочь добрым постом )

Всё, вроде разобрался - нужно быть более аккуратным при подборе коэффициентов. Сигнал действительно можно восстановить с любой точностью, для гармонического сигнала - ещё можно и форму подсгладить. * на рисунку 250 точек на период - это число может быть теоретически любым Всем спасибо кто помогал!

Пытаюсь сделать интерполяцию синком - не получается немного ... Вот формула, для восстановления сигнала: x(t) - исходный сигнал Fmax - частота сигнала, пусть Fmax = 1000 Гц dt = 1/2Fmax (отсчеты идут через этот интервал времени) dt = 1/2*1000 = 0.0005 При это допустим что ацп выдает нам 13 отсчетов сигнала на период. Сам же период T = 1/f = 0.001. Вот на интервале времени в 1 период я и хочу восстановить сигнал. Тогда суммирование будет идти от n=0 до n=2Fmax*T=2000*0.001=2 // Всего 2 отсчета будет использоваться, а не все 13? // s(n*dt) - это как раз сами отсчеты которые у меня есть. // Это массив с отсчетами, которые у меня есть за 1 период data_01[0]:= 1.10929; data_01[1]:= 1.02396; data_01[2]:= 0.85501; data_01[3]:= 0.54537; data_01[4]:= 0.31164; data_01[5]:= 0.08533; data_01[6]:= 0.02226; data_01[7]:= 0.09275; data_01[8]:= 0.26341; data_01[9]:= 0.56763; data_01[10]:= 0.81249; data_01[11]:= 1.0388; data_01[12]:= 1.09445; ... //константы, что обговорили выше: f_max:=1000; dt:= 0.0005; x:= 0.0004; // вычисление значения восстановленного сигнала x(t) в точке x for n:=0 to 2 do begin buff:= data_01[n]*sin(2*3.14*f_max*(x-n*dt))/(2*3.14*f_max*(x-n*dt)); result:= result+buff; end; Я получаю 1,0849 - довольно близкий отсчет. Пробую строить сам график, беру 100 точек интерполяции с шагом в 0.0004 for j:=1 to 100 do begin result:=0; // обнуляю результат вычисления для каждой новой точки dx:= j*0.0004; // шаг восстановления: 0.0004, 0.0008, 0.0016 и.т.д. for n:=0 to 2 do begin buff:= data_01[n]*sin(2*3.14*f_max*(dx-n*dt))/(2*3.14*f_max*(dx-n*dt)); result:= result+buff; end; // И добавляю вычесленную точку на график (x,y) Series2.AddXY(dx,result,'',clRed); В результате получаю вот такую картинку: синк он мне рисует ... но это не восстановленный сигнал. Как я понял - тут должна быть сумма синков - и тогда образуется нужное. Или я ошибаюсь? Помогите пожалуйста разобраться, а то голова кругом уже

Измерять нужно амплитуду. Про цифровую интерполяцию интересно! Пойду искать информацию по этой теме, спасибо за идею. * Если кто нибудь знает хорошую ссылку на алгоритм/или мат. описание интерполяции sinc(x) прошу поделится

Да, сейчас тоже пересчитал - получается что ацп правильно работает - и там получается 10 точек на период. Буду пытаться увеличить частоту дискретизации каким то образом. Непонятно пока - сколько этих точек на период в среднем необходимо для более менее верной оцифровки? Или это определяется исходя из личных условий задачи? Вы как считаете?

ATMega16 управляет внешним АЦП TLV1570 по встроенному SPI и пытаемся оцифровать гармонический сигнал с частотами до 20кгц. Немного о TLV1570 - 8ми канальный 10ти разрядный последовательный АЦП 1.25MSPS. Входные напряжения: 0 .. 5В По теореме Котельникова, частота дискретизации: Fдиcкр > 2Fmax В моём случае 2Fmax = 40кГц, а частота дискретизации АЦП по даташиту считается так: Fдискр = 1/16*Fsclk (на каждую выборку нужно передать 2 байта) (в обвязке к ATMega стоит резонатор на 16МГц, при настройках SPI получил: Fsclk = 4Mhz ) => Fдиск = 1\16*4Mhz = 250кГц Т.е. мы укладываемся с головой. Частота дискретизации 250 кГц, а сигнал 20кГц Код прошивки такой: while (1) { for (i=0;i<100;i++) { ADC_CS = 0; adc_result_hi[i] = spi(0x00); adc_result_low[i] = spi(0x60); ADC_CS = 1; } for (i=0;i<100;i++){ putchar(adc_result_hi[i]); putchar(adc_result_low[i]); } } * я сначала собираю отсчеты по 100 точек и сохраняю их в буффер, а затем отправляю по UART на COM порт в ПК. (так быстрее производительность, т.к. отправка по уарту занимает значительное время) Просимулировал этот код в VMLAB, получил следующие тайминги: С учетом всех погрешностей на запись в переменные и т.п - получил, что снятие одного отсчета займет 10мкс - т.е. частота дискретизации 100кГц - все равно укладываемся. Итак, на практике вот что я получаю: Оцифровка сигнала частотой 10кГц амплитуда около 1В: Здесь около 10ти точек на период. Качество оцифровки неудовлетворительное. Сразу же в настройках SPI выставил галочку SCLK x2 Rate - т.е. удвоили частоту тактирующего импульса (я предполагал что и качество оцифровки увеличится в 2 раза) Вот как получилось с этой настройкой: Оцифровка сигнала частотой 10кГц амплитуда около 1В (SPI SCLK x2 rate): Получилось 13 точек на период - совсем небольшой прирост =( Мучил код, пробывал и так и сяк, симулировал. Вот как получается, если после получения отсчета от АЦП - сразу выплевывать его на UART: while (1) { ADC_CS = 0; putchar(spi(0x00)); putchar(spi(0x60)); ADC_CS = 1; } Совсем не так как хотелось бы. * Сигнал с меньшей частотой оцифровывает прелестно. Вот пример оцифровки синуса с частотой 1кГц: Здесь меня всё устраивает. Около 90 точек на период. Качество отличное Прошу помощи - оцифровкой занимаюсь в первый раз, как быть, вроде бы всё правильно - а на деле выходит совсем не то. Возможно код можно ещё как то более оптимизировать, или ещё где ошибку сделал? Прошу совета.

Посоветуйте пожалуйста, какой макс взять для измерения переменного тока, не более 1 ампера, частотой до 200кгц. На сайте ищу у них - но пока не особо уверен что выбрать

Даташит на AD9832 почитал, но там как то скользко, в общем вопрос простой: Возможно ли изменять амплитуду выходного сигнала с ДДС средствами встроенного ЦАПа?

Переделал на аппаратный SPI и оно заработало. Есть кое какие глюки - но пока работаю над этим, если что не получится - обязательно спрошу. Пока такой вопрос: По даташиту написано что ацп - однополярный, что я могу подавать сигнал в пределах от 0V - AVDD (0-5В) Мне нужно оцифровать переменный сигнал (синус) - как быть в этом случае? Т.е я просто подаю на выход как обычно, главное следить чтобы аплитуда была не более 2.5В ?

Обнаружилась следующая нехорошая вещь: При таком соединении: T2IN - TxD R2OUT - RxD UART работает как надо и нареканий нет, вот только на блоке питания спустя 1-2 минуты начинают жутко греться стабилизаторы (кренки) Навряд ли там уарт такой большой ток кушает, начал искать кз. Схемы проверил, всё прозвонил - нигде нет. Удалось установить, что: Если я поменяю местами T2IN - RxD R2OUT - TxD то перестает греться, но и уарт не работает как надо (куча мусора лезет - то что в начале было) В каком направлении искать сие загадочную пакость?

Пытаюсь подключить к ATmega16 и заставить работать внешнее АЦП TLV1570 - появились некоторые затруднения, прошу помочь разобраться Интерфейс соединения с микроконтроллером - SPI вот с этим я и борюсь. Исходная информация: 1. Схема подключения: В даташите структурно это выглядит так: На деле так: 2. Алгоритм работы и прошивка для МК Работает данное АЦП следующим образом: а. Передаем 16 конфигурационных бит с настройками. б. Передаем 16 конфигурационных бит с настройками и читаем 10 бит результата (то что сконфигурировали в пункте а.) ... и т.д. Т.е на каждую выборку, я должен отсылать конфигурационную последовательность, и получать свой результат. * Для оцифровки сигнала на канале 0, с внутренней опорой в 2.3В, мне необходима следующая комбинация битов: [00000000 01000000] или 0x40h 1. Определения #define ADC_SCLK PORTA.0 #define ADC_SDIN PORTA.1 #define ADC_SDOUT PORTA.2 #define ADC_CS PORTA.3 2. Функция передачи 16 бит на АЦП void spi_send (void) { char ctr = 8; ADC_CS = 1; ADC_SCLK = 0; ADC_CS = 0; while (ctr) { ADC_SDIN = adc_conf_hi & 0b10000000; ADC_SCLK = 1; adc_conf_hi <<= 1; ADC_SCLK = 0; ctr--; test_sdout = test_sdout + ADC_SDOUT; } ctr = 8; while (ctr) { ADC_SDIN = adc_conf_low & 0b10000000; ADC_SCLK = 1; adc_conf_low <<= 1; ADC_SCLK = 0; ctr--; } ADC_CS = 1; } } 3. Основная процедура while (1) { adc_conf_hi = 0x00; adc_conf_low = 0x40; spi_send(); }; * Состояние ноги ADC_SDOUT (т.е. там где должны появлятся оцифрованные данные) - контролирую по УАРТУ (код посылки состояния ноги в ПК не стал приводить, дабы не загромождать(putchar(ADC_SDOUT);)) 3. Временные диаграммы Проэмулировал работу прошивки в VMLAB - вроде всё как в даташите: Диаграмма из ДШ: Диаграмма из VMLAB (передача [00000000 01000000]): * насколько я понял чтение данных происходит по спаду. Признаки жизни При передачи 16 бит конфига: [00000000 01000000] - я говорю АЦП что бы использовался канал #0. Тогда напряжение, подаваемое на CH0 отобразится на ноге AIN - т.е на аналоговом входе. Путем изменения номеров каналов, и подачи постоянного напряжения туда - убедился в том что АЦП распознает конфигурационные 16 бит, и правильно выбирает канал для оцифровки. => оно живое, оно работает, просто вредничает и не хочет оцифровывать мой сигнал Перепробывал уже почти всё, на выходе (ADC_SDOUT) всегда 0 оцифрованных данных. Может кто советом поможет?

Я не знаю как это получилось, но решил руководствуясь замечанием Dx! поменять местами RxD TxD (от max232 до меги) - и что самое интересное оно заработало! (Хотя я был уверен что при неправильном подключении просто ничего не будет происходить) Как всегда - все оказалось банально до немогу. Постейшая невнимательность. Всем ОГРОМНОЕ спасибо. Буду разбираться ещё немного и писать код под свою задачу - если что обязательно спрошу. Ещё раз всем спасибо

Попробывал, как Вы сказали: putchar(0x00); putchar(0xff); putchar(0x15); Уже заметно лучше, но все же ещё кое где проскальзывает ошибочные данные (вот что в терминале [должно быть 00 FF 15 ]): 00 FF 15 00 FF [b]11 D0 15[/b] 00 FF 15 00 FF 15 [b]FF E8 15[/b] 00 FF 15 00 FF 15 00

Пробывал, также и с проверкой готовности регистра передачи: while(!(UCSRA & (1<<UDRE))); UDR = 'R'; результат тотже

Всем добрый день, Пытаюсь заставить корректно работать UART на меге для связи с компьютером, и вот что получается: Исходные данные: 1. Схема по которой это все работает: * Вот здесь брал описание: http://easyelectronics.ru/svyaz-mikrokontr...erez-rs232.html 2. Прошивка для мк: * Она сгенерирована CodeWizard'ом в CVAVR на такие параметры: // USART initialization // Communication Parameters: 8 Data, 1 Stop, No Parity // USART Receiver: On // USART Transmitter: On // USART Mode: Asynchronous // USART Baud Rate: 9600 UCSRA=0x00; UCSRB=0x98; UCSRC=0x86; UBRRH=0x00; UBRRL=0x19; Добавленная строчка в основном цикле: UDR = 'R'; т.е - постоянно посылаем символ R Вот что получаю на самом деле в терминале: %%%%%%%%%%%ýIIIIIIIIIIIùRRRRRRRRRRRò***********ú•••••••••••õIIIIIIIIIIIùRRRRRRRRRRRò©©©©©©©©©©©é•••••••••••õ—%%%%%%%%%%åRRRRRRRRRRRò©©©©©©©©©©©ù•••••••••••õ%%%%%%%%%%%åíIIIIIIIIIIù©©©©©©©©©©©ù***********ú%%%%%%%%%%%ýIIIIIIIIIIIùRRRRRRRRRRRò***********ú%%%%%%%%%%%ýIIIIIIIIIIIùRRRRRRRRRRRò***********ú•••••••••••õIIIIIIIIIIIùRRRRRRRRRRRò©©©©©©©©©©©é•••••••••••õ%%%%%%%%%%%åRRRRRRRRRRRú©©©©©©©©©©©ùŸ**********ê%%%%%%%%%%%åíIIIIIIIIIIù©©©©©©©©©©©ù***********ú%%%%%%%%%%%ýIIIIIIIIIIIùRRRRRRRRRRR Т.е. - как видно символ 'R' он таки передаёт, но помимо него шлется ещё куча всякого мусора. Откуда он берется и как главное с ним бороться? Что уже попробывал: 1. Протестил саму прошивку в VMLAB - все четко, без ошибок, работает как часы. 2. Без контроллера, просто замкнул выводы TxD и RxD, и подал питание на схему - в терминале все тоже работает - переданные байты тутже возвращаются эхом назад. 3. Пробывал менять кварц 8мгц/4мгц, игрался с разными значениями бодрейта - не помогает. Комбинация фьюзов что на меге сейчас (под кварцы 3-8мгц): CKSEL0-3: 1111 SUT0-1: 11 CKOPT 1 (вообще, если это вдруг поможет - сейчас у меня все фьюзы выставлены в 1) 4. Монтаж проверял неоднократно - все в порядке 5. Пробывал также запускать UART использую бит паритета четный/нечетный - все равно мусор не уходит Помогите пожалуйста побороть злостную помеху

Так я уже пробывал =( Попробывал ещё раз - результат тотже плачевный. Никакой реакции. Мне кажется что загвоздка в самой функции ожидания окончания приёма - SPI_SlaveReceive() - на ней программа стопориться и не выполняется От блока питания, что сам собирал там фильтрация есть - всё нормально, думаю затык не в этом. Что самое интересное, как всегда вылезет, что причина в чем то очень простом и возможно банальном =)

Да, я SS посадил на землю - без этого даже кривая передача байта была невозможной

Всё вроде делаю правильно, а нужного результата не получаю. Попробую собрать всё в кучу, и описать что получается. Итак на данный момент код прошивки такой: #include <mega16.h> #include <io.h> #define DDR_SPI DDRB #define DD_MISO PORTB.6 void SPI_SlaveInit(void) { /* Set MISO output, all others input */ DDR_SPI = (1 << 6); /* Enable SPI */ SPCR = 0x40; } unsigned char SPI_SlaveReceive(void) { /* Wait for reception complete */ while(!(SPSR & (1 << 7))); /* Return data register */ return SPDR; } void main (void){ SPI_SlaveInit(); DDRA = 0xFF; while (1){ //SPI_SlaveReceive(); PORTA = SPDR; } } Как в реальности работает этот код: 1. МК запускается (светодиоды выключены) 2. Я посылаю байт на МК (светодиоды выключены) // Т.е - по сути ничего не происходит 3. Если я делаю RESET то на светодиодах появляется переданный в пункте 2 байт (PORTA = SPDR;) // Значит всё таки хоть и как-то криво, но байт передается 4. Если после пункта 3 (когда горят светодиоды), я посылаю ещё раз байт на МК - то всё снова гаснет, и отобразится лишь при следующем перезапуске Ещё стоит заметить, что в коде я закомментировал и не использую процедуру ожидания завершения передачи байта (из даташита): unsigned char SPI_SlaveReceive(void) { /* Wait for reception complete */ while(!(SPSR & (1 << 7))); /* Return data register */ return SPDR; } Путем отладки - выяснил, что условие while(!(SPSR & (1 << 7))) - никогда не будет пройдено => ничего не произойдет Вот такая вот загогулина