arhiv6

Я бы попробовал добавить пару блокировочных конденсаторов по питанию, по 1000пФ . Там у вас стоят два штуки 180пФ, но с МШУ они по земле соединены не напрямую, а через via.

Розе использовать не нужно. Для пайки чего-нибудь на керамике, есть специальные низкотемпературные припои, например ПОСК50-18. В ТУ на этот фильтр его тоже указали как один из рекомендованных.

Я бы не стал так делать. Линейность ухудшится точно, по шуму проигрыш будет. Лучше просто уменьшите значение аттенюатора до -8.7дБ, чтобы Kp тракта до входа модема стал +12дБ (и эту же настройку выставьте в регистре AGCMAP). Шум тракта получится 1.62дБ. Программа самописная, RxCalc, скачать можно здесь: https://sourceforge.net/projects/rxcalc/files/ А вообще эти расчёты (RF budget analisys) можно так же делать в ADISimRF , AppCad и даже простой RFcalc немного умеет. Третья строка снизу: вы взяли шум от двух компонентов (фильтр+МШУ), а усиление только от МШУ.

Не совсем понятно, чем симметричный не угодил. Вместо 50/50 Ом по входу/выходу у несимметричного 18.9/53 Ом по входу/выходу. В блок схеме не учтён аттенюатор. Он (любой пассивный элемента тракта) не просто уменьшает Kp тракта, он так же в тракт добавляет собственный тепловой шум. Т.е. считать нужно не так: а вот так: Ну и вариант без аттенюатора - Кш лучше почти на 1 дБ (разумеется, в ущерб динамике приёмника):

Не думаю, что для МК есть готовое решение, но его можно собрать из готовых. Если я правильно понял, нужен функционал: 1) console_shell, т.е. возможность в интерактивном режиме вводить команд (+история, автодополнения). Для МК есть из чего выбрать, например https://github.com/funbiscuit/embedded-cli 2) tcl_shell, т.е. запуск интерактивного TCL интерпретатора. Прямо на странице сайта TCL есть подборка его легковесных легковесных реализаций. Из подходящего для МК там есть ParTcl (github, статья). 3) исполнене tcl команд и запуск tcl_shell из console_shell. Это можно сделать так: в составе ParTcl есть интерпретатор, способный сохранять состояние между вызовами. Вот простейший пример как в embedded-cli завести две команды: tcl (вызов интерпретатора и передача ему аргументов команды) и tcl_shell (запуск интерактивного интерпритатора из примера ParTcl). Код: Вот что в консоле можно сделать: выполнить две TCL команды из console_shell (присваивание значений переменным), затем запустить интерактивный TCL интерпритатор и в нём выполнить суммирование переменных:

А сколько вы хотите? Вот есть такой фильтр -0,73дБ на 440Мгц, на ваших 433МГц у него -1,1дБ. Можете у них же заказать аналог на ваши частоты.

Понял, я думал это что-то внутри видно, а это просто внешний корпус вдавлен, тем самым образуя "резьбу". Я до этого видел немного другую конструкцию, где корпус резонатора без этих следов резьбы:

А есть фото, что внутри у этих фильтров? Если внешний корпус - это резонатор, то как он работает с такими вырезами, через которые видно спираль (или что это там за витки внутри)?

Не исключено, что PeakTech тоже генераторы покупает в Китае где-то. Потому что в таком корпусе ещё есть: LUMEL: https://www.lumel.com.pl/en/catalogue/product/signal-generator-ha-gfa005 Shijiazhuang Suin Instruments: https://www.suindigital.com/rf-signal-generators/synthesized-signal-generator.html

Если полосок залудить - будет хуже. На таких частотах из-за скинэффекта токи почти по поверхности текут, и увеличение толщины за счёт припоя лучше не сделает. А проводимость припоя хуже, чем у меди. Для таких цепей снимают маску и платы с покрытием золотом применяют. Землю - можете лудить, эффекта это не дист никакого.

Логотип производителя Brightking (их купила Yageo), диод SMBJ85CA.

В С99 есть Compound Literals, которые в gcc и clang поддерживаются и для С++ : func((int[]){1, 2, 3});

Добрый день. Как-то выключил управление отображением слоя BOT на одной плате. В "Layers & Colors" значок "глаз" стал серым, на нажатия левой кнопкой мыши не реагирует. Как его разблокировать? С другими платами проблем нет. Alium 20.2.6.

Где разделительный конденсатор по входу? Для проверки усилителя добавьте его и отключите все что на схеме справа от конденсатора С9, оставите только нагрузку 50 Ом.

Разделительные и блокировочные конденсаторы есть? Центральный пад пропаян? Выкладывайте схему и трассировку.

Кажется, у некоторых пользователей звание теперь дублируется. Так и должно быть?

Рано новость выкатили, нужно было до 1 апреля придержать.

