Буфер sim800

edem · 31.Декабрь.2025 09:58:19

добрый день я сделал небольшой логер на lgt8f328+сим800, данные с датчиков отправляются постзапросом, все как бы ок

11:15:09.482 → AT+HTTPPARA=“CONTENT”,“text/plain”
11:15:10.536 → AT+HTTPPARA=“USERDATA”,“X-Device-IMEI: 868428045XXXXX”
11:15:11.680 → AT+HTTPDATA=238,15000
11:15:14.752 → 2093;0;978704424;60
11:15:14.752 → 2093;1;985969704;60
11:15:14.799 → 5143;2;1051913256;60
11:15:14.799 → 3675;3;157573416;60
11:15:14.844 → 2100;0;978704424;30
11:15:14.844 → 2100;1;985969704;30
11:15:14.889 → 5037;2;1051913256;30
11:15:14.889 → 3675;3;157573416;30
11:15:14.935 → 2118;0;978704424;0
11:15:14.935 → 2112;1;985969704;0
11:15:14.981 → 4868;2;1051913256;0
11:15:14.981 → 3675;3;157573416;0

и 238 байт проходит норм, т.е это 3 измерения с 4 датчиков. но это край. Это ограничение буфера sim800 или куда можно посмотреть?

цель влезть в тариф iot, там 20мб. если б 300 байт в посылку запихнуть было бы норм.

MMM · 31.Декабрь.2025 10:13:34

Вы уверены, что в данных третьего датчика - 1051913256 - вам нужны все цифры? Не будет достаточно округлить ее до 1051000000 и, соответственно, передавать только 4 значащие цифры?
Как раз примерно столько и выиграете в обьеме, как при увеличении размера буфера с 238 до 300 байт.

edem · 31.Декабрь.2025 10:31:44

Да, все верно, но я подумывал о риске коллизий. …хотя вряд ли это коснется моего изобретения. Возьму 4 последних байта. А по поводу буфера gprs модуля глухо, нет вариантов?

MMM · 31.Декабрь.2025 10:41:56

если это ответ на мое сообщение #2 - то я ничего не понял… При чем тут коллизии? Я вам предложил просто переформатировать данные, на передачу это не должно влиять никак.

edem · 31.Декабрь.2025 10:48:23

я прикинул это я без труда еще одно измерение смогу всадить в запрос. Т.е это экономия на каждом 4 запросе. Норм

я про повторы. На одну адуину я вешаю не более 8 датчиков и для одного устройств вообще все отл.,но устройств много , все это летит в одну базу.

edem · 31.Декабрь.2025 11:21:11

14:08:31.765 → AT+HTTPDATA=223,15000
14:08:34.845 → 2162;0;976;90
14:08:34.845 → 2162;1;3936;90
14:08:34.845 → 4681;2;304;90
14:08:34.890 → 3675;3;291;90
14:08:34.890 → 2118;0;976;60
14:08:34.890 → 2112;1;3936;60
14:08:34.937 → 5106;2;304;60
14:08:34.937 → 3687;3;291;60
14:08:34.937 → 2112;0;976;30
14:08:34.983 → 2112;1;3936;30
14:08:34.983 → 5043;2;304;30
14:08:34.983 → 3687;3;291;30
14:08:35.029 → 2112;0;976;0
14:08:35.029 → 2112;1;3936;0
14:08:35.029 → 4975;2;304;0
14:08:35.074 → 3681;3;291;0
14:08:36.273 → AT+HTTPACTION=1

ну такое вот замутил,


unsigned long sensorAddressDecimal = 0;
for (int j = 0; j < 4; j++) {
// Берем Thermometer[4], Thermometer[5], Thermometer[6], Thermometer[7]
sensorAddressDecimal += (unsigned long)Thermometer[j + 4] << (j * 8);
}
uint16_t shortId = sensorAddressDecimal % 10000; // 0-9999

норм! на 1,2,3 датчиках будет вообще самолет.

edem · 31.Декабрь.2025 13:54:54

по итогу: 4 датчика, период 30сек, 30 посылок в час(каждые 2 минуты), 480 измерений - 40кб в час, 28 МБ в месяц.
т.е посылка с 16 записями и ответом где-то 1300 байт, из них полезного (измерений) около 230 байт

