Jump to content

    

Rst7

Модераторы
  • Content Count

    4412
  • Joined

  • Last visited

Everything posted by Rst7


  1. Так речь же о том, что выходное сопротивление эквивалентного источника (который суть УМЗЧ с Rвых стремящееся к 0 + Ваш делитель из резисторов) становится сильно больше нуля. Если ухом Вам не слышно - возьмите измерительный микрофон. Мало того, что будет подъем на резонансе, так еще и подъем на ВЧ из-за увеличения Z динамика там. А если у Вас многополосная АС с пассивным кроссовером, то все еще усложняется. Меня всегда поражают люди, которые рассказывают про "сцену", "воздух" и прочую фигню, но при этом не слышат изменения АЧХ на несколько дБ. И, повторюсь, фотографии комнаты, в которой это все прослушивалось - в студию. Для работы с АЧХ системы этого вполне достаточно.
  2. Да запросто. Вы же забрели на инженерный форум. Критика тут может быть только одна: без двойных слепых тестов - это все так, аудиофилия головного мозга. И даже черт с ними, можно и без них. Я не знаю, чем Вы там слушаете, но не услышать подъема НЧ на резонансной частоте из-за увеличения выходного сопротивления усилителя может только глухой. Либо у Вас там помещение имеет такую кучу паразитных резонансов, что бубнеж на резонансе АС просто теряется среди стояков в комнате. Фотографию КДП слабо показать?
  3. Так схема с одним ОУ не годится для заземленной средней точки. Надо два ОУ и брать разность. Просто я схему нарисовал до того, как узнал, что средняя точка заземлена. Но если уж рассматривать схему с одним ОУ, то проблемы с НЧ-наводкой возможно непринципиальны по той причине, что берутся два отсчета рядом и разность между ними. НЧ помеха будет подавлена во столько раз, во сколько ее частота ниже частоты семплирования. Да и "синфазные НЧ-наводки из канала возбуждения" - это нечто мифическое, ведь канал возбуждения - это генератор напряжения. Другое дело, что обычные 50Гц могут через емкостную связь проникать в суммирующую точку - это да. Но точно так же они могут проникать и в суммирующую точку двух отдельных усилителей. Причем, с разным уровнем. А вот тут в дело вступает другой момент в схеме с заземленным измерительным конденсатором. Это емкость монтажа с суммирующей точки на землю. Она прибавляется к измеряемой емкости. Насколько эта емкость стабильна - это отдельный вопрос. А вот схема с плавающей емкостью не имеет такой проблемы (ну пока там емкости на землю более-менее адекватны), потому может быть очень хорошо заэкранирована. Очень занятно. Надо будет поизучать на досуге.
  4. Ну да, если средний вывод заземлён - то железа надо больше. Правда, по варианту с заземлённой ёмкостью тоже делали, и подавали меандр, ничего там не возбуждалось (надо не забывать небольшой резистор возле инвестирующего входа до измеряемой емкости), но есть нюанс - у Вас на выходе будет сумма полезного сигнала и сигнала возбуждения. Так что лучше возбуждать обе стороны синфазно, тогда разница будет именно чистым полезным сигналом.
  5. Вот как-то так. Осциллограммы в уже устоявшемся режиме. Смысл фильтра после зарядового усилителя - это ведь почти согласованный фильтр для сигнала (он ведь меандр, а для него согласованный фильтр - это интегратор, а такой ФНЧ - ну в таком приближении более-менее интегратор). Потому при точках семплирования АЦП прямо на фронтах сигнала возбуждения как раз будет измеряться среднее значение за пол-периода.
  6. Ну вот я такое и предлагаю. Только еще резистор в пару мегаом надо включить между выходом ОУ и его инвертирующим входом. И у Вас на схеме слишком уж высокая частота возбуждения, 10МГц - это много. Потому на самом деле на выходе тут не нужный сигнал, а "издержки производства". Щас нарисую, как должно быть.
  7. Вот тут я не в курсе дела, поделитесь для общего развития подробнее, почему ему плохо от меандра?
  8. Все равно не понимаю, зачем именно синусом? Да и квадратурные сигналы там излишество, достаточно только одного канала. В общем, считаю, что ТС'у надо бы немного подробнее рассказать про сами датчики, что они из себя представляют.
  9. По нынешним временам я бы даже особо не раздумывая делал так - сигнал возбуждения на датчик - меандр, после чего просто усиливал зарядовым усилителем до удобного для АЦП уровня, потом бы цифровал с частотой 2Fвозбуждения, и брал разности между двумя соседними выборками. Между зарядовым усилителем и АЦП можно включить RC ФНЧ как псевдо-интегратор, соответственно, выборка АЦП должна происходить в момент переключения полярности сигнала возбуждения. Фильтрация полезного сигнала 5кГц - это уже выполнять в цифре. Прелестей много: а) Зарядовый усилитель позволяет подключить датчик достаточно длинным кабелем без потери чувствительности. б) Упрощается схема возбуждения (логический инвертор вполне подойдет). в) Резко уменьшается количество аналоговой обвязки.
  10. RTL8201

    Ну тогда Вам в стандарт 802.3 - там для Вас будем много новостей в смысле ограничений. На самом деле PHY должен выполнять все требования этого стандарта. А больше он ничего не должен ;)
  11. RTL8201

    Я думаю, что это ответ на Ваш вопрос. Я когда делал давно софтовый MAC, на подобное поведение при отладке наступал. Ограничьте время нахождения в состоянии TX разумным значением (например, соответствующее максимальной длине фрейма Ethernet).
  12. Если вот так сделать, как выше - то все зависит от поведения pvTaskGetThreadLocalStoragePointer. Если его можно позвать не в потоке - то вполне.
  13. Ну Вам просто надо сделать вот что. Вместо int TickCounter; написать #define TickCounter ((int*)pvTaskGetThreadLocalStoragePointer(NULL,TICK_COUNTER_INDEX)[0] И Ваш код заработает. Ну да, надо еще инициализацию сделать в каждом потоке. #define InitTickCounter vTaskSetThreadLocalStoragePointer(NULL,TICK_COUNTER_INDEX,(void*)malloc(sizeof(int))) Тут, конечно, круто использовать alloca() и инитить переменную прямо в стеке, если Ваш компилятор это позволяет.
  14. Если Вы посмотрите на внутренности setjmp/longjmp - то они ничем не отличаются, по-большому счету.
  15. Масса вариантов тогда. TLS какой-никакой есть. Есть Task Tag - тоже можно использовать. Ну и да, опенсорсное ядро вполне можно и пропатчить.
  16. Добавьте переменную __ECBList в область данных ОС, которая хранит состояние текущего потока. Конкретика реализации зависит от типа ОС. Либо храните его в Thread Local Storage (например, та же FreeRTOS поддерживает это). Это может быть даже банальный массив с обращением к нему __ECBList[GetCurrentThreadId()], где GetCurrentThreadId() - функция, которая вернет номер текущего потока. Вариантов масса. Расскажите Вашу конкретику, какая ОС используется?
  17. Moderator: Закрепленный в этом разделе топик что помешало прочитать? Тему перенес.
  18. Конечно. П-296. Вам же не нырять в воду долговременно?
  19. Все равно понадобятся ускорительные цепи, чтобы фронты не заваливать на хоть сколько нибудь длинной линии. Так что "мешок деталей" все равно будет.
  20. Если Вы про "слова производителей" в смысле слов производителей радиомикрофонов и IEM-систем с цифровыми каналами - то они сильно лукавят. Работает это все объективно так себе в реальных условиях, а с учетом негуманного совершенно прайслиста - так и вообще можно сказать, что не работает. Во-первых, никакими моднейшими алгоритмами сжатия с потерями в этих системах и не пахнет. Из-за ограничений по latency плюс предрассудки, царящие в отрасли. Во-вторых, когда в зал в зоне херового покрытия GSM заходит 1000 человек с мобильниками, и все телефоны начинают регулярно пытаться регистрироваться в сети, то наружу вылазят ограничения по линейности приемного тракта до ФСС. Забивает нафиг приемники по входу. И если в случае аналоговых систем там просто пошипит и перестанет, то в случае цифровых - будет мьют, что куда менее приятно.
  21. Все правильно. Заказчик не обязан быть полностью в курсе всех технических тонкостей. А вот разработчик - обязан. Потому именно разработчик формализирует исходные требования, как минимум переписывает их технически грамотным языком, с учетом того, что ему потом буква в букву реализовывать это все придется. Более того, грандмастера этого эпистолярного жанра делают сразу три параллельных документа: а) Техническое задание - потому что, грубо говоря, там написано, что устройство должно делать. б) Технические условия - потому что там написано, что устройство должно делать (это есть в ТЗ) и как это будет проверяться (ведь разрабатывая ТЗ, всегда надо понимать способы проверки, дабы не попали в ТЗ какие-нибудь нетехнические вещи). в) Программа и методика испытаний - потому что там написано, как это будет проверяться (см. пункт про ТУ). Понятное дело, что конкретикой типа "подключить кабель такой-то к разъему X1" документы б) и в) наполнятся только к концу разработки, но все остальное будет готово. И да. За такой эпистолярный жанр надо сразу брать денег с заказчика. 20% от стоимости проекта - это совсем нестыдная цифра для того, чтобы оттолкнуться от чего-то. Если, конечно, делается документ, по которому потом удобно будет работать, а не шопопало абы этап закрыть.
  22. Вы не поверите, но именно разработчик всегда пишет ТЗ на основе исходных данных заказчика. А заказчик его согласовывает. Так было испокон веков у профессионалов. Это только "ойтишнеги" решили, что ТЗ им должен заказчик предоставлять. Ну, собственно говоря, ничего удивительного: IT - это нифига не инженерное дело ;)
  23. Moderator: Точно так же, как и создавать документацию, соответствующую любому другому стандарту, в любой другой САПР. Задавайте конкретные вопросы, иначе снесу тему.