| |
 TCP соединение через SIM900, производительность передачи данных |
|
|
|
|
 Sep 5 2012, 10:26
|
Знающий
Группа: Участник
Сообщений: 881
Регистрация: 21-03-10
Из: _// \\_
Пользователь №: 56 107
|
Имеем типовую задачку для телеметрии и удаленного обмена данных прибор-сервер. Ранее у нас реализован был вполне развитый протокол управляющих сообщений, бегающих по RS-485. Теперь вот хотим вставить новый кирпичик - GSM-концентратор. Уперлись в следующий вопрос. Можно ли средствами SIM900 установить TCP соединение с помощью AT команд, после чего перевести все это в прозрачный режим, выбрав конкретное (оно у нас единственное) TCP соединение в качестве терминала? Просто наш собственный протокол и так не очень сложен, и вписывается в подмножество ASCII 32-127. Нам и этого (небольшого впрочем) оверхеда хватит  Несколько напрягает алгоритм приема IP-пакетов через AT-команды. Получается, что прием утяжелен оверхедом в виде +CIPRXGET в различных комбинациях, и кушает до 80% трафика. То есть на скорости UART 115200 останется не более 1-2КБ/с, маловато, как мне кажется. В режиме терминала теоретически можно было бы все 100% трафика по UART использовать, ну или хотя бы близко приблизится к потолку трафика по GPRS (вроде 85.6Кб). Но нас вообще больше закачка на сервер интересует, а там вроде только 42.8Кбит/с обещано. Но это все равно больше, чем получится при возне с АТ командами...
Сообщение отредактировал Hoodwin - Sep 5 2012, 10:31
|
|
|
|
|
|
3 страниц 
1 2 3 >
|
 |
