Добрый день.
На команду AT+COLP? выдается ответ о включении и поддержке идентификации подключения линии сетью оператора, т.е. где-то она может не работать?
В моем случае с life'ом ответ приходит "0", т.е. не поддерживается, хотя все работает.
Возник вопрос, что правильнее использовать: AT+COLP=1 или AT+MORING=1?
Вообще у них принцип определения подключения один и тот же или разный?
Спасибо.

Правильнее использовать CLCC

То запрашивать постоянно надо, а тут включил и жди когда придет URC.

Партия (SIMCOM) о вас позаботилась - на солнце полетите ночью.
(с) советские анекдоты

У SIM900x в отличии от других модулей не надо запрашивать.
По просьбе зрителей сделана автоматическая выдача на каждое изменение состояния.

Write Command
AT+CLCC=<n>
Parameter
<n>
0 Don’t report a list of current calls of ME automatically when the current call status changes.
1 Report a list of current calls of ME automatically when the current call status changes.

Причем ответ на COLP есть шанс и не получить - он может запрещаться оператором. А вот CLCC будет всегда.

Я сразу посоветую тут: делайте CLCC и сами его вызывайте. Всё остальное ересь и вообще, ещё спасибо потом скажете.

+1. URC могут теряться. Неплохо их получать, как только так сразу (то, о чём выше пишет CADILO), так реакция прибора быстрей, но до конца положиться на это нельзя и нужен периодический опрос. То же самое с ожиданием SMS, регистрации в сети, наличия SIM-карты и всего такого.

Вот хорошо-бы кабы так. Но есть там одна особенность... Во время установки соединения на все CLCC модуль молчит как партизан.

тоже такое заметил в телитах. Пока нет ответа на текущую команду (к примеру установка GPRS соеднинения) модем ассинхронные сообщения не передает, и подавать новые команды нельзя категорически. Может в CMUX это разрулено

Да, есть такое, у Телита по этому поводу в даташите точно видел замечание когда нельзя подавать команды иначе связь прервется.
Но это не только его особенность, у всех GSM модулей есть несколько моментов когда требуется дождаться ответа.
Все моменты навскидку не помню, но в доках и требованиях GSM 07.07, GSM 07.05 это все есть.
Поэтому я всегда и говорю что спешить не стоит, потом дороже обойдется искать причину сбоев.

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

Не читайте за обедом советских газет китайских даташитов. В ITU-T V.250 ясно совершенно, на первых страницах, описан протокол работы с модемом. И сказано, в частности, что следующую команду, разумеется, подавать нужно по финальному ответу (OK, ERROR, CONNECT, NO CARRIER, NO ANSWER и т.п.) на предыдущую. И что подача символа перевод строки, если не ошибаюсь, досрочно может прерывать выполнение текущей команды (на это китайцы клали, отправку SMS сделали через ()(), из-за этого имеем "зависания" на полторы минуты по поводу и без). Про то, какие ответы финальные, а какие промежуточные китайцы тоже не дочитали, поэтому, в частности, SIM900, SIM300 и т.п. дают NO CARRIER по-поводу и без, ERROR по два раза и т.п. И приходится после таких вот ответов ещё перепроверять за модемом по три раза. Если нет ответа долго, проверяем на AT. Если есть OK -- модем просто забыл ответ. Бывает... в связке с "Call Ready" особенно. Если сказал NO CARRIER это скорей вообще ничего не значит и нужно ждать другой ответ, если сказал ERROR то неплохо бы подождать второго ERROR и третьего OK... Некоторые команды, связанные с GPRS, и не только, нельзя комбинировать в одну строку -- ответы теряет. Очень много костылей и подпорок. Знание которых, видимо, большой коммерческий секрет.

Логфайл в студию - желательно с временными метками. Это ж как можно до такого довести модуль.... Жутики

Модем не выдаст "гарантированно". И будет гарантийный случай.
Причин почему -- масса. От нахождения в режиме передачи данных,
других режимах (когда где-то внутри модема все URC должны накапливаться,
и в теории выдаваться потом, но на практике почему-то не выходит из него потом),
до пресловутого "Call Ready" в момент формирования которого "OK" теряется, не то, что "+CLCC".

И я тут не сказки рассказываю, а исключительно из собственного опыта. С SIM300 разных версий и SIM900 начиная с B02 по B09.



