Добрый день!

Начал разбираться с GPRS на базе модуля SIM900. Ознакомился с файлом описания TCP/IP
(название документа: SIM900_TCPIP_ApplicationNote_V1.02.pdf).
Начал делать такой проектик:
Софт на РС будет сервером, а модуль SIM900 - клиентом. Модуль на
данный момент подсоединен к терминалу. Буду с терминала управлять
модулем SIM900 для первоначального запуска. Используется режим single
connection и non-transparent mode, установленные по умолчанию.
Начал выполнять действия, описанные в пункте 2.1.1 How to Establish a TCP Client Connection.
Команды AT+CPIN?, AT+CSQ, AT+CREG?, AT+CGATT?, AT+CSTT="internet.lmt.lv" (APN латвийского оператора LMT),
AT+CIICR, AT+CIFSR прошли нормально. Ответы на эти команды такие же, как в примере на страницах 5 и 6.
До этого момента вроде все нормально.

На следующую команду AT+CIPSTART="TCP","10.13.137.45","10000" получил такой ответ:
OK
а еще через какое-то время пришло:
STATE: TCP CLOSED CONNECT FAIL

На компе с IP адресом 10.13.137.45 уже до выполнения этой команды была
запущена программа сервера с номером порта сервера 10000.
Может какой-то не тот софт на PC? При запуске этой
программы нужно было только присвоить номер порта (выбрал 10000).
Софт уже сам считывал IP адрес РС.
В чем может быть проблема?
Какой софт можете посоветовать?

Думаю, что проблема все же не в софте на РС. Один человек подсказал следующее:
"Программа может и слушает, но модулю возможно не пробиться через сервер/рутер, сложно сказать не зная вашей архитектуры сети.
Настройки Nat, port forwarding и т.д. смотрите".
Где можно посмотреть настройки и какие они должны быть?

Заранее спасибо за помощь!
Дмитрий

Создал сразу 4 одинаковые темы. У меня сегодня РС тормозит.
Первые 3 можно не читать. Не могу найти, как их можно удалить.

Попробуйте с компа подцепиться к этому адресу. Комп возьмите с другой локалки.

В начале попробовал соединить два РС, которые включены в одну сеть.
На одном РС была запущена программа сервера, на втором - программа клиента.
Все работало, можно было обмениваться данными в обоих направлениях.
Возможно, у нас здесь (на работе) своя локальная сеть. Может она не пропускает что-то.
Если честно, то я в сетях мало что понимаю. Если что, надо будет спрашивать у администратора сети.
Пока у меня нет возможности подсоединиться с другой сети.
В крайнем случае нужно нести модуль домой, устанавливать весь софт и т.д.
Что нужно делать, если связь не установится между двумя РС в разных локальных сетях?
В любом случае эту проблему нужно решать.

Если связь не установится между двумя PC в разных локальных сетях, значит указанный IP адрес "серый" - спрятан за NATом, то есть существует только в пределах вашей локалки. Если не ошибаюсь, то диапазон 10.х.х.х используется как раз для локальных адресов...
GSM модуль существует в своей виртуальное подсети и за некорыми исключениями, может подключаться только к "белым" внешним адресам. Вам, чтобы решить эту проблему, нужно попросить у админа статический внешний адрес для экспериментов (это может потребовать некоторых финансовых затрат).

Хорошо, буду узнавать у нашего админа.
Если GSM модуль существует в своей виртуальной подсети, то и его IP начинается с 10.х.х.х?
При считывании IP адреса с SIM900 модуля он выдает разные адреса.
Один раз выдал 10.83.194.253, а другой раз - 10.40.25.55
IP адрес модуля нефиксированный, а динамический?
Поэтому его нужно каждый раз считывать?

Зачем вам нужен IP модуля? Какой в нём смысл?

"а еще через какое-то время пришло: STATE: TCP CLOSED CONNECT FAIL" мы программисты любим цифры, конкретно укажите через какое время Вам приходит " STATE: TCP CLOSED CONNECT FAIL" ?

Я так понимаю, IP адрес модуля понадобится, если захочу сконфигурировать
модуль сервером, а программу на РС - клиентом.
При подключении к серверу нужно указывать IP адрес и номер порта сервера.
Это для следующего эксперимента.

