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

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

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

- использую 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мВ.
- ошибку в управляющей программе полностью исключаю, т.к. проверена-перепроверена она не один десяток раз.

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

При передаче больших объёмов данных необходимо управление потоком. Если оно у Вас не реализовано, то стоит потыкать осциллографом на линию CTS и проследить за её состоянием. Если модуль не в состоянии больше принимать данные, то он активирует сигнал CTS чтобы приостановить передачу. Если же у Вас есть управление потоком, но сбой присутствует, то тогда ждите ответа тех, кто работает с SIM900 или представителей SIMCOM.
Про программные особенности SIM900 ничего сказать не могу так как с ними не работаю.

В телитах, например, есть свои ограничения на размер передаваемого блока данных (мах. 1500 байт). Внутренний буффер уарта там 4кБ. При передаче до 4х кБ проблем с передачей не было. При передаче пакетов по 40-50 кБ с задействованным управлением потоком также проблем с передачей не обнаружено. Если же молотить непрерывно без управления потоком, то были проблемы с передачей даже если посылку разбивать на блоки по 1-2 кБ и выжидать между блоками паузу, достаточную для передачи блока в модем.

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

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

Спасибо большое за совет. Обязательно попробую и отпишусь о результате в течении 3-4 дней.

Пока я как раз пошел по пути сокращения POST-запроса до размера который стабильно передается (1024 байта) и мне его, в принципе хватает более чем. Опасение только вызывает этот внезапный ребут. что мешает ему вдруг начать ребутиться и при длине посылки которую он вроде как прожевывал...

Практика показывает, что необходимо добиваться соответствия между получаемыми в конкретной реализации характеристиками и заявленными производителем. В противном случае не исключается загадочное поведение устройства, т.к. в нем остаются не решённые проблеммки.

Как всегда стоит обновить прошивку, если она у Вас не самая последняя. Ну и общаться на форуме с представителями SIMCOM и теми, кто смог освоить данный модем и успешно обходит различные баги прошивки.