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

Прежде чем начать хотел, сказать спасибо всем комментаторам, которые указали на недочеты. Например, прозрачные трубки — не лучший выбор: из‑за них действительно можно столкнуться с массовым размножением водорослей и образованием биопленки. Свет, тепло и богатый питательными веществами раствор создают для водорослей практически идеальные условия. Так что при окончательной сборке это учту и трубки поменяю.

Справедливо оказалось замечание и по поводу шума. Причем проблема даже не в насосе, а в том, что струя воды с силой бьет о верх башни. Ночью это звучало довольно громко: соседи точно не оценят подобный ежедневный перформанс, так что пришлось на ходу придумывать решение. Пока я обошелся парой мягких губок для мытья посуды, разместив их в верхней и нижней части башни. Это уже существенно снизило уровень шума, хоть и не убрало его окончательно. Скорее всего на одном из промежуточных модулей мне также придется разместить губку или похожий материал, снижающий шум капель.

Охлаждение раствора

Мне показалось довольно важным заранее позаботиться о том, чтобы раствор в системе не перегревался. Когда температура наружного воздуха превышает 30 градусов — корни легко могут начать гнить. В моей местности лето очень жаркое (до +45) — есть даже локальные мемы, вроде «обжегся холодной водой из‑под крана». Так что вопрос охлаждения стоит практически на первом месте. Важно не просто вернуть раствор к температуре окружающего воздуха (с этим бы и обычная система водяного охлаждения справилась), но снизить ее на 5–10 градусов, а потом поддерживать в более‑менее разумных границах.

Решение пришло в голову почти мгновенно. Я слышал, что элементы Пельтье вполне способны дать нужный эффект. Если пропускать раствор через водоблок, к которому с двух сторон приделаны такие термоэлектрические элементы, то должно получиться существенно снизить общую температуру раствора. Поэтому я заказал четыре модуля с маркировкой TEC1-12706 и пару алюминиевых водоблоков:

Мне до этого ни разу не приходилось работать с такими штуками, так что первым делом полез смотреть в документацию и читать статьи, как правильно использовать элементы Пельтье. Хорошо, что я начал именно с этого: если бы я просто подал 12V на модуль без отвода тепла, то за пару секунд получил бы ожог и сгоревший элемент. Оказалось, что это чертовски нежная штука, которая к тому же обладает очень низким КПД и способна потреблять потрясающе много энергии.

Оказалось каждый модуль кушает 5–6А при 12V, то есть примерно 60–70W. При одновременном включении всех четырех элементов суммарное потребление вырастет до 240W, что превышает возможности панели, которая в лучшем случае генерирует 140–150W при температуре ячеек 60–70 °C. Да и батареи в таком режиме проживут ~20 минут со значительной деградацией.

Благо, реальность сильно отличается от теории. Для начала, гонять модули на полном напряжении 12V нет необходимости. При работе от 7–8V они могут эффективно охлаждать, а «аппетит» упадет вдвое — до ~25–30W. Теоретически же, если при подаче 12V соединить их в две последовательные пары, на каждый модуль станет поступать 6V, суммарное потребление снизится до ~70–90W. Правда, все это предстоит проверить экспериментально.

Проблема лишь в том, что со всех четырех модулей потребуется снимать и эффективно рассеивать большое количество тепла, а значит еще ~10–30W уйдет на работу кулеров. В целом ~80–120W уже более‑менее приемлемо для дневной эксплуатации, когда эффективность солнечной панели будет максимальна, но на этом сложности не заканчиваются. Важно подумать также о потенциальной деградации элементов.

Основная фишка в том, что если их использовать в постоянном режиме, без термоциклирования — его хватит на 100 000–200 000 часов (если верить честным китайским даташитам). Но вот если гонять его в циклическом режиме, то дешевые элементы умирают значительно раньше — микротрещины в припое, рост контактного сопротивления и обрыв как следствие. Деградации будет способствовать и температура горячей стороны выше 80 °C.

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