При собственном опросе пропустить что-то как раз сложней. По крайней мере модем в командном
режиме и способен выдавать URC и ему в этом не мешает исполнение других команд. Пропустить не страшно, опрос периодический. Смена состояний -- состояний чего? Соединения (звонка) -- с таким же успехом оно может смениться сразу после выдачи сообщения +CLCC. Не аргумент. Состояние модема же поменяться в момент исполнения команды не может (перейти в режим данных, например), по крайней мере до ответа и подачи следующей команды. Если, конечно, ATS0=1 не делать.





В следующий раз наткнусь, сделаю, сюда выложу. Описанное, на самом деле, худо-бедно обходится. Кроме отправки SMS (когда отправить не может, но до выдачи ERROR коматозит от минуты до бесконечности, конкретно на МТС в Петербурге, на других операторах -- ок). Вообще стоило бы автомат разбирающий ответы модема и принимающий решение о выполнении команды и с каким статусом сюда нарисовать в картинках. Оно отнюдь не так прозрачно, как из V.250 следует.

Жутики -- это вот: http://electronix.ru/forum/index.php?showtopic=99265
Это с приёмом SMS. Ещё аналогичная история была с отправкой SMS. И я уж не знаю в чём там дело, просмотр биллинга оператора потом показал, что деньги взяты за одну SMS, но приходили адресату они много и долго.

Как думаете, кто во всём сразу виноват? Правильно. И после такого связываться с продукцией SIMCOM не хочется, ибо понимаешь в дерьме тебя измажут с ног до головы и виноват будешь во всём сам.

А выключить "Call Ready" который не несет смысловой нагрузки, что не позволило?
Слишком много казусов озвучиваете - может просто алгоритм общения с модулем неудачно построили.
Котов тоже нужно уметь готовить.
Есть конечно нюансы, однако они не столь порочны, да и большинство из них обусловлено не модулем, а оператором.

>>>Причин почему -- масса. От нахождения в режиме передачи данных.

Если я знаю что я передаю данные - зачем мне нужно CLCC???
Что за глупости ? От так вот от фонаря взять и запросить в этот момент????

>>>Смена состояний -- состояний чего?
>>>Соединения (звонка) -- с таким же успехом оно может смениться сразу после выдачи сообщения +CLCC

Да - состояние соединения. А значит выдаст следующее СLCC с новыми цифрами.

Так если оператор от модуля получил 1 SMS (за что и взяты деньги), но потом он адресату отправлял "много и долго", то причем тут модуль?

>>>>Жутики -- это вот: http://electronix.ru/forum/index.php?showtopic=99265

Читаю

>>> 'SIMCOM_SIM900B'
>>>'Revision:1137B08SIM900B32_ST'

Изначально неверно выбран модуль - неоднократно повторялось что у нас использование 900В не желательно. Не для нас его делали.

Кроме того там правильно заметили что в разное время приходили SMS - модуль физически не умет так зацикливаться. Сколько получил, столько и отобразил.

Ошибки бывают не спорю - в той же 9 версии для SIM900B по SMS с полдесятка исправлено, однако ни одной по Вашей проблеме.
Если бы такое было, то SIMCOM и нас уже засыпали бы письмами.


Еще из листинга: у Вас в одну строку - 'AT+CREG?;+COPS?;+CSQ'
Допустимо но - НЕЖЕЛАТЕЛЬНО из-за возможных потерь ответов.

Тем более что сами же себе противоречите.

>>>В ITU-T V.250 ясно совершенно, на первых страницах, описан протокол работы с модемом. И сказано, в частности, что следующую команду, разумеется, подавать нужно по финальному ответу (OK, ERROR, CONNECT, NO CARRIER, NO ANSWER и т.п.) на предыдущую.

Ну и где выполнение требований? В вашем листинге этого нет. Три команды подряд не дожидаясь ответов.

Более того, каким боком ITU для проводной сети относится к GSM модемам ??? - разве только похожи. А для GSM есть свои требования.

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

