Здравствуйте!

Хотел бы поинтересоваться у знающих специалистов:

1. Насколько транспорт GPRS применим для передачи навигационных данных с мобильных объектов, имея ввиду вероятность получения отказа на доступ к сети передачи данных со стороны оператора.


2. Варианты "дублирования" канала - SMS, модемная передача. С СМС более или менее понятно. По поводу модемного соединения - если в системе ок. 100 объектов, передающих данные в центр с интервалом 1 минута - как организовать "очередь" дозвона мобильных устройств до центра (привязка к спутниковым часам и выделение каждому объекту своего "кванта времени" или временнОго кадра ???). Иначе, если все начнут звонить в раз, то в "центре" будет постоянно занято. Далее - организация нескольких приемных каналов - объединение "приемных" GSM- терминалов в пул ???

И вообще, может кто-то из Вас уже работал с подобной задачей?
Задача поставлена одной службой, для которой принципиально наличие всех исходников - начиная от "прошивки" МК, заканчивая софтом верхнего уровня... Поэтому готовые изделия - ну никак... Хозяин - барин ?!

т.е. схема передачи данных прим. такая:

{ GPS } --> { Контроллер } --> { GSM \ GPRS модуль } --> { WEB - Сервер } --> { Картографич. ПО + БД }

также в кач. резервного "транспортного" канала есть возможность использовать ведомственные радио - каналы УКВ.
Только с УКВ опять ситуация с выделением (или определением) очереди при передачи данных...

Поэтому, хотелось бы использовать GPRS, и в качестве "железа" модули со встроенным TCP/IP стеком.

Может кто сможет посоветовать "железо" GPRS, так сказать, проверенное в бою ???. Мне пока только довелось поработать с Telit...

Заранее благодарен... хотя-бы за то, что дочитали до сюда

С уважением, DZ

Решается административно, т.е. путем заключения соответствующего договора с оператором сотовой связи.



Если доводить до ума такую сеть для где-то сотни или более подвижных объектов, то рассчитывайте примерно на год работы для трех человек.



Думаю, практически все равно. Юзал SonyEricsson GR-47 и GR-64, нареканий нет.

Благодарю за ответ
Позвольте уточнить:

"Решается административно, т.е. путем заключения соответствующего договора с оператором сотовой связи."


1. Что в таком случае является предметом договора с оператором ? - что то вроде "класса сервиса" ???
2. Если вообще оператора не ставить в известность, то какие тут "подводные камни" ???
3. Каким образом (с технической точки зрения) договор может очеспечить доступность сервиса передачи данных, например в час пик при максимальной загрузке сети???

Или может сделать ставку на передачу в режиме CSD и сделать модемный пул... Но как я писал ранее, не знаю как лучше организовать очередь при отзвоне с моб. объектов? ... или может применить что - то на подобие того механизма, что применяется в сети Ethernet - т.е. выбор случайной по продолжительности паузы при повторном дозвоне (в случае, если при первой попытке было "занято", т.е. была обнаружена коллизия, если в терминах Ethernet)

т.е. на данном этапе мне важно твёрдо определиться именно со структурой системы - что бы точно знать , ЧТО надо реализовать, какой канал основной, какие варианты создания резервных возможностей передать данные...
и в таком случае, конечно, было быполезно услышать Мнение Людей, уже построивших подобное, или просто способных разумно прояснить вопрос .

Выделение GPRS-канала для передачи телеметрической информации.



Можно "не дозвониться" в часы максимальной загрузки.



Оператор обязуется предоставить канал в любое время, вне зависимости от загрузки сети. Детали вам лучше уточнить у своего оператора.

