Waso

Приветствую! Встала задача собрать драйвер для СВЧ модулятора, который работает на двух pin-диодах. VD1, VD2 на прилагаемом рисунке - это они. Прямой ток через диод - 20мА, напряжение 0.8В. Нужно обеспечить скорость переключения диодов (фронт) не более 100 пикосекунд. Нужна также функция отключения, когда выход буфера переходит в высокоимпедансное состояние. Сразу подумалось о драйверах лазерных светодиодов. Пошарил на сайтах TI, ADI, Micrel. Не могу определиться с микросхемой. Вообще есть ли драйверы, которые могут тянуть выход и к плюсу и к земле? И как тогда будет выглядеть схема? Кто работал с драйверами лазерных диодов - подскажите пожалуйста!

Вот-вот. Планомерного в смысле запланированного. А насчет второй половины - это у вас такой тонкий сарказм, да? ИМХО у нас и так госзакупки организованы по этому принципу - тупо выделить много денег. Ну а дальше русские умные люди делают то, что делают... ))))

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

Всем привет! Назрел чайниковский вопрос. Вот если у идеального ОУ с двуполярным питанием разница входных напряжений равна нулю, то на выходе будет ноль. А в случае ОУ с однополярным питанием что там будет? Половина напряжения питания?

У меня основная проблема в том, что на один бит ПСП я делаю всего 2 семпла. А у вас получается 512/16 = 32 семпла. Ощутите разницу, как говорится. Если я буду на AVR делать столько семплов даже для 7-битного ПСП, то максимальная скорость передачи полезных данных будет в районе 10bps @ 16MIPS. А мне нужно минимум 1200 поиметь. Вторая проблема - дискретизация. Если сигнал слабый, то на выходе смесителя осциллографом можно разглядеть посылку, но она имеет малую амплитуду и зашумлена. Коррелятор бы ее выдернул из шума. А простой пороговый преобразователь превращает ее в шум. Получается нет никакого толка от кореллятора и ПСП. Поэтому отложу я их освоение до лучших времен. -_-

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

VCC запаралелены. AVCC есс-но отдельно. Но подключив питание только с одной стороны можно поиметь трудноуловимые глюки из-за просадок питания внутри микросхемы при нагрузке (вычислительной в том числе). Такчто будьте осторожны. Я сам так никогда не делал. Это теоретическое предположение. А что запаралелены знаю точно потомучто тестером прозванивал.

megadocent, спасибо за развернутый ответ! В том-то и дело, что длинными пакетами до 255 байт данных + служебная информация. Толи кварцы так врут, толи эффекты в радиоэфире такие случаются, толи погрешность интервалов семплирования у меня набегает - но в реальных условиях если синхронизироваться только по старту длинного пакета, то к концу синхра теряется. Поэтому надо периодически корректировать номер семпла. Меня Баркер привлек своей АКФ и тем что применение псевдослучайных последовательностей позволяет искусственно увеличить чуствительность приемника. Т.е. выделять сигнал при меньшем SNR. Но, как видится теперь, это лучше всего работает при анализе аналогового сигнала с приемника. А у меня данные с радиомодуля выходят в двоичном виде. 0 и 1. Буду применять манчестер и оверсемплинг - это классика в моей ситуации. Если кому понадобится - погуглите "Oversampling and data decision". Мне этот труд был известен и ранее, но хотелось попробовать Баркера. :)

А на эти вопросы может ктонибудь ответить? Я не думаю что они слижком дурацкие и описаны в любой литературе, потомучто там теория...

