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

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

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

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



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

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

Что значит подсоединение?
Раз в 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. А Вы сами тоже из Риги?

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

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


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

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

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


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