В этом документе (http://www.mt-system.ru/documents/sim900 at compare to sim300.pdf) указывается, на странице 6, что импульс DTR включает т.н. autobauding, в случае, если изначально скорость была насильно задана через AT+IPR. Импульс лог. 1 не менее 2-х секунд мол включает.

Ничего не включает. И если для SIM300 можно было установить скорость, но он её автоматически не запоминал, то с SIM900 возникает дурная история. Когда модуль запоминает скорость и после включения питания сразу работает только на ней. Функция autobauding более в принципе не работает.

Нехорошая ситуация, если стоит задача обновления ПО, при этом в старой версии используется другая скорость. Лучше было бы иметь всегда включенный autobauding после включения питания (не запоминать настройку AT+IPR, как и SIM300).


Забыл сказать. Не отключать autobauding тоже дурная идея, ибо глючит. На длинных последовательностях передаваемых данных собственно данные искажаются. Прошивка B08, ST.

Я бы посоветовал еще раз ВНИМАТЕЛЬНО прочитать.

AT+IPR=0 setting to auto-bauding will take effect after module resets. If user wants to change DTE baud rate during module is running, i.e. from 57600 to 4800, DTR shall be used to urge auto-bauding progress. DTR shall be pulled up to invalid state at least 2 seconds by DTE and then pulled down to valid state. The step will urge auto-bauding progress and DCE will synchronize its baud rate after it receives data from the serial port.

При помощи DTR можно изменить скорость только если IPR=0 - то есть автоопределение.

Тогда, если модуль изначально допустим засинхронизировался на 19200 а надо перейти на 9600, мы тянем на 2 сек. DTR и модуль опять начнет процесс синхронизации автоскорости.

Если же вы установите фиксированную скорость, то дергание DTR будет как мертвому припарка.

А потому вывод - все работает как и написано.

Кроме того по нашей просьбе после 06 версии переделан алгоритм работы DTR.
Окончательно это описано в SIM900_Serial Port_Application Note_V1.02.pdf
Обратите внимание что DTE и DCE это не выводы, а устройства.


NOTE: The DTR signal must pulled to low level voltage when DTE is sending data to module. If DTR does not connect with DTE, DTR must be connected to GND via a 10K resistor.

6.3 DTR
Module will automatically go into SLEEP mode (set AT+CSCLK=1) if DTR is set to high level and there is no on air and no hardware interrupt (such as GPIO interrupt or data on serial port). In this case, the current consumption of module will reduce to the minimal level. During SLEEP mode, the module can still receive paging message and SMS from the system normally. If DTR Pin is pulled down to a low level, this signal will wake up module from SLEEP mode. The serial port will be active after DTR changes to low level about 50ms. DTR must be held low during the call.
The AT command ”AT&D” can be used to set DTR function mode.
When it is set to ”AT&D0”, TA ignores status on DTR.
When it is set to ”AT&D1”, ON (low)->OFF (high) on DTR: module will be changed to command mode when the connected call is remained..
When it is set to ”AT&D2”, ON->OFF on DTR: call is disconnected, module is changed to Command mode. During state DTR = OFF, it is auto-answer off.
TCP/IP applications only support AT&D1 and AT&D0. In TCP/IP application (for more detail, please refer to TCP/IP application NOTE), DTR line of serial port can also be used to switch from data mode to command mode. To use this method, AT&D1 should be set firstly. Pull DTR line to ground for at least 1 second and then pull up, the module will switch from data mode to command mode and OK will be returned which indicates the module is in command mode.



>>>>Не отключать autobauding тоже дурная идея, ибо глючит. На длинных последовательностях передаваемых данных собственно данные искажаются.

Бывает только если скорость обмена находится на грани точности. Например наблюдалось на AVR с кварцем 20 мегагерц.
Тогда точность частоты составляет почти 2% что уже не допустимо. При переходе на "модемный кварц" 18.432 мегагерца,
рассинхронизация составляет менее 0.5% и ошибок не бывает.
Как пример могу привести что у меня при точности 0.5% автоопределение стабильно работает даже на 115200, что уже не есть гарантированым согласно документации.
И кроме того сам производитель настоятельно рекомендует работать на фиксированой скорости.

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

Это действительно так (проверено вручную). Но из документации как-то неочевидно.

Независимо от того, есть необъяснимое явление, когда при +IPR=0 и +CSCLK=2 искажаются данные. Причём, если на 9600 иногда заметно, то на 38400 -- нет. Такое впечатление, что модем "засыпает" в промежутках между байтами, если контроллер не успевает их один за одним выдавать. Какая связь с IPR=0 -- непонятно тогда. С +IPR=9600 проблем не замечено.


Кварц -- 7.94888 (есть PLL x4). Даёт 1.5% ошибку для скорости 115200. 0.5% для 38400. 0.001% для 9600.



Работать на фиксированной скорости в пределах одной версии -- можно. Но растёт обмен информации и скорость приходится увеличивать. При этом есть приборы с "запомненной" старой скоростью, что и вызывает трудности. Ставить же сразу 115200 неудобно по разным соображениям (контроллер без FIFO может и не успеть...)

При выходе из спячки при CSCLK=2 потеряется первый байт.

4.3.5
Wake Up SIM900 from Sleep Mode 2 (AT+CSCLK=2)
When SIM900 is in sleep mode 2 (AT+CSCLK=2), the following methods can wake up the module:
.............
* Note: The first byte of the user’s data will not be recognized.


Кроме того я повторюсь: рекомендую не использовать автоопределение вообще - избавит от множества проблем.
Ну а то что нужны более высокие скорости.... PIC12 с софтовым обменом чудненько общается на 115200 без всяких FIFO и при этом еще и два датчика обрабатывает. Писано правда на ассемблере - но тут С и не годится если хотим по временам укладываться.

Вот практический пример. Вот такое прилетает из сокета на сервере, после AT+CIPSEND. AT+IPR=0


В оригинале было "0.00: restart reason: POWER ON (128)" Налицо какой-то autobauding.
Глюки массовые и легко воспроизводимые. SIM900B, прошивка B08, память ST. Если на 9600 он глючил преимущественно в AT-командах, то тут практически 100% искажение передаваемых данных.

Тут же меняем на +IPR=38400 -- всё сразу без проблем работает. Физически скорость не изменялась.

И вы говорите, что autobauding только после DTR? Может скорость он меняет только после DTR и при +IPR=0. Но глючит он вне зависимости от состояния DTR -- достаточно только +IPR=0! Я считаю, что при +IPR=0 там работает какая-то автоподстройка скорости, причём работает всегда, причём глючно.

Я бы рекомендовал попросить авторов SIM900 убрать автосохранение AT+IPR -- только ручное сохранение. Кому нужно -- сохранят первой командой. Кому не нужно -- смогут нормально пользоваться без глюков +IPR=0 (которые тоже следовало бы исправить).

Так ведь IPR=0 это и есть autobauding. И он сам по себе глючный - потому и рекомендуют с него сразу уйти на фиксированую скорость.

SIM900B мы не поставляем и что там с прошивками не знаю. Но по остальным модулям жалоб на неудобства с сохранением IPR не было. Думаю что стоит Вам просто еще раз продумать алгоритм инициализации и переключения скорости.

С +CSCLK=2 история такова. Версии по B05 включительно не засыпали нормально при +CSCLK=1. А SIM300 засыпал. Сейчас версия B08 тоже засыпает при +CSCLK=1. Было поставлено +CSCLK=2. Тогда все SIM900 любых версий засыпают и даже работают нормально. Первый байт, на самом деле, никогда не теряется, потому, что логика работы осталась от того варианта, где +CSCLK=1 -- перед командой будет смена DTR с 1 на 0 -- вот он и проснётся. Первый байт не теряется. Теряется где-то в середине длинной AT-команды или при передаче длинных данных.



Успеет или нет зависит от двух причин:

1) от латентности обработчика прерываний. Где могут быть более высокоприоритетные прерывания (звук, например). Или не может быть нормальной системы приоритетов (PIC18). Это тот случай, когда FIFO полезен (медленный обработчик прерываний). И не надо PIC12 с ассемблерами притягивать за уши, который ничем больше не занят. 486DX40 вон не успевал, без 16550A если. Для PIC18 -- 800 тактов на байт. Он успеет, но он ничем другим больше занят не будет.