Корпус контроллера

Уверен, что каждый самодельщик меня сейчас поймет: корпус чуть ли не самая сложная часть устройства. Лет 15 назад я бы пошел на рынок искать подходящую коробочку, а потом с помощью лобзика, кусков пластика, саморезов и термоклея пытался бы изобразить крепления. Сейчас же 3D‑печать более чем доступна, поэтому это самый простой способ создания корпуса.

Но если получить готовое изделие довольно легко, то вот придумать и смоделировать, соблюдая все размеры, — задачка не самая простая. Тот же TinkerCAD для этого слишком примитивен, а Autodesk Fusion 360 сложен. Честное слово, я когда‑нибудь его освою. Ну а пока воспользовался Shapr3D. Он значительно более снисходителен к юзеру и при этом позволяет легко создавать сложные модели.

Внутри корпуса я планировал разместить два модуля по четыре реле в каждом и сверху Arduino Uno Q. Моим самым главным помощником в этом деле стал штангенциркуль, которым я замерял расстояния от краев плат до отверстий, а также диаметр последних. Оптимальной высотой размещения я выбрал 6 мм, поскольку это позволяет при необходимости пропустить кабели снизу.

У каждой платы четыре точки крепления, я решил сделать гибридный вариант: два отверстия и два скругленных штыря, размещенных по диагонали:

Это сокращает количество крепежа вдвое и позволяет точно устанавливать плату на место. Снизу предусмотрел отверстия для вывода проводов. Потом при необходимости их можно сделать меньше и даже закрыть какими‑нибудь заглушками:

Общий рендер корпуса выглядел примерно так:

Первая печать вскрыла три неочевидные проблемы:

1. Я случайно разместил крепления для Arduino Uno Q не с той стороны — можно было прикрутить ее только контактами вниз.

2. Стало ясно, что если захочу пропустить какой‑нибудь кабель под релейными модулями, то мне не хватит для этого зазора между платой и корпусом.

3. Накосячил с внутренним диаметром креплений и их общей толщиной — не подходила к болтам, которые были в наличии.

Так что еще раз засел за Shapr3D и стал все исправлять. Для начала удалил все точки крепления Uno Q и воссоздал их заново, расположив правильно. Забегая вперед: все равно на миллиметр ошибся и пришлось слегка подточить оба штыря. Затем увеличил диаметр внутренних отверстий (2,5 → 2,8 мм), внешний также изменил (4,0 → 6,0 мм).

Дополнительно сделал два прямоугольных ввода с боков и два полукруглых снизу. Позаботился и о скруглении, чтобы острые края случайно не повредили изоляцию проводов. Кроме того, сделал дополнительный срез, центрирующий будущую крышку. Рендер приобрел следующий вид:

После печати мне удалось поставить на место все три компонента и зафиксировать их болтами:

Подключение релейных модулей

Пытаться запитать катушки реле от Arduino Uno Q сразу же показалось мне плохой идеей. Тем более что каждый из модулей рассчитан на подключение внешнего питания +5V. Поэтому под них будет выделен отдельный БП. Чтобы сделать универсально, я взял обычный USB‑A кабель, зачистил жилы питания, которые подключил следующим образом:

GND модулей и Arduino соединил в общей точке не просто так. Дело в том, что когда последний подает на вход реле сигнал HIGH или LOW, модуль измеряет его относительно своего GND. Если он у модулей и Arduino будет разным — реле могут срабатывать нестабильно. А с общим GND проблема решится. В качестве дополнительной защиты от наводок пропустил жгут сигнальных проводов через ферритовое колечко:

Первый тест и найденный глитч

Для проверки работоспособности быстренько накидал следующий скетч, который реализует три режима:

1. Медленное включение и выключение каждого реле по очереди.

2. Быстрый «бегущий огонь».

3. Включение и выключение всех реле сразу.

