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

 
 
2 страниц V   1 2 >  
Reply to this topicStart new topic
> Передача данных через tcp стэк, необходимо передать пакет через модем sim300 больше чем 1024
Vasilievich
сообщение Dec 1 2010, 15:54
Сообщение #1





Группа: Новичок
Сообщений: 4
Регистрация: 1-12-10
Пользователь №: 61 312



Доброе время суток.

Имеется модем sim300, необходимо организовать по событию передачу по gprs определенного пакета данных, с помощью at команд устанавливается соединение и через at+cipsend = length передаеться пакет указанной длины, но возникла проблема связанная с ограничением размера пакета на 1024, когда пакет превышает по размеру модем возвращает Error ? и потом почему-то пишет send ok. как можно передать пакет большим размером не разбивая его при этом? может можно увеличить как-то стэк tcp?
Go to the top of the page
 
+Quote Post
av-master
сообщение Dec 1 2010, 17:29
Сообщение #2


Знающий
****

Группа: Свой
Сообщений: 857
Регистрация: 14-05-05
Из: Украина
Пользователь №: 4 998



передавайте в transparant mode (прозрачный режим)
Go to the top of the page
 
+Quote Post
Andrey Vasilyev
сообщение Dec 1 2010, 19:21
Сообщение #3


Участник
*

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



Цитата(Vasilievich @ Dec 1 2010, 18:54) *
как можно передать пакет большим размером не разбивая его при этом? может можно увеличить как-то стэк tcp?


Протокол TCP вообще не умеет передавать данные "не разбивая".
Например, если вы отправляете 100 байт, потом еще 500, потом еще 1 байт, на приемной стороне можете получить 576 и потом 25 байт.

Следовательно, просто отправляйте данные кусочками, а на приемной стороне дожидайтесь, пока не придет целое сообщение.
Go to the top of the page
 
+Quote Post
Vasilievich
сообщение Dec 2 2010, 07:46
Сообщение #4





Группа: Новичок
Сообщений: 4
Регистрация: 1-12-10
Пользователь №: 61 312



Цитата(av-master @ Dec 1 2010, 19:29) *
передавайте в transparant mode (прозрачный режим)



прозрачный режим, это отправка сообщения не фиксированной длины, а с помощью ctrl+Z?
Go to the top of the page
 
+Quote Post
av-master
сообщение Dec 2 2010, 09:36
Сообщение #5


Знающий
****

Группа: Свой
Сообщений: 857
Регистрация: 14-05-05
Из: Украина
Пользователь №: 4 998



нет это когда после соединения CONNECT можно пихать хоть мегабайты в ком порт (еслественно с аппаратным управлением потоком)
а вернуться к AT командам можно или ногой DTR или послав +++ . никаких контрол зет ненужно.
Go to the top of the page
 
+Quote Post
Vasilievich
сообщение Dec 3 2010, 07:43
Сообщение #6





Группа: Новичок
Сообщений: 4
Регистрация: 1-12-10
Пользователь №: 61 312



В общем если отправлять сообщения не задавая предварительно размер, а заканчивая его отправив в порт ctrl+z, то размер не ограничен smile.gif

Пробовал через транспорант , тоже работает. Спасибо за помощ.

Сообщение отредактировал Vasilievich - Dec 3 2010, 07:46
Go to the top of the page
 
+Quote Post
MKdemiurg
сообщение Dec 12 2010, 21:27
Сообщение #7


Знающий
****

Группа: Свой
Сообщений: 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
Go to the top of the page
 
+Quote Post
rx3apf
сообщение Dec 12 2010, 21:49
Сообщение #8


Гуру
******

Группа: Участник
Сообщений: 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 и вывести его можно только аппаратно?

Или используя последовательность "+++", соблюдая правила (пауза до, пауза после).
Go to the top of the page
 
+Quote Post
MKdemiurg
сообщение Dec 12 2010, 22:17
Сообщение #9


Знающий
****

Группа: Свой
Сообщений: 624
Регистрация: 15-06-10
Из: Россия
Пользователь №: 57 939




Спасибо за разъяснения.


Пакеты по 64 байта. Передаются от PC со статическим IP к подключившемуся модему. После передачи каждого пакета следует ответ ОТ модема серверу о приходе и запрос новых данных - как то так я это понимаю.
Кстати насколько большой таймаут стоит ставить по приёму. А то тут почитал - пишут данные по пол часа могут идти. Использую МТС УКР.