привет.
ниодин оператор не будет подставлять свою ж.... у меня в обоих договорах написано о факторах влияющих на качество услуг - плохие погодные условия.... Все зависит насколько развиты сети GSM у Вас в городе.
при моем опыте я бы советовал использовать и CSD и GPRS одновременно.
Пул модемов будет организовать не сложно - можно использовать "серийку". Оператор организовывает цепочку из номеров, первый из которых является callback который "зашивается" в модемы. Он всегда "свободен" и переадресовывает все звонки на следующий номер; дальше переадресация условная - если "свободен" - звонок принимется, если "занят" - переадресация дальше по цепочке. Подводные камни - необходимая емкость пула - при Вашей частоте передачи информации просто необходимо "выторгововать" у оператора спецтариф на CSD (у моей конторы сейчас порядка 1500 оконечных точек, откуда инфа собирается по CSD).
С этой позиции взгляд на GPRS более привлекателен. Во первых можно "висеть" практически постоянно on-line. Правда как будут работать мобильные точки - я не знаю. У операторов есть свои заморочки - я думаю без вдумчивых консультаций с опсосами никак. Советую сначала все "обкатать", то есть железо и софт на еденичных экземплярах. И прикинуть расходы на связь. А потом попросить опсосов сделать Вам коммерческое предложение. Во первых можно будет поторговаться , во вторых уладить вопросы со стороны операторов.
Использование же ведомственных радиочастот я бы поставил бы в стороне от GSM. во первых - это "цеплять" к другому ядру - это точно. я пока не видел девайсов, способных работать одновременно по простому радоканалу и GSM (CDMA, WCDMA, PCS) одновременно.
Посоветовать GPRS железо я не могу , так как его не юзаю. Однако на борту "машин" бороздящих просторы нашего GSM - wavecom wismo q2403 (2406) + контроллер am186.

to kuguar
Благодарю за ответ.

если не секрет, то что останавливает Вас (или Вашу контору ...) от перевода своей системы передачи данных на GPRS, ведь Вы тоже видете очевидные приемущества ? я не говорю о единовременном переводе СРАЗУ, а хотябы часть в тестовом режиме... отсутствие такой потребности ???

если сомнения такие - же, что и у меня, то тогда я Вас понимаю....

Всего Доброго,
73

1. затраты на замену "железа". у большинство этого чуда (называется оно falcom a2d-3) идет в составе q2403a. у него нет GPRS. денег на замену модулей - причем сама процедура достаточно трудоемкая - сейчас никто не даст - если я не докажу что это будет просто охрененно выгодно. Тем более в ту сторону не смотрели потому что систему делали в 2003-м - тогда новый у нас в городе оператор сказал что не будет у него возможности столько каналов предоставить. И самое главное - у GPRS была абонентская плата в $3 в месяц. Ежедневный же сбор информации по CSD + голосовые затраты у нас выходили примерно $2.5 на одну обслуживаемую станцию.
2. вместе с заменой модулей и способа связи придется менять софт второго уровня - а это тоже денег будет стоить немалых если не делать своими руками. у меня работает 1 программист - хватает для затыкания возникающих нужд (прошивки для новых или модифицированых типов вычислителей). Я конечно надеюсь что руки дойдут и до этого - но это будет нескоро и не быстро.

Это не совсем так - GPRS-то у него есть (класс 2), нет TCP/IP стека. Посему в аналогичной системе пришлось применить Q2406B.

...у меня сейчас проблемаименно с TCP/IP стеком. Железо - модуль Telit - GM-863 - QUAD.
управляю модулем с Mega-128. При попытки открытия сокета (т.е. конечной связи двухсетевых процессов - адрес IP+№порта) модуль встает "колом"... Ответа CONNECT от него не поступает, соответственно речи о
передачи данных идти не может.
Что самое интересное, до последнего времени всё работало - я специально написал тестовую прогу для компьютера, прицеплял к модулю через COM - порт (через MAX-232). Проходила отправка как пакетов UDP, так и данных поверх HTTP протоколом SMTP (данные с координатами отправлялись на адрес электронной почты).
И вдруг GPRS в модуле просто перестал работать. Без объяснения причин. Ни под управлением компа, ни под управлением контроллера Атмел....
В какую сторону думать, даже не знаю... Операторов связи пробовал разных, управляющие программы 100 процентов корректно посылают команды в модуль. Но не пашит.
Может кто-нибудь из Вас работал с такими модулями ???

