Размер буффера SIM900 для передачи данных по HTTP, помогите разобраться )))))) Опции

[epc-energy]

друзья! добрый день!

помогите плз разобраться! ))))

начальные условия:

- использую SIM900 + внешний микроконтроллер.
- отлаживаю передачу данных по HTTP протоколу на удаленный сервер через GSM
- для передачи данных применяю метод POST.
- построение управляющей программы для микроконтроллера велось в соответствии с документом: sim900_at_command_manual_v1.06.pdf от производителя.

суть проблемы:

- согласно описанию АТ-команд SIM900 может передавать в POST-запросе от 1 до 318976 байт данных!!! (см описание команды AT+HTTPDATA) на практике, при некоторой длине массива данных, которые заливаются в SIM900 по приглашению "DOWNLOAD" в ответ на команду "AT+HTTPDATA=<len>,<time>" модуль отвечает "OK", а при старте POST-сессии по "AT+HTTPACTION=1" сваливается в ребут.

опытным путем определил, что граница этой критичной длинный находится где-то между 1024 - 1300 байт. подробнее выяснять не стал. при длине отправляемого пакета 1024 байта все работает отлично.

- просадки по питанию не превышают 50мВ.
- ошибку в управляющей программе полностью исключаю, т.к. проверена-перепроверена она не один десяток раз.

подскажите плз в чем и где я ошибаюсь )))))

Прикрепленные файлы

 sim900_https_at_command_set_v1_00.pdf ( 161.14 килобайт ) Кол-во скачиваний: 25

 

[epc-energy]

аппаратного управления потоком у меня нет... наверное причина в этом...

[mempfis_]

аппаратного управления потоком у меня нет... наверное причина в этом...

Тогда вам один путь - с помощью осциллографа убедится что проблема именно в отсутствии управления потоком и искать возможность задействовать хотябы линию CTS.
Или при передаче резать посылку на блоки размера == размеру передаваемого пакета(он обычно должен задаваться в настройках) и ожидать большую паузу между блоками. Но такой вариант не гарантирует что пакет уйдёт весь. Ещё вариант организовать полный POST-запрос размером заведомо меньше чем максимальный размер пакета и размер буффера уарта модема.