На девайсе вход Rx если висит неподключенным к выходу передатчика Tx, даже если имеет подтяюку, может «поймать» наводку от прикосновения. И получит, может получить, Serial, например, байт 'E'. Скутч BRIDGE успешно выполнит эту команду — сотрет все файлы. Не хорошо. Имеет смысл после получения байта 'E' принять ещё хотбы один-три магических байта, снизив вероятность получения 'мусора' по Serial.
Каскад из if… else заменил бы на switch/case: switch( Serial.read() ) {
case 'D':
...
case 'M':
...
они в железном ящике. ок, учтём.
тут это совсем не важно.
Не сочтите что докапываемся по мелочам, но вопросы, относящиеся к метрологии, не так банальны как Вам могут показаться.
На пальцах поясню. Наверняка используете резисторы 5%, как правило у них ткс в зависимости от типа 50-200ppm. Т.к. Ваше железо работает в ящике на улице, то летом может быть +50, а зимой -20, т.е. общая дельта ~70град. Т.е. изменение сопротивления для 5%-резистора может быть в %% 0,35-1,4 при изменении температуры, т.е. с учетом разброса по номиналу сопротивления в 5% общее изменение с учетом климатики работы оборудования 5,35-6,4%. Как видите, легко по погрешности только уже по сопротивлению вываливаетесь из настроенных параметров границы срабатывания.
Да, на это можно и закрыть глаза на 1, 2… прототипах.
статья в основном про CCNet
А Вы не боитесь, что возможно переполнение стека при обращении к sendCCNET, т.к. используете вложенные вызовы?
По существу.
1. Выпиливайте все закомментированные куски кода, когда выкладываете исходник для публикации.
2. Зачем делать инициализацию перемменых «char rOld=0;», а потом в setup переинициализировать «rOld=EEPROM.read(9);»?
3. Из АЦП читается мгновенное значение «int key = analogRead (5);» и по мгновенному значению «key» сразу переключаете реле. Поэтому понятно, почему Вы ранее в своей статье писали «для исключения дребезга реле, числа в условиях подбираются опытным путём». Пример одной из Ваших границ из кода, которую Вы подбирали,: «if(key>920 && key<980) setRele(1);». Что составляет ~6% от динамического диапазона АЦП. Аналогично по другим границам.
Поясню. У Вас в схеме, т.к. не видел и могу лишь только предполагать, что в Вашем девайсе есть компоненты с изменяемым потреблением, реле, светодиоды и прочее. А так же т.к. Вы используете Arduino Uno R3, то фильтрация по опорному напряжению для АЦП никакое. У вас скачет питание, работаете с мгновенными значениями. Вот Вы и получаете танцы с бубном при настройке. Так же будете шаманить, когда будете делать второй комплект оборудования.
Решение. Оптимально сделать свой контролер. Но можно и доработать Arduino Uno R3, поставить отдельный фильтр на питание АЦП VAref, а лучше отдельный линейный стабилизатор. Ввести программный фильтр на АЦП: либо усреднять, это проще для понимания, либо добавить хотябы КИХ фильтр первого порядка, например: #define ALFA 16
float key_filt, key_filt1;
key_filt = key_filt1 + ( key_filt - key_filt1 ) / ALFA;
key_filt1 = key_filt;
key = (int)key_filt;
где ALFA – определяет полосу фильтра.
Тогда и помехоустойчивое кодирование нужно тащить с собой.
А это уже от конкретной задачи зависит. Например, в CD-дисках есть большая вероятность повреждения информации, царапины на поверхности и пр., поэтому и кодируется информация на аппаратном уровне с использованием кодов Рида — Соломона, исправляющих ошибки, в несколько слоев, на фрейм и на блок.
Верно ли я понимаю, что автор сделал и поделился наработками системы, которая может быть универсальной платформой сбора «медленной» телеметрии? (если доработать датчики)
Универсальная платформа — это громко сказано. Скажем так, оптимально и функционально в данный момент времени и для данной задачи. Плюс в том что датчики беспроводные, не надо тянуть провода, а это не всегда целесообразно и можно сделать, и с большим сроком автономности работы.
Есть и моменты, на которые и сам автор акцентирует. Например, на потери пакетов, т.к. нет подтверждений. Если изменить логику транспортного протокола, добавить хоты бы подтверждение, то потери могут свестись к минимуму. А если добавить еще и шифрование, то систему сложно будет «взломать».
Количество рекламаций от конечных пользователей 'глючных' девайсов и есть объективные цифры. Да, детская болезнь. Лет ~20 назад столкнулись с такой проблемой. В наших приборах иногда пропадали сохраняемые данные. Пропадали именно в момент включения/выключения устройства. Схемотехнические переделки, вочтог, контроллеры питания почти сняли проблему. Полностью вылечили контролем достоверности данных — crc/хэш.
Для регистров процессора и ОЗУ (с помощью которых считают CRC) это утверждение тоже справедливо?
Отчасти, да. Для 8-битников это не столь актуально, а для более сложных кристаллов, да. Например, для кортексов m3 есть аппаратный обработчик «Memory management fault», не говоря уже о прочих аппаратных обработчиках исключений.
Проблема не надумана. Начнем с того, что данные в EEPROM сохраняются не вечно. Производители не нормируют длительность времени сохранения данных.
Так же реально может произойти недостоверность записи данных, например, при пониженном питании. Влияет и количество записей/стираний, и условия эксплуатации.
Да же если данные с crc или счетчиками были успешно записаны и тут же проверены, со временем они могут пропасть/исказиться в силу физики EEPROM. Поэтому счетчики тут не помогут, например, записали — прочитали — все в норме, а со временем информация исказиться. А вот crc или хэш с очень высокой долей вероятности выявит искажения в данных. CRC защищает именно данные, а счетчики позволяют сказать только что данные сохранились.
Можно существенно сэкономить на потреблении, свести потребление к 0 в Standby, немного изменив схему и слегка подправив код в части включения и выключения. Убирается IC3, в R9 и R10 так же нет смысла. Геркон S1 подключается в разрыв питания. Параллельно S1 ставиться P-канальный ключ, bsh205, затвор подтянут высокоомным резистором к GND, а так же затвор подключается к любому порту gpio.Ключ по умолчанию выключен. При замыкании S1 на контроллере будет питание. Контроллер переводит затвор в 1. Да же если S1 разомкнется в параллель установленный P-канальный ключ обеспечит питание схемы. Выключение – подача на затвор 0 и перевод микроконтроллера в Standby.
Каскад из if… else заменил бы на switch/case:
switch( Serial.read() ) {
case 'D':
...
case 'M':
...
}
Не сочтите что докапываемся по мелочам, но вопросы, относящиеся к метрологии, не так банальны как Вам могут показаться.
На пальцах поясню. Наверняка используете резисторы 5%, как правило у них ткс в зависимости от типа 50-200ppm. Т.к. Ваше железо работает в ящике на улице, то летом может быть +50, а зимой -20, т.е. общая дельта ~70град. Т.е. изменение сопротивления для 5%-резистора может быть в %% 0,35-1,4 при изменении температуры, т.е. с учетом разброса по номиналу сопротивления в 5% общее изменение с учетом климатики работы оборудования 5,35-6,4%. Как видите, легко по погрешности только уже по сопротивлению вываливаетесь из настроенных параметров границы срабатывания.
Да, на это можно и закрыть глаза на 1, 2… прототипах.
А Вы не боитесь, что возможно переполнение стека при обращении к sendCCNET, т.к. используете вложенные вызовы?
1. Выпиливайте все закомментированные куски кода, когда выкладываете исходник для публикации.
2. Зачем делать инициализацию перемменых «char rOld=0;», а потом в setup переинициализировать «rOld=EEPROM.read(9);»?
3. Из АЦП читается мгновенное значение «int key = analogRead (5);» и по мгновенному значению «key» сразу переключаете реле. Поэтому понятно, почему Вы ранее в своей статье писали «для исключения дребезга реле, числа в условиях подбираются опытным путём». Пример одной из Ваших границ из кода, которую Вы подбирали,: «if(key>920 && key<980) setRele(1);». Что составляет ~6% от динамического диапазона АЦП. Аналогично по другим границам.
Поясню. У Вас в схеме, т.к. не видел и могу лишь только предполагать, что в Вашем девайсе есть компоненты с изменяемым потреблением, реле, светодиоды и прочее. А так же т.к. Вы используете Arduino Uno R3, то фильтрация по опорному напряжению для АЦП никакое. У вас скачет питание, работаете с мгновенными значениями. Вот Вы и получаете танцы с бубном при настройке. Так же будете шаманить, когда будете делать второй комплект оборудования.
Решение. Оптимально сделать свой контролер. Но можно и доработать Arduino Uno R3, поставить отдельный фильтр на питание АЦП VAref, а лучше отдельный линейный стабилизатор. Ввести программный фильтр на АЦП: либо усреднять, это проще для понимания, либо добавить хотябы КИХ фильтр первого порядка, например:
#define ALFA 16float key_filt, key_filt1;
key_filt = key_filt1 + ( key_filt - key_filt1 ) / ALFA;
key_filt1 = key_filt;
key = (int)key_filt;
где ALFA – определяет полосу фильтра.
А это уже от конкретной задачи зависит. Например, в CD-дисках есть большая вероятность повреждения информации, царапины на поверхности и пр., поэтому и кодируется информация на аппаратном уровне с использованием кодов Рида — Соломона, исправляющих ошибки, в несколько слоев, на фрейм и на блок.
Универсальная платформа — это громко сказано. Скажем так, оптимально и функционально в данный момент времени и для данной задачи. Плюс в том что датчики беспроводные, не надо тянуть провода, а это не всегда целесообразно и можно сделать, и с большим сроком автономности работы.
Есть и моменты, на которые и сам автор акцентирует. Например, на потери пакетов, т.к. нет подтверждений. Если изменить логику транспортного протокола, добавить хоты бы подтверждение, то потери могут свестись к минимуму. А если добавить еще и шифрование, то систему сложно будет «взломать».
Количество рекламаций от конечных пользователей 'глючных' девайсов и есть объективные цифры. Да, детская болезнь. Лет ~20 назад столкнулись с такой проблемой. В наших приборах иногда пропадали сохраняемые данные. Пропадали именно в момент включения/выключения устройства. Схемотехнические переделки, вочтог, контроллеры питания почти сняли проблему. Полностью вылечили контролем достоверности данных — crc/хэш.
Отчасти, да. Для 8-битников это не столь актуально, а для более сложных кристаллов, да. Например, для кортексов m3 есть аппаратный обработчик «Memory management fault», не говоря уже о прочих аппаратных обработчиках исключений.
Проблема не надумана. Начнем с того, что данные в EEPROM сохраняются не вечно. Производители не нормируют длительность времени сохранения данных.
Так же реально может произойти недостоверность записи данных, например, при пониженном питании. Влияет и количество записей/стираний, и условия эксплуатации.
Да же если данные с crc или счетчиками были успешно записаны и тут же проверены, со временем они могут пропасть/исказиться в силу физики EEPROM. Поэтому счетчики тут не помогут, например, записали — прочитали — все в норме, а со временем информация исказиться. А вот crc или хэш с очень высокой долей вероятности выявит искажения в данных. CRC защищает именно данные, а счетчики позволяют сказать только что данные сохранились.