потребление не измерял, но думаю небольшое. Вся старая электроника люстры (приемник команд от радиопульта) осталась, так как хотел обойтись минимальным вмешательством в схемотехнику. В отсутствии ШИМ энергию потребляет только цепь управления, запитана она в люстре насколько помню от конденсаторного БП, то есть ток там - несколько миллиампер. Плюс дополнительно все время запитан блок питания ESP32, думаю суммарно в выключенном состоянии сейчас люстра потребляет не более пары ватт мощности.
Реверс-нижиниринг драйвера люстры тоже был отдельной задачей, но оказалось что там все довольно просто устроено
с этого начинал, не получилось. У входа есть гистерезис, и длительность нуля при нормальном переходе получается примерно 1.5 мс, что может быть сравнимо с временем переключения выключателя. Если фильтровать такие импульсы, детектор не всегда срабатывает. Использование АЦП позволяет сократить это время до сотни микросекунд (считаем время только когда АЦП в максимальном значении) и надежно отделять сигнал от выключателя от перехода через ноль
знакомый документ ) Первые эксперименты были как раз по схеме оттуда с подачей сигнала на вход прерывания, но потом вариант со входом АЦП и опторазвязкой показался надежнее и безопаснее
с этого все и начиналось ) У меня не получилось отладить чисто аналоговый вариант системы с емкостью для определения перехода через ноль. Дело в том, что момент переключения может совпасть с моментом перехода через ноль - детектор не сработает. При слишком маленьком значении емкости были ложные срабатывания от наводок. Во время экспериментов на стенде в варианте с емкостью система работала, но процент срабатывания был процентов 80...90. В продакшн такое нельзя, когда механический выключатель не срабатывает с первого раза - раздражает страшно. После этого и появилась идея смотреть значение сигнала на входе с помощью АЦП
Прочитал вашу статью, ранее мне не попадалась. Интересное решение. По поводу кратковременных пропаданий электричества тоже были опасения, но за все время эксплуатации (более года) ложных срабатываний не случалось. Тут еще дело в длительности - если электричество пропадет на время более 1 секунды, то конденсаторы в блоке питания разрядятся и система стартует в исходном выключенном состоянии. Так что более вероятно нештатное выключение, чем включение
на момент самостоятельного вылета должен быть пройден ВЛЭК, а там требований будет гораздо больше. Чуть проще, чем у линейных пилотов, но в разы жестче водительской медкомиссии
просто формат данных очень похож на тот, что в моих датчиках — предположил, что там используется один и тот же чип. В моих датчиках все было логично — 5 байт: 4 данных и 5й — сумма. Все сошлось с первого раза, другие варианты даже не пробовал. Но у вас с передачей нибблами, возможно, все совсем иначе
датчик у меня вот такой.
А если сделать перестановки для всех байт пакета и просуммировать, может тогда CRC совпадет с суммой? Вряд ли там слишком много модификаций электроники.
Пакет у меня выглядел вот так:
Но вы смотрели уже с выхода приемника, может это повлияло на длительность импульсов
у вас какой-то странный порядок бит в таблице, подозреваю что при разборе пакета полубайты перемешиваются. Например, если поменять местами полубайты в первой посылке: 1001 0110 0101 1011 1000 0110 1000 0010 0001 1111 Key:0 Ch:2 H:40%, T:25.2 C
на
1001 0110 0101 0110 1000 1011 0010 1000 0001 1111
то получим:
0010 1000 = 40, это влажность. Дальше
0110 1000 1011 = 1675 — температура. Переводим по формуле
(1675-320)*5/9-500=252, или 25,2 градуса Цельсия.
Буквально несколько дней назад разбирался с подобным датчиком. Тоже довольно быстро нашел биты канала, биты поля влажности, и столкнулся со странным форматом поля температуры. Помог хабраюзер ValeriVP — он прямо указал что температура в таких датчиках передается в долях Фаренгейта и CRC рассчитывается как младший байт арифметической суммы всех байт пакета.
Кстати, я смотрел сигнал прямо со входа передатчика цифровым осциллографом и увидел там типичный манчестерский код. Соответственно алгоритм приема у меня реализован по-другому. Сначала идет четыре импульса по 700 мкс, потом 40 бит данных в формате MSB first. Если последовательно записать эти 40 бит, то разбирать их можно будет в привычном формате.
CRC там может быть просто арифметическая сумма всех байтов в посылке. А температура — в десятых долях Фаренгейта. Как раз недавно разбирался с подобной.
используя три приемника, методами дифференциального GPS можно вычислить ориентацию в пространстве не хуже гироскопа. Расстояние между антеннами на дроне, правда, не слишком большое, но видимо точности достаточно
потребление не измерял, но думаю небольшое. Вся старая электроника люстры (приемник команд от радиопульта) осталась, так как хотел обойтись минимальным вмешательством в схемотехнику. В отсутствии ШИМ энергию потребляет только цепь управления, запитана она в люстре насколько помню от конденсаторного БП, то есть ток там - несколько миллиампер. Плюс дополнительно все время запитан блок питания ESP32, думаю суммарно в выключенном состоянии сейчас люстра потребляет не более пары ватт мощности.
Реверс-нижиниринг драйвера люстры тоже был отдельной задачей, но оказалось что там все довольно просто устроено
с этого начинал, не получилось. У входа есть гистерезис, и длительность нуля при нормальном переходе получается примерно 1.5 мс, что может быть сравнимо с временем переключения выключателя. Если фильтровать такие импульсы, детектор не всегда срабатывает. Использование АЦП позволяет сократить это время до сотни микросекунд (считаем время только когда АЦП в максимальном значении) и надежно отделять сигнал от выключателя от перехода через ноль
выше отвечал на похожий вопрос. С конденсатором не получилось, ненадежно работало
не совсем понимаю, а как можно измерить длительность импульса триггером?
знакомый документ ) Первые эксперименты были как раз по схеме оттуда с подачей сигнала на вход прерывания, но потом вариант со входом АЦП и опторазвязкой показался надежнее и безопаснее
с этого все и начиналось ) У меня не получилось отладить чисто аналоговый вариант системы с емкостью для определения перехода через ноль. Дело в том, что момент переключения может совпасть с моментом перехода через ноль - детектор не сработает. При слишком маленьком значении емкости были ложные срабатывания от наводок. Во время экспериментов на стенде в варианте с емкостью система работала, но процент срабатывания был процентов 80...90. В продакшн такое нельзя, когда механический выключатель не срабатывает с первого раза - раздражает страшно. После этого и появилась идея смотреть значение сигнала на входе с помощью АЦП
реле может только включать/выключать свет, хотелось реализовать "искусственный рассвет" с плавным нарастанием яркости
проще всего было бы дополнительно к цепи с выключателями предусмотреть отдельную линию для постоянного питания люстры
Прочитал вашу статью, ранее мне не попадалась. Интересное решение. По поводу кратковременных пропаданий электричества тоже были опасения, но за все время эксплуатации (более года) ложных срабатываний не случалось. Тут еще дело в длительности - если электричество пропадет на время более 1 секунды, то конденсаторы в блоке питания разрядятся и система стартует в исходном выключенном состоянии. Так что более вероятно нештатное выключение, чем включение
А если сделать перестановки для всех байт пакета и просуммировать, может тогда CRC совпадет с суммой? Вряд ли там слишком много модификаций электроники.
Пакет у меня выглядел вот так:
Но вы смотрели уже с выхода приемника, может это повлияло на длительность импульсов
1001 0110 0101 1011 1000 0110 1000 0010 0001 1111 Key:0 Ch:2 H:40%, T:25.2 C
на
1001 0110 0101 0110 1000 1011 0010 1000 0001 1111
то получим:
0010 1000 = 40, это влажность. Дальше
0110 1000 1011 = 1675 — температура. Переводим по формуле
(1675-320)*5/9-500=252, или 25,2 градуса Цельсия.
Буквально несколько дней назад разбирался с подобным датчиком. Тоже довольно быстро нашел биты канала, биты поля влажности, и столкнулся со странным форматом поля температуры. Помог хабраюзер ValeriVP — он прямо указал что температура в таких датчиках передается в долях Фаренгейта и CRC рассчитывается как младший байт арифметической суммы всех байт пакета.
Кстати, я смотрел сигнал прямо со входа передатчика цифровым осциллографом и увидел там типичный манчестерский код. Соответственно алгоритм приема у меня реализован по-другому. Сначала идет четыре импульса по 700 мкс, потом 40 бит данных в формате MSB first. Если последовательно записать эти 40 бит, то разбирать их можно будет в привычном формате.
Tracking Drone Orientation with Multiple GPS Receivers