Уважаемый all, вот уж не знаю, что и думать с этим модулем, прям засада какая то.... ну по порядку:
есть две одинаковые платы с разными модулями:
SIMCOM_Ltd
SIMCOM_SIM300D
Revision:1008B14SIM300D32_SST34HF3284
и
SIMCOM_Ltd
SIMCOM_SIM300D
Revision:1008B10SIM300D32_SPANSION

Модули ведут себя одинаково и так же одинаково с двумя провами - kyivstar и mts

устанавливаю tcp соединение с сервером:

AT+CREG?
+CREG: 0,1
OK

AT+CIPCSGP=1,"www.ab.kyivstar.net"
OK

AT+CIPHEAD=1
OK

at+cipstatus
OK
STATE: IP INITIAL

at+cipstart="tcp","ххх.ххх.ххх.ххх","хххх"
OK
CONNECT OK

at+cipsend=16

>0123456789ABCDEF

SEND OK (данные приходят на сервер)

а потом увеличиваю размер пакета

at+cipsend=160

> 0123456789ABCDEF(х10)

и тишина на вечно... висим...!!!!!!
При этом - используется CTS/RTS, в процессе передачи CTS еще не разу не выставлялось в занято (высокий уровень), разводка питания
подразумевается правильная, емкости 0,1 + 100uF тантал + 2200uF low ESR + Li-ion аккум + зарядка.
PowerKey через полевик от процессора.
Микроконтроллер ATmega1280 питается от 3,3В через стабилизатор от аккума.

что может быть??? где копать???
на всяк случай еще привожу настройки профиля для 1008B14SIM300D32_SST34HF3284:

ACTIVE PROFILE
E: 0
L: 0
M: 0
Q: 0
V: 1
X: 4
S0: 0
S2: 43
S3: 13
S4: 10
S5: 8
S6: 2
S7: 60
S8: 2
S10: 15
+CRC: 0
+CR: 0
+FCLASS: 0
+IMODE: 0
+DR: 0
+CMGF: 1
+CSDH: 0
+ILRR: 0
+CRLP: 61,61,128,6,0,3
+CMEE: 1
+CBST: 7,0,1
+IFC: 2,2
+ICF: 3,3
+CNMI: 2,1,0,0,0
+CSTA: 129
+CSCS: "IRA"
+IPR: 0
+DS: 3,0,512,20
&C: 1
&D: 2
+CCWE: 0
+CDTX: 0
+CTZU: 0
+CTZR: 0
+CV120: 1,1,1,0,0,0
+CEXTHS: 0
+CEXTBUT: 0
+CSMINS: 0
+CMUX: 0
+CCUG: 0,0,0
+CLIP: 1
+COLP: 0
+CCWA: 0
+CAOC: 1
+CLIR: 0
+CUSD: 0
+CSSU: 0
+CSSI: 0
+CDIP: 0
+CSCLK: 0
+CIURC: 1
+SCLASS0: 0
+CSDT: 0
+CMIC: 2,2
+ECHO(NORMAL_AUDIO): 0,0,0
+ECHO(AUX_AUDIO): 0,0,0
+SIDET(NORMAL_AUDIO): 4096
+SIDET(AUX_AUDIO): 4096
+CLCAL: 1
+CCPD: 1
+CMTE: 1
+CSCA: "+380672021111",145
+CSMP: 17,255,0,241

сет тупит наверное. на приемной стороне чтото пришло? конект не разорвался? попробуй прозрачный режим поганять...
пакет больше 1-го (или 15.5 кБ непомню) неполучится.
х10 - ??? имеется в виду 10 таких строчек?

у меня редко проходи 20-ка байтов обычно на 2 -3 куска рвет. приложение потом в кучу собирает.

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

А Вы уверены что отправляете 160 байт в модуль. если хотябы на 1 байт меньше то модуль будет ждать.
а что касается второй стороны, то это врятли.
попробуйте еще посылать не указывая длину посылки at+cipsend а в конце посылки слать ^Z

Вы правы, не все данные уходили, оказался баг в софте, счетчик отправки 8 битный был... но заметил еще парочку осбенностей,
который возможно будут интересны на будущее.
Речь идет о прошивке 1008B14SIM300D32_SST34HF3284.
Линия CTS таки не поднималась не разу, сколько б не отправлял пакетов размером около килобайта, т.е. по локальному порту модем вероятно
прекрасно справляется с нагрузкой на скорости 57600. Подозреваю, что такое может иметь место для пакетов, размер которых больше заявленного
производителем (1460 байт).
Еще не всегда сразу приходит SEND OK, при этом данные уже могут быть на сервере, а данный ответ может прийти через секунд 80.
Но чаще он таки приходит сразу, в пределах 1-2 сек, поэтому наверно не стоит ориентироваться на этот ответ, как на гарантию доставки.
Имхо, надежнее просто время от времени проверять статус для проверки соединения.

to av-master
На счет прозрачного режима, а как он может помочь, если например параллельно с передачей данных нужно еще отлавливать входящий звонок?
В случае с +ipd:XXX можем точно разруливать где данные, а где URC приходят, в прозрачном эта процедура становиться не тривиальной....

ну о вызовах вы не говорили ))) а вообще я пользуюсь стандартной функией поиска строки в строке... и проганю данные через жту функцию в поиске номеров.. хотя у меня данных маловато OK, CRC да и все )) ну иногда блок из 50 байтов...

to av-master
Я так понимаю, вы используете DTR для переключения данные/команды? (&D = 1)
а вот что произойдет с входящими данными, если мы временно перешли в командный режим, подняв DTR.
Через некоторе время снова переключились на данные, сбросив DTR.
При этом мы потеряем данные или они тут же вывалятся? (при условии, что не будет переполнен внутренний буфер модема)

Да, и еще тут было замечено



у меня по началу тоже такая байда была, оказалось это на сервере чето подправить надо было в верхнем софте,
после этого не было ни одной фрагментации для входящих данных, если пакет не превышает заявленный для модуля максимум.

DTR не развел. потому не пользуюсь, +++ пока хватает. данные не пропадают, а приходят после возврата к сокету...

Фрагментацию убрал именно вверхнем уровне. а от сервера оно мало зависит. я на самом тупом мониторе сокета (на самом нижнем уровне) вижу эту фрагментацию.
потому просто собираем куски и роверяем crc. длина пакета или фиксированна или присутствует в начале пакета.

Сегодня заметил еще один очень неприятный момент с модемом.

at+cipsend=1024 (и менее)

>(получаем приглашение)

at+cipsend=1025 (и более)

ERROR

в доке ж вроде упоминается про 1460 байт, а не 1024... кто нить встречался с этим на практике?

он их наверное одним пакетом шлет. а пакет там ( в Интернетах) вроде как килобайтный... мож по этому... и в доке вроде было наисано про 1024 )))

а 1460 вообще полезно и в других местах ( в прозрачном режиме например )

Открываем документ _Module FAQ.pdf

5.3 Is SIM300 supposed to picture transmission and how large is the data buffer of SIM300?

The default data buffer is 1KB. For picture transmission application, it is advised to adopt UDP socket.

Хм... Вообще то SIM300_ATC_V2.02.pdf ангельским по белому написано для команды AT+CIPSEND:

Parameter
<Length> a numeric parameter which indicates the length of sending data, it must be less then 1460.
Note: There are at most 1460 bytes that can be sent each time.

В начале документа в summary для команд еще уточнятеся:
8.2.2 AT+CIPSEND Modified the discription of response in the write command
And changed the maximum length from 1024 to 1460

т.к. прошивка у меня относительно новая 1008B14SIM300D32_SST34HF3284,
полагал, что этот мануал должен соответствовать железке

Посмотрите внимательно, megaboy, документ "Release Notes" для прошивки 1008B14SIM300D32_SST34HF3284. На странице 3 сказано что при работе с данной прошивкой необходимо руководствоваться следующими документами ("Related documents"), в частности нас интересует "SIM300D AT Command Set, V2.00". А согласно этой версии руководства по AT-командам, для команды AT+CIPSEND максимальный размер посылки ограничивается 1024 байтами.

Просмотрел документы.

megaboy прав - начиная с 13 версии длина буфера увеличена до 1460.

Нужно внести это дополнение в FAQ. Замечание Симкому отправил.

Смею поспорить с CADiLO

Может всё-таки длина буфера увеличена до 1460 байт начиная с 15-й версии ?

Использую прошивку 1008B14SIM300D32_SST34HF3284. Больше 1024 байт данных отправить за раз не могу, та же ситуация о чём говорил megaboy:



Всё таки в 14-й версии ограничение пакета - 1024 байта, тогда как с 15-й версии (судя по документу "SIM300_ATC_V2.01.pdf") максимальный размер пакета увеличен до 1460 байт.

Спорить не буду - посмотрим в документы.

Для 300С фраза о 1460 встречается в следующих RN (по типам памяти)

SIM300С_Firmware_RN_1008B12SIM300C32_SPANSION

SIM300C_Firmware_RN_1008B14SIM300C32_SST34HF3284

А вот для 300D у меня нет релиз-нотес именно на 13 версию - в других же RN не упоминается 1460 байт.
Можно сделать предположение что упоминалось об этом именно в RN 13 версии.

Или же в прошивке для 300D не изменили длину.

Возможно это ограничение связано с параметром MTU (maximum transmission unit) сети конкретного сотового оператора. А SIM300 просто не умеет правильно фрагментировать UDP пакеты.