2) от скорости обработки поступающих данных. FIFO уже не поможет. Только если программный FIFO большего объёма, или снижение скорости передачи. Потому, что программа поступающие данные с такой скоростью обрабатывать не может. Тут конечно вспомнят о том, что есть RTS/CTS (которые глючат в SIM300...), XON/XOFF, GSM 07.10...




Если убрать автосохранение, то это нисколько не мешает тем, кому оно нужно: сохранят в первой команде (&W в конец добавить).

Если не убирать автосохранение, то это мешает тем, кто хочет всё-же менять скорость при смене прошивки прибора. Ничто не мешает стартовать в режиме +IPR=0 и первой командой сделать +IPR=38400, например. И работать на фиксированной скорости. Но если следующая прошивка захочет +IPR=115200 -- ей ничего не помешает это сделать (после включения питания модема). А сейчас нужно все скорости подряд перебирать пока на нужную не наткнёшься -- ненужное извращение.

Более того, это автосохранение доставляет... радости. Когда модем втихую перезапускается (из-за глюков в его прошивке) и делает вид, что дальше работает. Потому, что он не всё подряд автосохраняет... Лучше бы делал вид, что завис.

а разве при прошивке скорость не изменяется?
работаю на 9600, а прошиваю на 115200, проблем не встречал (SIM900 EAT)
или это специфика SIM900B?

+1.
Пытался это донести еще здесь.
Но безуспешно.