У меня нет классического образования в области радиотехники, но связь представлений сигнала во временной и частотной областях меня сильно интересует. При попытке сформировать в голове ясное представление возникают примерно такие вопросы.
Рассмотрим базовую ситуацию для любого радиоканала.
Передатчик излучает немодулированную несущую (Рис. 1)
Давайте для начала я задам два странных вопроса:
1. Можно ли постоянный магнит «выключить»?
2. Можно ли электромагнит сделать «постоянным»?
Смотря на эти вопросы, не правда ли, возникает ощущение, что здесь всё перепутано? :-)
Как ни странно, нет, и эти вопросы вполне себе корректны! ;-)
В статье ниже, с одной стороны, мы попробуем найти ответы на эти вопросы, а с другой — посмотрим, можно ли это как-то применить в практических целях и извлечь пользу.
Продолжаю публикацию статей по структуре "Умный дом" на основе локальной сети CAN. В этой статье описывается программа, которая записывается в каждый контроллер локальной сети.
Программа написана любителем, не профессионалом, поэтому за ошибки прошу не судить строго. К тому же сам признаю, что стиль написания программы несколько устарел, но переучиваться не хочется да и поздно.
В общем «не стреляйте в музыканта, он играет как может».
Попытался поместить исходный текст программы в статью, но понял что это невозможно из-за большого количества строк программы. Поэтому программу выложил в своем репозитории на github.
И попытался кратко описать основные моменты программы.
Всем привет.
В последнее время стало модно мечтать о замене живых, "мясных" водителей на автопилоты.
Разные гуру технологий нам регулярно обещают, что вот еще буквально уже совсем очень скоро всех водителей переквалифицируют в управдомы, а мы так же охотно об этом грезим.
Естественно, точная дата конверсии постоянно остается за горизонтом.
В этой публикации мне хотелось бы немного пролить свет на одну таинственную загадку: а зачем вообще необходим в машине водитель? Делает ли он что-то, что нельзя поручить бездушным роботам или пилотам на удаленке?
В дальнейших рассуждениях я буду говорить исключительно про мир семитрейлеров, поскольку они отвечают за примерно 60% перевозок, по крайней мере в США.
Помнится, как в своё время (давным-давно), был в школе у нас интересный урок по физике, где объясняли принципы работы электродвигателей, где нас с благоговейным трепетом запугивали: «если вы не знаете «правило буравчика» — то не видать вам постройки своего двигателя!» :-)
Прошли годы, и мне стало интересно, а можно ли создать электродвигатель, к которому это правило имеет весьма отдалённое отношение?
Как оказалось — вполне себе можно и такие двигатели есть, вернее, были! Итак…
Год подходит к концу, а это значит, что время подвести итоги и оценить пройденный путь. Для команды «Нанософт» 2025 год стал периодом системной работы над машиностроительным направлением и развитием продукта nanoCAD Механика PRO.
BIM давно зарекомендовал себя в гражданском и промышленном проектировании. А можно ли использовать информационное моделирование для технологических схем?Демид Сентемов, инженер-проектировщик технологических процессов, разработчик программных решений, ответил на этот вопрос утвердительно. С помощью компонента «СПДС» Платформы nanoCAD и среды API MultiCAD его команда разработала собственный продукт «Промпроектор», предназначенный для создания технологических схем по принципу BIM. Первым пользователем приложения стала компания «РИОС-Инжиниринг», которая уже опробовала новое решение при моделировании технологической схемы для установки реформинга бензина.
Эти станции так и не стали лицом Московского метрополитена. Подземка 90-х, лужковское метро – о нём не пишут в путеводителях, по нему не водят экскурсии. И зря! Рождённая на переломе эпох Люблинская линия сполна хлебнула хаоса, безденежья, безнадёги… и настоящего героизма, о котором тоже не вспоминают. А ещё архитектурных и технологических новшеств. Тридцать лет назад, когда о будущем думать было страшно, «салатовая ветка» предвосхитила будущее столичной подземки – частью ставшее её настоящим, а частью, увы, тоже забытое.
Обязательным условием всех способов повышения помехоустойчивости при передаче информации по зашумленным каналам связи является введение информационной избыточности. Вид избыточности и ее размер определяется используемым способом помехоустойчивого кодирования. Выбор способа кодирования происходит с учетом параметров сигнала и характеристик канала связи: для цифрового канала – интенсивности ошибок, для аналогового канала – уровня шума и помех. Большое значение имеет степень сложности кодирования/декодирования и, соответственно, требуемая вычислительная мощность. Практически во всех корректирующих кодах, обеспечивающих автоматическое исправление ошибок, степень вводимой избыточности определяется способом кодирования и жестко связана с размером кодируемого информационного блока. Поэтому представляет интерес возможность использования избыточности, размер которой регулируется в соответствии с уровнем шума в канале связи.
Тривиальный способ введения избыточности – увеличение длительности сигнала добавлением фрагмента любой длительности и любого содержания, например, нулевого. Это способ фиксирует параметры шума в канале, но не позволяет уменьшить уровень искажений сигнала. Но если избыточность вводить не в сигнал, а в спектр сигнала, результат оказывается другим. При цифровой обработке сигналов широко используется операция интерполяции (передискретизации) – повышение частоты дискретизации. При этом к высокочастотному концу цифрового спектра добавляется нулевой фрагмент требуемой длительности. В результате обратного преобразования Фурье (ОПФ) формируется сигнал, содержащий большее количество отсчетов, то есть, имеющий ту же форму, но более высокую частоту дискретизации. При передаче этого сигнала по каналу связи происходит наложение аддитивного случайного шума. В приемнике в процессе устранения введенной избыточности есть возможность провести усреднение случайного шума и снизить уровень искажений. Проведено моделирование в среде MATLAB этого способа передачи.
История не доносит до нас названия модели, с которой сняли копии китайцы, но, судя по количествам, в которых они тиражируются, прототип был избран верный. Конечно, копии унаследовали все бывшие у оригинала недостатки и дополнили их перлами китайского технического мышления, но есть у этого инженерного однообразия колоссальное преимущество.
В 2012 году перед МТС встала нетривиальная задача: обеспечить питерскую подземку мобильной связью. В дальнейшем этот проект стал одним из самых масштабных в моей карьере. Было важно выбрать оборудование, которое прослужит лет 20–30, смонтировать его, запустить, а также подстроиться по времени выполнения работ в тот небольшой интервал, когда метро закрыто.
Меня зовут Сергей Бородин, я эксперт в отделе развития сети МТС в Санкт-Петербурге. Занимаюсь планированием, реализацией и технической поддержкой систем, обеспечивающих работу мобильной связи внутри зданий и сооружений. Это торговые комплексы, бизнес-центры, аэропорты, стадионы. Итак, под катом — немного фото и мой рассказ, зачем нужна связь в тоннелях и как я накрутил по синей и оранжевой веткам метро 500 километров пешком.
Это вторая, завершающая часть опубликованной ранее на Хабре статьи про MIMO LQR/LQG регуляторы.
В первой части мы синтезировали LQR и LQG регуляторы. При всех достоинствах стандартные LQR (
) и LQG (
) по своей сути являются пропорциональными регуляторами (P-регулятором в терминах PID). Поэтому при наличии постоянного внешнего возмущения система в установившемся режиме (steady state) сходится не к нулю, а к некоторой статической ошибке 
. В этой точке управляющее воздействие 
лишь компенсирует возмущение, но не может вернуть переменную точно к уставке.
Вспомните тяжелые маятниковые двери в исторических вестибюлях метро. Обычно после прохода человека они закрываются точно по дверному проему. Но если включена напорная вентиляция (постоянное возмущение), двери приоткрываются и остаются в таком положении. Пружина (пропорциональный регулятор) уравновешивает давление воздуха, но не может закрыть дверь до конца.
В статье мы рассмотрели несколько подходов к решению этой проблемы и реализовали синтез LQR с расширенным состоянием (Augmented LQR) — метод, при котором в вектор состояния добавляются интегралы ошибок управления.
Как обычно, ссылка на код в конце статьи.
Меня всегда привлекали несколько парадоксальные устройства из техники, которые, не содержат практически ни одной детали, но, в то же время, выполняют свою функцию — по сути своей, они представляют собой идеальное техническое устройство, так как в нём идея минимизации количества компонентов (и максимизации надёжности, соответственно), доведена до абсолюта.
И сегодня мы рассмотрим ещё одно такое интересное устройство... ;-)
Системы управления инженерными сетями, в отличие от самих инженерных систем, редко проектируют с расчетом на десятилетия эксплуатации. Проблема чаще связана не со сроком службы оборудования, а с невозможностью модернизации и отсутствием запасных частей.
В статье разбираем кейс замены автоматики системы отопления в квартире с централизованным теплоснабжением. Исходная система проработала около 15 лет, после чего стала неремонтопригодной.
Тем не менее выход существует. Покажем, как удалось обойти существующие ограничения и вернуть управляемость отопления в квартире, получив при этом удаленный доступ со смартфона и возможность дальнейшего развития логики управления.
С виду он напоминает самолет, у него внушительное крыло и фюзеляж от транспортника, но на концах крыла вращаются огромные несущие винты, как у вертолета.
Такое впечатление, что природа не предполагала подобной машины. Это вообще летает? Вертолёт с крыльями? Самолет с пропеллерами над крылом?
Ка-22 «Винтокрыл» обещал совместить лучшее из разных сфер авиации: вертолетную вертикальную взлёт‑посадку и самолетную скорость с дальностью полета. Казалось, это могло навсегда изменить все правила игры в транспортной авиации. Но путь этого воздушного гибрида оказался тернистым и весьма драматичным.
Сперва хотел просто поделиться обзором Адама Севиджа на прикольные самодельные часы в стиле NASA, но что-то вышло из под контроля, и получился лонгрид про историю борьбы с колоссальным давлением при глубоководных погружениях через призму одной технологии.
Данная статья является продолжением раннее опубликованной мною темы: Умный дом на основе интерфейса CAN. Вот ссылки на предыдущие статьи:
1. Протокол обмена данными. Пользовательский уровень, поверх CAN 2.0. Проект
2. Выбор структуры для системы «Умный дом»
В качестве ядра схемы контроллера сети был выбран модуль ESP32-C6-WROOM-1-N8
Все слышали про Ивана Кулибина — талантливого механика и изобретателя XVIII века, чьё имя прочно закрепилось в массовой культуре как символ инженерной смекалки. Но в то же самое время в России работал другой, куда менее известный сегодня, но не менее масштабный инженер — гидротехник Козьма Фролов.
Он сумел поставить силу воды на службу промышленности и создал для своего времени по-настоящему передовые механизмы, которые значительно упростили труд и повысили производительность рудников Урала и Сибири.
В современных высокопроизводительных системах используются мощные вычислительные компоненты с высоким тепловыделением, при этом требования к энергоэффективности дата-центров ограничивают реальный тепловой режим работы сервера. Задача инженеров здесь — снизить риск перегрева компонентов и избежать потери производительности.
Меня зовут Анатолий Белановский, я старший инженер по методикам тестирования. В прошлом занимался спинтроникой, работал над разработкой STTMRAM, ReRAM, а также в области сверхпроводниковых кубитов. В статье расскажу о методике, которая позволит быстро определить тепловые ограничения процессоров, модулей памяти, накопителей, сетевых контроллеров и элементов питания. Инженеры могут использовать ее при аудите существующей инфраструктуры, оптимизации компоновки и нагрузок, приемочных испытаниях и ускоренного прототипирования систем охлаждения.
Если вы когда-либо строили высоконагруженные системы поиска, то знаете, что в какой-то момент узким местом становится не код, а сама архитектура. Поиск доступных отелей — как раз тот случай: миллиарды «ночей», десятки тысяч RPS, постоянные обновления календарей, строгая консистентность и высокая цена любой ошибки. Старый стек на Python + Postgres + Redis долго тянул, но однажды стал «тормозить» настолько, что оптимизировать дальше было невозможно — SQL-запросы разрастались, реплики множились, latency прыгала до 60 секунд, а кэширование превращалось в источник инцидентов.
Так мы пришли к идее построить собственную in-memory базу данных на Go — заточенную под наш домен. Быструю, безопасную и синхронизированную с Postgres.
Под катом — история того, как мы её спроектировали, какие архитектурные решения приняли, как победили холодный старт, справились с миллиардами значений. И почему в итоге смогли полностью отказаться от кэша доступности, переведя поиск в real‑time.
