|
Передача данных через tcp стэк, необходимо передать пакет через модем sim300 больше чем 1024 |
|
|
|
Dec 1 2010, 15:54
|
Группа: Новичок
Сообщений: 4
Регистрация: 1-12-10
Пользователь №: 61 312

|
Доброе время суток.
Имеется модем sim300, необходимо организовать по событию передачу по gprs определенного пакета данных, с помощью at команд устанавливается соединение и через at+cipsend = length передаеться пакет указанной длины, но возникла проблема связанная с ограничением размера пакета на 1024, когда пакет превышает по размеру модем возвращает Error ? и потом почему-то пишет send ok. как можно передать пакет большим размером не разбивая его при этом? может можно увеличить как-то стэк tcp?
|
|
|
|
|
Dec 1 2010, 19:21
|
Участник

Группа: Участник
Сообщений: 46
Регистрация: 5-12-08
Из: Санкт-Петербург
Пользователь №: 42 220

|
Цитата(Vasilievich @ Dec 1 2010, 18:54)  как можно передать пакет большим размером не разбивая его при этом? может можно увеличить как-то стэк tcp? Протокол TCP вообще не умеет передавать данные "не разбивая". Например, если вы отправляете 100 байт, потом еще 500, потом еще 1 байт, на приемной стороне можете получить 576 и потом 25 байт. Следовательно, просто отправляйте данные кусочками, а на приемной стороне дожидайтесь, пока не придет целое сообщение.
|
|
|
|
|
Dec 2 2010, 07:46
|
Группа: Новичок
Сообщений: 4
Регистрация: 1-12-10
Пользователь №: 61 312

|
Цитата(av-master @ Dec 1 2010, 19:29)  передавайте в transparant mode (прозрачный режим) прозрачный режим, это отправка сообщения не фиксированной длины, а с помощью ctrl+Z?
|
|
|
|
|
Dec 3 2010, 07:43
|
Группа: Новичок
Сообщений: 4
Регистрация: 1-12-10
Пользователь №: 61 312

|
В общем если отправлять сообщения не задавая предварительно размер, а заканчивая его отправив в порт ctrl+z, то размер не ограничен  Пробовал через транспорант , тоже работает. Спасибо за помощ.
Сообщение отредактировал Vasilievich - Dec 3 2010, 07:46
|
|
|
|
|
Dec 12 2010, 21:27
|
Знающий
   
Группа: Свой
Сообщений: 624
Регистрация: 15-06-10
Из: Россия
Пользователь №: 57 939

|
Тоже актуальная для меня тема.
Нужно передать данные , но не модем-> сервер, а сервер-> модем. Данные битовые 0x00-0xFF ,т.е. насколько я понял AT+CIPSEND не катит не в каком виде, т.к. пропадут некоторые байты как управляющие символы. Данных немного. Скорость особо не важна. Надо передать 1Кб, причём разбивая по 64байта с подсчётом контрольной суммы. т.е. думаю сделать так: -прозрачный режим -шлю на сервер что типа START -в ответ ,например, 0xFF 0xFF 0xFF 0xFF 0xFF(такая последовательность не встречается в информационном сообщении) и 64 байта + байт XOR или CRC кода -если контрольная сумма совпадает то шлю NEXT иначе RETRY. -и так 16 раз; -всё пишется в буфер размером 512-1024 байта на контроллере.
И появляются банальные вопросы. 1)Вообще реально ли так сделать, НЕИСПОЛЬЗУЯ аппаратный контроль?- ну не ввёл я при проэктировании кроме TX RX и DTR ничего 2)Если использовать готовые сокеты(delphi) для сервера то не придёт ли в ПРОЗРАЧНОМ режиме кроме информации ещё и "обвес" TCP? 3)Я так понял что во время обрыва соединения в прозрачном режиме модем виснет в data mode и вывести его можно только аппаратно?
Сообщение отредактировал MKdemiurg - Dec 12 2010, 21:28
|
|
|
|
|
Dec 12 2010, 21:49
|
Гуру
     
Группа: Участник
Сообщений: 3 834
Регистрация: 14-06-06
Из: Moscow, Russia
Пользователь №: 18 047