Чтобы снимать с солнечной батареи энергию эффективно, не достаточно просто подключить к ней напрямую нагрузку или аккумулятор. Ключевая фраза для поиска "MPPT контроллер". У TI есть готовые микросхемы, которые сочетают в себе как MPPT контроллер, так и контроллер для заряда буферного аккумулятора на одну или несколько ячеек. Вот список, выбирайте подходящий под свои требования (тип аккумулятора, количество ячеек, мощность нагрузки, напряжение солнечной батареи).

Можете пояснить, как тут применим болометр? Или это опечатка и имелось в виду что-то другое?

Но это не значит, что добавлением МШУ с усилением 50дБ получится изменить чувствительность с -90дБм до -140дБм. Давайте попробуем посмотреть, как изменится чувствительность приёмника при добавлении двух CMD263P3. Т.к. входных данных слишком мало (не хватает значения ширины полосы приёма (демодуляции) и текущего значения Кш приёмника), попробую поугадывать. Текущая чувствительность -90дБм реализуема при следующих возможных вариантах ПП/Кш: 200МГц/1дБ, 20МГц/11дБ, 2МГц/21дБ, 200кГц/31дБ, 20кГц/41дБ, 2кГц/51дБ, 200Гц/61дБ и т.д. Для первого варианта добавлять МШУ бессмысленно, Кш приёмника только ухудшится (станет 1.41дБ). Для второго варианта и далее чувствительность станет соответственно: -99.44дБм, -109.42дБм, -119.28дБм, -128.09дБм, -132.79дБм, -133.73дБм. Если дальше так же продолжать, всё равно упрётесь примерно в -134дБм, ниже с такими МШУ никак не получить. Вот, я для себя когда-то калькулятор писал https://sourceforge.net/projects/rxcalc/files/RxCalc-0.6.8_installer.exe/download Он помогает оценить динамику, чувствительность приёмника и т.д. Попробуйте сами в нём свой тракт собрать. Вот пример расчёта для варианта 20МГц/11дБ:

Это обычный планировщик задач, где каждая задача это run-to-complete функция, которая вызывается по какому-то событию. Сам когда-то подобный использовал и знаю как минимум одну ОС, которая работает с таким типом задач (uSmartX). Из плюсов такого подхода - минимальное потребление ресурсов и лёгкость портирования (никакого знания ассемблера не требуется). Из минусов - подходит только для простых задач: как только в задаче потребуется после какого-то события (даже обычный вызов delay()) не перезапускать задачу заново, а продолжать выполнять какую-то её логику, то задачи привычнее и проще для понимания писать в непрерывном стиле, как это делается на "взрослых" ОС. Как пример, что проще для понимания, псевдокод задачи из run-to-complete планировщика: void task_blink() { static uint8 led_state = 0; if (led_state == 1) { led_off(); led_state = 0; task_restart(task_blink, 500); } else { led_on(); led_state = 1; task_restart(task_blink, 100); } } или привычный линейный код: void task_blink() { while(1) { led_on(); delay_ms(100); led_off(); delay_ms(500); } } И там и там обычное мигание светодиода на 100мс с паузой 500мс, но второй код гораздо проще для понимания. Язык Си позволяет такое реализовать на основе Duff's device. При этом остаются те же достоинства планировщиков (минимальные ресурсы, общий стек, лёгкость портирования из-за отсутствия ассемблера) но разработка задач упрощается. Поэтому есть несколько кооперативных ОС, построенных на этом принципе: cocoOS, DemOS (+ protothreads как самая упрощённая, но рабочая реализация). ТС, если поймёте, что своего диспетчера вам уже недостаточно, но есть какие-то опасения для перехода на FreeRTOS, рекомендую их попробовать. С ростом сложности ваших проектов если упрётесь в их ограничения тогда уже осознанно перейдёте на вытесняющую ОС с раздельными стеками для каждой задачи, но уже с минимальными переделками своего кода.

Сначала берётся с запасом, потом реальное использование памяти каждой задачей можно уточнить (параметр usStackHighWaterMark из структуры TaskStatus_t, которую можно получить из vTaskGetInfo()). Вот статья про это: https://habr.com/ru/articles/352782/ там пятый раздел "Мониторинг использования ресурсов". Кроме того, есть варианты ОС без выделения отдельных стеков для каждой задачи: начиная от protothreads и их производных, заканчивая теми же Co-Routine из состава FreeRTOS.

Зачем такое делать вручную, если специально для этого существуют стилизаторы кода? Попробуйте Astyle, он очень простой в использовании. Выберите готовый стиль, похожий на свой (что-то вроде --style=kr ), потом при желании можно под себя его донастроить. Уверен, для notepad++ есть плагины для работы с astyle. Но даже если нету - то можно простой макрос сделать, который будет вызывать astyle для текущего файла по какому-нибудь сочетанию клавиш.

Как минимум, у MA35D16F987C рабочий диапазон от -40.

Harwin S1711-46R или S0951-46R + крышка подходящего размера из их серий S01-*, S02-*, S03-* или согнуть самому из резанной жести. Вроде Harwin не дефицит, что-то даже в ЧипИДип-е есть.