M2M: SIM900D vs GL868-DUAL, какой из модулей лучше, надежней, перспективней для M2M Опции

[CADiLO]

Я не буду спорить - подчеркну что это мое ИМХО, выведенное из простой логики. Время и клиенты рассудят.
Но те кто мыслит логически, думаю увидят ту же картинку что и я. Впрочем как Вы и сказали - это все догадки.........

[pau62]

>>>Так что хва уж передергивать, вроде уважаемые люди... Ну не место тут таким кривым аргументам, не лохи же вокруг поголовно.

Изначально фраза звучала так: "При этом пиковый ток, потребляемый модулем в режиме передачи 1,6А, вместо 2А у М10."

Смотрим определение: "Пиковое значение — наибольшее мгновенное значение напряжения или силы тока за период."
То есть это значит что больше этого уже быть не может - я другого контекста не вижу.

А таблица 29 четко указывает что оказывается может быть и больше и достигать 2 ампер.

И отсюда вывод - значение фразы: "При этом пиковый ток, потребляемый модулем в режиме передачи 1,6А, вместо 2А у М10." = FALSE

Странно что это Юзверя так задевает.... Или все же не юзверя ?

Т.е. уважаемый CADiLO утверждает, что пиковый ток в соответствующих таблицах и импульсный ток на соответствующих графиках в документации на м10 и на м80 не отличается примерно в 1.5 раза?

[CADiLO]

Я ничего не утверждаю из того что Вы мне пытаетесь навязать.
Речь идет о конкретной фразе и конкретном документе. Что пишут в других документах смотрите сами.
Свое объяснение по конкретному случаю я привел выше. Кроме того я оспаривал не Вашу реплику.
И насколько я вижу мои объяснения у Aleksandr_q (автора фразы) такой бурной реакции не вызвали.
Наверное потому что мы все понимаем что может быть и опечатка, и моя ошибка - и если я не прав то принесу
извинения Александру, как автору фразы, но никак не анонимному Юзверю как Вы сами себя назвали.

[CupuyC]

Т.е. уважаемый CADiLO утверждает, что пиковый ток в соответствующих таблицах и импульсный ток на соответствующих графиках в документации на м10 и на м80 не отличается примерно в 1.5 раза?

CADiLO говорит, что пиковый ток, который может быть при определенных условиях в любых GSM модулях может достигать 2А. Это касается М10, М12, ...М80, SIM300, SIM900, GL868,... пиковый ток у М80 - 2А, такой же как и у М10.

Сообщение отредактировал CupuyC - Nov 16 2011, 09:52

[Velund]

На прямой вопрос могу сказать следующее:
...
2. Возможна кастомизированная прошивка, под конкретный проект. Но поскольку Telit - коммерческая компания, проект должен быть достаточно серьезным. Примеры кастомизации имеются, в том числе и в России.
...

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

Но вот с 868-DUAL я после сделанного сегодня вечером "открытия" просто таки не знаю как поступать (если и правда багфиксы "раз в полгода а то и реже"). Пространства для маневра у меня не остается, либо уходить на LEON G100, либо ввязываться в серьезное перепахивание самой структуры прошивки и доработки на серверной стороне чтобы стало можно обходиться одним сокетом и уходить на SIM900.... Первое - не очень нравится, второе - не нравится очень. Тащить Моторолу в новый дизайн тоже нет большого желания уже, раз начинаются танцы с NRND...

Кратко... В командном режиме невозможно получить данные свыше какого то размера с сокетов открытых в UDP. Со 2 сокета и выше - точно, с 1 - не успел протестировать, там параллельно крутится обмен в котором самый большой пакет - 113 байт и быстро не получилось проверку сразу же сделать.

Когда нечто приходит небольшого размера - это выглядит так:

SRING: 2,9

AT#SRECV=2,9

#SRECV: 2,9
21056E5B6E6F27620F

OK

Т.е. все как в мануале - без проблем.

Как только пакет побольше - вот такие чудеса...

SRING: 2,134

AT#SRECV=2,134

00D0000DA0B00007386FF00000000

OK

Т.е. как корова языком слизала строку с #SRECV: и первые 120 байт данных. Причем эти 120 байт стабильно отгрызаются и у пакета длиной 134 байта и у пакета длиной 1280 байт. Даже не поленился проверить - реальные данные начиная со 120 байта выдаются модемом.

Пробовал вне зависимости от размера данных которые сообщает модем давать AT#SRECV=2,1500 - разницы никакой.

Прошивка последняя - 185. Взял второй прототип где модем еще не перешивался - на 184 обнаружилось то же самое в точности.

И как с этим быть?

[butthead2]

И как с этим быть?

Я уже говорил - режим с немедленным выпадением данных реализован убого. Попробуй получать просто сообщения о приходе данных, а выгребать их в фоне - возможно проблема уйдет

[sobr]

Преспективнее вот этот модуль Самый миниатюрный модем WS6318

А сэмплы то где?

[GeGeL]

И как с этим быть?