|
Цитата(MKdemiurg @ Dec 13 2010, 00:27)  1)Вообще реально ли так сделать, НЕИСПОЛЬЗУЯ аппаратный контроль?- ну не ввёл я при проэктировании кроме TX RX и DTR ничего Реально. Если пакеты будут небольшие и после передачи пакета клиент обязательно будет ожидать ответа сервера. Цитата 2)Если использовать готовые сокеты(delphi) для сервера то не придёт ли в ПРОЗРАЧНОМ режиме кроме информации ещё и "обвес" TCP? "Прозрачно" передаются только собственно данные, все, что наложено стеком, пользователь не видит. Цитата 3)Я так понял что во время обрыва соединения в прозрачном режиме модем виснет в data mode и вывести его можно только аппаратно? Или используя последовательность "+++", соблюдая правила (пауза до, пауза после).
|
|
|
|
|
Dec 14 2010, 05:17
|
Группа: Новичок
Сообщений: 4
Регистрация: 1-12-10
Пользователь №: 61 312

|
Я тоже использую МТС Укр, и максимальное ожидание было около 7 секунд при установке соединения, а так работает довольно быстро(1-2 сек. максимум).
|
|
|
|
|
Dec 17 2010, 20:48
|
Ортодокс
  
Группа: Свой
Сообщений: 219
Регистрация: 26-10-07
Из: Смела, Украина
Пользователь №: 31 775

|
Цитата(MKdemiurg @ Dec 16 2010, 21:59)  Может некорректно задам вопрос. НУжно ли использовать CRC для контроля данных или TCP 100500% сам отсеит ошибочные данные? Не буду здесь теоретизировать, но могу сказать следующее. При удаленной перепрошивке девайса (FOTA) использую протокол XModem-1K поверх TCP/IP. Во-первых, в целях поддержания единообразия при разных технологиях доставки данных, а во-вторых береженого Бог бережет.  Так вот неоднократно наблюдал случаи (хоть и очень редкие ~ 1 раз на 20-25Мб), когда при приеме пакета обнаруживается ошибка и приходит запрос на повторную передачу пакета. В чем там именно причина разбираться некогда, тем более, что за исключением этого все работает стабильно. Но, как говорится, факт остается фактом. Как говаривал дедушка Мюллер: "Никому нельзя верить"
|
|
|
|
|
Dec 18 2010, 07:03
|
Гуру
     
Группа: Участник
Сообщений: 3 834
Регистрация: 14-06-06
Из: Moscow, Russia
Пользователь №: 18 047

|
Цитата(MKdemiurg @ Dec 16 2010, 22:59)  ato
CONNECT
а по даташиту "CONNECT OK" Насколько помнит мой склероз, в "прозрачном" режиме именно "CONNECT", так же как при CSD. Цитата(butthead2 @ Dec 18 2010, 04:10)  Подтверждаю. Достаточно редко, но бывает. Возможно виноват сам стек а не оператор. Проверку лучше сделать и не гадать кто виноват. Точно битый пакет, а не потеря ? Вообще такие вещи интересно бы проанализировать, как это выглядит "живьем". У нас наблюдалась странная вещь, когда некоторые пакеты до модема стабильно не доходили, чуть контекст менялся - и начинали стабильно доходить. Правда, UDP, и устройство не мое, и модуль SIM300, и устройство с таким багом до меня не доходило (предположительно, все это зависело от месторасположения и грешили на оператора).
|
|
|
|
|
Dec 18 2010, 07:10
|
Местный
  
Группа: Участник
Сообщений: 301
Регистрация: 22-07-09
Пользователь №: 51 470

|
Цитата(rx3apf @ Dec 18 2010, 13:03)  Точно битый пакет, а не потеря ? Точно. Сравнивал пакеты на передаче и на приеме - изменился один байт. Неправильной передачей по UART обьяснить нельзя - сдвигом битов новое значение никак не получалось
|
|
|
|
1 чел. читают эту тему (гостей: 1, скрытых пользователей: 0)
Пользователей: 0
|
|
|