Category: технологии

Category was added automatically. Read all entries about "технологии".

Защита Attiny85 от помех

Добрый день, я программист по специальности, в электротехнике/схемотехнике плохо разбираюсь.

Делаю счетчик Импульсов с питанием от батареек. Узнал о существовании помех от механических контактов. 

Насколько я понимаю, мне защита особенно нужна, т.к. микроконтроллер спит, потребляя 4мкА, и более подтвержен помехам. Вход может быть долгое время замкнут, а значит нужно минимизировать ток утечки через подтягивающие резисторы.

Классическая схема защиты выглядит так (номиналы сам придумал):  

https://ic.pics.livejournal.com/vostnod/12893397/304847/304847_original.png

300-500кОм подтягивающий резистор при 3В даст 6-10мкА.
Эта схема подходит для подсчета импульсов по прерыванию и периодическим опросов.

Если отказаться от подтягивающего резистора, то либо подавать питание с 3-го пина в момент опроса входов, либо я такую схему придумал:
https://ic.pics.livejournal.com/vostnod/12893397/305106/305106_original.png
Тут только периодический опрос.

Насколько я понимаю, периодический опрос на потребление не сильно влияет.

На форумах по темам помех советуют:
1) Защита USB от ESD: USBLC6-2
2)
IP4220CZ6 тема: https://electronix.ru/forum/index.php?showtopic=126926
3) Триггер-шмитта: 74HC2G14
4) Защита iButton от статики волшебным диодом: DS9503

Collapse )

понижатель + инвертор (вопрос от чайника)

конкретика в цифрах
диапазон подаваемого напряжения 120 - 240 вольт
? на сколько нужно снижать 12,24,36 ?
после инвертора нужно 220 В 5-6 кВт чистая синусоида
? заземление конечных потребителей ?

Collapse )
  • dz

датчики веса

Краткая история фейла.

Задумался о датчиках веса. Идея была вообще идиотская - взвешивать холодильник чтобы делать предположение о том, что пора закупать жратву. Но, с другой стороны, датчики стоят недорого, можно и идиотские идеи попроверять. Тем более, что есть и более вразумительные способы использования - например, при монтаже пола вставить датчики под некоторые лаги, и получать представление о том, где в квартире есть люди, а где нет.

Так или иначе, кажется, что самому делать усилитель для тензометрических датчиков на опампах - гиблое дело. Лучшее, что у меня нашлось - LF412 (не А), и с ним пока НЧ шум усилителя больше, чем сигнал при давлении в несколько кг. (стандартная схема балансного усилителя ПТ на 3 оп ампах).

Есть готовые предусилители для этого дела, но это неспортивно. :) Впрочем, может быть, закажу.

Если кто что делал в этом направлении - поделитесь, пожалуйста.
  • dz

Емкостной датчик

Давно искал что-то под датчик присутствия. Недавно попалась чертовски изящная схема емкостного датчика, основанного на сравнении времени задержки в измерительной и референсной цепях. Решил попробовать на праздники - оказалась вполне работоспособна. Поменял в ней генератор на инверторе на 555 для стабильности (у инверторного частота гуляет на километр от всего). Ну и придавил дребезг на выходе оставшимся ТШ. Извините за неровный почерк тёплую ламповую шариковую ручку.

prox_sensor

555 тут модерновый, на полевиках. 74HCT14 - понятно, важно, чтобы HCT, хотя, наверное, и HC на такой частоте будет работать нормально. 155ТМ2 аутентичный. :)

Заявлено, что дальность срабатывания примерно равна диаметру "антенны" - обкладки датчика, но, на практике, получается раза в два меньше.

Инвертор 1-2 можно выкинуть, это рудимент генератора. Ёмкость 10.0 на выходе маловата, можно добавить порядок, а то всё равно в некоторой промежуточной точке выдаёт цепочку коротких срабатываний. Ну или поставить ТШ с бОльшим диапазоном. Из того же 555 сделать...

Вообще просится заменить 555 и подавитель дребезга на attiny (и сделать выход I2C для гомогенности;), но жутко лениво его программировать.
  • dz

Конфигурирование умного дома

(Модераторам - а тег "умный дом" не добавить ли?)

Попробую более-менее кратко описать, какой объём конфигурирования и поддержания знаний требуется для среднего размера системы умного дома. Мне кажется, коллеги проблему недооценивают.

Кратко о системе: Московская квартира 100м2, стойка 19" в потолок, модули в помещениях, полное централизованное управление светом (ручное, групповое, сценарное, по датчикам движения и открытия дверей), климатом (тёплый пол и управляемые радиаторы, под два десятка датчиков) и много по мелочи (уличные датчики, датчики звука, CO2, взаимодействие с теликами, снятие данных с NAS и т.п.). Ещё столько же в планах, но времени нет, и, главное - я вижу как растёт сложность системы.

Попытаюсь пройтись по тому, как документирована конфигурация всего этого.

Конфигурация роутера

Отдельная большая проблема. Есть карта всех IP (вне роутера!), она же прописана в роутер, там же фиксация MAC/IP для DHCP, и нет, туда нельзя положить дополнительные конфигурационные параметры - даже в довольно продвинутом mikrotik DNS сервер рудиментарный. И да, по возможности всем устройствам IP-адреса прописаны жёстко. То есть реально пара мак-ip живёт в трёх местах - документ, роутер, устройство.

Кросс-журнал

В сумме в стойку приходит около ста витых пар, примерно половина - локалка, половина - слаботочка умного дома. В основном - +24 вольта, RS485, датчики pt1000, 1wire и прямые линии управления, например - клапанами радиаторов. Много мелочей - например, импульсы расхода воды или аплинк от автономного контроллера протечки.

Силовых линий вряд ли меньше - во всяком случае, светильники и выключатели разведены на три кросса, 50+50+20 точек. Отдельно все люстры, бра, тёплые полы, блоки розеток и кое-где отдельные розетки (впрочем, управляемых розеток в итоге вообще нет, так что половина силовых просто разведена на гребёнки и автоматы).

Кросс-журнал - номера проводов, распайки по цветам жил, соединения проводов, подключение каждого конца каждого провода куда-либо. По факту - там есть ошибки. Иногда нахожу и исправляю. По факту - шесть проводо из оговоренного объёма в итоге непригодны для эксплуатации. Три тупо потеряны или рваные, три с короткими замыканиями.

Кросс-журнал сделан в виде нескольких вкладок в гугл-таблицах, информация продублирована. Отдельно есть таблица проводов (и сказано, к какому устройству он подключен), отдельно - таблица устройств (и сказано, какой провод на какую клемму приходит) - это позволяет проще искать ошибки.

Пример из кросс-журнала по плинтам: номер плинта, номер пары, номер провода, цвет, что на том конце, что на этом.


3 0 76 зел-бел,зел пт1000 детская 1 (у двери, ближний) МВА1.1
3 1 76 кор-бел,кор 1wire+клапан батареи plc 30 do2, mmnet2 1w2

Слаботочка: локалка разведена на стандартную патч-панель, специальная - на плинты. Местами есть кроссировка и между ними. Журнала для локалки нет, а, наверное, скоро будет нужен - буду вводить сегменты сети, отдельный на умный дом без роутинга в Интернет и отдельный на IP-камеру в подъезде с роутингом только в одну точку.

Пример из журнала распаек (по одному типу кабеля):


управл батареями + датчики темп 1 оранжевый-бел земля
НОМЕРА КОНТАКТОВ РАЗЪЕМА 2 оранжевый +24
СДЕЛАНО 3 зеленый-бел pt1000
6 зеленый pt1000
4 синий rs485 +
5 синий-бел rs485 -
7 коричневый-бел минус термопривода термопривод крана батареи между +24 (2, оранж) и кор-бел (7) - NB! - предохранитель на вых. контроллера!
8 коричневый 1wire термометр DS18B20


Журнал питания

В стойке стоит блок предохранителей, чтобы КЗ по питанию не выжгло провод в стене. Расписано, какой канал блока что питает (вне стойки). Кабель, напряжение, устройство. Как правило, везде идёт +24 и локально стабилизируется ШИМ-ом в +12 или +5. Снижаем ток в проводах, привносим стандарт.

Журнал 1-wire

А куда деваться? Они прописаны в конфигурации контроллера, но если контроллер умрёт - откуда их доставать и как их вспоминать? Это вот - одна из главных причин иметь централизованное конфигурирование.


Датчики температуры 1Wire В контроллере
MAC контроллер Шина Индекс расположение
28:8D:4E:AB:02:00:00:87 mmnet вытяжка - 0 Внутри вытяжки на контроллере
28:E3:37:AB:02:00:00:C9 mmnet вытяжка - 1 Снаружи вытяжки вверху (короткий провод)
28:44:36:AB:02:00:00:DD mmnet вытяжка - 2 Снаружи вытяжки внизу (длинный провод)


Журнал каналов умного дома

Каналом считается вход или выход основной системы, которая стоит в шкафу. Тут нет входов-выходов модулей, которые стоят по квартире.


Устройство Порт Канал Выключатель Лампа Фидбек Объект Комментарий
МДВВ0 1 0 A28-29 B32-31 да Столовая люстра Лев канал modbus порт 502
2 1 A28-29 B30-31 да Столовая люстра Прав
3 2 B12-11 B12-11 да Столовая бра Лев
4 3 B10-11 B10-11 да Столовая бра Прав
5 4 A8-7 B42-43 да Детская люстра Лев
6 5 A8-7 OR A9 B44-43 да Детская люстра Прав
7 6 - - нет Прихожая светодиоды
8 7 A8-7 B44-43 Детская ночник через реле включает два ночника в обоих люстрах

Обратите внимание на комментарий про ночники. Рисовать полную схему - убиться. Вместо этого все существенные вещи прописаны вот так в комментариях.
Так расписаны все железки в шкафу. Где уместно - указаны специфические настройки входов (опять конфигурация).

Разводка и конфигурация выносных модулей

Специфична для каждого типа. Вот пример для собственных контроллеров atmega128 + ethernet. Кстати, именно им я раздаю MAC-адреса из 1-wire DS2401, и именно им я хотел бы вместо этого выдавать конфигурацию из центрального конфигуратора. Потому как если оно сдохнет - его придётся перенастраивать руками.


