[dimon_rub 0]

Помогите если сможете пожалуйста. Вопрос следующий. При передаче TCP пакетов как заблокировать или правильно обработать входящий звонок или смс.

Ситуация такая. В момент передаче пока еще не пришло SEND OK. приходит например SMS CMTI команда соответственно. Модуль зависает примерно на 2-3мин потом приходит SEND OK.

Сесия MultiConnection. Как это побороть?

Спасибо

 

 

 

[Aner 3]

А SIM карта M2M или с голосом? Отказаться от MultiConnection.

[jcxz 191]

5 часов назад, dimon_rub сказал:

Помогите если сможете пожалуйста. Вопрос следующий. При передаче TCP пакетов как заблокировать или правильно обработать входящий звонок или смс.

Ситуация такая. В момент передаче пока еще не пришло SEND OK. приходит например SMS CMTI команда соответственно. Модуль зависает примерно на 2-3мин потом приходит SEND OK.

Вы имеете в виду +CMTI? Так это не команда, а URC.

А почему бы не обработать её обычным образом? Также как и когда нет передачи. Не пробовали?

[dimon_rub 0]

Извините неправильно выразился по поводу CMTI. Конечно же это URC.

Пробовал. Но нужно в начале обработать подтверждения отправки TCP пакета (SEND OK). А данный ответ приходит через огромную паузу. Если бы можно было отключить это все на момент передачи (типа BUSY).

Это конечно отключит звонок но а СМС.  Или хотя бы как то вернуть его к жизни сказав что в данный момент читать СМС мы не хотим (типа ATH0).

[dimon_rub 0]

SIM карта НЕ M2M. Обычная. А что даст отказ от Multi Connection?

[jcxz 191]

19 минут назад, dimon_rub сказал:

Пробовал. Но нужно в начале обработать подтверждения отправки TCP пакета (SEND OK).

Зачем "в начале"? Отправили сегмент данных, поставили флажок "ожидаю "SEND OK" от модуля" и дальше штатным образом команды и URC обрабатывайте. А флажок "ожидаю SEND OK" не должен блокировать парсинг команд. Он должен блокировать только отправку новых сегментов данных. У меня именно так сделано (насколько помню). Правда я работаю с BT-каналом, но думаю там алгоритм аналогичный.

Возможно эта дикая задержка у Вас и есть от того, что SIM ждёт вашей реакции на +CMTI и не шлёт новых сообщений. Там на это +CMTI нужна какая-то реакция со стороны прикладного МК?

[dimon_rub 0]

Спасибо. Попробую. Отпишусь

[Aner 3]

21 минуту назад, jcxz сказал:

Зачем "в начале"? Отправили сегмент данных, поставили флажок "ожидаю "SEND OK" от модуля" и дальше штатным образом команды и URC обрабатывайте. А флажок "ожидаю SEND OK" не должен блокировать парсинг команд. Он должен блокировать только отправку новых сегментов данных. У меня именно так сделано (насколько помню). Правда я работаю с BT-каналом, но думаю там алгоритм аналогичный.

Возможно эта дикая задержка у Вас и есть от того, что SIM ждёт вашей реакции на +CMTI и не шлёт новых сообщений. Там на это +CMTI нужна какая-то реакция со стороны прикладного МК?

Да, все верно. Возможно из-за стандарта по приоритетам. GPRS низкий, выше SMS, еще выше входящий голосовой. Если в момент передачи по GPRS приходит SMS, обработчик прерывает отправку данных по GPRS, обрабатывает SMS затем возврат к передаче данных по GPRS. Поэтому ответ по GPRS приходит через огромную паузу.