Резюме по DTMF детектору - дребедень, даже хуже чем в сим900. При достаточно хорошей связи:
- частые пропуски
- ошибки в пользу соседнего символа
- ложные срабатывания при внешнем шуме в микрофон вызывающего телефона (можно победить загрубив чувствительность)
- и самое печальное - с вероятностью 20% не работает при входящем вызове (на исходящих не проверял)

Да это издевательство форменное. В прошивке 185 относительно 184 изменилась команда #ssendext. Теперь настройка режима передачи в виде текста или hex на нее не действует - передача только текстом независимо от настроек. Классический пример моего утверждения - вы все дураки, а нам тут в телите виднее. Да, в доке указано что это настройка поведения #ssend, но зачем было #ssendext менять? Оно сильно мешало что обе команды подчиняются настройке?

Едем дальше:
AT#GSMAD=3
команда довольно тормозная, несколько секунд. В этот промежуток времени должны получить URC приема от сокета SRING: 1....... Команда #GSMAD вешается, таймаут секунд 30. Потом спасибо, вываливает +CME ERROR: 3 и ожидаемый URC. Но работать #GSMAD больше не будет до перезапуска - +CME ERROR: 3 с диким таймаутом и все.

Софтово делать определение антенны тоже не фонтан - АЦП часто в РАЗЫ неправильные уровни выдает.

Привет самому отлаженному в мире стеку!

А кстати, может кто подскажет, как отправлять/принимать данные в hex командой #ssend (#ssendext)?
модуль GL868, прошивка 10.00.184.

включаю прием/передачу в hex формате командой AT#SCFGEXT, а не работает.
передача текста работает.

может кто примерчик покажет?

AT#SCFGEXT=1,2,1,0,0,1

AT#SSEND=1

> 03AA7E00C6
Ctrl+Z

Спасибо, вроде я так же пробовал, не работало.
А сейчас вдруг прохрюкалось
Может где ошибка у меня была

Это еще, что. Вот если попробуете посредством SSEND более-менее приличный поток данных передать будет еще один "сюрпрайз!" ИМХО лучше их вообще не использовать - только прозрачный режим, вот он без проблем(тфу, тфу, тфу) работает.

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

Еще очень интересный момент. Когда выдается к примеру URC или ответ на команду, и в этот момент дать следующую команду, то она не сработает ( ERROR или с ошибкой в параметрах- смотря какую часть текста заденем) - похоже на взаимную блокировку RX и TX потоков. Возможно у меня этот эффект проявляется из-за некорректного подключения прослушивающего траффик кома. Кто то подобное наблюдал или все ок?

Вообще-то в описании команд указано, что новую команду нельзя выдавать до полного завершения предшествующей. Даже подчеркнуто, что не следует ориентироваться на OK в качестве признака завершения, поскольку далее следуют <CR><LF>.

Сообщение отредактировал box415 - Aug 17 2011, 07:58

Перечитал внимательно. Да, указано. Но ответ на команды это такое дело, программно естественно дальше не пойдешь пока нет ответа. А про URC индусописатели ничего не слышали??? Собственно на них сбои и заметны. Я балдею с этого телита...

Эти ограничения касаются в основном кол-ва одновременно устанавливаемых соединений, но никак не объема передаваемых данных. На том-же телите в прозрачном режиме 1-2М передаются без проблем. В непрозрачном - да передать можно не белее чем гарантированно поместится в буфер. А переключатся, как раз, не проблема - всего то и надо DTR-ом дернуть.

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

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


Потоком подавать не анализируя ответы это... просто кю, дешевая поделка.

В доке есть какие то пространные замечания про возможные ошибки на больших скоростях. Какие считать большими естесно не сказано. Попробовал зафиксировать на 19200, посмотрю что будет.

Да не совсем религиозный. В командном режиме нет возможности контролировать переполнение буфера. При переполнении при попытке отправить пакет получите ERROR, при этом часть данных может таки быть отправлена поэтому просто повторить передачу не получится. CTS в этом режиме не работает(и IPR, и #CFLO, и #FLO все пробовал - пофиг). Гарантировать же непереполнение буфера при том, что возможны "замирания" в GPRS канале секунд порядка 30сек тяжковато. В прозрачном режиме CTS работает как положено.



Вообще со скоростью ситуация непонятная. Есть 2 девайса с GL868(оба модуля из одной партии), один на STM32 другой на PIC32 и в том и другом выход UARTа, для согласования уровней, сконфигурирован как ОК. PIC32 на 115200 с модулем работает без ошибок, а вот на STM32 вышеописанная проблема. Пока грешу на то, что STMовская библиотека через которую конфигурировался UART не точно выставляет скорость. Как будет чуток времени буду копать дальше, а пока оставил на 57600.

Совсем религиозный задачи у всех разные и самое главное ПРОТОКОЛЫ. Меня переполнение не трогает ни разу - протокол основан на запросах с сервера. Если гнать потоком, то конечно - непрозрачный режим не годится. Так что нельзя сказать однозначто что этот режим дерьмо, а второй идеальный. Для унивесальности в модеме обязаны быть оба режима.


Точно так же: GL868 + STM32 с ОК = проблем ноль (ну кроме вышеупомянутых URC). От библиотек отказаля сразу - поглядел на исходники - волосы на голове зашевелились. Да еще и с ошибками.