Чтобы отслеживать статус — вывожу соответствующие сообщения в серийный порт. Из заметных особенностей: реле переходит в состояние ON при подаче сигнала LOW. Это связано с тем, что в схеме управления применены оптроны:

Де‑факто реле включается при условии, если через светодиод оптрона течет ток. Последнему, как известно, нужна разница потенциалов. При сигнале HIGH разности потенциалов недостаточно для тока, способного уверенно открыть оптрон, поэтому реле остается выключенным.

Когда MCU дает сигнал LOW, замыкая пин на землю, возникает разница потенциалов, ток начинает течь через светодиод оптрона, транзистор открывается и реле переходит в состояние ON.

sketch.ino

const byte relayPins[] = {2, 3, 4, 5, 6, 7, 8, 9};
const byte relayCount = sizeof(relayPins) / sizeof(relayPins[0]);
const byte RELAY_ON = LOW;
const byte RELAY_OFF = HIGH;

void setRelay(byte relayNumber, bool state)
{
    if (relayNumber >= relayCount) {
        return;
    }

    digitalWrite(
        relayPins[relayNumber],
        state ? RELAY_ON : RELAY_OFF
    );
}

void allRelaysOff()
{
    for (byte i = 0; i < relayCount; i++) {
        setRelay(i, false);
    }
}

void allRelaysOn()
{
    for (byte i = 0; i < relayCount; i++) {
        setRelay(i, true);
    }
}

// Режим 1:
// каждое реле включается на секунду и затем выключается
void sequentialTest()
{
    Serial.println("Mode 1: sequential test");

    allRelaysOff();

    for (byte i = 0; i < relayCount; i++) {
        Serial.print("Relay ");
        Serial.print(i + 1);
        Serial.println(" ON");

        setRelay(i, true);
        delay(1000);

        setRelay(i, false);
        delay(300);
    }
}

// Режим 2:
// одно включенное реле движется слева направо и обратно
void runningLightTest()
{
    Serial.println("Mode 2: running light");

    allRelaysOff();

    // Слева направо
    for (byte i = 0; i < relayCount; i++) {
        setRelay(i, true);
        delay(300);
        setRelay(i, false);
    }

    // Справа налево
    // Начинаем с предпоследнего, чтобы крайнее реле
    // не срабатывало дважды подряд
    for (int i = relayCount - 2; i >= 1; i--) {
        setRelay(i, true);
        delay(300);
        setRelay(i, false);
    }
}

// Режим 3:
// включение и выключение всех реле одновременно
void allRelaysTest()
{
    Serial.println("Mode 3: all relays");

    allRelaysOff();
    delay(500);

    Serial.println("All relays ON");
    allRelaysOn();
    delay(2000);

    Serial.println("All relays OFF");
    allRelaysOff();
    delay(1000);
}

void setup()
{
    Serial.begin(115200);

    for (byte i = 0; i < relayCount; i++) {
        // Сначала безопасное выключенное состояние,
        // затем вывод в режим OUTPUT
        digitalWrite(relayPins[i], RELAY_OFF);
        pinMode(relayPins[i], OUTPUT);
    }

    allRelaysOff();

    Serial.println();
    Serial.println("8-channel relay test started");
}

void loop()
{
    sequentialTest();
    delay(1500);

    runningLightTest();
    delay(1500);

    allRelaysTest();
    delay(3000);
}

Сам скетч отработал прекрасно, но вот в процессе перезагрузки Arduino Uno Q выяснилась крайне неприятная деталь. Это гибридная плата, состоящая из компьютера и микроконтроллера. Загружаются они по очереди. Вначале запускается Debian Linux, потом стартует Docker‑контейнер с кодом, который заливается в MCU. И пока MCU инициализируется до момента, когда загруженный код начинает работать, все реле по каким‑то причинам переходили в состояние ON. Опасность такого поведения представить очень легко.