Дома получилось подключиться к серверу.
Что касается компа на работе, то наш администратор дал
внешний IP адрес моего компа и снял Firewall с порта 10000.
В результате тоже получилось соединиться с програмкой сервера.
Данные передаются в обоих направлениях.

Модуль SIM900 поочередно выдает два IP адреса:
10.40.25.55 и 10.83.194.253
Можно ли сделать так, чтобы он всегда выдавал только один адрес.
Если не ошибаюсь, то где-то читал, что можно задать фиксированный IP адрес.
Когда модуль подключается к серверу, то в програмке
сервера в поле IP адреса клиента вместо 10.40.25.55 появляется
212.93.100.2, а при 10.83.194.253 появляется такой адрес 212.93.100.45

Теперь хочу сделать наоборот, чтобы комп был клиентом, а модуль - сервером.
Какой мне указывать адрес сервера (IP адрес модуля SIM900)?
Может локальные адреса предусмотрены для общения между аналогичними модулями SIM900,
а есть также какой-то внеший IP адрес для работы с остальным миром?
Это я просто предположил по аналогии с нашей локальной сетью.


Точно не скажу, но где-то порядка 30 секунд или примерно так.
Наверно, при отсылке команды AT+CIPSTART="TCP","10.13.137.41","10000" запускается таймер на определенное время.
Если модуль не подсоединяется к серверу за это время, то срабатывает таймаут и
модуль выдает сообщение STATE: TCP CLOSED CONNECT FAIL.
Эта проблема уже решилась после того, как администратор дал внешний IP адрес моего РС.

Чтобы модуль был сервером, нужно идти к оператору сотовой связи и просить у него услугу "статический внешний IP". Ни разу такой услугой не пользовался, но подозреваю, что дадут нестандартный APN и возьмут некоторое количество денег.

Попытался запустить модуль в качестве сервера, а софт на РС - в качестве клиента.
В начале сконфигурировал модуль сервером, как описано на странице 8 выше указанного документа.
Когда модуль находился в состоянии SERVER LISTENING, перепробывал все 4 IP адреса сервера,
но клиенту так и не удалось подсоединиться к серверу ни с одним адресом.
Это я просто хотел поэкспериментировать. В реальных устройствах модуль скорее всего будет клиентом.
Пока не актуально делать модуль сервером.

Интересно, а два SIM900 модуля будут между собой работать, если один будет сервером, а второй -клиентом?
Или с сервером будет такая же проблема?
Использовать их локальные адреса, что модули выдают на команду AT+CIFSR (Get local IP address).

Использование sim900 в качестве сервера (и не только) описано в документе SIM900_TCPIP_Application Note_V1.02.pdf

Как раз делал по примерам, описанным в этом документе.
Проблема заключалась в том, что клиент (софт на РС) не мог подсоединиться к серверу (модуль SIM900).
Загвоздка в IP адресе модуля (сервер). Тот локальный IP адрес, который считывается с SIM900, не проходит.
Не подходил также тот IP адрес, который определяет РС, когда модуль подсоединяется как клиент.
Чуть выше была описана возможное решение этой проблемы.
Пока с этим я возиться не буду. Модуль планируется использовать в качастве клиента.
Просто хотел попробовать.

В Украине только ЛАЙФ и УТЕЛ выделят белый ИП по жпрс, и будьте готовы к приходу большого количества мусора. Ип при подключении всегда разный.

Не все так просто у Вас сделать.
Все IP, которые начинаются на 10, серые.
----------------
inetnum: 10.0.0.0 - 10.255.255.255
netname: IANA-ABLK-RESERVED1
descr: Class A address space for private
------------------
Т.о., и модуль, и РС с сервером у Вас находятся за NAT, поэтому никоим образом недоступны друг другу, и все Ваши попытки создать описанное выше соединение бесполезны.
Выходов из данной ситуации есть много, но самым лучшим видится следующие:

1. Установить сервер на РС, имеющий белый IP (причем не обязательно статический). Многие домовые сети раздают клиентам именно белые IP. Если компьютер за роутером, то в роутере необходимо прописать нужный диаппазон портов на конкретный внутрненний IP вашего компьютера с сервером (VirtualServer).
Если IP от провайера белый, но динамический, пропишите в роутере или запустите на РС клиент dyndns, и бесплатно получите доменное имя на dyndns.com. В этом случае подключайтесь с модуля, используя функцию ресолвинга домена (в крайнем случае можно сделать и вручную, отправив заранее заготовленный UDP пакет на 8.8.8.8:53 и отпарсив ответ).
Тут есть "подводный камень" - иногда надо постоянную исходящую активность компа с сервером для поддержки arp в сети провайдера. Например, запустите на нем скайп.

2. Более изящный вариант: арендуйте самый дешевый VDS с реальным статитческим IP (это будет стоить 5$/мес), и используйте его в качестве транзитного узла. Можно подобрать нужный готовый софт, или же написать на gcc простенький демон, выполняющий нужные операции.


3. Если все же принципиально нужно соединение точка-точка в ваших условиях, то можно попробовать с помощью внешнего сервера настроить оба NAT (модуля и внутреннего сервера) друг на друга. Так делает, например, скайп или хамачи. Это достаточно сложно алгоритмически и не всегда выполнимо (все зависит от типов NAT).


Если быть точным, не снял Firewall, а проключил порт 10000 извне на ваш комп (создал VirtualServer-запись в своем роутере). Тоже вариант решения проблемы, но требует контакта с админом сети, его расторопности и желания.



С лайфом я не работал, а утел всегда белый и доступен извне. Если на модуле реализовать dyndns-клиент (протокол открыт, из-под OpenCPU или EAT это можно сделать), то не надо ничего просить у сисопа: сервер внутри модуля будет всегда доступен по домену. Может потребоваться периодическая активность модуля (см. выше): например, каждые 30 сек отсылать куда-нибудь удп-пакет с 1-байтной датаграмой. Мусора немного, все терпимо и отсекается на уровне сокета ядром (кстати, столько же, как и в режиме клиента), только 80й порт, естественно, не использовать

Спасибо всем за помощь в решении данной проблемы.
На данный момент пока достаточно ломать голову с этими IP адресами.

Надо двигаться дальше.
Написал программу для микроконтроллера, который управляет SIM900 модулем (клиент).
Программа на РС является сервером. Но планируется запускать эту программу
периодически, т.е. сервер с клиентом большую часть времени будут рассоединены.

В начале идет инициализация SIM900, как написано в выше упомянутом документе.
Когда при соединении с сервером (отправляется команда AT+CIPSTART="TCP","195.13.137.41","10000"),
а в это время сервер слушает клиента, то микроконтроллер получает ответ "CONNECT OK".
С этого момента можно обмениваться данными.
Если же программа сервера не работает, то микроконтроллер получает ответ "TCP CLOSED", "CONNECT FAIL"
и микроконтроллер пытается подсоединиться к серверу вновь. И так до тех пор пока клиент не подсоединится к серверу.
Период каждого запроса примерно составляет 2.5-3 секунды.
По идее устройство (клиент) должно подлючиться к серверу максимально быстро после запуска программы сервера,
т.к. пользователь с программы сервера может слать кое-какие команды устройству. Сейчас программа микроконтроллера
написана так, что при удачном соединении с сервером на сервер отсылается сообщение "I am ready". По этому принятому
сообщению программа сервера определяет, что можно начинать работу с клиентом.
Тут все работает как надо.

Вопрос 1:
Используется ли предоставляемый интернетовский объем данных при неудачных попытках подсоединения?
Если клиен будет запрашивать соединение каждые 2-3 секунды, не израсходуется ли быстро лимит данных?

Вопрос 2:
Устройство (клиент) должно будет слать на сервер довольно большие объемы данных (предварительно до 2 Мbit).
Нужно ли использовать handshake при отсылке данных, т.к. скорость передачи данных по каналу GPRS довольно низкая,
а внутренний буфер SIM900 ограничен (что-то вроде 500 байт, если не ошибаюсь)?

1. Да, используется. Да, израсходуется.
2. Можно использовать RTS/CTS или побить отправляемую информацию на пакеты и не отправлять следующий до доставки предыдущего.

