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

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

передавайте в transparant mode (прозрачный режим)

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

Следовательно, просто отправляйте данные кусочками, а на приемной стороне дожидайтесь, пока не придет целое сообщение.

прозрачный режим, это отправка сообщения не фиксированной длины, а с помощью ctrl+Z?

нет это когда после соединения CONNECT можно пихать хоть мегабайты в ком порт (еслественно с аппаратным управлением потоком)
а вернуться к AT командам можно или ногой DTR или послав +++ . никаких контрол зет ненужно.

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

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

Тоже актуальная для меня тема.

Нужно передать данные , но не модем-> сервер, а сервер-> модем. Данные битовые 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 и вывести его можно только аппаратно?

Реально. Если пакеты будут небольшие и после передачи пакета клиент обязательно будет ожидать ответа сервера.

"Прозрачно" передаются только собственно данные, все, что наложено стеком, пользователь не видит.

Или используя последовательность "+++", соблюдая правила (пауза до, пауза после).

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


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

Я тоже использую МТС Укр, и максимальное ожидание было около 7 секунд при установке соединения, а так работает довольно быстро(1-2 сек. максимум).

Может некорректно задам вопрос. НУжно ли использовать 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

Не буду здесь теоретизировать, но могу сказать следующее.
При удаленной перепрошивке девайса (FOTA) использую протокол XModem-1K поверх TCP/IP. Во-первых, в целях поддержания единообразия при разных технологиях доставки данных, а во-вторых береженого Бог бережет.
Так вот неоднократно наблюдал случаи (хоть и очень редкие ~ 1 раз на 20-25Мб), когда при приеме пакета обнаруживается ошибка и приходит запрос на повторную передачу пакета.
В чем там именно причина разбираться некогда, тем более, что за исключением этого все работает стабильно.
Но, как говорится, факт остается фактом. Как говаривал дедушка Мюллер: "Никому нельзя верить"

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

Насколько помнит мой склероз, в "прозрачном" режиме именно "CONNECT", так же как при CSD.


Точно битый пакет, а не потеря ? Вообще такие вещи интересно бы проанализировать, как это выглядит "живьем". У нас наблюдалась странная вещь, когда некоторые пакеты до модема стабильно не доходили, чуть контекст менялся - и начинали стабильно доходить. Правда, UDP, и устройство не мое, и модуль SIM300, и устройство с таким багом до меня не доходило (предположительно, все это зависело от месторасположения и грешили на оператора).

Точно. Сравнивал пакеты на передаче и на приеме - изменился один байт. Неправильной передачей по UART обьяснить нельзя - сдвигом битов новое значение никак не получалось

И никаких закономерностей ? Позиция в пакете, воспроизводимость ситуауии с теми же исходными данными ? Именно замена, не выпадение и не вставка ?

Да, именно замена. Всего было около четырех зафиксированных случаев. Никакой закономерности. Все в норме кроме одного байта в случайном месте.

Хочу использовать CRC8, но какой полином для этого взять? Какие типы ошибок могут возникнуть?

Один байт ловить - подойдет любой. Я использую CRC как в 1-wire.

А почему не старую добрую CRC16 ? Таблично считается быстро, надежность вполне пристойная...

У меня основа данных 8бит, придётся усложнять алгоритм и вводить дополнительный буфер. Хотя можно и не вводить На данный момент, впринципе, 100% сохранность данных не важна. Но когда HTML реализовывать буду - 1 байт закосячит и весь запрос повторять...