Простейший пример — принудительная перезагрузка зависшего контроллера MPPT. Вначале следует разорвать цепь питания солнечной панели, затем аккумуляторной сборки. Подождать несколько секунд и включить их в обратном порядке: сначала батарея (чтобы контроллер мог правильно определить режим работы: 12V или 24V) и лишь потом замкнуть цепь солнечной панели. 

Конкретная последовательность зависит от модели контроллера, поэтому приоритет имеет инструкция производителя. И да, я в курсе, что для этого в идеальном варианте панель не должна генерировать энергию — быть накрыта или перезагрузка в вечернее/ночное время.

Одновременное включение всех реле может вызвать выход из строя как самих модулей, так и контроллера солнечной панели. Да и нагрузка резко вырастет, так как на эти же реле будет завязано включение элементов Пельтье и охлаждения. Решить баг надо было в первую очередь.

Поиск глитча

Я решил воспользоваться подручными средствами, а именно — хоббийным «игрушечным» осциллографом DSO138. Валера, настало твое время. Я подключил его к одному из каналов управления IN и стал смотреть, что происходит, если вручную начать переводить реле из состояния OFF в ON.

Хорошо видно: в штатном режиме на IN приходит 3.3V (уровень HIGH). В этом положении реле выключено. Как только MCU подает сигнал LOW, мы видим просадку до нуля — и реле включается.

Теперь давайте глянем, что происходит в момент загрузки платы, когда все реле на обоих модулях самопроизвольно переходят в состояние ОN:

Хорошо видно, что пока MCU находится в каком‑то среднем неопределенном состоянии, на Digital‑пинах Arduino Uno Q присутствует чуть более 1V, которое в какой‑то момент проседает до нуля. Изначально я подумал — может, оптрону хватает этого небольшого напряжения, чтобы открыть транзисторы и включить все реле? 

Подобное решается двумя способами:

1. Подтянуть каждый IN вход реле на 3.3V через резистор, например 4.7kΩ. Таким образом HIGH сохранится, ток через светодиод оптрона не пойдет и реле останется выключенным.

2. Повесить дополнительный резистор того же номинала, что и R2 (в моем случае 1kΩ) с базы транзистора на землю. Это по факту делитель напряжения, что может удержать транзистор от открытия из‑за ложного сигнала зависшей базы.

Эксперимента ради попробовал первый вариант с подтяжкой на 3.3V. С одной стороны, трюк сработал и во время ребута до инициализации MCU сохранялся сигнал HIGH. Но потом все реле вновь включились, а у меня отобразилась вот такая картина:

Ничего не напоминает? Правильно — штатную команду от MCU с замыканием пина на землю. Реле включались не из‑за того, что присутствовало небольшое напряжение, а потому, что в процессе инициализации GPIO на некоторое время притягивается к земле либо переводится в состояние, эквивалентное LOW для входа релейного модуля. Следовательно, обойти это вторым способом с делителем напряжения или программно не получится.

Вывод однозначен: пока MCU перезагружается, нельзя ему давать управлять реле. Самый простой способ — оторвать VCC от оптронов и сделать подачу VCC через таймер. Плох он лишь тем, что в случае если плата задержится с инициализацией, глитч вновь сработает, а этого как раз хотелось бы избежать. Поэтому я выбрал более сложный, но и надежный способ — разорвать питание катушек JD‑VCC и подавать его только когда инициализация завершена и MCU начал исполнять скетч.

Продолжение следует…

Да, сейчас вопросов больше, чем ответов. Впереди организация активного охлаждения для элементов Пельтье, увеличение емкости аккумуляторов, добавление пары солнечных панелей и окончательное решение вопросов с найденным глитчем. Параллельно я пытаюсь разобраться с тем, как правильно размножить саженцы и работой TDS‑метра.

Третья часть выйдет уже совсем скоро! Вы пока подписывайтесь на блог МТС, чтобы не пропустить новые материалы, а я очень жду ваших комментариев и советов по охлаждению и отводу тепла от элементов Пельтье — пока это самый энергозатратный и проблемный вариант, но лучшего придумать не удалось.