Ну, можете считать, что Simcom пока что фирма некультурная издержки роста...
Сколько лет Texas-у и сколько Simcom-у
Сейчас документация уже вполне приличная, хотя и разбросана по многим документам не слишком системно.
Радуйтесь и этому, я когда начинал несколько лет назад, было всего два документа: хардварный дизайн и АТ-команды, где информации было раза в три меньше чем сейчас. И куча глюков в железе и софте. Только форум и помогал...

Пффф.... Я тут начал чехлить bluetooth модули от китайцев. Там кроме IDE с его хелпом документации НЕТ ВООБЩЕ А сим-ком по сравнению - хааарошая европейская фирма

Всем привет.
Тема интересная. Возьмите МС52i и выше, все получится.
Одно но. Вы уверены, что интернет сервис (tcp/ip stack) работает по GPRS-у? Я не уверен.
Удачи Вам.

А еще лучше мульнимлексный режим юзать - по одному каналу передаете, по другому командуете.

Любопытно узнать, какой скорости приёма/передачи удалось добится.
Или ещё тестируется?
Спасибо.

Пока еще точных данных мы не получили, так как не прикрутили передачу больших объемов данных. Пока что видно, что сетка дает довольно большую задержку: одиночный запрос-ответ затягивается на 5-7 секунд. Но вот у нас протокол поддерживает конвейерную обработку запросов, поэтому мы пробовали посылать 5 запросов подряд, ну где-то через 100 мс каждый. Запрос и ответ занимают около 20 байт. По логам видно, что тормозят первые, потом начинается некоторое оживление, можно наблюдать интервал прихода ответов около 16 мс. Из чего мы получили грубую оценку 19 байт / 16 мс ~= 1.2 Кб/с. Пока не готов ничего сказать про то, насколько это близко к истине, и что будет при передаче больших объемов данных. По идее, сота отдает приоритет голосовым данным, и поэтому скорости и задержки могут быть нестабильны.

В связи с этими соображениями возник вопрос, можно ли синхронизировать RTC (время) внутри модуля по сети? И с какой точностью это можно сделать? Нам вот хочется с погрешностью не более 0.5с, а лучше 100 мс.
Но при таком routd trip'е что-то не совсем ясно как. Нет никаких гарантий, что время пролета пакета туда равно времени пролета обратно.

>>>По идее, сота отдает приоритет голосовым данным

100% Да
При пиковой нагрузке слотов под данные не будет вообще.

Если не секрет, то что за модуль используете? Какой интерфейс - UART, USB? Какая цена?
Ссылочку дайте пожалуйста

Спасибо.
То есть никаких чудес от использования своего стека TCP (а что за стек кстати?) не получилось - всё те же единицы килобайт в секунду.


Тоже недавно пробовал закачивать данные на модуль (использовал стек sim900) с ПК (передавал пакетами ~530 байт): получилось 2-3 пакета в секунду, что соответствует 1-2 кБ/сек.

Нет-нет, мы никакой стек не изобретали. Сначала делали на TCP API от SimCom, потом переделали на transparrent mode. Наш собственный протокол (не стек) построен на подмножестве символов ASCII 32-ASCII 127, так что он на transparrent mode хорошо ложится. Приведенные выше данные по скорости относятся именно к transparrent mode. Скорость мы еще погоняем.

на самом деле у нас там всюду стоят довольно большие чипы NAND в связке с FRAM, сначала все пишется в FRAM, потом, по достижении 2Кб, в фоновом режиме переписывается в NAND. Объем NAND такой, что хватит на всю жизнь прибора. Поэтому скорость канала GPRS не так критична, она представляет интерес только для оценки, на сколько приборов хватит одного GSM-модуля, в среднем. То есть, это больше экономическое требование, чем техническое.

Понял, спасибо.

Если я хочу проключить http-server с мк, то я правильно понял:

-я открываю сервер и становлюсь в ожидание.
-получаю конект от клиента.
-получаю запрос (GET например, вся расшифровка в мк).
-перехожу в Transp.mode отдаю данные (т.е. html).
-возвращаюсь в com.mode.
-жду следующего запроса.

Но http требует дисконекта каждый раз
после отработки запроса и нового конекта пои след. запросе.
Как это будет выглядеть на что повлияет, если так
дергать конект? (IP статический, конечно). Или надо другой
протокол использовать?

Речь идет о TCP-конекте или о GPRS-конекте?
Если о TCP, то клиент (браузер) по идее сам закрывает соединение после получения HTML, после чего слущающий сокет модуля готов принять новое соединение (даже если он на одного клиента рассчитан).

А вот интересно, что я получу на входе, если буду выходить
из IExplorer на свой stat.IP ?
Я получу конект с сервером (например REMOTE IP 192.168.1.5,
клиент же подразумевает конект)?
И куда денется идущий следом GET запрос? Он получиться в виде
данных или нет?

Запустите снифер и посмотрите, что происходит при открытии страницы.
Connect (тройное рукопожатие для установки тсп-соединения) не в счет, он в даной ситуации производится сокетом по вашей команде. Затем клиент (браузер) посылает порцию данных, где указывает, что бы он хотел получить в ответ (это и есть GET-запрос). Сервер (модуль) получает эти данные, парсит их (находит GET и выделяет следующие за ним параметры) и посылает в ответ также пакет с данными, содержащими HTML-код. После чего клиент (или сервер) могут закрывать тсп соединение, а могут оставить.

Для реализации простейшего веб-сервера напишите html-страницу (можно с жава-скриптами), поубирайте лишние пробелы и переносы строк, запустите веб-сервер (например, Денвер) и отсниферите запрос браузера и ответ сервера.
Затем со снифера скопируйте данные ответа сервера, оформите в виде static char массива в программе MC (или модуля).
Откройте слушающий tcp-сокет, в получаемых данных ищите строку GET, если нашли, обрабатывайте следующие за ней параметры и отвечайте пакетом данных из массива. Если хотите в нем что-то менять (выдавать результаты), перед ответом сделайте патч по определенным смещениям в буфере.

ПС: у меня таким образом функционирует веб-сервис для мобильных клиентов в жпс-сервере (правда, не на модуле, а на VDS с Linux, но принцип тот же). Сделано все на уровне сокетов, на С, весит 22К, не требует ничего, кроме Linux (также есть версия под Win32), При получении данных ищется GET и парсятся следующие за ним параметры: номер трекера, масштаб, тип карты. Затем выдается заранее сделанная веб-страница, предварительно по фиксированным адресам в массиве меняются данные о номере трекера, времени, координатах, скорости и т.д.
Страница содержит ссылку на рисунок из GoogleStaticMap (предварительно пропатченную сервером в нужных местах), а также маленькие жава-скрипты для элементов управления, позволяющие менять масштаб и тип карты клиентом.
Получив ответ, браузер запрашивает рисунок с GoogleMap и отображает вместе с нужной информацией. Если клиент хочет изменить масштам или тип карты, он использует элементы управления, жаваскрипт сам патчит требуемые места в ссылке и рисунок перезагружается. Повторного обращения к серверу при этом не производится, только к GoogleMap.
Если кого заинтересует, скачать можно на http://www.gegelsoft.ru/files.php?dir=files