stream

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

Вот тут надо определиться: передача данных или разрыв соединения? Судя по твоему логу, второе. Похоже, это пучит прошивку и она выдает наружу всякий мусор. Ты ведь уже передал данные, так? И хочешь разорвать соединение? А в ответ вместо NO CARRIER всякая фигня с ERROR на конце приходит? Явно прошивка. Оператор тут чисто опосредованно - допустим, используется такой вид соединения, который в прошивке неправильно обрабатывается. Или перешивать до победного (я не помню, что нынче последнее для "D"), либо забить и ждать в программе _любого_ ответа модема - либо 0x0A, "NO CARRIER", 0x0D - либо 0x0A, "ERROR", 0x0D. Остальное тупо игнорировать.

Практически (как обычно) с 3,3V ARM никаких проблем не возникает. Если же туда 5 вольт запиндюрить - тогда да...

Разве? Тогда № 2 и № 3 потерялись в Text-mode? Если прикинуть по длине сообщений, то старый номер №4 стал №3 в PDU, а №2 вообще раньше на было??? Может, у тебя в процессе какие-то новые сообщения приходили и модуль их пересортировал?

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

Определить можно только экспериментально, и, к сожалению, не всегда с первого раза. Например, ATH при завершении голосового или CSD звонка выдает OK практически моментально, а при завершении внешней GPRS-сессии (установленной с компа через ATD*99#) - секунд через 10... При наборе номера, как правило, лучше считать собственный таймаут. Если за это время не получено никакого ответа, принудительно завершать набор через ATH. У нас, например, время, в течение оператор ждет ответа абонета, зависит чуть ли не от тарифного плана - простых смертных отшибают через 30-45 секунд, корпоративные абоненты могут занимать линию гораздо дольше. А вот тут все еще хуже, потому что таймауты начинают идти не только от сети, но и от самого TCP/IP стека - такой уж принцип его работы. Предельное время установление соединения с сервером (только на уровне TCP/IP!) в случае хитрого сдыхания роутинга на сервер - примерно 60 секунд. Прием/передача данных из-за глюков промежуточных роутеров может висеть чуть ли не вечно, тут уже надо делать принудительные таймауты в приложении (зависит от требований приложения, обычно - около 5 минут).

Да, правильно. Например, у меня не заработал внутренний стек, когда я задавал точку доступа через +CGDONT. Я еще удивлялся, зачем сделано несколько команд, задающих, в общем-то, одно и то же. Изолированы ли настройки друг от друга полностью - никто не проверял, но для надежности, думаю, лучше делать так, как ты написал - настройки/команды внутреннего стека отдельно, внешнего отдельно.

+CGDCONT действует для "классического" соединения со стороны компа через ATD*99#. Собственно, после ATD*99 еще можно как-то указать и номер контекста, вот тут-то эти 10 штук и заработают. Насколько настройки "внешнего" dial-upного gprs-а влияют на "внутренний" стек модуля - вопрос темный. Похоже, что настройки не пересекаются, и лучше подобрать работающую последовательность команд для твоей задачи экспериментально.

Дело CADiLO - предупредить, чтобы к нему в случае "если вдруг чего" потом модули менять не бегали. Я уже неоднократно писал, что практически оно работает нормально как угодно, даже если pwrkey нагло притянут к земле. Пока ничего не подохло. Даже если выйдет из строя 1-2 изделия из 100, для нас это не критично. Если вдруг CADiLO накаркает :-) и в какой-то момент начнется поголовный падёж модулей - про SimCom просто придется забыть, как страшный сон. Потому что реализовать все требования по удерживанию питания и обязательному выключению через PWRKEY в принципе нереально, или будет стоить столько денег, что дешевле окажется поставить другой модуль без подобного геморроя. В случае же низкого VBAT и Pwrkey на земле, как я понял, модуль может пойти вразнос из-за прыгания VBAT при постоянного требовании включения. Например, при питании от батареи - батарея разряжается - модуль сам отключается - потребление пропадает, напряжение на батарее повышается - модуль включается - напряжение на батарее тут же снова проседает - и т.д. А китайцы не гарантируют, что в такой экстремальной ситуации все отработает нормально.

