Пытаюсь передавать данные в командном режиме с помощью команды AT#SSEDEXT. Когда получаю в ответ вместо "OK" получаю "+CME ERROR: 563" повторяю передачу. В результате данные на стороне приема иногда дублируются. Т.е. вообще не понятно, что нужно делать получив ответ отличный от "OK". Повторяше передачу - дублируются, не повторяешь - теряются. Эта проблема вообще имеет решение? Или если нужно передать больше сотни-другой байт то только прозрачный режим? Но прозрачный режим при работе с несколькими сокетами тоже не удобно.
Лог в прикрепленном файлеНажмите для просмотра прикрепленного файла

Пробовали запросить после +CME ERROR: 563 количество переданных байт командой AT#SI=1?

Пробовал, send не менялось. Кстати ask_waiting иногда бывало отрицательным, что вообще полный сюрр.

error 563: - TX error

Я думаю, что это может быть связано с размером отправки.

максимальное количество для отправки составляет 1024 байт для версий прошивок 7.03.02/7.02.07 и от 10.0x.xx0 до 10.0x.xx2,

А для версий, начиная с 10.0x.xx3, этот размер составляет 1500 байт.

Может быть пытаетесь отправить больше данных и это вызывает излишки которые теряются?

GL868 меньше 10.0.183 и не бывает. А отправляется действительно 1500 байт, как видно из лога.

При попытке отправить больше 1500 байт модуль ругается сразу, '>' не выдает. Так-что нет. В общем плюнул на #SSNDEXT, работаю в прозрачном режиме, в принципе тоже ничего получилось, хотя терзают смутные сомненья - не будут ли теряться данные при переключении из data mode в command mode?
PS Да еще, проблема возникает только при отправке потока данных. С единичными посылками все нормально.

Какая кстати прошивка? Последняя сейчас 10.0.184.

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


Из лога видим gsm: SendData() - Delay 1000

т.е. вы ставите таймаут после TX fail, попробуйте поставить таймаут между посылками и проверить теряются ли данные?

Пробовал. Ошибок получается меньше, но кардинального решения проблемы не дает. Ну не ставить же таймауты по 10сек? Собственно в примере я 1сек специально поставил, чтоб продемонстрировать проблему. Кстати данные не теряются, а дублируются.
Как мне кажется ноги у проблемы растут от переполнения приемного буфера. Причем не буфера порта, поскольку CTS сидит в '0', а буфера сокета. С учетом, что при передаче через GPRS могут быть длительные "замирания" просто увеличением таймаутов эту проблему не решить. Было-бы неплохо если-бы Telit добавил бы команду с помощью которой можно было бы определить кол-во свободного места в буфере, чтоб не нарываться на переполнение.

Размер буфера 4KB, тех. поддержка советует включить hardware flow control командой AT&k3.
(with RTS and CTS signal enable)

Аппаратное управление потоком включено командами AT+IFC =2,2; AT+FLO=2; и AT#CFLO=1. Попробую, конечно, еще и AT&k3, но сильно сомневаюсь.... Кстати в прозрачном режиме CTS работает как положено. Важно знать не размер буфера, а сколько в нем пустого места.