Port B Kitchen Vent - http://mmnet1. Rack - http://mmnet2. Bath - http://mmnet3.
192.168.88.129 192.168.88.130 192.168.88.131
0 - output, SS for ? - - -
1-3 - SPI SCK/MOSI/MISO - - -
4 - DHT11 y y y
5 - data flash SS - - -
6,7 - uart tx enable / LED
Port D
0,1 - I2C SCL/SDA - bmp180 -
2,3 - UART1 (debug) n n n
4-7 - DI/DO/PWM PD6 - Di Light, PD7 - Di motor n клапаны воды контакты Di
2-7 - Multibus 1wire n y, chan 6 - температура в стойке n


Журнал шин и адресов

Тут - все IP-адреса всех устройств, все шины 485 и 1wire, номера modbus юнитов, номера портов на TCP/serial конверторах и настройки скорости/формата последовательных портов. И, конечно, указано, что к чему подключено (например, на какой 485-й порт какого контроллера приходит шина или куда уходит порт tcp/serial конвертора)

Журнал настроек

Здесь фиксируются разные настройки, которые или вручную выставлены в устройствах, или прошиваются в них из контроллеров/софта на старте.

Как нетрудно видеть, поддерживать это сложно. Кроме того, всё это - просто документы, никак не связанные. Контроля целостности между документами нет, в кросс-журнале и распайке могут быть написаны разные применения для жил кабеля. Нет и контроля совпадения между документом и прошивкой.

И ещё есть куча вещей, которые вообще хардкод, а хотелось бы иметь возможность конфигурировать. И это ещё я вообще не коснулся OpenHAB-а и его скриптинга, и его связи с контроллерами (а только тут есть ТРИ метода связи), и его связи с наколенными скриптами и драйверами разного железа. Для примера - есть драйвер, который ходит через конвертор интерфейса и специальный протокол поверх модбаса в CCU825, а полученное запихивает в OpenHAB. И в нём есть отображение Item-ов OpenHAB на входы CCU, и это тупо забито в код. И где это искать - через год ты уже не помнишь. И всё это прописывать в доки уже нет никакой мочи.

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

И всё это тряхозвоние я хочу заменить на

- один глобальный канал обмена данных все на всех (MQTT/UDP)
- одну глобальную методику конфигурирования

Довольно понятно, что и то и другое не удастся на 100%, но если я структурирую за следующий год хотя бы треть этого зоопарка, я буду счастлив.
  • dz

MQTT/UDP

Привет.

В своих делах по умному дому захотел обеспечить все компоненты системы унифицированным транспортом. Поглядел на MQTT и остался почти доволен. Но - у меня возникли сомнения насчёт запихивания его в PLC, контроллеры на базе atmega8 и вообще, брокер показался мне избыточной сущностью, не нужной для задачи в целом.

И я спроектировал и реализовал самый простой и маленький IoT протокол на планете - MQTT/UDP. Требования к окружению у этого протокола фантастически минимальны - нужно уметь хотя бы только посылать только UDP пакеты. :)

Репозиторий тут - https://github.com/dzavalishin/mqtt_udp

Русский вводный текст тут - https://github.com/dzavalishin/mqtt_udp/blob/master/README.ru.md

Очевидные схемы применения (англ, сорри) тут - https://github.com/dzavalishin/mqtt_udp/blob/master/dox/Topologies.md

Написал :

  • реализации на Си, Яве, Питоне

  • скетч для ардуино с UDP/IP стеком, только на отправку пока

  • простой гейт-коннектор к классическому MQTT (обменивается апдейтами в обе стороны и глушит зацикливания)

  • программу для мониторинга данных в канале (бродкаст же, всё всем видно, мониторить легко)

Пока не осилил версию для Овен ПЛК, всё же этот их ST language - феерическое г на палке.

Буду рад, если кто-то применит в своих проектах. Повторюсь - проще протокола на планете, кажется, нет. :)

Тантал vs ниобий

Не понимаю, почему так - доступного ниобия на Земле гораздо больше больше, чем тантала, ниобиевые конденсаторы не хуже танталовых (а в чём-то даже получше), технологии изготовления очень похожи, но ниобиевых выпускается гораздо меньше и стоят они дороже. Почему так?

Вопрос за модуль умного дома

All, скажи, если нужно сделать более-менее универсальный модуль умного дома, то какие интерфейсы в нём должны быть (ОК/сухой контакт/ModBUS/etc)?
Интересует и модуль-датчик, и модуль-исполнительное устройство.

А если делать устройство и потенциально автономным, то какие есть варианты? (GSM/WiFi/etc)

Благодарю.

Парализованные реле!

Некогда задавал тут вопрос, поучаствовал в дискуссии и самостоятельно нашёл решение. Но всё как-то руки не доходили проверить на практике - я был уверен, что схема рабочая, но всё же, всё же... платы были давным-давно заказаны, вся комплектуха лежала по пакетикам, дожидаясь лучших времён и тут вдруг решился.

Collapse )