Интересно, как можно минимизировать ненужный расход лимита и сохранить
быстрое подключение к серверу после того, как он включится?
Увеличивать период запроса на подсоединение клиента к серверу до, например,
нескольких минут не хотелось бы, т.к. в конечном счете пользователю нужно будет ждать.
Может используемый лимит в холостом режиме не такой уж большой, чтобы тут заморачиваться?

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

Хотелось бы знать, как обычно люди поступают в этом случае?



Ок, тут более-менее понятно.
Надо пробовать делать.

Что значит подсоединение?
Раз в 2-3 секунды не выйдет.



handshake не нужен, достаточно получать ответы от модема (SEND OK).


Побольше вроде, пакет ведь до 1кБ.

Под попыткой подключения / подсоединения клиента к серверу я понимаю следующую
последовательность команд:
1) AT+CREG?
2) AT+CGATT?
3) AT+CSTT="internet.lmt.lv"
4) AT+CIICR
5) AT+CIFSR
6) AT+CIPSTART="TCP","IP address of server","Port number of server"
Разумеется, выше перечисленные команды посылаются только после приема соответствующего ответа от SIM900.
Если на последнюю команду (6) принимается "STATE: TCP CLOSED" "CONNECT FAIL", то процесс повторяется с
отсылки команды (1).
Этот весь период занимает меньше 3 секунд, типично 2.5 секунды. Смотрел пакеты данных на осциллографе.

При Вашем подходе расход трафика будет очень большой: модуль практически постоянно будет слать sin-пакеты (они дублируются и сокетом).
Как часто планируется включать сервер? Сколько времени в % он будет отключен?
Думаю, лучшим решение видится все же инициализация входящим звонком на некоторое количество попыток подключения. Если хотите автоматизировать этот процесс со стороны сервера, тоже установите на нем модем с модулем.

Непонятно зачем зачем apn и регистрацию в GPRS повторять многократно.
Если модуль уже зарегистрирован, то дальше достаточно только пытаться соединится по сокету.


Что-то как-то быстро у вас получается.

PS. Если за траффик беспокоитесь, то может UDP попробовать?

Сервер планируется включать раз в неделю или еще реже, возможно, даже раз в месяц.
Устройство должно работать в автономном режиме, периодически, допустим, с интервалом 1 минута архивировать состояние датчика. Время и состояние датчика будет записываться в FRAM. С объемом памяти 2Мбита данные могут записываться в память без ее переполнения до 1 месяца.
Софт на РС должен считывать память до того, как она переполнится. Часто не нужно считывать данные, поэтому
активировать программу сервера раз-два в месяц было бы достаточно.
С РС также нужно будет устанавливать кое-какие параметры.

Модем у РС не хотелось бы ставить, т.к. это лишние затраты. Готовый модем, наверно, стоит около 100-200 евро.
Минус этого варианта является то, что нужно оплачивать 2 SIM карты.
Хотя, такое решение более правильное, т.к. позволяет автоматизировать процесс.
Оптимально с точки зрения цены на обслуживание сделать дозвон или послать смс с телефона оператора.
Тут уже человеческий фактор может сказаться, забыть отслать смс и программа не будет работать.


Возможно при повторных запросах первые 2 команды можно и не слать.
Насчет 3, 4, 5 команд нужно экспериментировать.
Хотя, судя по диаграмме состояний на странице 25, нужно начинать с команды 3 (AT+CSTT="apn"),
т.к. после команды AT+CIPSHUT модуль находится в состоянии IP INITIAL.
Микроконтроллер отсылает AT+CIPSHUT, когда получает ответ "STATE: TCP CLOSED" "CONNECT FAIL"
на команду 6.



Микроконтроллер отсылает следующую команду практически сразу после получения
ответа от предыдущей команды. Интервал времени между ответом и новой командой как правило меньше 1мс.
Поэтому может и получается максимально быстро на скорости 9600. Хотя baud rate не так критичен,
т.к. SIM900 отвечает с довольно большой задержкой. Как я вижу больше 100мс для самых быстрых ответов.


UDP использовать не хотел бы, т.к. в этом режиме нет подтверждения того,
что отосланные данные приняты.

UDP тут не поможет, т.к. в смысле трафика практически без разницы, что шлется: зондирующий УДП-пакет или sin-пакет инициализации tcp-сессии. При отключенном сервере на них ответ не приходит.

