Немного оффтоп. А почему для иллюстрации была выбрана именно такая картинка? Просто я совершенно чётко вижу, что на иллюстрации вовсе не компьютерная серверная, а что-то типа аппаратной какого-то вещательного комплекса — какие-то кодеры и эфирные процессоры, коммутационные панели с XLR (это такие звуковые разъемы) и т.д.
А зачем там вообще используется прерывание, если по сути вы его никак не используете? Куда проще прямо в рабочем цикле проверять состояние датчиков.
Всё, что под if (firstStart) надо переносить в setup — это типичная инициализация, для которой setup и предназначен.
Ну и вложенные циклы с одним и тем же условием isSensorStarted — это что-то за пределами моего понимания
Прежде всего несколько непонятно — у вас обычные BLDC двигатели (под трапецию) или рассчитанные на векторное управление (под синус)?
Двигатель ниже 5 об/мин двигается рывками, а ток сильно возрастает
момент при малых оборотах высокий, а с увеличением оборотов нелинейно падает, и чем меньше напряжение питания, тем хуже зависимость
Собственно — это одна проблема. И она называется «противоэдс». То есть вращение ротора вызывает ЭДС в катушках. В управлении бездатчиковыми двигателями этот эффект используется для уточнения положения ротора.
По большому счёту вам надо рассчитывать подаваемое напряжение с учётом требуемого ускорения и текущей скорости. Либо работать с токовыми драйверами.
первый шаг периодически сопровождался рывком ротора. Удар можно убрать, путем снижения амплитуды первой половины шага (в моем случае 20% от максимума) и значительно увеличив время первой половины шага по сравнению с другими шагами.
Здесь имеет смысл плавно (линейным нарастанием) вывести на максимальное значение чтобы плавно поставить ротор в заданное положение и дальше уже регулировать напряжение в зависимости от требуемого ускорения.
PS: На всякий случай хочу заметить, что даже при использовании DMA чудеса ещё как бывают.
Стандартный приём при использовании DMA — наличие ДВУХ буферов — один сейчас «в эфире», второй копит данные. При окончании данных в первом буфере — натравливаем DMА на второй буфер, а данные льём в первый. И так они по очереди и работают. В таком случае мы избегаем любых блокировок или потерь данных.
А зачем здесь вообще DMA? Подобные задачи (низкоскоростной вывод) куда проще решаются через кольцевой буфер и прерывание по пустому буферу передачи. Никаких блокировок.
Копируем данные в кольцевой буфер и смотрим — свободен ли сейчас буфер UART. Если свободен — кидаем туда первый байт.
Дальше по прерыванию просто кидаем следующий байт и всё. Дошли до указателя последнего байта — остановились.
А с чего вдруг получится сверхмалое потребление тока? Яркость приблизительно пропорциональна среднему току через светодиод. Чем мы его достигаем — ШИМом или активным элементом последовательно светодиоду — да пофиг — потери в любом случае равны (Uпитания — Uсветодиода)*I. А напряжение на светодиоде почти не зависит от тока — их даже раньше использовали в качестве этакого стабилитрона.
Единственный способ понизить потребление — индуктивность последовательно светодиоду, ШИМ и схема стабилизации тока. Но это такой геморрой, что это имеет смысл только на каких-то уж очень больших цифрах.
Это не ШИМ заметен, это частота обновления. В большинстве библиотек делают частоту обновления порядка 10 герц и «ступенчатость» изменения яркости очень заметна.
Я когда делал свою снежинку/гирлянду делал частоту обновления порядка 100Гц и все зажигания/потухания сделал плавными. Визуально очень хорошо смотрится.
Это типичная проблема, когда площадка общая для двух SMD компонентов — при расплавлении паяльной пасты силы поверхностного натяжения «стягивают» компоненты вместе. Надо было оставить полоску маски, тогда такого бы не было.
Оказалось, что давление 0.00 Bar начинается когда 7-й байт содержит значение 97. Не ясно почему так.
Скорее всего там просто абсолютное давление, умноженное на 100. То есть при абсолютном давлении 1 бар (без избыточного давления) на выход должно идти 100. 3 единицы — просто погрешность.
А цветастость была важным условием? Всё-таки адресные светодиоды весьма крупные, из-за этого приходится делать «ножки-световоды», которые дают некрасивые «пучки» света снизу.
Не было идеи просто сделать плату подсветки на копеечных SMD светодиодах формата 0805? Тогда нижний торец можно было бы сделать плоским и подсветка была бы намного равномернее.
Хотя даже с текущей конструкцией можно было бы существенно улучшить равномерность подсветки если сделать ножки не прямоугольниками, а трапециями и матировать нижнюю грань (обращённую к светодиодам).
Ох, как будто вернулся в конец 90х — начало нулевых… Когда Резонит драл за платы неадекватные деньги, китайцы еще не раскачались и всё делали ЛУТом. Когда нормальных микроконтроллеров еще просто не было и всё делалось либо на MCS-51, либо на at2313. И да, приходилось всё делать на ассемблере, так как каждый байт был на вес золота.
Много что еще можно вспомнить. И так удивительно видеть всё это в конструкции 2019 года.
Извините, но Вы серьезно ссылаетесь на Wiki, как на серьёзный источник?
Вообще-то, в сети без проблем находятся оригинальные документы. И в них это называется:
«Испытание турбоагрегата №7 Чернобыльской АЭС в режиме совместного выбега с нагрузкой собственных нужд» accidont.ru/Prog1985.html
> Кнопки нажимали сотрудники станции, но ведь идея была московского института
Так всё-таки — «проводил приехавший специалист» или таки «работники станции»? Приехавшие специалисты там действительно были. Но они турбинисты и занимались исключительно турбиной, насколько я помню (там даже стоял отдельный фургончик с дико дорогущей аппаратурой для записи параметров, который потом ушёл в радиоактивные отходы).
Несколько лет назад интересовался этой темой, перечитал кучу воспоминаний и отчётов. Для себя сделал следующий вывод: базовой причиной аварии стало рассогласование методов управления после передачи АЭС от военных к производственникам.
Попробую пояснить. У нас в целом распространён азиатский метод управления — подчинённый должен знать ровно то, что ему нужно для выполнения его обязанностей. В военной среде это всё предельно усугубляется крайне низкой квалификацией исполнительского персонала. Поэтому инструкции делаются в виде «программы» для биороботов — стрелочка дошла до такого-то значения — закрой такой-то вентиль. Мощность реактора упала ниже такого-то значения — останови реактор на такое-то время. Почему и как особо не поясняется — всё равно исполнитель не поймёт — ему это знать не надо. И вопрос цены его действия у военного не стоит вообще.
При переводе энергетического атома от военных к производственникам все инструкции остались в прежнем виде. Но вот подход производственников совершенно другой — тяни план и задание любой ценой. В результате отношение к инструкциям совершенно другое — если для выполнения задания надо слегка не выполнить инструкцию — да и чёрт с ним — попробуем.
Тем более в этой среде было распростанено мнение, что серьезно повредить РБМК неверными действиями невозможно — реакторы не взрываются.
В результате возникла ситуация:
— полной информацией о существующих проблемах и возможных их последствиях обладали только вышестоящие организации — вниз это информация не спускалась
— предполагалось, что исполнители строго следуют инструкции
— исполнители стремились исполнить задание любой ценой, что приводило к многочисленным нарушениям инструкций без полного понимания возможных последствий
Всё это продолжалось до тех пор, пока при случайном стечении обстоятельств исполнителям не удалось напороться на конструкторскую недоработку, которая в нормальных условиях эксплуатация не проявилась бы никогда.
> есть стандартная программа, которая передаёт видео с камеры по wi-fi
Такие программы совершенно нестандартные — каждый производитель лепит что-то своё. Поэтому если в родной программе такого нет — ничего совместимого с 99% вероятности не существует.
Даже интересно — и как же это самолёты летали, когда никаких GPS и ADS-B в помине еще не было?
Я не специалист по авиационной электронике, но одно время плотно увлекался виртуальным пилотированием. С изучением реальных flight manual'ов и подобной документации.
Первое понятие, которое автор не учитывает — комплексное самолётовождение. В условиях, когда любая система может отказать — это база. То есть своё местоположение ты должен знать из нескольких источников и если один из источников показывает что-то не то — просто исключаешь его из рассмотрения.
Что у нас есть из навигации в полёте.
1. Приводные радиостанции. Да-да, старые добрый маяки, расставленные по всей стране и выдающие в эфир свой сигнал опознавания (морзянкой). Используются радиокомпасом.
2. VOR/DME. Забыл как это у нас называются. Маяки, которые позволяют определить направление на самолёт и дальность до маяка.
Ну и диспетчеры тоже как бы смотрят — кто где летит и не сильно ли вылетел из заданного эшелона/маршрута.
Ну и при посадке к этому добавляется ILS и маркерные маяки. Ну и диспетчер посадки как бы тоже за тобой смотрит — не вышел ли ты из глиссады. Ну и локационный высотомер тоже никто не отменял…
Тут тоже действует принцип комплекса. То есть если ты заспуфил ILS (а ILS вообще довольно капризная система и от неё вечно ждут неприятностей) и «понизил» глиссаду, то дальний привод самолёт пройдёт на нестандартной высоте и пилот сразу начнёт разбираться — какого чёрта… А если отклонил от курса, то самолёт на дальним приводом вообще не пройдёт.
То есть заспуфить GPS само по себе — не даст ничего. Вообще. Грамотный пилот немедленно обнаружит, что что-то здесь не так и просто исключит систему из рассмотрения.
То есть спуфить надо вообще ВСЕ системы, причём согласованно. Не исключая и наземные средства.
Всё, что под if (firstStart) надо переносить в setup — это типичная инициализация, для которой setup и предназначен.
Ну и вложенные циклы с одним и тем же условием isSensorStarted — это что-то за пределами моего понимания
Собственно — это одна проблема. И она называется «противоэдс». То есть вращение ротора вызывает ЭДС в катушках. В управлении бездатчиковыми двигателями этот эффект используется для уточнения положения ротора.
По большому счёту вам надо рассчитывать подаваемое напряжение с учётом требуемого ускорения и текущей скорости. Либо работать с токовыми драйверами.
Здесь имеет смысл плавно (линейным нарастанием) вывести на максимальное значение чтобы плавно поставить ротор в заданное положение и дальше уже регулировать напряжение в зависимости от требуемого ускорения.
Стандартный приём при использовании DMA — наличие ДВУХ буферов — один сейчас «в эфире», второй копит данные. При окончании данных в первом буфере — натравливаем DMА на второй буфер, а данные льём в первый. И так они по очереди и работают. В таком случае мы избегаем любых блокировок или потерь данных.
Копируем данные в кольцевой буфер и смотрим — свободен ли сейчас буфер UART. Если свободен — кидаем туда первый байт.
Дальше по прерыванию просто кидаем следующий байт и всё. Дошли до указателя последнего байта — остановились.
103 — 0.01мкФ
104 — 0.1мкФ
105 — 1мкФ
Единственный способ понизить потребление — индуктивность последовательно светодиоду, ШИМ и схема стабилизации тока. Но это такой геморрой, что это имеет смысл только на каких-то уж очень больших цифрах.
Я когда делал свою снежинку/гирлянду делал частоту обновления порядка 100Гц и все зажигания/потухания сделал плавными. Визуально очень хорошо смотрится.
Скорее всего там просто абсолютное давление, умноженное на 100. То есть при абсолютном давлении 1 бар (без избыточного давления) на выход должно идти 100. 3 единицы — просто погрешность.
Не было идеи просто сделать плату подсветки на копеечных SMD светодиодах формата 0805? Тогда нижний торец можно было бы сделать плоским и подсветка была бы намного равномернее.
Хотя даже с текущей конструкцией можно было бы существенно улучшить равномерность подсветки если сделать ножки не прямоугольниками, а трапециями и матировать нижнюю грань (обращённую к светодиодам).
Много что еще можно вспомнить. И так удивительно видеть всё это в конструкции 2019 года.
Вообще-то, в сети без проблем находятся оригинальные документы. И в них это называется:
«Испытание турбоагрегата №7 Чернобыльской АЭС в режиме совместного выбега с нагрузкой собственных нужд»
accidont.ru/Prog1985.html
> Кнопки нажимали сотрудники станции, но ведь идея была московского института
Так всё-таки — «проводил приехавший специалист» или таки «работники станции»? Приехавшие специалисты там действительно были. Но они турбинисты и занимались исключительно турбиной, насколько я помню (там даже стоял отдельный фургончик с дико дорогущей аппаратурой для записи параметров, который потом ушёл в радиоактивные отходы).
Попробую пояснить. У нас в целом распространён азиатский метод управления — подчинённый должен знать ровно то, что ему нужно для выполнения его обязанностей. В военной среде это всё предельно усугубляется крайне низкой квалификацией исполнительского персонала. Поэтому инструкции делаются в виде «программы» для биороботов — стрелочка дошла до такого-то значения — закрой такой-то вентиль. Мощность реактора упала ниже такого-то значения — останови реактор на такое-то время. Почему и как особо не поясняется — всё равно исполнитель не поймёт — ему это знать не надо. И вопрос цены его действия у военного не стоит вообще.
При переводе энергетического атома от военных к производственникам все инструкции остались в прежнем виде. Но вот подход производственников совершенно другой — тяни план и задание любой ценой. В результате отношение к инструкциям совершенно другое — если для выполнения задания надо слегка не выполнить инструкцию — да и чёрт с ним — попробуем.
Тем более в этой среде было распростанено мнение, что серьезно повредить РБМК неверными действиями невозможно — реакторы не взрываются.
В результате возникла ситуация:
— полной информацией о существующих проблемах и возможных их последствиях обладали только вышестоящие организации — вниз это информация не спускалась
— предполагалось, что исполнители строго следуют инструкции
— исполнители стремились исполнить задание любой ценой, что приводило к многочисленным нарушениям инструкций без полного понимания возможных последствий
Всё это продолжалось до тех пор, пока при случайном стечении обстоятельств исполнителям не удалось напороться на конструкторскую недоработку, которая в нормальных условиях эксплуатация не проявилась бы никогда.
Такие программы совершенно нестандартные — каждый производитель лепит что-то своё. Поэтому если в родной программе такого нет — ничего совместимого с 99% вероятности не существует.
Ну и естессно, нужен OTG приёмник, например от Eachine.
Но будет довольно заметная задержка.
Я не специалист по авиационной электронике, но одно время плотно увлекался виртуальным пилотированием. С изучением реальных flight manual'ов и подобной документации.
Первое понятие, которое автор не учитывает — комплексное самолётовождение. В условиях, когда любая система может отказать — это база. То есть своё местоположение ты должен знать из нескольких источников и если один из источников показывает что-то не то — просто исключаешь его из рассмотрения.
Что у нас есть из навигации в полёте.
1. Приводные радиостанции. Да-да, старые добрый маяки, расставленные по всей стране и выдающие в эфир свой сигнал опознавания (морзянкой). Используются радиокомпасом.
2. VOR/DME. Забыл как это у нас называются. Маяки, которые позволяют определить направление на самолёт и дальность до маяка.
Ну и диспетчеры тоже как бы смотрят — кто где летит и не сильно ли вылетел из заданного эшелона/маршрута.
Ну и при посадке к этому добавляется ILS и маркерные маяки. Ну и диспетчер посадки как бы тоже за тобой смотрит — не вышел ли ты из глиссады. Ну и локационный высотомер тоже никто не отменял…
Тут тоже действует принцип комплекса. То есть если ты заспуфил ILS (а ILS вообще довольно капризная система и от неё вечно ждут неприятностей) и «понизил» глиссаду, то дальний привод самолёт пройдёт на нестандартной высоте и пилот сразу начнёт разбираться — какого чёрта… А если отклонил от курса, то самолёт на дальним приводом вообще не пройдёт.
То есть заспуфить GPS само по себе — не даст ничего. Вообще. Грамотный пилот немедленно обнаружит, что что-то здесь не так и просто исключит систему из рассмотрения.
То есть спуфить надо вообще ВСЕ системы, причём согласованно. Не исключая и наземные средства.