Jump to content
    

A7682E задерживает отправку данных по MQTT

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

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

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

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

image.thumb.png.8f841df73d9b1d8cb784a72f4214b923.png

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

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

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

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

Share this post


Link to post
Share on other sites

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

 

image.thumb.png.17843312fa8c370f2cd8329216c4a7a1.png

Share this post


Link to post
Share on other sites

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

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

 

image.thumb.png.17843312fa8c370f2cd8329216c4a7a1.png

Спасибо! 

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

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

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

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

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

Share this post


Link to post
Share on other sites

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

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

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

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

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

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

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

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

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

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

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

 

Share this post


Link to post
Share on other sites

4 hours ago, CADiLO said:

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

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

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

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

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

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

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

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

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

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

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

 

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

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

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

Share this post


Link to post
Share on other sites

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

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

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

 

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

8 hours ago, CADiLO said:

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

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

Спасибо!

Share this post


Link to post
Share on other sites

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.


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

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...