К сожалению в разделе цифровой обработки сигналов эта тема не вызвала какой-либо реакции, поскольку тамошние обитатели видимо работают только с нормальным, годным для ЦОС железом... Что-ж, поищу счастья здесь. Дело такое - я в очередной раз изобретая велосипед (радиомодем) на дешевой рассыпухе (мега16 + DP1203) пытаюсь выжать максимум скорости и надежности. Да, я знаю что в DP1203 есть неплохой BitSyncronizer и даже встроенный тормозной Баркер, но мне их мало. Потомучто мне нужно уметь определять "стирания" (когда очередной бит не был обнаружен вовремя из-за помехи) для того чтобы потом восстанавливать пакет по кусочкам. Как я сделал - беру 7-битную поледовательность Баркера (чирп): 1110010. Приемник опрашивает ногу в два раза чаще чем передатчик выставляет биты чирпа. В приемнике есть два сдвиговых регистра, в них данные со входа поступают по очереди. Это сделано с тем расчетом, что например четные семплы могут попасть на область фронта, тогда нечетные гарантированно "смотрят" на "полочку". Коэффициенты корреляции просчитаны и записаны в табличку, т.е. для 7-битной последовательности это массив из 128 байт, каждый элемент которого представляет количество совпадений бинарного представления номера ячейки с последовательностью Баркера. По каждому прерыванию таймера я достаю из этой таблички результат корреляции простейшим образом result = corr_table[shiftreg]. Когда этот коррелятор выдает 0 - значит принят закодированный 0, если выдает 7 - принята 1. Принятый бит задвигается в буфер данных, таймер таймаутов сбрасывается. Если таймер таймаутов достигает максимума, то записывается бит в буфер стираний. Затем при повторной посылке пакета буфер стираний используется для копирования гарантированно принятых битов данных. Таким образом даже в довольно зашумленном окружении за несколько попыток можно восстановить пакет данных. Я попробовал изменить верхний и нижний пределы коррелятора на 1 и 6, т.е. 0 или 1 - принят "0", 6 или 7 - принята "1". Т.е. разрешил случаться одной ошибке в последовательности Баркера. Тогда коррелятор стал довольно часто выхватывать ложные комбинации из шума и даже иногда "проскальзывать" внутри посылки. Но тогда нет смысла в корелляторе - можно было тупо сравнивать регистры с кодом Баркера. Думаю что если даже взять 11-битную последовательность, то с одной ошибкой она возможно еще будет работать, а с двумя - уже нет. Тогда в свою очередь нет смысла и в свойствах Баркера. Можно брать Манчерстер и делать оверсемплинг с тем-же результатом. Получается Баркер имеет смысл только в случае использования честной корреляции на мощных DSP. Мучает мысль что я гдето сильно перемудрил. Кто делал кодеки Баркера на АВР - подскажите где я не прав? Спасибо.

ой. 2 раза улетело... Господа администраторы, удалите это сообщение, пожалуйста.

Просветите пожалуйста, как на практике в деталях (в железе) работает корреляция. С теорией я знаком - умножая корреляционную функцию на сигнал мы получаем максимум в точке их совпадения. И вот я в очередной раз изобретая велосипед (радиомодем) на дешевой рассыпухе (мега16 + DP1203) пытаюсь выжать максимум скорости и надежности. Да, я знаю что в DP1203 есть неплохой BitSyncronizer и даже встроенный тормозной Баркер, но мне их мало и я пришел именно в этот раздел ЦОС с вопросами по ЦОС. Так вот. Я беру 7-битную поледовательность Баркера (чирп): 1110010. Приемник опрашивает ногу в два раза чаще чем передатчик выставляет биты чирпа. В приемнике есть два сдвиговых регистра, в них данные со входа поступают по очереди. Это сделано с тем расчетом, что например четные семплы могут попасть на область фронта, тогда нечетные гарантированно "смотрят" на "полочку". Или наоборот - четные на полочку, нечетные - на фронт. Или оба на "полочку" - тогда оба регистра дадут максимум корреляции в соответствующий момент. Результат корреляции просчитан и записан в табличку, т.е. для 7-битной последовательности это массив из 128 байт, каждый элемент которого представляет количество совпадений бинарного представления номера ячейки с последовательностью Баркера. Когда этот коррелятор выдает 0 - значит принят закодированный 0, если выдает 7 - принята 1. Принятый бит задвигается в буфер данных, таймер таймаутов сбрасывается. Если таймер таймаутов достигает максимума, то записывается бит в буфер стираний. Затем при повторной посылке пакета буфер стираний используется для копирования гарантированно принятых битов данных. Таким образом даже в довольно зашумленном окружении за несколько попыток можно восстановить пакет данных. Я попробовал изменить верхний и нижний пределы коррелятора на 1 и 6, т.е. 0 или 1 - принят "0", 6 или 7 - принята "1". Т.е. разрешил случаться одной ошибке в последовательности Баркера. Тогда коррелятор стал довольно часто выхватывать ложные комбинации из шума и даже иногда "проскальзывать" внутри посылки. Но тогда нет смысла в корелляторе - можно было тупо сравнивать регистры с кодом Баркера. Думаю что если даже взять 11-битную последовательность, то с одной ошибкой она возможно еще будет работать, а с двумя - уже нет. Тогда я и задумался о том, как же работают корреляторы в нормальных DSP. 1. В каком виде анализируется поток данных - в аналоговом (с выхода смесителя подаем на АЦП), или в цифровом (после смесителя стоит скажем триггер Шмидта, а с его выхода уже двоичный сигнал поступает на DSP) ? 2. Сколько семплов приходится на один битик Баркеровской последовательности? 3. Наверное DSP всетаки делают честную свертку - умножают и складывают. Умножают и складывают. ? 4. Какой уровень погрешности допускают нормальные корреляторы? Если есть возможность делать С семплов на бит, а сама последовательность Баркера N-битная, то максимум коррелятора равен N*C. При достаточно большом С можно вводить погрешности равные или больше N. Верно рассуждаю?