Встроенный IP-стек - практически весь через ()(). Начиная с +CIPSTART, когда OK/ERROR и CONNECT OK/CONNECT FAIL приходят в случайном порядке - приходится делать специальную процедуру для ловли таких фокусов. С +CIPCLOSE, по-поему, такая же фигня. Изменение в SIM900 синтаксиса URC +IPD, не описанное нигде, стоило нам круглой суммы. На ATH в режиме данных реакция совершенно непредсказуемая - в зависимости от фазы луны можно получить OK/NO CARRIER/ERROR.
По поводу совета отключить Call Ready - напоминает анекдот про сантехника и унитаз. Это тот же самый костыль, из знания которых и формируется наш, так сказать, опыт разработчика.
Что касается репорта багов - с моей подачи было исправлено кое-что в SIM900, но мне, например, если проблему можно обойти, проще написать костыль, ибо старые приборы тоже должны работать. А сообщал я только о критических вещах, когда какая-то функциональность в SIM900 не работала вообще или совсем не так, как в SIM300.

Я совершенно спокойно отношусь к багам, тем более при такой цене за модуль. Мелкие исправления китайцы делают чуть ли не за несколько часов. И я понимаю, что IP-стек они при все желании не перепишут с нуля правильно. И (отсутствующие) семафоры между задачами в модуле тоже не рискнут сильно менять. И в квиктеле все те же баги, только в профиль. Просто не надо делать удивленные глаза "до чего вы довели модуль" и "вы его готовить не умеете". А ваша идиосинкразия на SIM900B выглядит еще более странной. Сначала без вопросов продаете SIM300Z, потом говорите: не надо использовать SIM900B, выкидывайте все свои изделия. "Изначально неверно выбран модуль" - да, очень смешно. Изначально - это когда мы в качестве платформы SIMCOM выбрали, да?

>>>Встроенный IP-стек - практически весь через ()(). Начиная с +CIPSTART, когда OK/ERROR и CONNECT OK/CONNECT FAIL приходят в случайном порядке - приходится делать специальную процедуру для ловли таких фокусов.

Точно знаю что этот же стек используют в своих изделиях LG, Samsung и Philips - и вроде как без фокусов.

>>>Сначала без вопросов продаете SIM300Z

Давайте определимся - в Украине 95% применяло SIM300D или SIM300C. Мы изначально информировали всех о нежелательности использования обычного SIM300. Точно так же как SIM900B - которых сейчас в поставке - НОЛЬ!
Тем кто хотел именно SIM300 - мы продавали, зачем же терять клиента даже если он не слушает советов.
Вы с таким же успехом могли бы и SIM300S/SIM900S или SIM900A применить, а потом удивляться что они вообще у нас не работают.
А то что вас не информировал ваш продавец, так при чем же тут платформа SIMCOM или QUECTEL.

Кстати и у QUECTEL есть фишки c модулями
Европа M80 и М95
Азия M50 и M35

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

Стек адекватный. Но АПИ и в самом деле крайне неудачное. CONNECT и OK без плюсов и могут выскочить в любом месте - пришлось довольно сильно менять автомат разбора сообщений от модуля. Приём из сокета тоже сделан неудачно - я сразу принудительно перевёл модуль в режим CMUX - это наиболее надёжный способ достоверно читать данные из сокета. В нормальном режиме данные легко пропустить.

С API согласен, для того же EAT из-за неудобств пришлось полностью переделывать точки входа для UDP иначе при ответе могли перемешаться входящие данные и ответ на команду. В последней прошивке ЕАТ исправлено.
В стандартной прошивке работа со стеком будет подкорректирована чуть позже, работы ведутся. Изменения войдут в прошивку вместе с усовершенствованиями в FTP и HTTP.

Главное, чтоб в новую версию ЕАТ SIMCOM не забыл включить функцию работы с памятью по SPI !!!!! (Например для SST25VF016B-75-4I-S2AF).

Киньте мне в личку или на почту кусочек программы - как вы пытались общаться с памятью.
Потому как секторами по 4К она должна писаться и читаться в блочном режиме.

Там проблема с CS, например когда мы хотим считать данные из внешней памяти, нужно поставить CS в ноль, указать адресс, считать нужное количество байт и потом вернуть CS в "1". SPI в EAT я так понял предназначен только для дисплея.... надеюсь это временно.

http://electronix.ru/forum/index.php?showt...20eat&st=60

Вроде бы получилось написать свои функции SPI....но пришлось использовать комбинации, которые Симком запрещает.....ну...пока деваться некуда....
это функции типа while(ebdat6_04WriteGpio(EEPROM_SELECT,0)!=FL_OK);