GPRS, SIM900, TCP, Модуль (клиент) не соединяется с сервером Опции

[Electronics Engi...]

Добрый день!

Начал разбираться с 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 можно не читать. Не могу найти, как их можно удалить.

[andrewlekar]

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

[Electronics Engi...]

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

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

[andrewlekar]

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

[Electronics Engi...]

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

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

[_Артём_]

При считывании IP адреса с SIM900 модуля он выдает разные адреса.
Один раз выдал 10.83.194.253, а другой раз - 10.40.25.55
IP адрес модуля нефиксированный, а динамический?
Поэтому его нужно каждый раз считывать?

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

[alexdos]

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

[Electronics Engi...]

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

Я так понимаю, 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 адрес для работы с остальным миром?
Это я просто предположил по аналогии с нашей локальной сетью.

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

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

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

[andrewlekar]

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

[Electronics Engi...]

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

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

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

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

[_Артём_]

Попытался запустить модуль в качестве сервера, а софт на РС - в качестве клиента.
...

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

[Electronics Engi...]

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

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

[west329_]

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

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

[GeGeL]

Не все так просто у Вас сделать.
Все 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).

Что касается компа на работе, то наш администратор дал
внешний IP адрес моего компа и снял Firewall с порта 10000.

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

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

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

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

[Electronics Engi...]

Спасибо всем за помощь в решении данной проблемы.
На данный момент пока достаточно ломать голову с этими 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 байт, если не ошибаюсь)?

[andrewlekar]

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

[Electronics Engi...]

1. Да, используется. Да, израсходуется.

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

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

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

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

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

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

[_Артём_]

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

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

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

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

а внутренний буфер SIM900 ограничен (что-то вроде 500 байт, если не ошибаюсь)?

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

[Electronics Engi...]

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

Под попыткой подключения / подсоединения клиента к серверу я понимаю следующую
последовательность команд:
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 секунды. Смотрел пакеты данных на осциллографе.

[GeGeL]

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

[_Артём_]

Под попыткой подключения / подсоединения клиента к серверу я понимаю следующую
последовательность команд:
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", то процесс повторяется с

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

Этот весь период занимает меньше 3 секунд, типично 2.5 секунды. Смотрел пакеты данных на осциллографе.

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

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

[Electronics Engi...]

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

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

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

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

Возможно при повторных запросах первые 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мс для самых быстрых ответов.

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

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

[GeGeL]

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

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

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

[vka_]

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

[Electronics Engi...]

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

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

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

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

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

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

[_Артём_]

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

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

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

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

[Electronics Engi...]

Как-то быстро всё равно - у меня подключение к 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. А Вы сами тоже из Риги?

Сообщение отредактировал Electronics Engineer - Oct 12 2012, 16:32

[_Артём_]

При включении питания, действительно, на одну из команд AT+CREG? или AT+CGATT? (сейчас точно не помню какая) нужный ответ приходит где-то через 7-10 секунд.
А уже последующие попытки подключения клиента к серверу занимают в основном до 3 секунд.

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

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

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

[Electronics Engi...]

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

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

[_Артём_]

Если не секрет, какое оборудование делаете на базе SIM900?

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

Если что, было бы полезно на всякий случай иметь контакт в Риге.

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

[Electronics Engi...]

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

Эскизы прикрепленных изображений

 

[Electronics Engi...]

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

[MKdemiurg]

Вопрос заключается в том, как можно по возможности увеличить скорость передачи данных?

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

[_Артём_]

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

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

[GeGeL]

Очень много времени занимает ожидание "SEND OK". Иногда эта задержка может достигать
10 секунд и даже больше. Тут, как я понимаю, ничего не поделаешь,
т.к. подтверждение нужно и количество байтов в пакете тоже нельзя превышать 1380.

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

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

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

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

[Electronics Engi...]

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

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

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

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

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

[GeGeL]

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

[vintick]

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

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

[GeGeL]

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

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

[vintick]

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

[GeGeL]

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

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

[Romashki]

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