реклама на сайте
подробности

 
 
 
Reply to this topicStart new topic
> Размер буффера SIM900 для передачи данных по HTTP, помогите разобраться ))))))
epc-energy
сообщение Jul 21 2014, 06:39
Сообщение #1





Группа: Новичок
Сообщений: 3
Регистрация: 21-07-14
Пользователь №: 82 298



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

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

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

- использую 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
 
Go to the top of the page
 
+Quote Post
mempfis_
сообщение Jul 21 2014, 09:17
Сообщение #2


Профессионал
*****

Группа: Свой
Сообщений: 1 001
Регистрация: 27-06-06
Пользователь №: 18 409



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

В телитах, например, есть свои ограничения на размер передаваемого блока данных (мах. 1500 байт). Внутренний буффер уарта там 4кБ. При передаче до 4х кБ проблем с передачей не было. При передаче пакетов по 40-50 кБ с задействованным управлением потоком также проблем с передачей не обнаружено. Если же молотить непрерывно без управления потоком, то были проблемы с передачей даже если посылку разбивать на блоки по 1-2 кБ и выжидать между блоками паузу, достаточную для передачи блока в модем.
Go to the top of the page
 
+Quote Post
epc-energy
сообщение Jul 21 2014, 11:14
Сообщение #3





Группа: Новичок
Сообщений: 3
Регистрация: 21-07-14
Пользователь №: 82 298



аппаратного управления потоком у меня нет... наверное причина в этом...
Go to the top of the page
 
+Quote Post
mempfis_
сообщение Jul 21 2014, 11:32
Сообщение #4


Профессионал
*****

Группа: Свой
Сообщений: 1 001
Регистрация: 27-06-06
Пользователь №: 18 409



Цитата(epc-energy @ Jul 21 2014, 14:14) *
аппаратного управления потоком у меня нет... наверное причина в этом...


Тогда вам один путь - с помощью осциллографа убедится что проблема именно в отсутствии управления потоком и искать возможность задействовать хотябы линию CTS.
Или при передаче резать посылку на блоки размера == размеру передаваемого пакета(он обычно должен задаваться в настройках) и ожидать большую паузу между блоками. Но такой вариант не гарантирует что пакет уйдёт весь. Ещё вариант организовать полный POST-запрос размером заведомо меньше чем максимальный размер пакета и размер буффера уарта модема.
Go to the top of the page
 
+Quote Post
epc-energy
сообщение Jul 21 2014, 14:06
Сообщение #5





Группа: Новичок
Сообщений: 3
Регистрация: 21-07-14
Пользователь №: 82 298



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

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

Практика показывает, что необходимо добиваться соответствия между получаемыми в конкретной реализации характеристиками и заявленными производителем. В противном случае не исключается загадочное поведение устройства, т.к. в нем остаются не решённые проблеммки.
Go to the top of the page
 
+Quote Post
mempfis_
сообщение Jul 21 2014, 14:17
Сообщение #6


Профессионал
*****

Группа: Свой
Сообщений: 1 001
Регистрация: 27-06-06
Пользователь №: 18 409



Цитата(epc-energy @ Jul 21 2014, 17:06) *
Опасение только вызывает этот внезапный ребут. что мешает ему вдруг начать ребутиться и при длине посылки которую он вроде как прожевывал...
Практика показывает, что необходимо добиваться соответствия между получаемыми в конкретной реализации характеристиками и заявленными производителем. В противном случае не исключается загадочное поведение устройства, т.к. в нем остаются не решённые проблеммки.


Как всегда стоит обновить прошивку, если она у Вас не самая последняя. Ну и общаться на форуме с представителями SIMCOM и теми, кто смог освоить данный модем и успешно обходит различные баги прошивки.
Go to the top of the page
 
+Quote Post

Reply to this topicStart new topic
1 чел. читают эту тему (гостей: 1, скрытых пользователей: 0)
Пользователей: 0

 


RSS Текстовая версия Сейчас: 23rd August 2025 - 06:46
Рейтинг@Mail.ru


Страница сгенерированна за 0.01386 секунд с 7
ELECTRONIX ©2004-2016