зы на все команды модуль реагирует адекватно, СМС отправляет, номера набирает, а вот GPRS сдулся ???

1. попробовать перепрошить модуль (если такое возможно)
2. попробовать другой модуль.
то есть GPRS теперь даже с компа не идет?

Да, в том то и дело, что с компа тоже не идёт.
Насчет перепрошить - не уверен, а другой модуль - сегодня - завтра должны доставить.
Если буднт работать, тогда интересно, как он так странно "глуканул" - всё работает, кроме GPRS

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


интересно. никаким способом наличие GPRS у этих модулей у меня не получилось. как узнать?

Если на AT+CGDCONT (в принципе, на любые команды, связанные с GPRS) отвечает ERROR, то GPRS таки нет Wismo2C, к примеру, именно так и отвечает.
Может, прошивка какая-то своеобразная? Мне 2403A без GPRS не попадались, а знаком с ними с 2003 года. Даже иногда на этот форум через модем на базе Q2403A заходил
Другое дело, что класс GPRS низкий и скорость оставляет желать лучшего. 2406 (класс 10) куда шустрее.

>AT+CGDCONT=?
>ERROR
большая часть модемов как раз в 2003 закупалась. а если софт модуля обновить? поможет?
>ATI3
>433Q09gm.2D 1270036 030303 17:31
просто если простая перешивка модуля поможет - то будет рационален взляд на возможности перехода на GPRS. То есть писать софт, считать деньги - возможную экономию.

1. Применимо, делали и используем, работает.

2 Cудя по объему передаваемой информации (100 объектов, передающих данные в центр с интервалом 1 минута) SMS просто не выгодно, модемное соединение будет тоже мягко сказать недешево и организация такой системы без спец. договора с провайдером скорее всего нереальна, таким образом GPRS остаеться наиболее дешевым (но и наименне надежным решением).

Я бы перевел вопрос несколько в иную плоскость - какие требования к надежности системы и доставки сообщений от объекта к серверу? если нужна гарантированная доставка всех сообщений то GSM не применим (на мой взгляд), если нужно просто знать приблизительное местонахождение объекта хотя бы с точностью 1-3-5 минут - то вполне будет работать, естественно исключая моменты пиковой перегрузки сети. Те объекты которые не отвечают в течении определенного времени можно подсвечивать на карте и с ними связываться вручную.
Другой вопрос: а какую сумму в месяц готов платить клиент за эксплуатацию этой системы?

PS Задача похожа на мониторинг либо такси либо УВОшников
PPS 2:5030/1023 плотно работает в этой области и я думаю может дать более продвинутутые рекомендации (Надеюсь Тимур на меня не обидиться за разглашение информации , вы вроде с ним знакомы).

...похоже стало понятно, что почем.
при первых тестах с компа я использовал шнур от ком-порта с имеющейся линией ДТР и РТС, а тут не поглядел, и подключил через шнур, в котором только RX-TX & GND
Без линии DTR всё понимает, а как дело доходит до открытия сокета - ждёт установки DTR. что в принципе разумно

А тестовый софт уже написан по данный модуль (команды там есть АТ специфические...)
Спасибо !

А можно так: для удалённых точек есть ftp сервер, на него все эти точки сбрасывают информацию, а затемприложение на "сборном пункте" всё это дело собирает.
А не очень разбираюсь в тонкостях ftp, но можно ли одновременно с нескольких точек менять файл (для каждой точки свой)? Тогда наверно и будет решена проблема сбора информации. В конце концов не обязательно удалённый ftp, но как резерв можно и удалённый. Кто-нибудь такое пробывал?

Наверное, стоит попробовать два режима :
1. С установлением соединения (например HTTP протокол). Передачу непосредственно на "слушающий" порт сервера...
2. Без установления соединения, т.е. с использованием протокола UDP . Тоже самое, только без квитирования (нет подтверждений о приёме данных слушающим сервером). Менее надёжно, но быстрее установка соединения (точнее, соединение с сервером как таковое не устанавливается, модуль просто отправляет данные в сеть с указанием IP адреса и "слушающего" порта)

Вариант без установления соединения (UDP) уже попробовал, естественно есть потери при передачи...
->>> может у кого есть статистика по этому вопросу - как зависит от времени суток (час пик в сети или нет), и т.д. Не охота изобретать велосипед

Вариант с установкой соединения по HTTP (поверх TCP протокола) сейчас готовлю, сервер допишу - попробую.

В любом случае, думаю, что эти дваподхода надо совместить, только в каких пропорциях, пока не знаю...

Ребят, если есть у кого опыт работы по GPRS, может поделитись. Я не "комерс", скорее радиолюбитель и разработчик железа и софта, и клепать эти девайсы на конвеере не стану. Просто интересно услышать мнение тех, кто уже потоптал этот вопрос...

Всем удачи!

...и 73

Сомнительно.
Вот довольно свежий Q2403A:
ati3
641b09gg.Q2403A 1320676 061804 14:38
at+wssw
a04_3tgg.Q2403A 0000002C8F5DC7AA
at+cgdcont?
OK
at+cgdcont=?
+CGDCONT: (1-4),"IP",,,(0-1),(0-1)
+CGDCONT: (1-4),"PPP",,,0,0

OK

А вот Wismo2С:
ati3
420_09gm.2C 1171736 042301 17:30
AT+WSSW

A00_06gm.2C 000100008F5DC6EA
AT+CGDCONT?

ERROR

Судя по всему, у Вас Wismo2D. Или же, чем Wavecom не шутит, Q2403 с софтом от 2D - я таких не встречал. Тогда шансы есть.

если честно, прочивав release notes к прошивкам что я скачал нифига не понял. получается "внутри" 2403 куча модификаций, к которым каждой свои прошивки? прошивка этого модуля фирмвером, взятым с сайта wavecom привело к выпадению модуля в осадок. Таки получается что у меня 2d и надежд на GPRS нету.

можешь поделится опытом как ты это делал через АТ-команды?

где бы для wismo2d прошивки надыбать?

Для построения такой сети и чтоб было надежно в GPRS попробуйте модуль с аппаратной поддержкой 2-х симок. И обязательно РАБОТАЮЩИЙ GPRS 10класс.
Многие заявляют, но реально работает только 8, а это медленно. К примеру попробуйте на СИМКОМЕ прокачать 1 мегабайт и все поймете.

Кстати энергетики всякие телеметричесчкие GSM устройства без 2-х симок(а то и 3-х) вообще не рассматривают.
Я бы еще на температуру посмотрел. Используйте модули только от -30.

Обычно все работают по UDP. Желательно модуль с мультисокетами (понадежней).
пишется простенький скрипт на сервак и поехали.
Я использую GR64 с прошивкой R3B.

Потери есть, но незначительные (десятые доли процента). Никакие "часы пик" и "праздничные дни" не влияют. Траффик экономится. На мой взгляд, для некритичной информации UDP - идеальное решение.

Можешь поделится АТ-командами передачи данных по UDP? Без образования соединения точка-точка, от IP адреса к другому адресу.

Вот, смотрите. пример для GR64. Мегафон Питер.

//определяем PDP контекст для мегафона
at+cgdcont=1,"IP","internet"
OK
at*enad=1,"Account1 ","gdata","gdata",1,0
OK
at*e2ips=2,8,2,1020,1
OK
ats12=0
OK
at*e2ipa=1,1 //аттачимся в GPRS
*E2IPA: 000
OK
// Открываем UDP сокет. Тип сокета: 1 =TCP, 0 =UDP
AT*E2IPO = 0,”129.59.217.99”,80,1
CONNECT
// Теперь мы в дата мод, DCD поднято и мы на 80 порту Гугла.

