Я fram использую очень давно. С ним нет никаких проблем.
Я расписывал здесь, как даталоггер может хранить 3 месяца в fram памяти. С вот с оперативной - это проблемы. В fram закинул байт, потом ещё, потом ещё и максимум, потерять можно байт, или последнюю запись. С оперативкой сложнее, там нужно выделять память и в этих рамках только оперировать. И потом, куда скидывать из оперативки? На SD карту, тогда постоянно это делать нужно, если не скидывать и ждать наполнения, то есть риск потерять всю оперативку. Много нюансов. И с eeprom (которая адресуется как fram) есть много проблем. Она не любит много циклов перезаписи. Если брать flash, то туда писать можно только блоками, значит эти блоки нужно собрать сначала.
SD - тоже писать секторами, значит наполнение взять нужно, но пишет долго. Есть риск потерять весь файл.
В итоге, оптимально - это fram, с бесконечной перезаписью, побайтной записью и примитивной i2c.
Попробуйте, потом скажете свое мнение. Можно начать с внешней eeprom на i2c, разобраться, как она пишет, а потом воткнуть fram.
Я вас очень понимаю и сам часто визуализирую данные в виде графиков, особенно если система динамичная. А уж все АСУ ТП системы, так там любая информация - это графики. Как менялась температура, давление, расход и многое другое (PiSystem от Osi Soft, один из представителей подобного рода систем)
Здесь же, автор говорил именно про логгирование. Не хочу быть душным, но это немного другое:
Логгирование информации (журналирование) — это автоматическая текстовая запись хронологии событий, происходящих в компьютерной системе, программе или оборудовании.
Сам по себе лог — это строго текст или структурированные данные.
Ну а графическом представление, которое более информативное - это визуализация данных.
И то и другое имеет место быть и они имеют разное назначение.
Ram - это оперативка и в ней хранить как то не безопасно. Суть логгера сохранить данные, ну и забивать эту память в динамике - можно просто повешать МК при переполнении.
Использование внутренней флеш-памяти ESP32 для постоянного побайтового или построчного логирования приведет к быстрому выходу устройств из строя на реальных объектах.
Встроенная память рассчитана на 100 000 циклов записи и не факт что она их отработает. Если много логов, то спустя год - полтора могут начаться проблемы с записью и чтением. А если циклически записывать данные в одну и ту же ячейку (например, каждую секунду в цикле loop), память выйдет из строя всего за ~27 часов.
Поэтому контроллер лучше использовать как управление, а данные гонять грамотно и оптимизировано, учитывая возможности модулей и компонентов.
Они меньший ресурс имеют чем FRAM, но думаю что при нечастой записи их на век хватит.
Я так понял, SD карта требуется в случаях когда логгер куда-то жестко вмонтирован, и есть ситуация когда пропадает связь а данные требуется считать.
По сути да, и логгер всегда стоит в параллель с потоком данных и сам не занимается считыванием, иначе он становится основным датчиком с накоплением, а не логгером.
А самый оптимальный вариант - это накопление данных в EEPROM или FRAM, а потом, при заполнении переписать на SD. В новый файл, не трогая предыдущий, для сохранения. Затем проверить записались ли данные и сравнить их с тем, что лежит в EEPROM или FRAM и если все ок, то очистить EEPROM или FRAM и приготовиться писать туда опять.
Ну вам видимо нужно много попкорна, а мы так обогатительные фабрики автоматизировали и рудники, не говоря уже про банальные комнаты. Вы вообще понимаете, о чем иднт речь или так просто написать решили? Я же написал про шину rs485, а это немного промышленный стандарт, который легко поднимается где угодно, ну а питание для примитивных датчиков в пару миллиампер - не проблема, в том же кабеле вместе с rs485. Если это вам о чем-то говорит.
А где лог? Я вижу только график и он без пояснений, а лог - это обычно текст, с отметкой времени и данными. Возможно с пояснения и, заметками, отметками. Формат любой по желанию. И лог не предназначен для вывода в виде графика, в виде данных и так далее, лог нужен для того, что бы восстановить пропущенные данные в базах, увидеть и понять какие либо ошибки, а график, который представлен здесь нужен для понимания работы процесса, датчика и так далее, для поиска зависимостей, и всего того, что душа пожелает.
Эта версия, да, стоит дорого, но есть дешевле, объёмом немного меньше.
FM24V10-G на 1 мегабит, или MB85RC256V на 256 килобит. Эти стоят менее 100 рублей, но они вечные, ни одна SD карта столько не отработает и запись на них простая, я выше писал преимущества.
Так там же емкостный датчик влажности применяется, он не имеет контакта открытой меди с грунтом, соответственно окисления нет. Его ещё отдельно лаком заливают, что бы герметичность была лучше.
Очень странно, я же спросил автора, а не критиковал, а мне за вопрос кинули - 1, для меня это действительно интересно, потому что хочу сделать просто как на плате у автора, но мне ещё важна безопасность при эксплуатации.
Серьёзно? А вы в норме? Людей оскорбляете, себя ставите выше всех присутствующих, ноги о мнение других вытираете, а не адекватный здесь я?
А рот вам нужно помыть, что бы больше не говорить такой бред! И совет на будущее: если думаете что что-то знаете, перепроверьте и потом уже доказывайте, есть вероятность ошибиться и потом выглядеть по идиотски.
А самое неприятное, вы ни разу не признали ни один факт того, что ошиблись и продолжаете стоять на своём, это признак нарциссизма, эгоцентризма, и догматичности.
Это по вашему адекватность?
Прощайте и удачи вам.
Нет желания более общаться, тем более это и общением то назвать нельзя. Есть вы, есть ваше мнение и есть другое-неправильное.
А зачем такие непонятные действия делать? И потом коммутировать перед началом записи? Типа дополнительная емкость, ну тогда нужно перед ними, на линии питания диод ставить, что бы разряд шёл только с схему, а не на другие конденсаторы и стабилизаторы (если они там будут).
Я что-то похожее делал для бистабильно го реле, что бы отключать его, если пропало питание. Они же без тока не переключаться обратно, поэтому дополнительное микрореле ставил и коммутировать его так, что бы заряженные конденсаторы отрабатывали на отключающие катушки. Вам можно сделать аналогично. Коммутация конденсатора в момент отключения питания. Реле подключено на самом входе без конденсатор в, потом диод, что бы конденсаторы не удерживали катушку реле, за диодом конденсатор базовый и следом подключаемый.
Посмотрите комментарий внизу, решение очень простое.
А ещё, самая большая проблема в том, что ваше устройство никуда данные не передаёт, ни на сервер, ни в систему умного дома, просто хранит их у себя и все. При этом вы ежесекундно считываете данные, а отображает только последние из буфера. Зачем? Почему? Какова цель? Ну хотя тогда сравнивайте текущие с предыдущим и записывайте только те, которые изменились и для корректной метки времени обязательно нужны часы типа DS3231. Потому что после перезагрузки, у вас метка времени будет кривой и она будет повторяться в вашем файле. Логгирование всегда привязано к реальному времени или к порядковому номеру, если время не важно. У вас ни того ни другого, просто таймер millis / 60000. После перезагрузки МК он обнуляется.
В чем смысл тогда логгирования. Это же просто сбор данных без возможности дальнейшего использования. А потом вы что, возьмёте SD карту и с ней пойдёте к ПК переносить инфу? А куда? В Excel? Так сейчас не 2000 год, а 2026, и у вас микроконтроллер с Wi-Fi, Bluetooth, а это такие возможности!
А SD карта, в таком режиме сдохнет через 1-3 месяца, китайская за 1,5 - 2 недели.
Вместо sd карты можно установить FRAM CY15B102J, на 2 МБит (512КБайт), этого вполне достаточно что бы хранить там метку времени на 32 бита и 3 числа типа float в количестве 16384 записи. Даже если метеостанция будет каждые 10 минут снимать показания (а это слишком много), то этого объема в 16 384 записи вам хватит на 113 дней непрерывной автономной работы без перезаписи!
Но я все таки надеюсь, что и опрос будет реже и вы все таки не будете просто хранить данные на метеостанция за весь период, а будете передавать их на хост и очищать память. А запись будет только в том случае, если нет связи с хостом, иначе непонятно, зачем вообще их хранить на метеостанции. Если для прикола только.
А теперь преимуществ FRAM-памяти (CY15B102J) перед SD-картой при записи малых объемов данных (метка времени и три числа float):
В 100 раз выше скорость работы. Запись одной пачки данных во FRAM занимает всего 0,17–0,4 миллисекунды, тогда как на SD-карту текстовая строчка пишется от 10 до 40 миллисекунд из-за долгой инициализации и работы файловой системы FAT32.
В 500 раз ниже потребление тока. В момент физической записи чип FRAM потребляет около 150 микроампер, в то время как SD-карта при перезаписи флеш-массива требует от 50 до 100 миллиампер.
Практически бесконечный ресурс. FRAM выдерживает до 100 триллионов циклов перезаписи. SD-карта при постоянной циклической дозаписи мелких строчек выйдет из строя в сотни раз быстрее из-за ограниченного ресурса ячеек флеш-памяти. А дешёвая карта очень быстро, как это бывало на Raspberry Pi.
Отсутствие лишних операций с памятью. Во FRAM можно записать ровно 16–20 байт данных. На SD-карту невозможно записать блок меньше одного сектора (512 байт), поэтому системе приходится каждый раз считывать, модифицировать и перезаписывать сотни лишних байт.
Высокая надежность при внезапном отключении питания. Во FRAM данные сохраняются физически в момент отправки последнего бита. Если питание пропадет при записи на SD-карту, файловая система FAT32 может полностью разрушиться, что приведет к потере всего текстового файла.
Экономия памяти микроконтроллера. Для работы с FRAM используется простой и легкий код передачи данных по шине I2C. Для SD-карты требуется подключать тяжеловесные библиотеки для работы с файловой системой, которые занимают много оперативной и флеш-памяти контроллера.
Просто были подобные проекты и там этих граблей было так много, и что мы только не использовали. А вот вариант с FRAM стал спасением.
Это как? Заряжать конденсаторы непосредственно перед записью, когда они уже на линии питания находятся? Ничего не смущает? Они там просто будут находиться всегда заряженные на 100%.
Факты в студию. Бла бла бла не принимаются. Я вам код программы отдал, смотрите и разбирайтесь. Это и есть логгирование, если вы понимаете написанный код. Тем более на уровне МК, в моменты начала и завершения операций. Точнее не придумаешь.
пришлю вам нормальный лог) именно лог, а не непонятную штуку, как то там посчитанную)
Рот сначала помойте, и глаза,потом посмотрите на мой код программы, потом ещё 2 раза, потому ч то с первого не поймёте (вижу что вы и с второго раза порой не понимаете),ну а когда сможете разобраться, подумайте на своими словами. И вспомните эту фразу: Вы не самый умный человек на этой земле. Вы что-то знаете и что-то понимаете, но в мире есть люди умнее и это нормально. У них стоит учиться как делать правильно.
А ваш "нормальный" лог, без кода и объяснений можете напечатать на рулоне туалетной бумаги. Что с ним делать дальше, рассказывать не буду.
Статика для любого ip устройства, это нормально, тем более если мы хотим экономить на расход аккумулятора, а утопия переводить все барахло на динамику, контролировать сложнее и тем более, если оно всегда рядом и не болтается как смартфон. Вы в своём ip поле можете сделать столько миллионов адресов, сколько вздумается, и ещё это все в одну подсесть засунуть.
Для каждого случая стоит предусматривает самые оптимальные варианты. Если статика даст экономию времени в 1 секунду, то это отлично, можно использовать. Если нет необходимости заморачиваться, пусть будет динамика.
Канал можете привязать, не проблема. Главное покажите это, без "слюней".
Так сделайте и улучшите хоть что нибудь и будет вам натуралка, а не синтетика. В чем прикол воздух сотрясать?
С вашим мнением никто не спорит, оно навсегда останется вашим. Речь идёт о том, что вы стремитесь натянуть субъективные вещи на объективные. Свой опыт на чужой, считая свой - эталонным.
Вот если бы вы сказали так: У меня, нагрев был больше, в пределах 1-1.5 градусов в моем корпусе и исполнении, а время передачи составило от 5 до 6 секунд.
Да вопросов бы не было! У вас получились такие результаты, другой чип, другой корпус, другой код и другие мозги. И это нормально!
Но вы же решили сказать, что что-то будет влиять очень сильно, не зная фактов автора статьи, а я включился в дебаты, потому как для меня эти цифры ну сверх неразумные. А ещё это выглядит так: вы умны, а все идиоты, потому что думают не так как вы.
Если логи, то у вас нормальные, а у остальных - непонятная штука, как то там посчитанная. Вы считаете это нормальным и хотите что бы к вашему мнению прислушивались? Извините, но нет! Как вы к людям, так и они к вам... Предполагаю, что с вами просто никто и никогда не спорил и вы посчитали это своей силой, но это было так: он несёт свою хрень, ну да ладно пусть несёт, главное что бы работал нормально и по углам не гадил.
1) кремниевый диод с потерей 06-07В, при полном зарядке 4.2В снизит напряжение до 3.5В,а при подсаженной банке до 3х Вольт. Вполне рабочее решение.
2) поставить AP2112K-3.3 стабилизатор с управлением сна. И с входа на выход посадить как раз кремниевый диод. В режиме сна, он потребляет 0мА а сном управляет микроконтроллер.
Если напряжение аккума упало до 3,5 вольт, то для пробуждения ему хватит и 2.8В а потом запустится стабилизатор и отдаст 3,3 Вольта и запрет диод.
И тот и другой варианты рабочие, ну и диод и AP2112K-3.3 пропускают нормальные токи (AP2112K-3.3 до 200мА, кремниевый диод поболее) времени на нагрев диода не будет, потому как микроконтроллер пробуждается 30-50мсек (зависит от МК) и после включения основной ток пойдёт через стабилизатор.
3) Можно оставить и 1 стабилизатор, но потребление в холостую 55мкА, многовато и если мы максимально экономим аккум, то варианты 1 и 2.
И таким образом можно уменьшить габариты устройства, используя прямоугольный и плоский аккумулятор.
Я fram использую очень давно. С ним нет никаких проблем.
Я расписывал здесь, как даталоггер может хранить 3 месяца в fram памяти. С вот с оперативной - это проблемы. В fram закинул байт, потом ещё, потом ещё и максимум, потерять можно байт, или последнюю запись. С оперативкой сложнее, там нужно выделять память и в этих рамках только оперировать. И потом, куда скидывать из оперативки? На SD карту, тогда постоянно это делать нужно, если не скидывать и ждать наполнения, то есть риск потерять всю оперативку. Много нюансов. И с eeprom (которая адресуется как fram) есть много проблем. Она не любит много циклов перезаписи. Если брать flash, то туда писать можно только блоками, значит эти блоки нужно собрать сначала.
SD - тоже писать секторами, значит наполнение взять нужно, но пишет долго. Есть риск потерять весь файл.
В итоге, оптимально - это fram, с бесконечной перезаписью, побайтной записью и примитивной i2c.
Попробуйте, потом скажете свое мнение. Можно начать с внешней eeprom на i2c, разобраться, как она пишет, а потом воткнуть fram.
Я вас очень понимаю и сам часто визуализирую данные в виде графиков, особенно если система динамичная. А уж все АСУ ТП системы, так там любая информация - это графики. Как менялась температура, давление, расход и многое другое (PiSystem от Osi Soft, один из представителей подобного рода систем)
Здесь же, автор говорил именно про логгирование. Не хочу быть душным, но это немного другое:
Логгирование информации (журналирование) — это автоматическая текстовая запись хронологии событий, происходящих в компьютерной системе, программе или оборудовании.
Сам по себе лог — это строго текст или структурированные данные.
Ну а графическом представление, которое более информативное - это визуализация данных.
И то и другое имеет место быть и они имеют разное назначение.
Ram - это оперативка и в ней хранить как то не безопасно. Суть логгера сохранить данные, ну и забивать эту память в динамике - можно просто повешать МК при переполнении.
Использование внутренней флеш-памяти ESP32 для постоянного побайтового или построчного логирования приведет к быстрому выходу устройств из строя на реальных объектах.
Встроенная память рассчитана на 100 000 циклов записи и не факт что она их отработает. Если много логов, то спустя год - полтора могут начаться проблемы с записью и чтением. А если циклически записывать данные в одну и ту же ячейку (например, каждую секунду в цикле loop), память выйдет из строя всего за ~27 часов.
Поэтому контроллер лучше использовать как управление, а данные гонять грамотно и оптимизировано, учитывая возможности модулей и компонентов.
Да, вполне можно и эти использовать.
Они меньший ресурс имеют чем FRAM, но думаю что при нечастой записи их на век хватит.
По сути да, и логгер всегда стоит в параллель с потоком данных и сам не занимается считыванием, иначе он становится основным датчиком с накоплением, а не логгером.
А самый оптимальный вариант - это накопление данных в EEPROM или FRAM, а потом, при заполнении переписать на SD. В новый файл, не трогая предыдущий, для сохранения. Затем проверить записались ли данные и сравнить их с тем, что лежит в EEPROM или FRAM и если все ок, то очистить EEPROM или FRAM и приготовиться писать туда опять.
Да нет, не белорусских. Я правда в тенге смотрю, потому как из Казахстана. Ну вот, посмотрите сами:
Курс рубля: за 1 рубль 6 тенге. Посчитайте.
Я когда нашёл за такую цену, заказал себе 2 десятка. Есть пара проектов, куда их можно будет применить.
От 500 до 5000 Ампер, для тиристора
До 400-500 Ампер симмисторы справляются.
И это все на запуск, на постоянную работу уже идут контакторы, после запуска, но бывают исключения, когда приходится гонять все только на тиристорах.
Ну и ещё IGBT на таких токах работают, очень неплохо. Но сильно дороже.
Ну вам видимо нужно много попкорна, а мы так обогатительные фабрики автоматизировали и рудники, не говоря уже про банальные комнаты. Вы вообще понимаете, о чем иднт речь или так просто написать решили? Я же написал про шину rs485, а это немного промышленный стандарт, который легко поднимается где угодно, ну а питание для примитивных датчиков в пару миллиампер - не проблема, в том же кабеле вместе с rs485. Если это вам о чем-то говорит.
А где лог? Я вижу только график и он без пояснений, а лог - это обычно текст, с отметкой времени и данными. Возможно с пояснения и, заметками, отметками. Формат любой по желанию. И лог не предназначен для вывода в виде графика, в виде данных и так далее, лог нужен для того, что бы восстановить пропущенные данные в базах, увидеть и понять какие либо ошибки, а график, который представлен здесь нужен для понимания работы процесса, датчика и так далее, для поиска зависимостей, и всего того, что душа пожелает.
Эта версия, да, стоит дорого, но есть дешевле, объёмом немного меньше.
FM24V10-G на 1 мегабит, или MB85RC256V на 256 килобит. Эти стоят менее 100 рублей, но они вечные, ни одна SD карта столько не отработает и запись на них простая, я выше писал преимущества.
Так там же емкостный датчик влажности применяется, он не имеет контакта открытой меди с грунтом, соответственно окисления нет. Его ещё отдельно лаком заливают, что бы герметичность была лучше.
Очень странно, я же спросил автора, а не критиковал, а мне за вопрос кинули - 1, для меня это действительно интересно, потому что хочу сделать просто как на плате у автора, но мне ещё важна безопасность при эксплуатации.
А здесь на входе 220В просто делитель стоит? Я просто не вижу ни диодов ни чего-то ещё. И развязки я так понимаю нет, везде есть высокий потенциал?
Серьёзно? А вы в норме? Людей оскорбляете, себя ставите выше всех присутствующих, ноги о мнение других вытираете, а не адекватный здесь я?
А рот вам нужно помыть, что бы больше не говорить такой бред! И совет на будущее: если думаете что что-то знаете, перепроверьте и потом уже доказывайте, есть вероятность ошибиться и потом выглядеть по идиотски.
А самое неприятное, вы ни разу не признали ни один факт того, что ошиблись и продолжаете стоять на своём, это признак нарциссизма, эгоцентризма, и догматичности.
Это по вашему адекватность?
Прощайте и удачи вам.
Нет желания более общаться, тем более это и общением то назвать нельзя. Есть вы, есть ваше мнение и есть другое-неправильное.
А зачем такие непонятные действия делать? И потом коммутировать перед началом записи? Типа дополнительная емкость, ну тогда нужно перед ними, на линии питания диод ставить, что бы разряд шёл только с схему, а не на другие конденсаторы и стабилизаторы (если они там будут).
Я что-то похожее делал для бистабильно го реле, что бы отключать его, если пропало питание. Они же без тока не переключаться обратно, поэтому дополнительное микрореле ставил и коммутировать его так, что бы заряженные конденсаторы отрабатывали на отключающие катушки. Вам можно сделать аналогично. Коммутация конденсатора в момент отключения питания. Реле подключено на самом входе без конденсатор в, потом диод, что бы конденсаторы не удерживали катушку реле, за диодом конденсатор базовый и следом подключаемый.
Посмотрите комментарий внизу, решение очень простое.
А ещё, самая большая проблема в том, что ваше устройство никуда данные не передаёт, ни на сервер, ни в систему умного дома, просто хранит их у себя и все. При этом вы ежесекундно считываете данные, а отображает только последние из буфера. Зачем? Почему? Какова цель? Ну хотя тогда сравнивайте текущие с предыдущим и записывайте только те, которые изменились и для корректной метки времени обязательно нужны часы типа DS3231. Потому что после перезагрузки, у вас метка времени будет кривой и она будет повторяться в вашем файле. Логгирование всегда привязано к реальному времени или к порядковому номеру, если время не важно. У вас ни того ни другого, просто таймер millis / 60000. После перезагрузки МК он обнуляется.
В чем смысл тогда логгирования. Это же просто сбор данных без возможности дальнейшего использования. А потом вы что, возьмёте SD карту и с ней пойдёте к ПК переносить инфу? А куда? В Excel? Так сейчас не 2000 год, а 2026, и у вас микроконтроллер с Wi-Fi, Bluetooth, а это такие возможности!
А SD карта, в таком режиме сдохнет через 1-3 месяца, китайская за 1,5 - 2 недели.
Это тоже проходили и убивали карты.
Вместо sd карты можно установить FRAM CY15B102J, на 2 МБит (512КБайт), этого вполне достаточно что бы хранить там метку времени на 32 бита и 3 числа типа float в количестве 16384 записи. Даже если метеостанция будет каждые 10 минут снимать показания (а это слишком много), то этого объема в 16 384 записи вам хватит на 113 дней непрерывной автономной работы без перезаписи!
Но я все таки надеюсь, что и опрос будет реже и вы все таки не будете просто хранить данные на метеостанция за весь период, а будете передавать их на хост и очищать память. А запись будет только в том случае, если нет связи с хостом, иначе непонятно, зачем вообще их хранить на метеостанции. Если для прикола только.
А теперь преимуществ FRAM-памяти (CY15B102J) перед SD-картой при записи малых объемов данных (метка времени и три числа float):
В 100 раз выше скорость работы. Запись одной пачки данных во FRAM занимает всего 0,17–0,4 миллисекунды, тогда как на SD-карту текстовая строчка пишется от 10 до 40 миллисекунд из-за долгой инициализации и работы файловой системы FAT32.
В 500 раз ниже потребление тока. В момент физической записи чип FRAM потребляет около 150 микроампер, в то время как SD-карта при перезаписи флеш-массива требует от 50 до 100 миллиампер.
Практически бесконечный ресурс. FRAM выдерживает до 100 триллионов циклов перезаписи. SD-карта при постоянной циклической дозаписи мелких строчек выйдет из строя в сотни раз быстрее из-за ограниченного ресурса ячеек флеш-памяти. А дешёвая карта очень быстро, как это бывало на Raspberry Pi.
Отсутствие лишних операций с памятью. Во FRAM можно записать ровно 16–20 байт данных. На SD-карту невозможно записать блок меньше одного сектора (512 байт), поэтому системе приходится каждый раз считывать, модифицировать и перезаписывать сотни лишних байт.
Высокая надежность при внезапном отключении питания. Во FRAM данные сохраняются физически в момент отправки последнего бита. Если питание пропадет при записи на SD-карту, файловая система FAT32 может полностью разрушиться, что приведет к потере всего текстового файла.
Экономия памяти микроконтроллера. Для работы с FRAM используется простой и легкий код передачи данных по шине I2C. Для SD-карты требуется подключать тяжеловесные библиотеки для работы с файловой системой, которые занимают много оперативной и флеш-памяти контроллера.
Просто были подобные проекты и там этих граблей было так много, и что мы только не использовали. А вот вариант с FRAM стал спасением.
Это как? Заряжать конденсаторы непосредственно перед записью, когда они уже на линии питания находятся? Ничего не смущает? Они там просто будут находиться всегда заряженные на 100%.
Факты в студию. Бла бла бла не принимаются. Я вам код программы отдал, смотрите и разбирайтесь. Это и есть логгирование, если вы понимаете написанный код. Тем более на уровне МК, в моменты начала и завершения операций. Точнее не придумаешь.
Рот сначала помойте, и глаза,потом посмотрите на мой код программы, потом ещё 2 раза, потому ч то с первого не поймёте (вижу что вы и с второго раза порой не понимаете),ну а когда сможете разобраться, подумайте на своими словами. И вспомните эту фразу: Вы не самый умный человек на этой земле. Вы что-то знаете и что-то понимаете, но в мире есть люди умнее и это нормально. У них стоит учиться как делать правильно.
А ваш "нормальный" лог, без кода и объяснений можете напечатать на рулоне туалетной бумаги. Что с ним делать дальше, рассказывать не буду.
Статика для любого ip устройства, это нормально, тем более если мы хотим экономить на расход аккумулятора, а утопия переводить все барахло на динамику, контролировать сложнее и тем более, если оно всегда рядом и не болтается как смартфон. Вы в своём ip поле можете сделать столько миллионов адресов, сколько вздумается, и ещё это все в одну подсесть засунуть.
Для каждого случая стоит предусматривает самые оптимальные варианты. Если статика даст экономию времени в 1 секунду, то это отлично, можно использовать. Если нет необходимости заморачиваться, пусть будет динамика.
Канал можете привязать, не проблема. Главное покажите это, без "слюней".
Так сделайте и улучшите хоть что нибудь и будет вам натуралка, а не синтетика. В чем прикол воздух сотрясать?
С вашим мнением никто не спорит, оно навсегда останется вашим. Речь идёт о том, что вы стремитесь натянуть субъективные вещи на объективные. Свой опыт на чужой, считая свой - эталонным.
Вот если бы вы сказали так: У меня, нагрев был больше, в пределах 1-1.5 градусов в моем корпусе и исполнении, а время передачи составило от 5 до 6 секунд.
Да вопросов бы не было! У вас получились такие результаты, другой чип, другой корпус, другой код и другие мозги. И это нормально!
Но вы же решили сказать, что что-то будет влиять очень сильно, не зная фактов автора статьи, а я включился в дебаты, потому как для меня эти цифры ну сверх неразумные. А ещё это выглядит так: вы умны, а все идиоты, потому что думают не так как вы.
Если логи, то у вас нормальные, а у остальных - непонятная штука, как то там посчитанная. Вы считаете это нормальным и хотите что бы к вашему мнению прислушивались? Извините, но нет! Как вы к людям, так и они к вам... Предполагаю, что с вами просто никто и никогда не спорил и вы посчитали это своей силой, но это было так: он несёт свою хрень, ну да ладно пусть несёт, главное что бы работал нормально и по углам не гадил.
Есть более изящные варианты:
1) кремниевый диод с потерей 06-07В, при полном зарядке 4.2В снизит напряжение до 3.5В,а при подсаженной банке до 3х Вольт. Вполне рабочее решение.
2) поставить AP2112K-3.3 стабилизатор с управлением сна. И с входа на выход посадить как раз кремниевый диод. В режиме сна, он потребляет 0мА а сном управляет микроконтроллер.
Если напряжение аккума упало до 3,5 вольт, то для пробуждения ему хватит и 2.8В а потом запустится стабилизатор и отдаст 3,3 Вольта и запрет диод.
И тот и другой варианты рабочие, ну и диод и AP2112K-3.3 пропускают нормальные токи (AP2112K-3.3 до 200мА, кремниевый диод поболее) времени на нагрев диода не будет, потому как микроконтроллер пробуждается 30-50мсек (зависит от МК) и после включения основной ток пойдёт через стабилизатор.
3) Можно оставить и 1 стабилизатор, но потребление в холостую 55мкА, многовато и если мы максимально экономим аккум, то варианты 1 и 2.
И таким образом можно уменьшить габариты устройства, используя прямоугольный и плоский аккумулятор.