Ответов
(1 - 35)
|
|
Sep 5 2012, 11:29
|
Знающий
Группа: Участник
Сообщений: 881
Регистрация: 21-03-10
Из: _// \\_
Пользователь №: 56 107
|
Да я и спрашиваю про прозрачный режим, как его включить то?
Хочется как с модемом раньше было, получил CONNECT и пиши себе все что хочешь, потом +++ и обратно к AT командам. Такое можно сделать?
Ну, я понимаю, что при интерфейсе, поддерживающем потенциально несколько соединений, это не всегда возможно сделать, но может быть можно сказать, что вот хочу превратить соединение X в простой терминал, и после этого прозрачный доступ как по модему.
Сообщение отредактировал Hoodwin - Sep 5 2012, 11:30
|
|
|
|
|
|
|
|
Sep 6 2012, 09:31
|
Знающий
Группа: Участник
Сообщений: 881
Регистрация: 21-03-10
Из: _// \\_
Пользователь №: 56 107
|
Верю, что нога DTR лучше. Но в design guide про нее написано только в отношении sleep, про режим терминала ничего не сказано. Вообще странно, что там все как-то половинчато расписано. DTR можно использовать для перевода модуля в спящий режим, но для этого надо сначала включить эту фичу (AT+CSCLK=1), а можно ее не включать и переводить в спячку с помощью AT+CFUN. Аналогично, расписаны фичи сигнала RING, а потом выясняется, что статусы звонков и СМС прекрасно валятся по UART. Спрашивается, зачем тогда пин анализировать. Почитав этот документ я сделал вывод, что больше пользы будет от RING, и сейчас подключены три сигнала RING, TXD, RXD. Вопрос сводится к тому, действительно ли DTR имеет функцию входа выхода из режима команд AT и простого терминала, и можно ли его тогда подключить к МК вместо RING. Дело в том, что выводов свободных у МК уже нет, и нужно искать компромис.
|
|
|
|
|
|
|
|
Sep 6 2012, 10:03
|
Гуру
Группа: Свой
Сообщений: 6 023
Регистрация: 26-08-05
Из: Днепр
Пользователь №: 7 988
|
>>> Но в design guide про нее написано только в отношении sleep, про режим терминала ничего не сказано. Вообще странно, что там все как-то половинчато расписано. А кроме design guide что-то пользовали??? Например апнотесы? Там поболее написано..... По первому вопросу SIM900_TCPIP_Application Note_V1.02.pdf По DTR SIM900_Serial Port_Application Note_V1.03.pdf http://microchip.ua/simcom/?link=/SIM900x/AppNotesЯ обычно исхожу из того что разработчик просмотрел всю доступную документацию и не нашел ответ или не допонял его. Ваши вопросы просто не возникли бы после прочтения апнотесов. Тем более что все доки в свободном доступе.
--------------------
Не можна втрачати надію. Не можна здаватися до останньої миті. Можливо саме вона, остання мить, принесе весну, яка стане початком нового життя.
|
|
|
|
|
|
|
|
Sep 6 2012, 11:03
|
Знающий
Группа: Участник
Сообщений: 881
Регистрация: 21-03-10
Из: _// \\_
Пользователь №: 56 107
|
Да, действительно, есть такие документы Почитаем, спасибо. Я не против чтения док, просто культурные фирмы ссылаются обычно из главного документа на дополнительные. Читать вообще все доки, чтобы воспользоваться 10% - это неправильно. Ну, видимо, у SIMCOM такая нетривиальная организация док, не совсем привычно, мягко говоря. Например, глянул бегло в Serial port AN. Оказывается, там приведены схемы подключения к МК со сдвигом уровней. Зато в design guide их нет, и даже нет ссылки, что есть подробный мануал на Serial port, в котором повторено все, что есть в design guide.
|
|
|
|
|
|
|
|
Sep 6 2012, 12:38
|
Знающий
Группа: Участник
Сообщений: 881
Регистрация: 21-03-10
Из: _// \\_
Пользователь №: 56 107
|
Ну, я привык к градациям док от TI. У них доки, в которых расписана столбовая дорога, называются user guide, иногда reference guide. Но никогда (!) не application notes. В Application notes они публикуют труды своих инженеров (с указанием авторства), которые могут быть полезны кому-то, например, практическая реализация какого-то алгоритма, справка по использованным для него ресурсам, и т.п. То есть это весьма такие второстепенные документы, которых может быть много, и которые могут никогда не пригодиться. При этом документ, в котором описаны absolute maximum ratings, electrical characteristics, AC timing characteristics, назначение выводов и чертеж, коды для заказа, обычно называется datasheet, а не hardware design. Конечно это все не фатально, научимся, будет работать, никуда не денется .
|
|
|
|
|
|
|
|
Sep 6 2012, 13:48
|
Просто Che
Группа: Свой
Сообщений: 1 567
Регистрация: 22-05-07
Из: ExUSSR
Пользователь №: 27 881
|
Цитата(Hoodwin @ Sep 6 2012, 14:03)  Я не против чтения док, просто культурные фирмы ссылаются обычно из главного документа на дополнительные. Читать вообще все доки, чтобы воспользоваться 10% - это неправильно. Ну, видимо, у SIMCOM такая нетривиальная организация док, не совсем привычно, мягко говоря. Ну, можете считать, что Simcom пока что фирма некультурная  издержки роста... Сколько лет Texas-у и сколько Simcom-у Сейчас документация уже вполне приличная, хотя и разбросана по многим документам не слишком системно. Радуйтесь и этому, я когда начинал несколько лет назад, было всего два документа: хардварный дизайн и АТ-команды, где информации было раза в три меньше чем сейчас. И куча глюков в железе и софте. Только форум и помогал... 
|
|
|
|
|
|
|
|
Sep 6 2012, 18:28
|
Группа: Новичок
Сообщений: 7
Регистрация: 3-09-12
Из: Харьков
Пользователь №: 73 369
|
Всем привет.
Тема интересная. Возьмите МС52i и выше, все получится.
Одно но. Вы уверены, что интернет сервис (tcp/ip stack) работает по GPRS-у? Я не уверен.
Удачи Вам.
|
|
|
|
|
|
|
|
Sep 10 2012, 18:36
|
Знающий
Группа: Участник
Сообщений: 881
Регистрация: 21-03-10
Из: _// \\_
Пользователь №: 56 107
|
Пока еще точных данных мы не получили, так как не прикрутили передачу больших объемов данных. Пока что видно, что сетка дает довольно большую задержку: одиночный запрос-ответ затягивается на 5-7 секунд. Но вот у нас протокол поддерживает конвейерную обработку запросов, поэтому мы пробовали посылать 5 запросов подряд, ну где-то через 100 мс каждый. Запрос и ответ занимают около 20 байт. По логам видно, что тормозят первые, потом начинается некоторое оживление, можно наблюдать интервал прихода ответов около 16 мс. Из чего мы получили грубую оценку 19 байт / 16 мс ~= 1.2 Кб/с. Пока не готов ничего сказать про то, насколько это близко к истине, и что будет при передаче больших объемов данных. По идее, сота отдает приоритет голосовым данным, и поэтому скорости и задержки могут быть нестабильны.
В связи с этими соображениями возник вопрос, можно ли синхронизировать RTC (время) внутри модуля по сети? И с какой точностью это можно сделать? Нам вот хочется с погрешностью не более 0.5с, а лучше 100 мс.
Но при таком routd trip'е что-то не совсем ясно как. Нет никаких гарантий, что время пролета пакета туда равно времени пролета обратно.
|
|
|
|
|
|
|
|
Sep 11 2012, 00:38
|
Местный
Группа: Свой
Сообщений: 202
Регистрация: 18-05-09
Из: Novosibirsk
Пользователь №: 49 204
|
Цитата(MKdemiurg @ Sep 6 2012, 20:21) Пффф.... Я тут начал чехлить bluetooth модули от китайцев. Там кроме IDE с его хелпом документации НЕТ ВООБЩЕ  А сим-ком по сравнению - хааарошая европейская фирма  Если не секрет, то что за модуль используете? Какой интерфейс - UART, USB? Какая цена? Ссылочку дайте пожалуйста
|
|
|
|
|
|
|
|
Sep 11 2012, 11:59
|
Гуру
Группа: Свой
Сообщений: 2 128
Регистрация: 21-05-06
Пользователь №: 17 322
|
Цитата(Hoodwin @ Sep 10 2012, 21:36) Пока еще точных данных мы не получили, так как не прикрутили передачу больших объемов данных. Пока что видно, что сетка дает довольно большую задержку: одиночный запрос-ответ затягивается на 5-7 секунд. Но вот у нас протокол поддерживает конвейерную обработку запросов, поэтому мы пробовали посылать 5 запросов подряд, ну где-то через 100 мс каждый. Запрос и ответ занимают около 20 байт. По логам видно, что тормозят первые, потом начинается некоторое оживление, можно наблюдать интервал прихода ответов около 16 мс. Из чего мы получили грубую оценку 19 байт / 16 мс ~= 1.2 Кб/с. Спасибо. То есть никаких чудес от использования своего стека TCP (а что за стек кстати?) не получилось - всё те же единицы килобайт в секунду. Цитата(Hoodwin @ Sep 10 2012, 21:36) По логам видно, что тормозят первые, потом начинается некоторое оживление, можно наблюдать интервал прихода ответов около 16 мс. Из чего мы получили грубую оценку 19 байт / 16 мс ~= 1.2 Кб/с. Тоже недавно пробовал закачивать данные на модуль (использовал стек sim900) с ПК (передавал пакетами ~530 байт): получилось 2-3 пакета в секунду, что соответствует 1-2 кБ/сек.
|
|
|
|
|
|
|
|
Sep 11 2012, 16:09
|
Знающий
Группа: Участник
Сообщений: 881
Регистрация: 21-03-10
Из: _// \\_
Пользователь №: 56 107
|
Нет-нет, мы никакой стек не изобретали. Сначала делали на TCP API от SimCom, потом переделали на transparrent mode. Наш собственный протокол (не стек) построен на подмножестве символов ASCII 32-ASCII 127, так что он на transparrent mode хорошо ложится. Приведенные выше данные по скорости относятся именно к transparrent mode. Скорость мы еще погоняем.
на самом деле у нас там всюду стоят довольно большие чипы NAND в связке с FRAM, сначала все пишется в FRAM, потом, по достижении 2Кб, в фоновом режиме переписывается в NAND. Объем NAND такой, что хватит на всю жизнь прибора. Поэтому скорость канала GPRS не так критична, она представляет интерес только для оценки, на сколько приборов хватит одного GSM-модуля, в среднем. То есть, это больше экономическое требование, чем техническое.
|
|
|
|
|
|
|
|
Dec 4 2012, 11:05
|
Местный
Группа: Свой
Сообщений: 403
Регистрация: 29-04-11
Из: Украина
Пользователь №: 64 682
|
Цитата(vintick @ Dec 4 2012, 11:22) Если я хочу проключить http-server с мк, то я правильно понял:
-я открываю сервер и становлюсь в ожидание.
-получаю конект от клиента.
-получаю запрос (GET например, вся расшифровка в мк).
-перехожу в Transp.mode отдаю данные (т.е. html).
-возвращаюсь в com.mode.
-жду следующего запроса.
Но http требует дисконекта каждый раз
после отработки запроса и нового конекта пои след. запросе.
Как это будет выглядеть на что повлияет, если так
дергать конект? (IP статический, конечно). Или надо другой
протокол использовать? Речь идет о TCP-конекте или о GPRS-конекте? Если о TCP, то клиент (браузер) по идее сам закрывает соединение после получения HTML, после чего слущающий сокет модуля готов принять новое соединение (даже если он на одного клиента рассчитан).
|
|
|
|
|
|
|
|
Dec 4 2012, 17:14
|
Местный
Группа: Свой
Сообщений: 403
Регистрация: 29-04-11
Из: Украина
Пользователь №: 64 682
|
Запустите снифер и посмотрите, что происходит при открытии страницы. 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
|
|
|
|
|
|
|
|
Dec 5 2012, 06:51
|
Местный
Группа: Свой
Сообщений: 403
Регистрация: 29-04-11
Из: Украина
Пользователь №: 64 682
|
Цитата(andrewlekar @ Dec 5 2012, 08:14) Зачем так сложно? В природе существуют веб-серверы: апач или иис. Если уж сильно хочется написать самому, то можно взять питон или перл и реализовать веб-сервер в десяток строчек. Так в том то и дело, что на самом деле это, наоборот, очень просто На С практически тоже в несколько строчек получается. А прикручивать и настраивать тот же апач + SQL на порядок сложнее этих нескольких строчек. Да и на рнр я не особо мастер  Кроме того, изначально речь шла об реализации http-сервера на базе GSM-модуля (на микроконтроллере): тут уж все вручную придется все делать. А по поводу моей реализации GPS-сервера: на VDS за 5 уе/мес (500 MHz, 256RAM) запускаю полсотни таких демонов, каждый на 254 машины, загрузка мизерная. А какие ресурсы потребует классический подход для 10000 трекеров?
Сообщение отредактировал GeGeL - Dec 5 2012, 06:53
|
|
|
|
|
|
|
|
Dec 5 2012, 07:06
|
Частый гость
Группа: Участник
Сообщений: 186
Регистрация: 4-05-09
Пользователь №: 48 624
|
Цитата(GeGeL @ Dec 4 2012, 20:14) Запустите снифер и посмотрите, что происходит при открытии страницы. 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В устройстве у меня уже есть и web-server и html страницы и c java и c ajax, используется для web-конфигурирования, но через RJ-45 конечно. Хочу получать полный обмен с встроенным сервером. Проключение http-сервера открывает много возможностей.
|
|
|
|
|
|
1 чел. читают эту тему (гостей: 1, скрытых пользователей: 0)
Пользователей: 0
|
|
|
