[CADiLO 9]

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

Но те кто мыслит логически, думаю увидят ту же картинку что и я. Впрочем как Вы и сказали - это все догадки.........

 

[pau62 0]

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

 

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

 

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

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

 

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

 

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

 

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

 

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

 

[CADiLO 9]

Я ничего не утверждаю из того что Вы мне пытаетесь навязать.

Речь идет о конкретной фразе и конкретном документе. Что пишут в других документах смотрите сами.

Свое объяснение по конкретному случаю я привел выше. Кроме того я оспаривал не Вашу реплику.

И насколько я вижу мои объяснения у Aleksandr_q (автора фразы) такой бурной реакции не вызвали.

Наверное потому что мы все понимаем что может быть и опечатка, и моя ошибка - и если я не прав то принесу

извинения Александру, как автору фразы, но никак не анонимному Юзверю как Вы сами себя назвали.

 

[SiriuS 0]

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

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

Изменено 16 ноября, 2011 пользователем CupuyC

[Velund 0]

На прямой вопрос могу сказать следующее:

...

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 0]

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

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

[sobr 0]

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

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

 

[gegel 0]

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

Да проститят меня дистрибьютеры, но опять же с благими намерениями:

это как в том анекдоте про Вовочку "Мне б ваши заботы, МарьВановна..."Зачем создавать такие вот трудности и потом так мужественно их преодолевать? Умом же тронуться можно.

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

Просто почувствуйте разницу...

Изменено 22 ноября, 2011 пользователем GeGeL

[Velund 0]

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

 

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

 

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

 

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

 

[molecul 0]

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

 

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

 

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

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

[Velund 0]

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

Просто почувствуйте разницу...

 

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

 

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

 

[butthead2 0]

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

Пардон, затупил на ночь глядя.

А если попробовать выгребать меньшими кусками?

SRING: 1,1000

 

AT#SRECV=1,30

[Telit 0]

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

 

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

 

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

 

 

 

 

[=F8= 0]

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

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

 

[Velund 0]

Пардон, затупил на ночь глядя.

А если попробовать выгребать меньшими кусками?

SRING: 1,1000

 

AT#SRECV=1,30

 

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

 

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

SRING: 1,62

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

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

 

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

 

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

 

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

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

>

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

 

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

AT

OK

SRING: 1,6


> 

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

 

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

 

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

 

 

 

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

 

 

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

 

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

 

 

 

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

 

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

 

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