CADiLO 9 16 ноября, 2011 Опубликовано 16 ноября, 2011 · Жалоба Я не буду спорить - подчеркну что это мое ИМХО, выведенное из простой логики. Время и клиенты рассудят. Но те кто мыслит логически, думаю увидят ту же картинку что и я. Впрочем как Вы и сказали - это все догадки......... Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
pau62 0 16 ноября, 2011 Опубликовано 16 ноября, 2011 · Жалоба >>>Так что хва уж передергивать, вроде уважаемые люди... Ну не место тут таким кривым аргументам, не лохи же вокруг поголовно. Изначально фраза звучала так: "При этом пиковый ток, потребляемый модулем в режиме передачи 1,6А, вместо 2А у М10." Смотрим определение: "Пиковое значение — наибольшее мгновенное значение напряжения или силы тока за период." То есть это значит что больше этого уже быть не может - я другого контекста не вижу. А таблица 29 четко указывает что оказывается может быть и больше и достигать 2 ампер. И отсюда вывод - значение фразы: "При этом пиковый ток, потребляемый модулем в режиме передачи 1,6А, вместо 2А у М10." = FALSE Странно что это Юзверя так задевает.... Или все же не юзверя ? :) Т.е. уважаемый CADiLO утверждает, что пиковый ток в соответствующих таблицах и импульсный ток на соответствующих графиках в документации на м10 и на м80 не отличается примерно в 1.5 раза? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
CADiLO 9 16 ноября, 2011 Опубликовано 16 ноября, 2011 · Жалоба Я ничего не утверждаю из того что Вы мне пытаетесь навязать. Речь идет о конкретной фразе и конкретном документе. Что пишут в других документах смотрите сами. Свое объяснение по конкретному случаю я привел выше. Кроме того я оспаривал не Вашу реплику. И насколько я вижу мои объяснения у Aleksandr_q (автора фразы) такой бурной реакции не вызвали. Наверное потому что мы все понимаем что может быть и опечатка, и моя ошибка - и если я не прав то принесу извинения Александру, как автору фразы, но никак не анонимному Юзверю как Вы сами себя назвали. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
SiriuS 0 16 ноября, 2011 Опубликовано 16 ноября, 2011 (изменено) · Жалоба Т.е. уважаемый CADiLO утверждает, что пиковый ток в соответствующих таблицах и импульсный ток на соответствующих графиках в документации на м10 и на м80 не отличается примерно в 1.5 раза?CADiLO говорит, что пиковый ток, который может быть при определенных условиях в любых GSM модулях может достигать 2А. Это касается М10, М12, ...М80, SIM300, SIM900, GL868,... пиковый ток у М80 - 2А, такой же как и у М10. Изменено 16 ноября, 2011 пользователем CupuyC Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Velund 0 21 ноября, 2011 Опубликовано 21 ноября, 2011 · Жалоба На прямой вопрос могу сказать следующее: ... 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 22 ноября, 2011 Опубликовано 22 ноября, 2011 · Жалоба И как с этим быть? Я уже говорил - режим с немедленным выпадением данных реализован убого. Попробуй получать просто сообщения о приходе данных, а выгребать их в фоне - возможно проблема уйдет Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
sobr 0 22 ноября, 2011 Опубликовано 22 ноября, 2011 · Жалоба Преспективнее вот этот модуль ;)Самый миниатюрный модем WS6318 А сэмплы то где? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
gegel 0 22 ноября, 2011 Опубликовано 22 ноября, 2011 (изменено) · Жалоба И как с этим быть? Да проститят меня дистрибьютеры, но опять же с благими намерениями: это как в том анекдоте про Вовочку "Мне б ваши заботы, МарьВановна..."Зачем создавать такие вот трудности и потом так мужественно их преодолевать? Умом же тронуться можно. Ради прикола, не сочтите за рекламу, попробуйте прогнать UDP данные из-под опецпу на М12. Просто почувствуйте разницу... Изменено 22 ноября, 2011 пользователем GeGeL Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Velund 0 22 ноября, 2011 Опубликовано 22 ноября, 2011 · Жалоба Я уже говорил - режим с немедленным выпадением данных реализован убого. Попробуй получать просто сообщения о приходе данных, а выгребать их в фоне - возможно проблема уйдет Я уже и выгребаю командой из другого потока (см. выше - там явно видно). Блин, не могу поверить, что _такой_ косяк мог оставаться незамеченным столько времени. Просто в голове не укладывается. Если вдруг кто то из обладателей девкита может оперативно поставить эксперимент на 865-DUAL или QUAD с теми же самыми условиями с последним релизом прошивки - буду очень благодарен. Если вдруг там такого косяка нет - я прежде чем делать резкие телодвижения попробую заменить 868 на 865... Просто на нервах уже, если честно. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
molecul 0 22 ноября, 2011 Опубликовано 22 ноября, 2011 · Жалоба Я уже и выгребаю командой из другого потока (см. выше - там явно видно). Блин, не могу поверить, что _такой_ косяк мог оставаться незамеченным столько времени. Просто в голове не укладывается. Если вдруг кто то из обладателей девкита может оперативно поставить эксперимент на 865-DUAL или QUAD с теми же самыми условиями с последним релизом прошивки - буду очень благодарен. Если вдруг там такого косяка нет - я прежде чем делать резкие телодвижения попробую заменить 868 на 865... Просто на нервах уже, если честно. Напишите мне в личку. Кит с GL865-QUAD имеется. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Velund 0 22 ноября, 2011 Опубликовано 22 ноября, 2011 · Жалоба Ради прикола, не сочтите за рекламу, попробуйте прогнать UDP данные из-под опецпу на М12. Просто почувствуйте разницу... Да нет у меня времени уже на эксперименты такого рода. Добывать где то М12, разбираться с опенцпу, плату переразводить. Кроме того - ну не могу я отделаться от мысли что квектел в один прекрасный момент просто продастся и его продукция исчезнет с рынка, либо ценник радикально изменится. Либо чипсет сменят, новый модуль станет в чем то несовместим и придется опять городить зоопарк, от которого поддержка повесится окончательно. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
butthead2 0 22 ноября, 2011 Опубликовано 22 ноября, 2011 · Жалоба Я уже и выгребаю командой из другого потока (см. выше - там явно видно). Пардон, затупил на ночь глядя. А если попробовать выгребать меньшими кусками? SRING: 1,1000 AT#SRECV=1,30 Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Telit 0 22 ноября, 2011 Опубликовано 22 ноября, 2011 · Жалоба Да нет у меня времени уже на эксперименты такого рода. Добывать где то М12, разбираться с опенцпу, плату переразводить. Кроме того - ну не могу я отделаться от мысли что квектел в один прекрасный момент просто продастся и его продукция исчезнет с рынка, либо ценник радикально изменится. Либо чипсет сменят, новый модуль станет в чем то несовместим и придется опять городить зоопарк, от которого поддержка повесится окончательно. Velund, тех. поддержку запросили. только без паники :) Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
=F8= 0 22 ноября, 2011 Опубликовано 22 ноября, 2011 · Жалоба Но вот с 868-DUAL я после сделанного сегодня вечером "открытия" просто таки не знаю как поступать (если и правда багфиксы "раз в полгода а то и реже"). Командный режим у телита ни к черту не годится. Там грабли на граблях. Из-за чего использую только прозрачный режим, вот с ним проблем нет. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Velund 0 22 ноября, 2011 Опубликовано 22 ноября, 2011 · Жалоба Пардон, затупил на ночь глядя. А если попробовать выгребать меньшими кусками? 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 и используешь модем просто как прозрачный канал - тогда да, это решение. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться