Arduino Mega. Контроллер теплицы. Хроники - 4.0

Вот только что с Гарденбосса последние данные

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

 

да, теперь работает. Долго ждал события - пришлось накрыть конструкцию крышкой от кастрюли. Помогло. По логу было несколько ребутов - связь с ГБ восстанавливалась.

 

Очень странно. В обоих логах в конце - как раз момент зависания? Если так - то понятно, почему ватчдог успокаивается, а контроллер ни на что не реагирует - он висит в цикле вычитки байт, которые должны придти. Единственное, что изменилось - это игнорирование перевода строки (т.е. чтение на 2 байта больше, по факту), и успокоение ватчдога в процессе чтения.

Так что либо SIM800 такой, либо - схемотехника, байты пропадают. Что можно посоветовать - хз, но крайние правки, судя по документации SIM800 - правильные, и всё должно вычитываться верно. К тому же, если судить по логам - оно всё верно и вычитывается, собственно, т. к. до этого можно увидеть, что запросы проходят нормально.

Единственное, что могу сделать со своей стороны - добавить настройку таймаута чтения ответа для SIM800, чтобы долго в этом цикле не висел. Как сделаю - отпишусь. Откатываться не надо, лучше ещё раз проверить схемотехнику.

 

@olegmak3, вот тут очень странное сочетание в логах, перед зависанием:

Перевожу: данные отправили, ответ сразу не пришёл. Поскольку ответ может придти в любое время, в свободное время - пингуем GPRS, т. к. настало время для пинга. Отправили SIM800 команду для пингования, он ответил первой строкой +CIPPING:, потом уже - выплюнул +RECEIVE ответа от gardenboss, т. е. в приемном буфере с самого начала буфера лежало +RECEIVE. Контроллер начал вычитывать это дело, и - всё. Возможно, при таком сочетании SIM800 крышу сносит, хотя утверждать не буду.

Второй лог, самый конец, прошу обратить внимание на временнЫе метки (это НЕПОРЯДОК, так быть не должно, что-то в вашем железе ЖЁСТКО тупит):

Потому что между первой и второй строкой в логе - полсекунды, ни в какие ворота. А уж интервал в 6 секунд: 18:32:13.371 - 18:32:19.611 - вообще не алё.

Ещё раз НАСТОЙЧИВО предлагаю: не надо весь фарш сразу, пожалуйста. Так - не проверяется, и я не смогу понять, в чём дело. Надо просто оставить прошивку в минимальной конфигурации, как я писал выше. Это нужно хотя бы для того, чтобы точно быть уверенным, что проблема именно в SIM800, а не в тупняке где-то по железу и по помехам.

Ну введу я сейчас таймаут на чтение - толку от этого? Начнутся странности в другом месте, как пить дать. По логам-то видно, что запросы обрабатываются неоднократно, и даже вклинивание команд между отсылом запроса на gardenboss и получением ответа - нормально отрабатывает:

И даже когда пинг вклинился - всё норм:

Это всё косвенные признаки того, что проблема может быть по железной части. Конечно, списывать со счетов мои возможные ошибки - тоже не стоит, но считаю, что к решению проблемы надо подходить системно, например - есть кучу настроек, то же пингование GPRS: можно его отключить на время, чтобы посмотреть, изменилось ли что. И т. д.

Я уже не говорю, что SIM800 от китайцев тоже могут быть с разными версиями прошивок... Короче, пока с таймаутом на чтение я повременю. А сделать можно вот что: пойти в CoreTransport. cpp последней версии, и закомментировать строчки 4730 и 4745, вот эти:

а именно - вызов updateExternalWatchdog(). Если контроллер начнёт пересбрасываться по ватчдогу - значит, именно в этих циклах он висит, значит - проблема в вычитке данных с порта. Буду признателен за отзыв по проверке этого факта, а там уже будем думать, что делать

З. Ы. Ввести настройку таймаута чтения с пересбросом SIM800 при подобном затыке - я всё же сейчас попробую, как сделаю - отпишусь

 

