[Nazar Diadiun 0]

Приветствую! 

Ищу помощи в следующем вопросе:

Имеется модем А7682Е с STM32F103, который периодично отправляет данные по MQTT на брокер. Все работает отлично и написано основываясь на АТ commands manual. 
Один момент, с которым нужно поработать - это задержка отправки сообщения на брокер. Периодичность установить невозможно, так как происходит случайно (или я пока не понял). 

Для иллюстрации приведу скриншот с лог.анализатора за 15 минут работы



На скриншоте стрелками выделил места, в которых создалась задержка. Я установил QoS = 1, в таком режиме после отправки команды на передачу данных до получения +CMQTTPUB: 0,0 проходит 16 секунд с копейками. При этом значение в 16 секунд соблюдается до десятков миллисекунд. 

Когда я выставляю QoS = 0 я сразу же получаю +CMQTTPUB: 0,0 через 50-100мс, однако данные на брокер доходят с приблизительно той же задержкой. 

Проверил брокер и то, как ходят на него сообщения - задержки минимальные. Это связано с нагрузкой на сеть ? 

Благодарю каждого, кто откликнется, любая информация от меня.

[CADiLO 12]

Это нормальное явление. Погуглите MQTT latency - за 15 минут найдете много интересного.

 

[Nazar Diadiun 0]

On 6/3/2024 at 8:29 PM, CADiLO said:

Это нормальное явление. Погуглите MQTT latency - за 15 минут найдете много интересного.

 

Спасибо! 

Да, я читал про задержки в MQTT и что это не лучший протокол для отправки больших массивов данных. 

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

Я отправляю одно сообщение раз в 30 секунд, в котором 36 байт полезных данных. 

Другой вопрос, что я написал на питоне простое приложение, пока искал причину, и там за час время отправки не превысило 130мс. Из чего я справедливо делаю вывод, что это на стороне модема творится. 

Есть ли возможность нивелировать этот эффект, или скрыть его ?

[CADiLO 12]

Давайте посмотрим как работает RTOS модуля. Грубо говоря, основная задача это GSM/LTE стек и обмен с сотами.

Все остальное вторично, включая IP стеки, команды и так далее.

Оно будет выполняться только в тех "окнах" где нет работы основного процесса.

Если только GSM/LTE стеку потребуется выполнение действий, то все остальное прервется пока не выполнится главный процесс.

Это кстати хорошо видно если писать встраиваемые приложения линейно - по "контроллерному" или делать в них замкнутые циклы.

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

Скорее всего эти паузы и есть те моменты когда модуль отвечает на какой либо запрос соты или ее команду.

Теоретически можно вычислить что модуль делает в эти моменты.

Но это нужно брать софт логгера у производителя, писать лог, отправлять его на расшифровку и так далее.

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

Там самой бюрократии больше чем проблем от ошибок.

 

[Nazar Diadiun 0]

4 hours ago, CADiLO said:

Давайте посмотрим как работает RTOS модуля. Грубо говоря, основная задача это GSM/LTE стек и обмен с сотами.

Все остальное вторично, включая IP стеки, команды и так далее.

Оно будет выполняться только в тех "окнах" где нет работы основного процесса.

Если только GSM/LTE стеку потребуется выполнение действий, то все остальное прервется пока не выполнится главный процесс.

Это кстати хорошо видно если писать встраиваемые приложения линейно - по "контроллерному" или делать в них замкнутые циклы.

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

Скорее всего эти паузы и есть те моменты когда модуль отвечает на какой либо запрос соты или ее команду.

Теоретически можно вычислить что модуль делает в эти моменты.

Но это нужно брать софт логгера у производителя, писать лог, отправлять его на расшифровку и так далее.

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

Там самой бюрократии больше чем проблем от ошибок.

 

Похоже на то, что это действительно софт.момент в модеме, т.к. окно ожидания составляет всегда 16.13 - 16.15 секунды. 

Получается, что мне остается только либо отправлять пакеты чаще, либо мириться с этим ? Потому что предугадать, как я понял, этот ивент не получится. 

Спасибо за разъяснение процесса!

[CADiLO 12]

"все очень просто, сказки обман"

(с) Макаревич

А серьезно - GSM 07.07 (или ETSI) - раздел burst wind - там 16.12567 получаются из передачи умноженной на 8 секций.

 

[vit496 0]

К брокеру Mosquitto подключено несколько сотен GSM устройств, в основном на SIM800C. Никаких часто возникающих задержек в 16 сек нет.

[Nazar Diadiun 0]

8 hours ago, CADiLO said:

А серьезно - GSM 07.07 (или ETSI) - раздел burst wind - там 16.12567 получаются из передачи умноженной на 8 секций.

Так вот откуда оно всё...Буду подтягивать мат.часть, не знал что читать конкретное для понимания. 

Спасибо!

[Nazar Diadiun 0]

On 6/7/2024 at 12:59 PM, CADiLO said:

А серьезно - GSM 07.07 (или ETSI) - раздел burst wind - там 16.12567 получаются из передачи умноженной на 8 секций.

Приветствую!

Я не смог найти самостоятельно таких цифр в документах в интернете. Зато я нашел похожие цифры для LTE...Только в секции Power Saving Mode. Я его не настраивал, и не уверен есть ли он на этом модеме, но выдержка из файла
 

Quote

(T3412 Extended Timer -T3324 Active Timer)/T3412 Ratio should be > 90% in order to achieve optimum battery savings by use of the PSM feature.

There is no network recommended value but the value cannot be below: Minimum: 16 Seconds Minimum Allowed Value, calculated from: (2*DRX cycles (MNO LTE DRX cycle value (e.g. 2.56sec)) + 10 seconds (buffer time)) = 2*2.56sec + 10 seconds = 16 seconds.

Это не может быть связанно, и как можно точно отбросить ?