230/1300= около 17% , интересно нормальная это эффективность для http? надо покопаться в rested, может удаться с этого камня выжать еще немного воды.

BOOM · 31.Декабрь.2025 14:13:38

40кб в 1 час = 960кб в сутки, 960кб * 31 (максимальное количество дней в месяце) = 29Мб.
Ну в принципе да.

Но это если отправка прошла по utp с первого раза. А по факту будет tcp (с подтверждающими обратными пакетами), считается и исходящий трафик и трафик подтверждения пакета, и отправка может пройти не с первого раза хорошо. Поэтому я бы умножал на 1.25
А это значит уже 36Мб. Ну я бы как «параноик» рассчитывал на 40Мб.

Протестируй месяца три четыре и потом расскажешь.

edem · 01.Январь.2026 18:56:37

из биллинга оператора.
Сейчас поднял билинг который раньше делал на Get запросах. Отправлял 1 измерение каждые 30 сек, такое же количество измерений.

здесь получалось около 450 кб в час, 365 мб в месяц.
Разница колоссальная, эффект очевиден. Да и заморочек не так уж, много. Накопили в буфер, выставили смещение, отправлии на веб сервер. Ну а там уже дело техники, нужно всего лишь положить данные в sql базу с учетом смещения.

Можно был и в Геты напихать несколько измерий, но мне эта идея как-то на зашла, парсинг получался какой-то кривой, забросил.
Счас вот писал это и пришла такая мысль, можно было в один get параметр строку всего измерения запихивать. Ну да ладно какнить в следущий раз. Кстати, длина гет запроса может стать ограничением.

BABOS · 02.Январь.2026 13:26:17

а че полный код зажали ?)))

sim800.print("AT+HTTPDATA=500,30000\r\n");
delay(2000);  // дать время на ответ 
SerialGSM.begin(115200);// не меньше!

может пригодится, и вот это еще

// 1. Инициализация HTTP
sim800.println("AT+HTTPINIT");
delay(1000);

// 2. Настройка параметров
sim800.println("AT+HTTPPARA=\"URL\",\"http://server.com/api\"");
delay(500);
sim800.println("AT+HTTPPARA=\"CONTENT\",\"application/json\"");
delay(500);

// 3. Отправка данных
sim800.println("AT+HTTPDATA=238,15000");
delay(1000);
sim800.println(payload);
delay(15000);  // ждем DOWNLOAD

// 4. Выполнение POST-запроса
sim800.println("AT+HTTPACTION=1");
delay(5000);   // ждем ответа сервера

// 5. Чтение ответа (опционально)
sim800.println("AT+HTTPREAD");
delay(2000);

// 6. ОБЯЗАТЕЛЬНО: Завершение сессии
sim800.println("AT+HTTPTERM");
delay(500);

edem · 03.Январь.2026 18:58:30

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

edem · 08.Январь.2026 06:00:19

08:37:01.337 -> AT+HTTPPARA="USERDATA","X-IMEI: 12345604519907\r\nX-PRD: 30000\r\nX-PWR: 16\r\nX-OPR: MTS\r\nX-CNT: 4"
08:37:02.512 -> AT+HTTPDATA=208,15000
08:37:05.732 -> 199;976;12
08:37:05.732 -> 200;3936;12
08:37:05.732 -> 470;304;12
08:37:05.732 -> 378;291;12
08:37:05.732 -> 198;976;9
08:37:05.732 -> 200;3936;9
08:37:05.732 -> 485;304;9
08:37:05.732 -> 377;291;9
08:37:05.732 -> 198;976;6
08:37:05.732 -> 198;3936;6
08:37:05.732 -> 500;304;6
08:37:05.732 -> 378;291;6
08:37:05.732 -> 198;976;3
08:37:05.732 -> 198;3936;3
08:37:05.732 -> 511;304;3
08:37:05.732 -> 376;291;3
08:37:05.732 -> 198;976;0
08:37:05.732 -> 198;3936;0
08:37:05.732 -> 513;304;0
08:37:05.732 -> 376;291;0
08:37:06.910 -> AT+HTTPACTION=1