prototype, большое человеческое спасибо Вам за развернутый ответ! Я думаю что если собрать множество субъективных мнений, то из них можно выделить объективную часть.

Нехочу начинать новую тему. Интересует сабж. Но в этой к сожалению так и не сравнили CADSTAR c Altium. Больше спорили про Ментор. Есть такие кто пользовался и CADSTAR или СR-5000 и Altium и могут поделиться впечатлениями? Сам я пользую АД, и доволен его рюшечками, но при подготовке КД приходится пользовать сторонние программы. Это маленько напрягает... Ментор показался слижком угрюмым, но раз уж он такой профессиональный - не буду ругаться - наверное я просто еще не дорос до него.

Снижение максимальной частоты работы ноги приводит к сглаживанию фронтов и сужению спектра. Кароче наводок меньше будет испускать. ЭМС лучше. Насчет битовых масок - да, программисты, пишушие на языках высокого уровня надеются на разумность компилятора. Это дает легко переносимый код. Кому хочется выжимать все соки из проца - те пишут на ассемблере. Но это, ИМХО, они делают ради собственного удовольствия. А кто деньги зарабатывает - не тратят время на возню с асмом. Ну кроме критичных мест, разумеется.

Сдох MT-Link. Незнаю что стало причиной, но при включении светик не мигает и винда выдает сообщение о неизвестном устройстве. Разрезал "корпус". Замкнул джампер ERASE. Включил-подождал-выключил. Замкнул джампер TEST. Включил-подождал-выключил. Встроенный загрузчик SAMBA-BOOT должен был скопироваться в начало флеша. Запустил SAM-PROG. Включил. Не видит. Значит проц сдох окончательно. Проц заменить не проблема, но прошивку я всеравно не получу, как я понял... Выбрасывать теперь только чтоли? ='( Еще вопрос. В шкафу лежал пылился атмеловский SAM-ICE. У меня есть крякнутый драйвер JLinkARM_V336a, который позволяет юзать SAM-ICE с другими процами, но он не поддерживает STM32, которые мне надо прошивать "вчера". Может есть вылеченные дрова поновее? ========================================================================== Отпишусь как вышел из положения. Нашел тему с исходниками MT-Link Тестером и глазами убедился что сигналы по ногам проца распределены у SAM-ICE J-Link u MT-Link одинаково. Перешил SAM-ICE-у мозги, потом он обновился до последней версии (4 с чемто) - работает. Танцы с бубном при перешивке можно найти здесь. НА МТ поменял проц. В наличии был sam7s256. Цоколевка одинаковая, и памяти побольше. Прошился, и определяется системой. Когда запускаешь отладчик - предлагает обновить прошивку. До версии 336 обновляется успешно. А 408 и старше - умирает на шаге 'Waiting new firmware to boot'. Больше не определяется системой. Только перешивка SAM-PROGом по новой. У МТ линка кроме проца попортился выходной буфер - на TCK выдает очень слабый сигнал. За новым буфером в магазин идти лениво. Такчто пока забросил его на дальнюю полку. Вот думаю с чем связан глюк при обновлении версии. Неужели с жирной памятью? Или горелые буфера както влияют?

Попытался адаптировать библиотеку Чижова под STM8. Изменения коснулись только файлов ports.h и atomic.h. Работа с битами в выходном регистре оптимизируется компилятором хорошо, а вот конфигурирование ведет себя так, будто не все известно при компиляции. static void SetConfiguration(DataT mask, Configuration cfg) { if((cfg==Out)||(cfg==OpenDrainOut) ||(cfg==Out2Mhz)||(cfg==OpenDrainOut2Mhz) ||(cfg==Out10Mhz)||(cfg==OpenDrainOut10Mhz)) {ATOMIC DDR::Or(mask);} else {ATOMIC DDR::And(~mask);} if((cfg==InPU)||(cfg==InPUIRQ) ||(cfg==Out)||(cfg==Out2Mhz)||(cfg==Out10Mhz)) {ATOMIC CR1::Or(mask);} else {ATOMIC CR1::And(~mask);} if((cfg==InIRQ)||(cfg==InPUIRQ) ||(cfg==Out)||(cfg==OpenDrainOut10Mhz)||(cfg==Out10Mhz)) {ATOMIC CR2::Or(mask);} else {ATOMIC CR2::And(~mask);} } Это часть класса, связанная с конфигурацией. В итоге все эти условия так и лезут в кристалл. Что я делаю не так? Прикрепил весь проект в ИАР. Посмотрите пожалуйста. testpult.zip