все правильно. Т.е. пункты 1-5 проходят нормально, а проблема только с посылкой второй команды? Такого быть не может, ищи программный или аппаратный косяк. Что за процессор используется? Посмотри электрическую спецификацию пинов на нем. Если написано, что пины "5V tolerant", то никаких резисторов ставить не надо, можно подключать напрямую. В некоторых случаях есть проблема с тормозным автободингом, но, если на первую команду приходит нормальный OK, это не твой случай. Что за RST? Может, имелось в виду RTS? Желательно подать ноль еще и на DTR.

Перешивать однозначно. Зависит от того, как сделано устройство. Если COM-порт заведен напрямую на модуль, то скорее всего можно. Если стоит какой-то добавочный контроллер, который пропускает поток через себя - то скорее всего нет. На форуме ищите... Тема называется так, что перепутать невозможно...

В том-то и дело, что сложно. Хочется сделать не тупо математически, а точки зрения пользователя (т.е. 1 палка - работаем на грани, 0 - сеть еще видим, но ничего не гарантируем, 5 - хороший запас и гарантированное качество). Делить поровну не имеет смысла. Вернее, между "1" и "5" можно поделить, но надо знать эти нижнюю и верхнюю практические границы. Как я писал, за минимальный работающий уровень по результатам экспериментов еще можно принять 101-103 дб, а вот максимальный... что-то мне кажется, что с точки зрения пользователя телефон будет работать одинаково хорошо и при -51, и при -61, и при -71 дб (да и что-то сомневаюсь я, что когда-нибудь увижу -51). Ну, раз готовых рекомендаций нет, буду рисовать что-то отфонарное по своим ощущениям. :unsure:

А как вообще делается визуальное отображение уровня сигнала "в палках"? Какое значение сигнала в децибелах принимают на 0 или 1 палку, какое - за максимальное значение? Есть какие-нибудь рекомендации или каждый лепит по вкусу? Ну, допустим, за минимально рабочий уровень я приму -104 или -102 децибела (экспериментальное значение после получаса бегания по полю в поисках точки "а здесь ловится"). А что считать максимальным, "приемом на 5 палок"? Сдается мне, вряд ли имеет смысл использовать полный диапазон значений, выдаваемых модулем.

Минимум 14-й. 12-я и 13-я для SST нерабочие, проверено лично. Вернее, полная стабильность неработы. Может перезагружаться в цикле десятки раз подряд. Может зависнуть со включенным передатчиком и в течение нескольких секунд непрерывно тянуть с источника 2 ампера. С такими багами она запросто может и самоуничтожиться. Кстати, автор темы так и не написал версию своей прошивки.

Не знаю. У меня NO CARRIER приходит сразу после отбоя удаленной стороной.

Странный вопрос, потому что способов куча. 1) +COLP=1 После ATD даже на голосовом звонке будет пауза (как в обычном модеме), а при (не)соединении скажет OK/BUSY/NO CARRIER. 2) +MORING=1 Будут добавочные сообщения по разным случаям (на том конце пошли гудки, сняли трубку, и т.п.)

Хочу добавить, что туннелирование _UART_ов не прокатит - SIMCOM перепрошивается весьма вычурно, обмен с загрузчиком начинается на скорости 28800, и скорость меняется в процессе. Поэтому туннелировать нужно напрямую состояние пинов в режиме GPIO. Так работает.

Раз уж RAR, то лучше было бы сделать solid архив - прошивки же все примерно одинаковые, архив бы от силы полтора метра получился.

Перестать париться. Ничего делать не надо. У тебя совершенно нормальный прошивальщик. В нем, наоборот, нет никаких лишних галочек, случайно поставив которые, можно получить неработающий модуль :) Т.е. в природе существуют два прошивальшика. Тот, который рекомендует CADiLO, более навороченный (может еще и считать содержимое памяти), но там можно убить персональные настройки модуля, если случайно поставить галку "full flash erase". Я шью более простым, чтобы не заморачиваться с галками. Дополнение: у меня их собралось уже 3 штуки: "SIMCOM FLASH UPDATE TOOL V1.08" - самый простой, умеет только прошивать, полного стирания флеша нет. "SIMCOM FLASH UPDATE TOOL V1.10" - тот, что выложил CADiLO, появилась возможность считать флеш и full erase. "FlashSIM.exe" - про себя пишет просто "FLASH downloader", умеет прошивать и считывать, есть full erase. По-моему, работает только с флешами spansion. Просто шить можно любым. Первый безопаснее :)

