fxr

Благодарю за разъяснение, общий принцип теперь понятен. Поскольку в даташите рекомендовано использовать резистор R1 меньше 4.17К, я поставил 1.02К. Значения для резисторов подбирал методом подгонки исходя из доступных номиналов. Приемлемы ли выбранные значения для R1 и R2? Также прошу проверить, верна ли формула и мои расчеты? Vout=1000/(1+(R2/R1)+(Iadj)*(R2)) R1 - 1.02K R2 - 37.4K Iadj - 1.21V Действительно стаб отличный, спасибо за подсказку! При всем уважении, но выходное напряжение в данном стабе задается резисторами ;) Почему называете его Ripple Blockerом, ведь по сути это линейный стабилизатор, а не специализированная микросхема? Извините, но я такого рисунка не вижу(

Прошу извинения за тупость, даташит конечно же смотрел, просто путаюсь с расчетами по формуле и вычислением значения R2. VOUT=1000/(1+(R2/R1))+(12*R2) А какая есть альтернатива Silent Switcher с низким уровнем пульсаций?

Относится ли утверждение насчет значения номинала R1 к линейному стабу от линеаров LT1764 (ADJ) или только к серии Silent Switcher? Как будет выглядеть формула расчета делителя для этого стаба 12В?

Огромное спасибо! Silent Switcher интересен, надеюсь что он действительно обеспечит низкий уровень пульсаций и ЭМИ.

Никак не пойму как правильно рассчитать номиналы для R1 и R2 для выходного напряжения 12В. Рассчитывал по формуле из даташита, но получаемые значения явно не верны. Прошу помочь разобраться в расчетах.

Объем потока не лицензируется, а лицензируется лишь частота линии пропускания. Например новый WiFi передает на частотах до 6 GHz и способен обеспечивать поточную передачу до 9.6 Gbps. Но скорее всего такая скорость передачи данных от датчиков избыточна, я указал максимальную возможную скорость считывания с них информации. Каждый нод имеет свой уникальный номер и регистрируется в начале сеанса связи. Думаю применить классическую схему с рекурсивным опросом датчиков. Верно подмечено ;) Немного поспешил с вопросом, сейчас как раз рассчитываю требуемую частоту и скорость передачи данных. Если кое что оптимизировать на стороне датчиков и NRF24L01 вполне может хватить.

Спасибо, посмотрю. Лучший способ синхронизации был бы запрос-ответ для каждого датчика, но в этом случае получим слишком большую задержку. Каким способом предполагаете разделять по времени? Еще рассматриваю Блютуз ЛЕ, там вроде бы можно работать параллельно с несколькими трансмиттерами. В плане минимального потребления и много поточности ZigBee интересная железка, но скорость слишком низкая.

Приветствую! Имеется датчик с которого МК считываются данные с максимальной частотой до 20 МГц. Требуется передать полученные данные по воздуху на принимающее устройство на расстоянии до 20 метров. Пока выбор пал на NRF24L01, скорость передачи (250 kbps up to 2 Mbps) вполне удовлетворяет, но потребление высоковато. Прошу посоветовать трансивер с более низким потреблением энергии. UPD Еще не устраивает ограничения в объеме передаваемой информации в пакете - всего 32 байта, желательно иметь ~256 байт. Также непонятно справится ли ресивер с одновременным приемом от нескольких передатчиков (3-10 шт.). NRF24L01 не способен одновременно принимать более одного сообщения даже если они приходят по разным каналам.

Про LTspice услышал и опробую при первой же возможности. Верно ли я понял, что LTspice и HyperLinx предназначены для решения разных задач? Т.е. вначале делается отработка прохождения сигналов в LTspice, затем разводится дизайн платы и после симулируется в HyperLinx? Кстати, возможно ли конвертировать библиотеки от других ХХspice программ в LTspice? А разве Altium Designer позволяет проводить симуляцию как в HyperLinx?

Было бы интересно посмотреть на форму сигнала при условии параллельного согласования на стороне приемника. В какой программе проводите симуляцию?

Я ни в коей мере не приуменьшаю достоинства анализа с применением IBIS моделей, а только уточняю что не все можно просимулировать достоверно. Но с симуляцией сигнальных трасс уж явно проблем быть не должно) Было бы очень интересно увидеть кусок трассировки этих банков памяти. В голове не укладывается что такая разница по шумам может образоваться только за счет трассировки шины данных. Может быть в первом варианте трассировки фильтрующие конденсаторы стояли слишком далеко? Что послужило причиной?

Хочу поблагодарить сообщество за участие в обсуждении! Некоторые советы оказались действительно полезными. Особенно мне понравилась идея по поводу симуляции в HL. Однако, судя по всему, симуляция тоже не дает достоверной картины, во всяком случае не по всем вопросам. И вот что сказано в Вики по поводу IBIS моделей (да простит меня сообщество за пристрастие к этому ресурсу) с помощью традиционной модели IBIS невозможно промоделировать буфер с реальной системой питания и заземления, возникают большие трудности с моделированием шумов одновременного переключения и дифференциальных буферов. Более того, представление корпуса микросхемы в виде сосредоточенных ёмкости, индуктивности и сопротивления хорошо работает лишь в определенном, не очень высоком диапазоне частот. Источник - https://ru.wikipedia.org/wiki/IBIS

Ну ребята, вы и жжете. Термина́тор, согласователь — поглотитель энергии (обычно резистор) на конце длинной линии, сопротивление которого равно волновому сопротивлению данной линии. Применительно к электронике слово «терминатор» используется в основном в компьютерном жаргоне, терминологичным синонимом ему является выражение «согласованная нагрузка». Терминаторы применяются на всех линиях, соединяющих передатчик и приёмник сигнала, когда отраженный от конца линии сигнал значительно влияет на работу линии связи. Источник - https://ru.wikipedia.org/wiki/Терминатор_(электроника)

В каком центре обучения можно посмотреть эти раскошенные видеоролики? На Ютубе нашел коротенький ролик где за 2.5 минуты демонстрируется техника согласованию сигнальной трассы. Класс, все наглядно и понятно Согласно различным источникам, лучшим способом согласования линий является не последовательное терминированние, а все же параллельное на стороне нагрузки. Этот же способ применяется и в осциллографе. Единственным недостатком такого способы согласования является то, что источник должен выдавать сигнал достаточной мощности. Например, для согласования длинной трассы от кв. генератора может потребоваться последовательный драйвер/буфер. Вот например аппноут на согласование сигналов тактовой частоты - https://www.ctscorp.com/wp-content/uploads/2015/10/AN1025.pdf

Последовательное согласование может делать делаться как на стороне источника, так и на стороне приемника, а также на обеих сторонах. Я в командировке, под рукой из инструментария есть только планшет на андройде, даже на LTSpice промоделировать пока нет возможности. Промоделирую как доберусь до нормального компа, а пока хотел разобраться в теоретических вопросах. А именно, мне совершенно не ясно в каких случаях применяется та или иная схема согласования. Длина линии: 180мм, длительности фронта/среза: 2.5нс Разве не нужно учитывать токовые и емкостные характеристики входного и выходного затворов? Какой смысл в просмотре обучающих роликов по HyperLynx если он все равно платный?