Частота меандра прыгает примерно от 1кГц до 100кГц. Скважность от 2 до 5, меняется вместе с частотой. Результат я должен выдавать с частотой всего 50Гц. Думаю входной сигнал меняется не быстрее. Только что подумал что неплохо бы как-то синхронизоваться с изменениями сигнала.. Но оставим пока этот вопрос. АЦП 12-битный, семплирую с частотой 256кГц чтобы потом легко было делить на 256. Скользящее среднее как я понимаю уберет высокочастотный шум, а мне мешает наоборот низкочастотный. Тоесть мой полезный сигнал иногда накладывается на мощные по амплитуде низкочастотные (сотни Герц) колебания, не синусоидальные, которые как раз и дают левые палки в спектре даже на моих частотах. Еще бывает пролетают какие-то цифровые посылки. Они коротенькие, но тоже вызывают дрожание спектра. От этого можно избавиться вычисляя среднее по спектру во времени. Нафик это надо я незнаю. Держат в секрете. Хотя вроде бы и не военная разработка.

День добрый! Стараюсь не вмешиваться в полемику, поскольку в этой области я полный дилетант. Насчет известности исходного сигнала - не понятно. Я по Фурье вычисляю максимальный бин и по нему считаю частоту известной. Теперь еще надо найти скважность. И выдать ее в цифровом виде, а там уже заказчик извлекает свою информацию из частоты и скважности. Можно ли считать опорным сигналом меандр с полученной частотой? В двух словах - что даст фильтр Винера в частотной области?

Вообще нужно анализировать только спектр. Но в принципе доступ к данным АЦП тоже есть.

Это интересный вариант! Спасибо. Ну оно так по ТЗ надо. Да и по другому легче не получится. Потому что сигнал плавает по амплитуде, шумы иногда бывают и посильнее... Так что тут как-то просто так фронты не выцепишь... Вернее выцепишь много лишнего. А так - знаешь примерно свою частоту. Ищешь в спектре там палку, от нее определяешь первый минимум и готово. Научиться чистить спектр и будет счастье!

Вот именно, что функция от скважности. Получается я должен задать несколько форм огибающих - для каждого возможного значения скважности - и проводить анализ с каждой формой. Потом искать среди них максимум. Очень медленно получается. Или есть способ попроще? Я просто не очень знаком с корелляционными методами... Насчет энергетической оценки - надо попробовать, но мне кажется что шумы тут тоже попортят всю малину... У меня уровень шума сравним с уровнем сигнала, но присутствует не всегда. Помехи - цифровые посылки на соседних частотах.

Имеется радиосигнал, модулированный прямоугольными импульсами переменной скважности и немного зашумленный. Сигнал подвергается 2048-точечному БПФ и по полученному спектру я должен определить текущую скважность сигнала. Если смотреть на спектр чистого импульсного сигнала, то первый минимум огибающей (который рядом с максимумом) соответствует частоте, обратной величине ширины импульсов. Я пока написал дубовый алгоритм, который перебирает кратные гармоники и приблизительно определяет этот минимум. Но когда в сигнал добавляется шумок, спектр начинает дрожать. Основная частота определяется четко, а вот по скважности моя програмулина начинает давать шнягу... Подскажите, пожалуйста, как решить эту задачу грамотно. По идее надо делать корреляцию с ожидаемой функцией огибающей, но огибающая же плавает....

Судя по ERRATA-м (0_о OMG! WTF! сколько там ошибок!) у них ревизии идут в обратном алфавитном порядке (см. таблицу Product evolution) : 1. Z 2. Y 3. X .... PS Особенно меня забавляет строчка "Not fixed (no fix planned)"

Спасибо. Каюсь. Грешен. Ненавижу читать стандарты... Уже в который раз я удивляюсь - каким чудом работали мои предыдущие программы??...