1 2 3 4 5 6 7 8 9 10 10/10 10,00оценок: 11

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

Тема в разделе "Теплицы и парники", создана пользователем Анкор Плюс, 19.05.18.

Статус темы:
Закрыта.
  1. olegmak3
    Регистрация:
    14.08.11
    Сообщения:
    496
    Благодарности:
    406

    olegmak3

    Живу здесь

    olegmak3

    Живу здесь

    Регистрация:
    14.08.11
    Сообщения:
    496
    Благодарности:
    406
    Адрес:
    Санкт-Петербург
    Вот только что с Гарденбосса последние данные
    Безымянный22.png
    Позвонил на номер, смс пришла, данные на гарденбоссе после 15 минутного ожидания не появились.
    Попробую последний вариант, если что откачусь назад.
     
  2. necrjd
    Регистрация:
    05.11.14
    Сообщения:
    145
    Благодарности:
    98

    necrjd

    Живу здесь

    necrjd

    Живу здесь

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

    Вложения:

  3. DIYMan
    Регистрация:
    19.05.13
    Сообщения:
    7.423
    Благодарности:
    6.101

    DIYMan

    Любопытный рукосуй :)

    DIYMan

    Любопытный рукосуй :)

    Регистрация:
    19.05.13
    Сообщения:
    7.423
    Благодарности:
    6.101
    Адрес:
    80 км от Краснодара
    Очень странно. В обоих логах в конце - как раз момент зависания? Если так - то понятно, почему ватчдог успокаивается, а контроллер ни на что не реагирует - он висит в цикле вычитки байт, которые должны придти. Единственное, что изменилось - это игнорирование перевода строки (т.е. чтение на 2 байта больше, по факту), и успокоение ватчдога в процессе чтения.

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

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

    DIYMan

    Любопытный рукосуй :)

    DIYMan

    Любопытный рукосуй :)

    Регистрация:
    19.05.13
    Сообщения:
    7.423
    Благодарности:
    6.101
    Адрес:
    80 км от Краснодара
    @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 при подобном затыке - я всё же сейчас попробую, как сделаю - отпишусь ;)
     
    Последнее редактирование: 23.06.19
  5. DIYMan
    Регистрация:
    19.05.13
    Сообщения:
    7.423
    Благодарности:
    6.101

    DIYMan

    Любопытный рукосуй :)

    DIYMan

    Любопытный рукосуй :)

    Регистрация:
    19.05.13
    Сообщения:
    7.423
    Благодарности:
    6.101
    Адрес:
    80 км от Краснодара
    @olegmak3 - обновил на гугльдиске, добавил настройку SIM800_INCOMING_DATA_TIMEOUT (смотреть в Configuration_MEGA_NEW.h), она по умолчанию закомментирована. Раскомментировать, оставить 10 секунд по умолчанию, перешить - и проверить.

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

    Прошу отписаться по результату, самому интересно - проблема аппаратная или программная. Кстати сказать - в предыдущей версии почему работало: потому что там минус два байта вычитывалось из порта, т. е. по факту на пропадание байт - было пофиг, т. к. запасик небольшой был. Я так думаю, во всяком - что именно в этом причина: данные в UART пропадают, помехи там, ещё чего... Проблема сложная, как понимаете, и точно - комплексная, т. е. не один программист виноват :)
     
  6. olegmak3
    Регистрация:
    14.08.11
    Сообщения:
    496
    Благодарности:
    406

    olegmak3

    Живу здесь

    olegmak3

    Живу здесь

    Регистрация:
    14.08.11
    Сообщения:
    496
    Благодарности:
    406
    Адрес:
    Санкт-Петербург
    Все сделал.
    На всякий случай- два лога. По более раннему был провал в передаче данных. Но, думаю, из-за не регистрированной на тот момент 7-ки.
    По второму логу остановов не было. Поставил на запись, завтра гляну. Как вариант подоткну резервный модем (оказывается он есть).
     

    Вложения:

  7. DIYMan
    Регистрация:
    19.05.13
    Сообщения:
    7.423
    Благодарности:
    6.101

    DIYMan

    Любопытный рукосуй :)

    DIYMan

    Любопытный рукосуй :)

    Регистрация:
    19.05.13
    Сообщения:
    7.423
    Благодарности:
    6.101
    Адрес:
    80 км от Краснодара
    Как я и предполагал - проблема аппаратная:
    За 10 секунд все данные не вычитаны, там чуть ниже видно, что часть данных вычитана. Т. е. иногда данные с UART пропадают.

    Вывод: ищем косяки в схемотехнике, помехи на линиях и т. п. ;)
     
  8. DIYMan
    Регистрация:
    19.05.13
    Сообщения:
    7.423
    Благодарности:
    6.101

    DIYMan

    Любопытный рукосуй :)

    DIYMan

    Любопытный рукосуй :)

    Регистрация:
    19.05.13
    Сообщения:
    7.423
    Благодарности:
    6.101
    Адрес:
    80 км от Краснодара
    Обновы!

    Если кто помнит, то до последнего времени была такая недоработка: при использовании 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 не может быть меньше, чем интервал отсыла показаний, настроенный в конфиге прошивки вайфайного модуля с датчиками ;)

    Не стесняемся - пробуем ;)
     
  9. olegmak3
    Регистрация:
    14.08.11
    Сообщения:
    496
    Благодарности:
    406

    olegmak3

    Живу здесь

    olegmak3

    Живу здесь

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

    DIYMan

    Любопытный рукосуй :)

    DIYMan

    Любопытный рукосуй :)

    Регистрация:
    19.05.13
    Сообщения:
    7.423
    Благодарности:
    6.101
    Адрес:
    80 км от Краснодара
    Олег, UART у меги - четыре штуки, к одному из них подключен SIM800. Любые серьёзные помехи - могут привести к потере данных ;)
     
  11. olegmak3
    Регистрация:
    14.08.11
    Сообщения:
    496
    Благодарности:
    406

    olegmak3

    Живу здесь

    olegmak3

    Живу здесь

    Регистрация:
    14.08.11
    Сообщения:
    496
    Благодарности:
    406
    Адрес:
    Санкт-Петербург
    Да, я думал о связи с внешним миром.
    При случае надо пробовать менять и мегу (хотя вроде пару лет назад и пробовал.
    А вот за напоминание о внутренних уартах спасибо, вероятно разводку к модему сделал кривовато.
    Надо смотреть.
     
  12. evgeny1241
    Регистрация:
    07.07.16
    Сообщения:
    305
    Благодарности:
    29

    evgeny1241

    Живу здесь

    evgeny1241

    Живу здесь

    Регистрация:
    07.07.16
    Сообщения:
    305
    Благодарности:
    29
    Попробую wifi завтра отпишусь сейчас не рядом с контроллером
     
  13. necrjd
    Регистрация:
    05.11.14
    Сообщения:
    145
    Благодарности:
    98

    necrjd

    Живу здесь

    necrjd

    Живу здесь

    Регистрация:
    05.11.14
    Сообщения:
    145
    Благодарности:
    98
    7.png
    Периодически получал показания влажности и температуры с DHT22 ровно в 2 раза меньше чем должно быть. Увеличил таймауты процентов на 7 в DHTSupport. cpp. Два дня показания корректные.
     
  14. DIYMan
    Регистрация:
    19.05.13
    Сообщения:
    7.423
    Благодарности:
    6.101

    DIYMan

    Любопытный рукосуй :)

    DIYMan

    Любопытный рукосуй :)

    Регистрация:
    19.05.13
    Сообщения:
    7.423
    Благодарности:
    6.101
    Адрес:
    80 км от Краснодара
    Поконкретней, пж. Дело в том, что там делалось по даташиту к DHT22, и если в вашем случае увеличение таймаутов помогло - вполне возможно, что стоит это дело вынести в настройки прошивки ;)

    Так что делитесь, где конкретно и что ;)
     
  15. necrjd
    Регистрация:
    05.11.14
    Сообщения:
    145
    Благодарности:
    98

    necrjd

    Живу здесь

    necrjd

    Живу здесь

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

Смотрите также:

Статус темы:
Закрыта.