Как стать автором
Обновить

Комментарии 22

Разводить макетку в трассировщике? Использовать ардуину как программатор? Меня сложно удивить, но тут — получилось.

Интересно, когда ардуину начнут использовать как блок питания?
Разводить макетку в трассировщике?

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

Интересно, когда ардуину начнут использовать как блок питания?

Смешно конечно, но в процессе работы с этим проектом я всего два раза доставал блок питания, в остальное время питался от Arduino UNO, и от батарейки в самом конце. Не люблю лишние сущности, если то что есть справляется, зачем покупать/паять дополнительное железо.
Высоковольтный программатор я на бумаге разводил, не понравилось, а обвесить макетку пучком проводов, эстетика не позволяет, а так всё относительно быстро получается и выглядит неплохо.


Ну так сделайте уже следующий шаг — сделайте нормальную печатку либо сами, либо закажите где нибудь. Тем более, насколько я понял — это не разовое изделие.
Данное изделие разовое, как раз посмотреть нужно оно или нет. В остальном Вы правы, с макетками надо завязывать. Вероятно следующие изделие буду ЛУТ-ом разводить. Спасибо за замечание, мотивирует.

Видимо тут нужно пояснение… Электроника для меня скорее развлечение, очень давно, ещё в школе, разбирался с этим подробно, в итоге периодически накатывает, но не достаточно сильно, чтобы развернуться «по взрослому».
Первый раз вижу такую аккуратную пайкe на макетке. Интересная техника.

ЛУТ, конечно, попробуйте, но используйте то что Вам удобнее.
Макетки, бредборды, SMD все имеет свои достоинства и недостатки, не стоит зацикливаться
Цель — создать сенсор работающий, условно говоря, в коробке с искусственным освещением и передающий температуру и статус освещения с немедленной реакцией на изменение освещения

Извините, я настолько испорчен, или это действительно монитор для гроубокса?
это действительно монитор для гроубокса

Предполагалось какая-то автоматизация инкубатора для птиц/яиц, но там всё не серьезно, я сказал что могу, мне сказали — хотим… вряд-ли от этого будет польза, ну кроме этой статьи, разумеется.
Блин. Это было второй идеей. Всё-таки, я настолько испорчен. =)
У вас, в конце статьи, ссылка на схему с умножителем (Charge Pump), которая была тут реализована… первые две фото после КДПВ, плюс две под спойлером.
а можете пояснить почему время активности радиомодуля увеличелось в 3 раза по сравнению с 8мгц? в моем представлении в радиомудуль для отправки передается около 32 баит, и через SPI они должны уити за пару ms.
а также почему время активности микроконтролера изменилось не в 8 раз?
почему время активности радиомодуля увеличелось в 3 раза по сравнению с 8мгц?

Время активности радиомодуля, это вот этот кусок кода:
    radio.powerUp();
    network.write(header,&payload,sizeof(payload));
    radio.powerDown();

Основные задержки от powerUp/Down, теоретически он активен чуть меньше указанного времени, но не на много.

а также почему время активности микроконтролера изменилось не в 8 раз?

Наличие delay в коде, на 2ms микроконтроллер спать ведь не отправишь.
а какой тогда период времени понимается под «цикл»?
и как delay может влиять? он же в обоих случаях должен спать именно 2ms и не больше, и не меньше.
самое главное не ясно почему время работы радиомодуля 51ms, а контролера 15? контроллер же не может спать пока идет передача данных, он же ей собственно и управляет.
В целом интересно было бы узнать методику измерения/расчета тока и времени.
посмотрел код и похоже библиотека rf24 использует программный SPI соответсвенно и стандартный digitalWrite который в силу свой универсальности тратит много лишних тактов на простое дерганье битов на порте, тогда задержки становятся понятными. Может можно адаптировать под digitalWriteFast или прямую работу с портами?
Если до оптимизации дойдет дело, библиотеки, конечно, нужно будет перетряхнуть основательно, а вероятнее всего, сделать необходимое «руками».
Всё верно, измерения были не прямые, из-за накладных расходов, польза их была-бы не большой либо измерять пришлось бы слишком много. Согласен что получилось грязно, но для грубой оценки вполне пригодно. Конкретно алгоритм был следующий.

Энергопотребление: радиомодуля — return в начале loop; микроконтроллера — return перед sleep() (после powerDown радиомодуля); режим сна — return после sleep().

Время работы: [1] uptime полного цикла сбора данных и отправки — millis в начале каждого цикла; [2] 10 циклов buildStat + один полный buildStat с отправкой данных; [3] рабочий режим — полный uptime за 120s включая всю промежуточную работы и финальный сбор данных и отправку.

В итоге было получено время активности радиомодуя как [1] — ([2] — [1])/10 и микроконтроллера как [3] — [активность радиомодуля].
Спасибо за сообщение, у меня была ошибка, активность микроконтроллера на 8MHz — 4ms, ожидаемое время изменилось несущественно 733 → 739 дня.
Не совсем в тему, но какое сечение МГФТ, что на макетке заметен?
0.12 кв.мм, что-то вроде стандарта по умолчанию.
Я правильно разглядел, что у Вас это все напрямую от батарейки питается? Можно присобачить step up конвертер и вытягивать из батарейки побольше. Я недавно вот такие штуки купил – очень мелкие и делают 3.3V из практически любого меньшего напряжения.

P.S. А вообще, дешевле и проще было бы собрать это все на ESP8266 через wifi. Только по энергопотреблению, вероятно, чуть хуже получилось бы (хотя она тоже умеет глубоко спать).
В данном DC-DC конвертере не видно, что за чип использован, но думаю это не важно, схема должна что-то потреблять и вряд-ли она целесообразна, чтобы отобрать у батарейки оставшиеся 40-50mAh. ESP8266 спит не плохо, но в режиме передачи потребляет 170mA, CR2032 это не вытянет в принципе.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации

Изменить настройки темы

Истории