отказался от сотых градусов
в смещении убрал 0
что позволило увеличить измерений с 16 до 20
вкинул в заголовок http еще коекакую инфу (разберусь с ней потом на стороне сервера, сигнал, количество датчиков, дискретность измерений)

По расчету для 4х датчиков выхожу на 15мб трафика. И это с дискретностью показаний 30 сек.
А идеи по оптимизации все не заканчиваются….

По итогу хочу прийти к Индивидуальной Дискретизации Каждого датчика.
т.е Уличный датчик - на кой его дергать и отправлять каждый 30 сек - 3-4 минут за глаза
Температура в помещении - 2 минут
Ну по остальным надо более подробно потому как надо.
Т.е с сервака устанавливаю каждому датчику множитель к базовой дискретизации , уличный 30сек*6, датчки в помещениях * 4

Гетом раз в час , а можно и в сутки забираю настройки , записываю в еепром. и кручу отправку уже с учетом этих множителей.

andycat · 08.Январь.2026 16:29:01

Давно давно…был проект, там тысячи устройств, счёт трафика шёл на экономии даже не мегабайт, а отдельных байт.
Так вот, операторы считают даже длину пакета tcp/ip пакета.
Отсюда совет : хотите сократить отправку данных - придумайте побитную упаковку отправляемых данных и отправляйте например одной строкой в dbase64.

BOOM · 08.Январь.2026 16:34:15

Думаю если было дело «давным-давно», то могло многое поменяться…

andycat · 08.Январь.2026 16:41:45

Не, устройства работают, операторы просто перестали давать корпоративные тарифы с минимальными тарифицируемыми объёмами в десятки байт. Соответственно и экономия трафика уже не стоит вопрос, все равно за сотню килобайт платить при малейшем подключении

edem · 08.Январь.2026 16:57:21

Насколько я понял проблему, основным баластом являются “накладные расходы” http трафика, служебные заголовки и т.д. Например, отправляя GET запрос, сколь малые данные он бы не нес, трафик туда сюда составит около 1к. Наиболее выгодным являет отправка POST запрос с набором измерений. Но все равно, сейчас результаты такие, отправка 200 байт полезных х данных -это 1.2к итого на круг. Ужав 200 байт в 100 я не получу от слова совсем. Поэтому 2 пути:

Впихивать в запрос больше данных (смотррим название темы)
Отправлять запрос реже.
3. МQTT, или UDP. но это не моя тема. Это надо или свой сервак или vps арендовать. Мне на бесплатном хостинге норм.

По уровню оптимизации я уже приблизился к системе Zont, месяц работы тако системы обходится примерно в 30 МБ, т.е это около 15 датчиков + управление. Дискретизация Температуры там около 2.5 мин. Кроме того там есть система экономии трафика. Т.е если веб морду никто не смотрит система ничего не отправляет, как только дернул, она вываливает все накопленные данные за раз. Надо глянуть что там за модем и какой проц.

Сегодня не удалось реализовать алгоритм Индивидуальной дискретизации датчиков, но если такое будет это еще 2х кратная экономия. На этом можно будет остановиться. Хотя и здеь при обдумывании закралась проблема, если ставить множитель базовой дискретизации 5 или 6 на какой-то из датичков я не попадаю в 20 измерений, которые я могу отправить. Они будут заняты датчиками с базовой 30 сек дискретизацией. Короче, все упирается в ограничение объема полезных данных.

andycat · 09.Январь.2026 05:30:22

ничего не мешает отправлять “сырые” данные, главное чтоб вы смогли на той стороне их обработать.

edem · 11.Январь.2026 13:45:43

хостер мешает, он не хочет поднимать другие сервисы кроме Hptt и ftp . Это если vps или свой собственный тогда ничего не мешает.

MMM · 11.Январь.2026 13:56:28

По-моему вы не поняли, что вам советуют.
“Сырые данные” можно отправлять и по Http

andycat · 11.Январь.2026 14:20:39

Хостер обычно блокирует что либо кроме https трафика, sim800 умеет отправлять https. Но так же он может отправлять что угодно по 443 порту. А уж фильтрует Хостер трафик и разбирает ли он его по косточкам…вопрос сложный, надо пробовать.