Еще пара слов вдогонку. Сейчас мне попался руки модуль SIM300Z B12 SST. Все проблемы, что я описывал для 13-й версии, в нем на том же месте, те же самые. Т.е. теряет профайлы и самопроизвольно перезагружается. Получается, что для модулей с флешем SST не 13-я версия "неудачная" (как писал CADiLO), а все, что меньше 14-й - кривое. Так что у кого SIM300Z с памятью SST и версия прошивки меньше 14-й - СРАЗУ шейте как минимум 14-ю. С 14-й у меня проблем пока не было.

Модем был в режиме GPRS и соединен с компом через ppp. Смотрелся вывод netstat с разными параметрами (tcp/udp/interface и т.п. statistic). Других интерфейсов, кроме lo, на машине не было. lo у меня никто не использует, так что вся статистика относилась только к ppp. Ретрансмиты, конечно, были tcp/ip. Собственно по физическому ppp-обмену все было чисто. Кто был виноват (стек в компе, модеме, или у оператора) - я сказать не могу.

Вряд ли кто-то проводил подобные исследования. Я видел максимальную скорость аплоада в районе 3 с хвостиком кб/сек (средняя на на файле в пару мегабайт). Машина была под WinXP. В плохих условиях, при загруженных каналах в центре города, начались какие-то непонятки. Правда, на той машине была другая, совсем не виндовая, ОС и, соотвественно, другой PPP-клиент. Все страшно тормозило. В статистике PPP-интерфейса на передачу было огромное кол-во ретрансмитов по таймауту (объем физически прокачанных через модуль данных был почти в два раза больше логически отправленных). В статистике на прием - очень много out-of-order blocks. За сеанс было два запроса на смену размера окна. Я не знаю, кто был виновен в таком поведении - неудачный PPP-клиент на компе, модуль, или я так неудачно попал, что именно в этот момент колбасило оператора (тогда даже ответы на пинги приходили порой не по порядку). В другом месте города, на другом операторе - 3 и более кб/сек без проблем.

Во втором случае поможет +CIPSHUT. Кстати, в неправильной фазе он тоже ERROR говорит :-(

Вот это и называется - автободер нормально не работает. Он должен был уже на ATI как надо ответить, без всякого шаманства с "сначала это, потом паузу, потом еще вот это". Не могу себе представить, каким можно умудриться написать именно ТАК. Почему-то в наших изделиях никаких танцев с бубном не требуется, она сразу отвечают на первую же команду, выданную на любой скорости. Тогда нафига автобод нужен? :-) Я как раз читаю внимательно, там написано - before sending the first AT character. А практически можно ждать после включения или ATZ хоть полчаса - все равно первую AT оно потом сожрет, а среагирует только на вторую, и только при наличии дополнительной паузы между ними. Вы не правы, AAAAAAT.... - вполне допустимая последовательность. Все, что было до AT, модем должен спокойно игнорировать. Но речь была не об этом. Просто была гипотеза, что оно не успевает зацепиться за первый символ, а несколько символов подряд схватит скорость - но она не подтвердилась, все равно нужен таймаут после первого символа. Кстати, попробуйте _быстро_ скормить ему после ATZ (через макрос, например) несколько символов - хотя бы тех же "А" - в ответ вместо эха такой разнообразный мусор вернется... Либо у вас скорость порта стояла 115200 - тогда проблем нет, либо разница версий - есть ощущение, что в ранних версиях прошивки (в районе 6-й) оно работало по-другому, и не исключено, что лучше.

К сожалению, в даташите не написано, в чем именно проявляется бага :) А бага там в том, что автободер нормально автободится только на 115200. После ATZ/AT&F автободер уходит в себя и тихо жрет следующие несколько символов, если их скорость отлична от 115200. Причем жрет очень хитро - много "A" подряд его не устраивают, нужно еще и какие-то таймауты в процессе выдерживать (типа послали "A", подождали пару секунд, еще раз послали "А" - вот только тогда оно зацепилось). В общем случае (например, для виндового INF-файла) алгоритм получается кривой и трудноформализуемый. Поэтому приходится гнать весь обмен через внешний контроллер, который общается с модулем только на 115200, а с писюком уже автободится нормально сам контроллер.