GPRS для чайников Опции

[ISG2015]

Необходимо разработать систему с передачей данных c использованием технологии GPRS.
Выбор пал на модемы SimCom

Готовых решений не встречал (готов за разумные деньги приобрести) и поэтому вынужден заняться изобретением велика
Несколько вводных вопросов относительно темы:

1. Можно ли организовать GPRS канал связи используя только АТ команды, не пользуясь Embedded AT?
2. После прочтения мануалов и даташитов на тот же Sim900 реализуемо своими силами?
3. Как учесть все особенности и нюансы каждого GSM оператора используя только одни АТ команды?

Буду оч. признателен за любые советы и помощь.

[id_Alx]

Необходимо разработать систему с передачей данных c использованием технологии GPRS.
Выбор пал на модемы SimCom

Готовых решений не встречал (готов за разумные деньги приобрести) и поэтому вынужден заняться изобретением велика
Несколько вводных вопросов относительно темы:

1. Можно ли организовать GPRS канал связи используя только АТ команды, не пользуясь Embedded AT?
2. После прочтения мануалов и даташитов на тот же Sim900 реализуемо своими силами?
3. Как учесть все особенности и нюансы каждого GSM оператора используя только одни АТ команды?

Буду оч. признателен за любые советы и помощь.

1 - можно.
2 - реализуемо.
3 - AT командами можно определить оператора. Особенности работы с конкретным оператором выясняются опытным путем.

[p_kav]

А какой конкретно GPRS? TCP, UDP, почта, WEB? Только отправка данных, или двухсторонний обмен? Есть ли потребность в минимизации трафика?

Сообщение отредактировал p_kav - May 6 2015, 17:34

[ISG2015]

А какой конкретно GPRS? TCP, UDP, почта, WEB? Только отправка данных, или двухсторонний обмен? Есть ли потребность в минимизации трафика?

Все пока на стадии инициации проекта. Толком еще не расставлены акценты. Все еще в виде черновика и мутных планов.
Но точно необходимо будет:

1. Технология будет похожа на клиент-серверную организацию;
2. Скоррее всего на стороне сервера будет статический IP;
3. Минимальный трафик;
4. Обмен данными двухсторонний, но есть мысли о том чтоб клиенты получали информацию читая данные из тиблиц БД на сервере, отправляли данные записывая данные в БД на сервере. Таким образом нам не нужно будет работать напрямую от сервера к клиенту.

В принципе можно поднять на сервере TCP сервер или WEB сервер. Выбор технологии будет связан с клиентской стороной. На стороне клиента(тов) будут SIM900 и Ethernet модули.

Сообщение отредактировал ISG2015 - May 7 2015, 05:36

[p_kav]

Всё это описано в документе "SIM900 TCPIP Application Note", с примерами команд.
Думаю, вам подойдет прозрачный режим - настроили модуль, подняли соединение, и общаетесь с сервером напрямую, посылая и принимая данные из сокета прямо с последовательного порта. Если при этом будет нужна обработка звонков и SMS, то можно подключить контакт RI к контроллеру, и модуль будет информировать о входящих SMS и звонках импульсами на этом контакте.

[ISG2015]

Всё это описано в документе "SIM900 TCPIP Application Note", с примерами команд.
Думаю, вам подойдет прозрачный режим - настроили модуль, подняли соединение, и общаетесь с сервером напрямую, посылая и принимая данные из сокета прямо с последовательного порта. Если при этом будет нужна обработка звонков и SMS, то можно подключить контакт RI к контроллеру, и модуль будет информировать о входящих SMS и звонках импульсами на этом контакте.

Да, спасибо.

Что имею на сегодня:
1. Поднял на сервере с статическим адресом от провайдера TCP-сервер.
2. AT командами установил на модеме SIM900 соединение с сервером.
3. Успешно попробовал отправлять данные от модема к серверу.

Но все это верхушка айсберга. Не понимаю совершенно, как поддерживать это "сессию" в актуальном состоянии, как обрабатывать ошибки, отваливания, и вообще как следить за линком?

Подскажите, каким вы пользуетесь софтом для работы с АТ командами? Каким для работы с СОМ портом?
Попробовал "Terminal.exe" и "COM Port Toolkit 3.9". Мне показались они не оч. подходящими.

Спасибо!

Сообщение отредактировал ISG2015 - May 8 2015, 07:08

[p_kav]

PuTTY приличный терминал для COM-порта.

Насчет управления сессией - экспериментируйте, создавайте сбойные ситуации. Например, взяли и закрыли сессию на сервере, или закрыли порт на сервере файрволом прямо в процессе обмена данынми, и смотрите что говорит модуль.

Насчет поддержания сессии - рекомендую определить на сервере какую-то последовательность, на которую он просто отвечает и не выполняет никаких действий. например, если отправить на сервер "NOP", сервер вернет "NOP OK". SIM900 должен отправлять этот "NOP" раз в минуту и если получает ответ, значит сессия жива, иначе её надо переустановить. Суть в том, что на механизм TCP надеяться не следует - если в течение какого-то времени по TCP-сессии не передается никаких данных, многие файрволы просто забывают о ней никак не уведомляя клиент и сервер, и оба шлют данные в никуда.

[ISG2015]

Спасибо за советы.

Еще не очень понимаю, как именно посмотреть статистику по расходу трафика на стороне модема? Как понять сколько трафика расходует SIM900 в GPRS режиме в данных конкретных обстоятельствах?

По поводу "NOP" - "NOP OK" это наверное правильно, ведь если на серверной стороне я еще смогу понять что нет линка с конкретным клиентом средствами самого сервера, то на клиенте все далеко не так очевидно. Хотя вообще чайник ,могу и ошибаться.

Сейчас у меня при простое модема с поднятой сессией отваливается "PDP DEACT"

[p_kav]

Счетчиков трафика в модуле я не нашел, но я не вижу в них смысла - вы же сами принимаете и передаете все данные и сам знаете сколько передали и приняли. Есть, конечно, оверхед протокола TCP, но им можно пренебречь т.к. оператор всё-равно округлит количество данных, переданных по каждой GPRS-сессии до сотен килобайт в большую сторону, поэтому считать байты, как было на GPRS-WAP смысла нет.

[kan35]

Можно пойти пацанским путём: использовать PPP и внешний tcp стек, благо нынче и железа подходящего полно и софт есть
например lwIP и STM32 и любой модем включая проводные))

[GeGeL]

как поддерживать это "сессию" в актуальном состоянии, как обрабатывать ошибки, отваливания, и вообще как следить за линком

Гораздо проще использовать UDP. На сервере держите всего один сокет, при получении пакета от клиента проверяете контрольную сумму, сохраняете данные в базе, возвращаете КС на IP/порт отправителя.
Алгоритм клиента: если есть новые данные, поднимаете GPRS, отправляете данные и КС, ждете ответа 2-3 сек, если нет, то повторяете 3-5 раз. После получения подтверждения или исчерпания попыток рвете GPRS (если сеансы реже 5-10 мин), или оставляете, если чаще.
Преимущества: не нужна поддержка открытой ТСП-сессии, нет процедур конекта/дисконекта, гарантийность доставки и таймауты организованы под задачу, а не универсал. Т.к. у вас статический IP на сервере, не надо ресолвить доменное имя. Трафик, как минимум, в 1.5 раза меньше, чем в случае с ТСП.
С помощью OpenCPU/EAT это реализуется за час. И, кстати, почему Вы не хотите использовать EAT? Если нет желания изучать все команды, можете использовать всего одну - отправку данных в виртуальный порт. И один обработчик - получение данных с него. А дальше отсылайте АТ-команды, и получайте ответы так же, как и в случае с внешним процессором. И надежней, и дешевле, и код переносимый будет.

Что касается канала сервер-диспетчер, то тут как угодно, например, SQL.

[p_kav]

Не соглашусь про разрыв GPRS - оператор округлит объем в большую сторону и 20 байт превратятся в 100 килобайт.
Про UDP тоже не всё так просто. Если сервер захочет передать модулю какие-то данные не сразу после прихода сообщение от модуля, а в произвольное время, то не факт, что они дойдут т.к. файрвол провайдера может просто забыть об этой сессии. Клиенты мобильных операторов сидят за NAT, адресов не так много, поэтому неактивные сессии там устаревают и сбрасываются очень быстро. С TCP же понятно подключен ли в конкретный момент конкретный модуль к серверу и дошло ли сообщение. Если начать реализовывать все эти проверки доставки на UDP, то в конце концов просто заново изобретешь TCP.

[GeGeL]

разрыв GPRS - оператор округлит объем в большую сторону

Не все операторы это делают, и объем округления тоже разный. Надо смотреть индивидуально, и учитывать время между активностью. Дело в том, что всегда имеется фоновый IP-спам, который тарифицируется в случае, если сисоп назначает модую "белый" IP. Поэтому решение о разрыве надо принимать по факту, исходя из задачи и условий.

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

По условию ТС сервер поднят на белом IP. Поэтому, независимо от того, какой IP назначен сисопом модулю, первый же и любой пакет, отправленный с модуля на сервер в любое время, инициирует фаервол провайдера, и будет выпущен наружу. Т.к. по определению на серверной части нет фаервола, то он будет доставлен. NAT со стороны провайдера будет инициализирован, и сервер имеет около 3 минут на ответ. По истечение этого времени NAT провайдера закроет соединение, и сервер никак не достучится до клиента, аж до следующей активности клиента. Если передачу "клиент-сервер" по условию задачи инитит только клиент, то все ОК. Если требуется возможность активации клиента со стороны сервера, то, как по мне, проще сделать это входящем звонком клиенту (при разумном количестве клиентов и редких случаях, например, конфигурирование клиента), чем держать все время отрытую TCP-сессию.

Если начать реализовывать все эти проверки доставки на UDP, то в конце концов просто заново изобретешь TCP.

Именно к этому я и веду: многие разработчики, со студенческой скамьи запомнив, что TCP обеспечивает гарантированную доставку, понятия не имеют, как на самом деле это происходит. Более того, в большинстве случаев не могут повлиять на таймауты переотправки, закрытия и т.п. сокета, определяемые внутренними настройками TCP-стека. Известно: универсальных вещей хороших не бывает. Если вы сделаете свой слой гарантийной доставки и контроля под задачу над UDP, то он будет однозначно лучше штатного TCP. Но обычно лень побеждает, и придумываются оправдания.

[BIOlinq]

Под SIM900 и AVR например есть готовые опенсорсные библиотеки, которые умеют TCP, у вас что будет подключено к SIM900? МК?

[p_kav]

Под SIM900 и AVR например есть готовые опенсорсные библиотеки, которые умеют TCP

Видел я эти библиотеки, полный страх, ужас и неоптимальность. Когда общаешься с модулем, программу нужно строить полностью самому под конкретную задачу, библиотека тут скорее навредит, чем поможет.