epc-energy

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

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

друзья! добрый день! помогите плз разобраться! )))) начальные условия: - использую 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