// Теперь можно уйти назад в командный режим с помощью DTR
OK
// Можно глянуть DNS
AT*E2IPI=1
*E2IPI: 129.1.13.100
OK
//Проверяем активно ли соединение
AT*E2IPO?
*E2IPO: 1
OK
//Уходим в дата мод
ATO
CONNECT
//Если Гугл нас отбросил мы снова в командном режиме..
NO CARRIER

// Можно открыть другие сокеты и попередовать данные, при этом не забывая переключаться из дата
// в команд мод

//Первые сокет
at*e2ipo=1,"10.132.40.114",5001,1
CONNECT
12345678901234567890123456789012345678901234567890123456789012345678901234567890
1234567890123456789012345678901234567890123456789012
OK
//Второй сокет
at*e2ipo=1,"10.132.40.114",5002,2
CONNECT
12345678901234567890123456789012345678901234567890123456789012345678901234567890
1234567890123456789012345678901234567890123456789012
OK
//Ну и так далее.....

//или можно закрыть GPRS сессию..
AT*E2IPA=0,1
OK
//Финиш


Таким образом можно поднять до 15 активных сокетов одновременно. Можно слушать, принимать и передовать. Все это есть в АТ командах на GR64. А как дальше все это разруливать это предмет работы ))

2alexQ:
пример понятен, но он демонстрирует отправку данных через канал между сервером и клиентом. Интересует возможность отправить данные с сервера(порядка 10 байт) конкретному клиенту на IP адрес.

Теперь я не понял ... вопроса.

Вы имеете в виду сервер это некий IP в инете ? а клиент модем?

Сервер, находящийся в реальном инете не сможет выступить инициатором соединения с модулем,
т.к. APN провайдера закрыт NAT-ом на маршрутизаторе ОПСОСа.

В этом случае, модем должен законнектиться к серверу на порт, открыть сокет в режиме Server Listen и висеть на нем. желательно раз в 5-10 минут кидать пакет, чтобы ОПСОС не сбросил модуль с GPRS канала. как-то так ....

Так, попробую пояснить -
есть сервер со статич. IP и клиент у него IP динамич.(можно и для него статич., не проблема), оба подключены к модулю FargoMaestro 100 с wavecom q2406b, только сервер подключен к компьютеру, а клиент к микрконтролеру. Надо чтоб сервер мог обмениватся с клиентами посылками, причем максимально быстро. Организовывать поочередное открытие канала от сервера с каждым объектом - очень долго, так опрос 100 объектов может затянутся на час и более, что не приемлимо по условиям задачи. Вот я и думал что может через UDP будет это проще сделать.

Понятно.

В любом случае, т.к. сервер не знает IP клиентов они должны постоянно "висеть" каждый на своем выделенном порту. тем более активных сокетов и портов на серверной стороне (UNIX/Linux) может быть очень большое количество. инициатором соединения должен быть клиент.
по UDP обмен будет быстрее.

мы используем уникальный идентификатор устройства сбора передачи данных (УСПД). то есть если клиент соединился - он может должиться , я мол, такой то такойто. это предусматривалось на случай ввода платы за определитель номера.

Идентификацию должен делать сервер в любом случае.
Мобильный цепляется на порт сервера и говорит я ID такой-то и висит на каком-нибудь порту.

Я думаю в Вашей задаче нужно больше уделить вниманию серверной стороне, т.к. пока модем висит на сервере трафик все равно не идет Но нужно предусмотреть посылку по таймеру пары байт в 10 минут, чтобы ОПСОС по тихому не скинул с GPRS.

В Петербурге у Мегафона таймер разрыва 4мин, данные цифры из саппорта.
А вообще все ICQ клиенты имееют параметр KeepAlive =1мин.