Попробовал пересылать большие пакеты данных с клиента (SIM900) по запросу сервера (софт на РС).
В данном случае передаются 10000 байтов.
В качестве данных могут быть лювые бинарные числа (0х00...0хFF), в том числе и 0х1А.
Поэтому используется отправка фиксированного количества данных:
AT+CIPSEND=<LENGTH>, где <LENGTH> может быть в пределах от 1 до Packet Maximal Value.
На команду AT+CIPSEND? была получена цифра 1380, что и есть Packet Maximal Value.
Это число считал с SIM900 только 1 раз, чтобы не усложнять программу. Но в описании написано,
что это число в общем случае нефиксированное.
Нужно ли это число проверять каждый раз перед отсылкой команды AT+CIPSEND=<LENGTH>?
Пока проблем не было с тем, что в программе Packet Maximal Value всегда принят за 1380.
Может это зависит от оператора и загруженности сети?

Ниже приведена временная диаграмма сигналов на RXD и TXD модуля SIM900.
В начале идет инициализация SIM900. После того, как клиент подключается к серверу,
программа сервера посылает запрос / команду на считывание 10000 байтов.
На временной диаграмме видно, что передаются 7 пакетов по 1380 байтов и 1 - по 340 байтов.
7 * 1380 + 1 * 340 = 10000, которые передаются примерно за 35 секунд.
Средняя скорость передачи данных примерно равна 10000 байт / 35 секунд = 286 байт/с = 2300 бит/с.
Скорость по UART равна 9600 baud/s.
Перед тем, как слать следующий пакет данных, контроллер ждет ответ "SEND OK".

Вопрос заключается в том, как можно по возможности увеличить скорость передачи данных?
Первое, что я вижу, это увеличение скорости по UART до 115200 baud/s. Это может увеличить
среднюю скорость передачи данных по GPRS на 30-40%.
Очень много времени занимает ожидание "SEND OK". Иногда эта задержка может достигать
10 секунд и даже больше. Тут, как я понимаю, ничего не поделаешь,
т.к. подтверждение нужно и количество байтов в пакете тоже нельзя превышать 1380.

Сообщение отредактировал Electronics Engineer - Oct 17 2012, 10:44

Увеличил скорость обмена данными по UART между микроконтроллером и SIM900 до 115200 baud/s.
Как я понимаю, это максимально допустимая скорость для SIM900.
В результате средняя скорость передачи данных по GPRS увеличилась приблизительно до 8000 b/s.
Объем передаваемых данных был 50000 байт, которые пересылались за 51-52 секунды.
Это уже более-менее приемлемая скорость передачи данных.
Если нужно будет переслать данные объемом 2 Mbit, то это может занять около 4.5-5 минут.

Прозрачный режим. не?

MKdemiurg, вы использовали этот режим? Даёт он прирост скорости передачи?

Думаю, SEND OK выдается при получении модулем подтверждения сервера (получении модулем tcp-пакета нулевой длины с параметром ACK, совпадающим с SEQ сокета модуля). Такая логика не использует концепцию tcp-окна и ничем не отличается от UDP с подтверждением и повторными отправками по таймауту.
Учитывая что в жпрс доставка пакета от 1 сек и выше, это уже несколько сек на 1380 байт. Да и сокет сервера не моментально подтверждет ACK, а по таймауту (если в пакете не установлен флаг ургентности).
Посмотрите подробное описание tcp-протокола, сразу все прояснится.

Можно попробовать отправлять данные по 1380 байт, не дожидаясь SEND OK, но контролируя ответ на команду отправки. По идее, при переполнении буфера отправка должна вернуть ошибку, в этом случае повторять отправку данного пакета с небольшим интервалом.

В OpenCPU, например, такой подход с функцией отправки работает.

Сообщение отредактировал GeGeL - Oct 18 2012, 18:19

Хорошо, буду иметь такой вариант в виду.
На данный момент существенное повышение скорости передачи данных некритично.
Для начала хватит и 8 kbps, т.к. данные планируется считывать редко (1-2 раза в месяц).
На мой взгляд лучше подтверждение о доставке пакетов данных не игнорировать,
т.к. потом можно соответствующим образом на это реагировать.

Интересно, а при отсылке / отправке пакетов считается / проверяется CRC?
В общем случае важно знать не только, что все байты принялись, но и принялись ли правильно.
Или нужно самому в конец пакета добавлять CRC, который считается по массиву данных, а на стороне сервера
проверять добавленную на стороне клиента CRC с пересчитанной CRC на сервере?

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

Уточните еще раз пожалуйста:

как можно устанавливать конект с модулем в режиме
сервера с статическим IP, начинается на 81.30...
С пк с обычным (ADSL) интернетом можно ли добиться?
Или может к пк подключить сотовый на таком же операторе
и тогда через него выходить. Или есть другие варианты?
Это надо для отработки команд в ручном режиме.

Модуль должен постоянно поддерживать соединение с инет, периодически проверяя его. В даном случае модем будет периодически послыть пакеты на ваш сервер и ждать ответа.
Пакет должен содержать 4 байта локального IP модема, определенного средствами стека, и контрольную сумму. Если ответа нет раза 3 - перезапуск.
Поднимите UDP-сервер на любом внешнем IP (если речь идет об АДСЛ, то проключите на адсл-роутере нужный порт и заведите учетку на dyndns). Получив пакет от модуля, сервер проверяет КС, запоминает текущий IP модуля и отсылает ответ. Если надо связаться с модулем, отсылаем данные на последний запомненный IP.

Для более сложных случаев (этот к таковым не относится), когда и сервер, и модем имеют серый IP (находятся за NAT) можно написать подобие STUN-сервера и повесить его на любом внешнем IP. Ничего сложного в этом тоже нету, просто надо разобраться в типах NAT.

На данный момент мне надо вариант
когда модуль-сервер, а пк-клиент.
И конектиться из терминала пк на модуль
в ручном режиме. Как сделать такой вариант.
На пк АДСЛ, на модуле статич. IP. Доступен ли
IP модуля из нета.

Если все так, как описано (на модуле СТАТИЧЕСКИЙ IP 81.xx.xx.xx), то он будет доступен с любого места инета, в т.ч. из-за NAT. Но ведь это денег стоит - статический внешний IP на данную симку вешать.

Я к тому веду, что модуль ведь все равно периодически должен проверять, не потерял ли он связь (жпрс). Так почему же не совместить эту процедуру с сообщением своего ДИНАМИЧЕСКОГО (возможно, даже серого) айпи серверу и пробросом через NAT провайдера (если он есть). Фактически, модуль будет клиентом, но на постоянной связи.
Выбор варианта зависит от того, как часто надо связываться с модулем, и как оперативно это должно происходить.

По поводу скорости - передавал на сервер с СИМ900 фотографию с камеры (JPEG) около 7КБ, процесс длился около 5 секунд...НО оператор был киевстар (по передаче данных у нас считается хорошим).....думаю здесь и от оператора тоже многое зависит...