С коммутацией батареи в обход преобразователя (чтобы схема могла быть запитана напрямую с батареи, а не через диод преобразователя) напортачил, что привело к неработоспособности узла в целом. Желание одной ногой МК управлять и разрешающим работу DC-DC пином и ключом на полевиках привело к тому, что в момент переключения возникает конфликт устройств и линия питания оказывается в состоянии близком к закорачиванию на землю. Убрал совсем, чтобы в следующей версии сделать раздельное управление.
Переписал весь софт, существенно упростив и сократив его, попутно соптимизировав алгоритм, не забывая ложить процессор в сон везде, где это только возможно. Раньше sleep использовался только во время ожидания окончания процесса преобразования датчиков, теперь процессор спит даже в моменты, пока идет передача данных по интерфейсам (I2C и SPI). Т.е. записал регистр на передачу, сформировал условия старта и в слип. Ядро спит, периферия работает. Пришел ответ от устройства, процессор проснулся и либо прочитал ответ, либо зарядил новую передачу. Весь цикл работы по опросу трех датчиков (+замеры напряжений силами самого МК), формированию пакета для отправки и самой передачи данных занял приблизительно 200 миллисекунд. Это время могло бы быть намного меньше (почти в десять раз), если бы не главный тормоз -- датчик освещенности. Пока размышляю над тем, стоит ли его опрашивать каждый раз или есть смысл делать пропуски в циклах измерений. И у того и у того решения есть свои "за" и "против". Если делать пропуски, то цикл измерений существенно сократится. С другой стороны, 200мс измерений на фоне минутного стендбая между измерениями -- это совсем немного, чтобы серьезно озабочиваться этим вопросом.
В CubeMX есть простенький калькулятор потребляемой мощности, где довольно грубо можно прикинуть, сколько МК станет жрать в полном цикле для моих условий. Усредненное энергопотребление вписывается в пределы 20-30мка, причем считал я так, что все неопределенности и двусмысленности трактовались в пользу повышения энергопотребления. Так данная версия калькулятора умеет считать слип только для режимов, когда вся периферия либо включена, либо выключена. У меня в слипе работает только одно периферийное устройство, но в расчет я заносил данные, будто вся периферия активна. То же самое относится и к датчикам. Считал грубо, что на весь цикл преобразований они потребляют по максимуму, хотя это не так. В конечном итоге оно насчитало мне, что даже с пары солевых батареек АА оно должно работать более полутора лет. Не сильно доверяя этим данным, просто принял к сведению, что утройство теоретически может проработать больше двух-трех месяцев и от этих элементов, что меня вполне устраивает.
Дальше провел натурные испытания по замеру потребления в условиях комнатной температуры. Здесь пошли неожиданности. Неожиданности для меня, но закономерности, если смотреть на схему беспристрастно, как потом выяснилось. Главная "неожиданность" заключалась в том, что даже при переходе устройства в стендбай потребление не падало ниже 1.6ма, что было на несколько порядков больше ожидаемого. После недолгих поисков с отключением частей схемы был найден и виновник. Им оказался передатчик NRF24L01+. После изъятия этого модуля из схемы потребление резко снижалось, что оказывалось даже меньше моих первоначальных ожиданий. Первая мысль была обвинить китайцев насчет их безыскусных подделок, но решил сначала все же разобраться.
На время замеров я использовал для питания устройства пару NiMH аккумуляторов, выдававших в сумме около 2.5в, что при выключенном DC-DC и с учетом падения на диоде, давало где-то 2.25-2.3в на линиях питания датчиков и МК. На таком питании все устройство функционировало без проблем и замер китайским тестером (чья точность, конечно, тоже под большим вопросом, но больше измерить нечем) тока потребления показывал значения в 5-6 микроампер в стендбае. Включение DC-DC приводило к тому, что напряжение на линиях питания датчиков и МК становилось 3.39в, а потребление увеличивалось до 16-19мка (речь опять про периоды, когда устройство спит). Попробовал питать преобразователь с одного элемента АА. Все запускается и работает без каких-либо проблем, но ток с батареи тянет уже значительно больший -- 40-60мка (стендбай). Смысл возникающей разницы в цифрах, думаю, понятен.
Возвращаюсь к "чудесам" с передатчиком. Как известно, любое самое необъяснимое чудо имеет в своей природе самое простое и незамысловатое объяснение, если разобраться. Так и тут. Выяснилось, что передатчик, повешенный на длинных проводах, очень отзывчив на наводки, возникающие в этих самых проводах, после того, как МК ушел в стендбай и вывесил все свои ноги (SPI-интерфейс и управляющие линии) в отключенном состоянии. Чего уж там с ним происходит понять снаружи сложно, но потребление устройства в целом меняется, даже если просто приближать или удалять руку. Так как в мыслях у меня было, что передатчик в конечной конструкции может находиться на некотором удалении от основной платы, то совсем отказываться от проводов мне не хотелось. Ладно, уменьшил длину и выполнил соединение экранированным проводом. Потребление упало до 300-500мка, но это все равно получалось очень много. Думал-думал, но лучше, чем подтянуть через сопротивления CE и CSN к земле и питанию (один туда, другой туда), ничего не придумал. Потребление еще упало, но все равно оказывалось повышенным. Здесь мне не совсем понятна суть явления, т.к. CSN, подтянутый к плюсу обязан полностью отключать SPI, а CE на землю -- вырубить радио, но факт остается фактом -- целиком проблему это не решило. Подтянул к земле и все три линии интерфейса SPI. Наконец-то все пришло в норму.
Забыл сказать, что перед испытаниями датчики в виде китайских модулей подверглись доработке, в результате которых с них были сняты LDO и схема трансляции уровней с модуля SI7021. Доработки простейшие, но чтобы избавить от траты времени на разглядывание дорожек на модулях, если кто-то возьмется делать то же самое, помещаю здесь фотки модулей, чтобы сразу было видно, что и как там должно быть.
Несмотря на то, что используемый мной DC-DC несколько шумноват, лишенные стабилизаторов модули не показывают признаков нестабильности, в чем я специально убедился, проведя серию замеров с включенным преобразователем и выключенным. Никакой разницы мне обнаружить не удалось.
Пришло время приступить к первым натурным экспериментам. Я старался поторапливаться, т.к. дело идет к весне и очень бы хотелось посмотреть, как оно все работает при отрицательных температурах. В этой спешке я допустил ряд мелких оплошностей, которые, тем не менее, особо не сказались на результатах. Чтобы имитировать ускорение времени, я задумал выставить частоту опроса датчиков и передачи данных в шесть раз большую, чем планируется использовать при нормальной работе сенсора. По недосмотру получилось, что не в шесть, а чуть больше, т.ч. круглых цифр не вышло, но это и не повлияло ни на что особо. Длительность рабочего цикла вместо 10с вышла 8.64с. С такой периодичностью сенсор выходит из режима сна, делает замеры, отправляет результаты и снова погружается в сон. Работа в таком режиме в течении пяти суток соответствует 34-м суткам, как если бы замеры производились раз в минуту. Ровно пять суток и проводился натурный эксперимент.
Основной целью эксперимента было посмотреть, как поведут себя батарейки на холоде, в условиях приближенных к боевым. Чтобы еще больше усложнить жизнь источнику питания, было решено использовать вместо двух, только одну батарейку. Это в какой-то мере должно было изображать подсевшую пару батарей в условиях работы при включенном преобразователе (самый нагруженный режим для батарей). Использование одной батарейки, с замерами снижения напряжения на ней по ходу эксперимента, так же преследовало цель соотнести в некотором смысле полученные результаты с графиками тестирования батареек в интернете. В случае с двумя батарейками, сколь-нибудь правдоподобное соотнесение выполнить было бы сложнее. В общем, для участия в эксперименте была отыскана в хозяйстве Duracell Alkaline Battery, неизвестной степени истощенности, но выдающая напряжение в 1.6 вольта -- совсем, как новая. Плата сенсора, датчики и отсек с единственной батареей, соединенные в соответствии со схемой, были помещены на лоджию, на открытый воздух, где находились во включенном состоянии в течение пяти суток без какого либо вмешательства извне. Ватчдог в программе был выключен для упрощения отслеживания аварийных ситуаций или нештатной работы. Впрочем, нештатных ситуаций не случилось даже тогда, когда на последние полтора суток все это хозяйство замело снегом, а устройство не имело ни влагозащиты, ни даже корпуса -- просто плата с датчиками на проводах с разъемами. Так оно и производило радиовещание из под снега, уж не знаю, правда, насколько точно можно под снегом измерять, например, влажность.
Раскуривая по второму разу NRF24L01+, я полностью переписал работу с радиомодулем, теперь уже без оглядки на библиотеку от maniacbug-a, как это было сделано для первой версии. Для сигнализирования о возможных проблемах, был задействован режим с динамической длиной пакета, что позволяло дополнять "телеметрию" отладочными данными по мере необходимости. Так же за счет уплотнения первоначального формата, удалось выцарапать дополнительные четыре бита из десятибайтового пакета. Это позволило "нумеровать" пакеты передаваемых данных, облегчая отслеживание потерь при передаче. Проблема, как сохранять хоть какие-нибудь данные внутри МК, когда он выходит из стендбая и все содержимое регистров и памяти обуляется, была решена посредством задействования неиспользуемых полей регистра "будильника" (дата, час, суб-секунды), которые переживают любое событие в неизменном виде, за исключением прекращения подачи питания. Так стало возможным запоминать, какой номер пакета был в прошлый раз и сохранять между сеансами кое-какие флаги состояний.
Более внимательный анализ потерь пакетов при передаче показал, что для моих конкретных условий теряется не 10%, как в прошлый раз, а меньше 1%. Правда, тут нужно добавить, что я поднял скорость передачи до 2мбит и мощность до полной (вроде для китайских версий NRF24L01+ она составляет 2-3db, против 0db у оригинала).
За полные пять суток, которые, по идее, должны соответствовать работе устройства в течение одного месяца (чуть больше, если точнее), в условиях температур от -3 до -8, батарейка "подсела" на 50 милливольт. По данным замеров средствами МК, напряжение упало с 1.6 вольт до 1.55 вольта. Разрядный график током 100ма (что намного больше, чем в моем случае) именно для использованной мной Duracell Alkaline Battery был найден на просторах интернета и представляет собой следующее:
Не совсем корректно сравнивать данные с этого графика и полученные мной результаты скорости разряда, но некоторые предположения, из попытки приблизительного сопоставления данных, сделать все-таки можно. По графику видно, что период, в течение которого батарея "разряжается" на 50 милливольт, относится к периоду полного разряда, как очень малая величина к величине довольно большого значения. Речь, скорее всего, может идти о нескольких десятках раз. Это позволяет осторожно надеяться, что заложенный мной самим в ТЗ срок между заменами батарей -- одни раз в год, окажется существенно большим, даже с учетом всех припусков и толковании нестыковок не в мою пользу. Начинает потихоньку вырисовываться, что беспроводной сенсор на обычных батарейках не лишен перспектив стать долгоиграющим устройством.
К настоящему моменту переразвел плату с учетом всех изменений в схеме, но работу переосмысленного "обходного" коммутатора питания еще не проверял на макетке. Без этой проверки собирать устройство несколько преждевременно, т.к. особого смысла в еще одном промежуточном прототипе уже нет и следующий вариант, скорее всего, будет окончательным. Соответственно, он должен быть полностью рабочим, чтобы уже можно было показывать схему.
Совершенно не зная, может это кому-то показаться интересным или полезным, планирую все результаты моих поисков выложить сюда. Мне они уже вряд ли когда-нибудь понадобятся, т.к. я почти никогда не возвращаюсь к пройденной теме, а кто-то может и подсмотрит для себя что-нибудь любопытное. Так мне, во всяком случае, хотелось бы думать.
- Вложения
-
- BH1750_MOD_CR.jpg
- (75.49 KiB) Скачиваний: 3953
-
- SI7021_MOD_CR.jpg
- (60.72 KiB) Скачиваний: 3418
-
- BMP180_MOD_CR.jpg
- (67.75 KiB) Скачиваний: 3904