Да проститят меня дистрибьютеры, но опять же с благими намерениями:
это как в том анекдоте про Вовочку "Мне б ваши заботы, МарьВановна..."Зачем создавать такие вот трудности и потом так мужественно их преодолевать? Умом же тронуться можно.
Ради прикола, не сочтите за рекламу, попробуйте прогнать UDP данные из-под опецпу на М12.
Просто почувствуйте разницу...

Сообщение отредактировал GeGeL - Nov 22 2011, 06:49

[Velund]

Я уже говорил - режим с немедленным выпадением данных реализован убого. Попробуй получать просто сообщения о приходе данных, а выгребать их в фоне - возможно проблема уйдет

Я уже и выгребаю командой из другого потока (см. выше - там явно видно).

Блин, не могу поверить, что _такой_ косяк мог оставаться незамеченным столько времени. Просто в голове не укладывается.

Если вдруг кто то из обладателей девкита может оперативно поставить эксперимент на 865-DUAL или QUAD с теми же самыми условиями с последним релизом прошивки - буду очень благодарен. Если вдруг там такого косяка нет - я прежде чем делать резкие телодвижения попробую заменить 868 на 865... Просто на нервах уже, если честно.

[molecul]

Я уже и выгребаю командой из другого потока (см. выше - там явно видно).

Блин, не могу поверить, что _такой_ косяк мог оставаться незамеченным столько времени. Просто в голове не укладывается.

Если вдруг кто то из обладателей девкита может оперативно поставить эксперимент на 865-DUAL или QUAD с теми же самыми условиями с последним релизом прошивки - буду очень благодарен. Если вдруг там такого косяка нет - я прежде чем делать резкие телодвижения попробую заменить 868 на 865... Просто на нервах уже, если честно.

Напишите мне в личку. Кит с GL865-QUAD имеется.

[Velund]

Ради прикола, не сочтите за рекламу, попробуйте прогнать UDP данные из-под опецпу на М12.
Просто почувствуйте разницу...

Да нет у меня времени уже на эксперименты такого рода. Добывать где то М12, разбираться с опенцпу, плату переразводить.

Кроме того - ну не могу я отделаться от мысли что квектел в один прекрасный момент просто продастся и его продукция исчезнет с рынка, либо ценник радикально изменится. Либо чипсет сменят, новый модуль станет в чем то несовместим и придется опять городить зоопарк, от которого поддержка повесится окончательно.

[butthead2]

Я уже и выгребаю командой из другого потока (см. выше - там явно видно).

Пардон, затупил на ночь глядя.
А если попробовать выгребать меньшими кусками?
SRING: 1,1000

AT#SRECV=1,30

[Telit]

Да нет у меня времени уже на эксперименты такого рода. Добывать где то М12, разбираться с опенцпу, плату переразводить.

Кроме того - ну не могу я отделаться от мысли что квектел в один прекрасный момент просто продастся и его продукция исчезнет с рынка, либо ценник радикально изменится. Либо чипсет сменят, новый модуль станет в чем то несовместим и придется опять городить зоопарк, от которого поддержка повесится окончательно.

Velund, тех. поддержку запросили. только без паники

[=F8=]

Но вот с 868-DUAL я после сделанного сегодня вечером "открытия" просто таки не знаю как поступать (если и правда багфиксы "раз в полгода а то и реже").

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

[Velund]

Пардон, затупил на ночь глядя.
А если попробовать выгребать меньшими кусками?
SRING: 1,1000

AT#SRECV=1,30

Кусками по 100 байт выгребается без ошибок. НО... Клеит вместе все пришедшие за время выгребания UDP датаграммы.

Например паравозиком приходит команда устройству (62 байта) и подтверждение пакета данных отправленного серверу (6 байт)

CODE

SRING: 1,62

SRING: 1,68
AT#SRECV=1,100

#SRECV: 1,68
<68 пар hex digits>
OK

Имеем 2 склеенные датаграммы, по сути обе потерянные. Телит однозначно считает UDP сокет потоковым. За что им "большое спасибо".

Да, я мог бы сам мониторить сколько пришло, сколько я уже выгреб и определять границы датаграмм по количествам данных в буффере, передаваемом в SRING. Если бы не было фокусов с URC, которые могут:

a) вклиниться в эхо передаваемой контроллером команды

CODE

AT#
SRING: 2,10
SSENDEXT=2,22

>

(это была команда AT#SSENDEXT=2,22 на которую наложился приход данных по 2 сокету)

б) вынести совсем эхо передаваемой команды и вместо него влезть

CODE

AT

OK

SRING: 1,6


>

(здесь было AT чтобы проверить что модем отвечает нормально после паузы в обмене и потом AT#SSENDEXT - судя по промпту команда принялась, вот только у меня то код ждет эхо...

в) взаимоуничтожиться в эхом передаваемой команды.

(выглядит аналогично предыдущему, только еще и URC исчезает).



За последние 3 недели я насмотрелся на это вдосталь.


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

Так как у меня делается устройство под обкатанный и в тысячах устройств используемый протокол, а не протокол под то что можно физически сделать на Телите, я в ОЧЕНЬ больших раздумьях.

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

Я не вижу метода как в онлайн режиме оперативно работать с двумя UDP сокетами одновременно. Да и с одним то как то тяжко.

Если работаешь в TCP и используешь модем просто как прозрачный канал - тогда да, это решение.