При таком интервале работы тем более нет смысла зондировать сервер и единственный выход - входящим звонком. Не совсем понял про модем за 100-200 евро Модем - это тот же модуль SIM900 + блок питания + PL2303. На сколько я понимаю, все в 15 евро легко укладывается. Не хотите звонком - активируйте входящим SMS (можно отправлять бесплатно с сайта оператора) или, если сисоп поддерживает, через шлюз email->SMS (в этом случае процесс конекта можно полностью автоматизировать без участия оператора сервера).

Кстати, совет: используйте EAT в SIM900: не надо внешнего микроконтроллера, памяти и не надо корячится с установкой соединения через АТ-команды. Только модуль, питание и ваши датчики. Внутри модуля есть флеш для данных, ее должно хватить. Если нет, можно посмотреть в сторону Quectel M12-128: внутри вроде до 9 МБайт памяти, и еще SD пятью проводами можно к модулю подцепить.

Не совсем понятна Ваша проблема: по существу Вы "изобретаете велосипед" (мое мнение). Модем, который может быть и клиентом, и сервером, и входить в связь через GPRS по звонку о по расписанию уже давно выпускается например здесь: http://www.amrita.ru/index.php?units.php?sec=50
Называется "Барк".

Пока мне нужно в единичном экземпляре. Себестоимость компонентов, плат, корпуса будет стоить около 100 евро
для единичного экземпляра. Плюс потраченое время. В таком случае, проще купить готовое изделие, чтобы оно
имело товарный вид.
Вариант email->SMS тоже буду иметь в виду.
Понятно, что постоянно пытаться подключаться к серверу не рекомендуется.


Как я понимаю, есть специальный софт для программирования самого SIM900?
Конечно, этот вариант нужно рассматривать. Но сейчас я только начал работать с SIM900,
поэтому мне легче запрограммировать знакомый AVR или какой-то другой микроконтроллер.
А вообще, EAT в SIM900 актуально при более-менее серийном производстве.


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

Как-то быстро всё равно - у меня подключение к GPRS занимает до секунд 15, плюс сокет TCP может несколько секунд подключатся (не более 60).


Самому можно сформировать...

При включении питания, действительно, на одну из команд AT+CREG? или AT+CGATT? (сейчас точно не помню какая) нужный ответ приходит где-то через 7-10 секунд.
А уже последующие попытки подключения клиента к серверу занимают в основном до 3 секунд.
Еще был момент, который описан где-то в начале темы, т.е. когда клиент пытался подключиться к серверу, IP адрес которого не был виден.
Тогда пытался подключиться к РС, который находился в локальной сети. Тогда, действительно, ответ "STATE: TCP CLOSED" "CONNECT FAIL" на команду
AT+CIPSTART="TCP","IP address of server","Port number of server" приходил с большой задержкой. Наверно, больше 30 секунд.
Сейчас такого нет с белым адресом.

P.S. А Вы сами тоже из Риги?

У меня такая же картина: gprs подключается за секунд 10-20, сокет тоже подключается в пределах нескольких секунд.Бывает, правда, оператор не даёт подключится (наверное считает что модем не отключался) и тогда дело затягивается, но это не часто.


Да, живу в Риге.

Если не секрет, какое оборудование делаете на базе SIM900?
У меня это было только ознакомление с SIM900. Разобрался с
отсылкой / получением смс, voice call, TCP/IP по каналу GPRS.
По ссылке можете посмотреть краткое описание демонстрационных
проектиков на базе SIM900:
http://embeddedsolutio.ucoz.com/index/projects/0-6
Если что, было бы полезно на всякий случай иметь контакт в Риге.

Да тоже что и все сейчас - GPS/GLONASS-GSM-GPRS оборудование и тому подобное.


Если что - пишите в личку.

Попробовал пересылать большие пакеты данных с клиента (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.

Увеличил скорость обмена данными по 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, например, такой подход с функцией отправки работает.

Хорошо, буду иметь такой вариант в виду.
На данный момент существенное повышение скорости передачи данных некритично.
Для начала хватит и 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 секунд...НО оператор был киевстар (по передаче данных у нас считается хорошим).....думаю здесь и от оператора тоже многое зависит...