Сообщение отредактировал MKdemiurg - Dec 12 2010, 22:21
Go to the top of the page
 
+Quote Post
Vasilievich
сообщение Dec 14 2010, 05:17
Сообщение #10





Группа: Новичок
Сообщений: 4
Регистрация: 1-12-10
Пользователь №: 61 312



Я тоже использую МТС Укр, и максимальное ожидание было около 7 секунд при установке соединения, а так работает довольно быстро(1-2 сек. максимум).
Go to the top of the page
 
+Quote Post
MKdemiurg
сообщение Dec 16 2010, 16:59
Сообщение #11


Знающий
****

Группа: Свой
Сообщений: 624
Регистрация: 15-06-10
Из: Россия
Пользователь №: 57 939



Может некорректно задам вопрос. НУжно ли использовать CRC для контроля данных или TCP 100500% сам отсеит ошибочные данные?

Ещё столкнулся с багом в прошивке

AT+CGATT=1
OK
AT+CIPCSGP=1,"internet","",""
OK
AT+CIPMODE=1
OK
AT+CIPSTART="TCP","ya.ru","80"
OK

CONNECT
//+++
OK
ato

CONNECT

а по даташиту "CONNECT OK"

или я чото не так понял? SIM900_Revision:1137B06SIM900M64_ST

Сообщение отредактировал MKdemiurg - Dec 16 2010, 19:07
Go to the top of the page
 
+Quote Post
Aurochs
сообщение Dec 17 2010, 20:48
Сообщение #12


Ортодокс
***

Группа: Свой
Сообщений: 219
Регистрация: 26-10-07
Из: Смела, Украина
Пользователь №: 31 775



Цитата(MKdemiurg @ Dec 16 2010, 21:59) *
Может некорректно задам вопрос. НУжно ли использовать CRC для контроля данных или TCP 100500% сам отсеит ошибочные данные?

Не буду здесь теоретизировать, но могу сказать следующее.
При удаленной перепрошивке девайса (FOTA) использую протокол XModem-1K поверх TCP/IP. Во-первых, в целях поддержания единообразия при разных технологиях доставки данных, а во-вторых береженого Бог бережет. wink.gif
Так вот неоднократно наблюдал случаи (хоть и очень редкие ~ 1 раз на 20-25Мб), когда при приеме пакета обнаруживается ошибка и приходит запрос на повторную передачу пакета.
В чем там именно причина разбираться некогда, тем более, что за исключением этого все работает стабильно.
Но, как говорится, факт остается фактом. Как говаривал дедушка Мюллер: "Никому нельзя верить" sm.gif
Go to the top of the page
 
+Quote Post
butthead2
сообщение Dec 17 2010, 22:10
Сообщение #13


Местный
***

Группа: Участник
Сообщений: 301
Регистрация: 22-07-09
Пользователь №: 51 470



Цитата(Aurochs @ Dec 18 2010, 02:48) *
Но, как говорится, факт остается фактом. Как говаривал дедушка Мюллер: "Никому нельзя верить" sm.gif

Подтверждаю. Достаточно редко, но бывает. Возможно виноват сам стек а не оператор. Проверку лучше сделать и не гадать кто виноват.
Go to the top of the page
 
+Quote Post
rx3apf
сообщение Dec 18 2010, 07:03
Сообщение #14


Гуру
******

Группа: Участник
Сообщений: 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, и устройство с таким багом до меня не доходило (предположительно, все это зависело от месторасположения и грешили на оператора).
Go to the top of the page
 
+Quote Post
butthead2
сообщение Dec 18 2010, 07:10
Сообщение #15


Местный
***

Группа: Участник
Сообщений: 301
Регистрация: 22-07-09
Пользователь №: 51 470



Цитата(rx3apf @ Dec 18 2010, 13:03) *
Точно битый пакет, а не потеря ?

Точно. Сравнивал пакеты на передаче и на приеме - изменился один байт. Неправильной передачей по UART обьяснить нельзя - сдвигом битов новое значение никак не получалось
Go to the top of the page
 
+Quote Post

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

 


RSS Текстовая версия Сейчас: 18th July 2025 - 15:11
Рейтинг@Mail.ru


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