@olegmak3 - обновил на гугльдиске, добавил настройку SIM800_INCOMING_DATA_TIMEOUT (смотреть в Configuration_MEGA_NEW.h), она по умолчанию закомментирована. Раскомментировать, оставить 10 секунд по умолчанию, перешить - и проверить.

Если проблема именно в пропадании данных в порту, то тогда в логе будут надписи типа:

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

 

Все сделал.
На всякий случай- два лога. По более раннему был провал в передаче данных. Но, думаю, из-за не регистрированной на тот момент 7-ки.
По второму логу остановов не было. Поставил на запись, завтра гляну. Как вариант подоткну резервный модем (оказывается он есть).

 

Как я и предполагал - проблема аппаратная:

За 10 секунд все данные не вычитаны, там чуть ниже видно, что часть данных вычитана. Т. е. иногда данные с UART пропадают.

Вывод: ищем косяки в схемотехнике, помехи на линиях и т. п.

 

Обновы!

Если кто помнит, то до последнего времени была такая недоработка: при использовании Wi-Fi модулей с датчиками (прошивка UniversalWiFiSensorsModule), если модуль отвалился, то в контроллере так и висели его последние показания.

Решил я это дело исправить, для чего ввёл новый модуль в прошивку контроллера. Короче - смотрим настройку USE_DYNAMIC_SENSORS_RESET_MODULE в конфигурационных файлах Configuration_MEGA_NEW.h или Configuration_DUE_NEW.h (в зависимости от платы), читаем комментарии и, если надо - пользуемся.

У кого есть ссылка на гугльдиск - качаем. У кого нет ссылки - все запросы исходников открытой версии - на spywarrior@gmail.com, пожалуйста.

З. Ы. Нововведения я лично не тестировал, но работать обязано. Буду признателен, если желающие подобного функционала - отпишутся по факту. Проверить просто: достаточно дождаться, пока с модуля появятся показания на контроллере, потом выщелкнуть модуль от питания, и подождать DYNAMIC_SENSORS_RESET_INTERVAL - после этого данные этого датчика должны сброситься.

Как понимаете, настройка DYNAMIC_SENSORS_RESET_INTERVAL не может быть меньше, чем интервал отсыла показаний, настроенный в конфиге прошивки вайфайного модуля с датчиками

Не стесняемся - пробуем

 

Как это может выглядеть?
Разъем УАРТ на меге стандартный. В него вставлен кабель USB. Тоже стандартный. Где здесь может быть схемотехника ?
Помехи по УАРТ ? Ну м. б.,м.б.
Но при работе контроллера в стандартном режиме (без отлавливания дебагов) все должно работать нормально? УАРТ-то не используем?
Советуйте, знающие...
Заранее благодарен.
Пока данные на гарденбосс идут без сбоев.

 

Олег, UART у меги - четыре штуки, к одному из них подключен SIM800. Любые серьёзные помехи - могут привести к потере данных

 

Да, я думал о связи с внешним миром.
При случае надо пробовать менять и мегу (хотя вроде пару лет назад и пробовал.
А вот за напоминание о внутренних уартах спасибо, вероятно разводку к модему сделал кривовато.
Надо смотреть.

 

Попробую wifi завтра отпишусь сейчас не рядом с контроллером

 

Периодически получал показания влажности и температуры с DHT22 ровно в 2 раза меньше чем должно быть. Увеличил таймауты процентов на 7 в DHTSupport. cpp. Два дня показания корректные.

 

Поконкретней, пж. Дело в том, что там делалось по даташиту к DHT22, и если в вашем случае увеличение таймаутов помогло - вполне возможно, что стоит это дело вынести в настройки прошивки

Так что делитесь, где конкретно и что

 

Просто, наудачу, поменял эти интервалы. Тестов, какой именно параметр повлиял, не проводил еще.
Думаю несколько дней еще проверить работу, потом по одному возвращать к даташитным.
19 const uint32_t mstcc = (F_CPU / 37000); / сторож таймаута - 100us (было 40000 вместо 37000)
51 delayMicroseconds (50); / ждём 40us, как написано в даташите (было40)
107 if (micros() - tMicros > 45) / единичка / (было40)