[virfis 0]

ставьте фиксированую скорость.

Пробовал, не помогает.

И при скорости более 9600 используйте RTS-CTS

Не получится, нет свободных выводов процессора.

Тогда уж для проверки повесьте на VRTC конденсатор вместо батарейки.

Поставили 100 мкФ, не помогает.

На VBAT поставили 4700 мкФ. Все равно есть зависания.

Снизили скорость до 19200. Работает без зависаний вообще.

[av-master 0]

Не получится, нет свободных выводов процессора.

Снизили скорость до 19200. Работает без зависаний вообще.

 

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

[CADiLO 9]

>>>>И при скорости более 9600 используйте RTS-CTS

 

>>>>Не получится, нет свободных выводов процессора.

 

А придется.... Иначе шанс поймать висяк останется.....

[virfis 0]

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

Я использую программное управление потоком XON/XOFF, писал выше. Кроме того в документации написано что за один раз можно отправлять до одного килобайта. Я отправляю 510 байт. О каком переполнении буфера может идти речь.

 

А придется.... Иначе шанс поймать висяк останется.....

А разве программным управлением потока нельзя обойтись?

Изменено 16 марта, 2009 пользователем virfis

[HARMHARM 0]

На передаче модуль жрет хорошо. У меня даже СМС больше 50 знаков перегружали модуль, пока LM1084 по 1000 low esr с двух сторон не обвесил, хотя на модуле 200 тантал и керамика, и 2000 low esr уже были... Причем осцилом не поймаешь просадку.

Это точно. Если время отклика регулятора на изменение нагрузки велико, можно постоянно ловить глюки. Конденсатор для прокорма GPRS нужен будет уж почно побольше 2000 мкФ :)

[virfis 0]

Пробовали использовать режим RTS/CTS: CTS в нуле, выдали 510 байт на 115200, через 23 мс видим CTS поднялся в 1 и модем завис. Тоже самое с режимом XON/XOFF - модем выдал XOFF после приема пакета и XON уже не выдает, повис. И дальше уже не отвечает ни на какие команды.

Смотрели осциллографом - просадки напряжения нет после того как поставили 4700 мкФ.

[HARMHARM 0]

Пробовали использовать режим RTS/CTS: CTS в нуле, выдали 510 байт на 115200, через 23 мс видим CTS поднялся в 1 и модем завис. Тоже самое с режимом XON/XOFF - модем выдал XOFF после приема пакета и XON уже не выдает, повис. И дальше уже не отвечает ни на какие команды.

Смотрели осциллографом - просадки напряжения нет после того как поставили 4700 мкФ.

Может, схему покажете?

[virfis 0]

Лучше задайте вопрос по схеме, я отвечу.

[HARMHARM 0]

Лучше задайте вопрос по схеме, я отвечу.

Опишите как подключен sim300D :cranky:

[SV_TC 0]

Опишите как подключен sim300D :cranky:

Я работаю вместе с virfis, занимаюсь схемотехникой.

Вот описание схемы подключения модуля:

На VBAT модуля подается напряжение 4,0 В - через LP3963; конденсаторы 1х4800мкФ(LowESR)+2х100мкФ(LowESRтантал)+1х2мкФ(керамика) с обеих сторон преобразователя. Длина проводника от вывода VBAT модуля до демпфирующих конденсаторов - не более 3 мм. Преобразователь питания управляется контроллером. Контроллер связан с модулем только цепями TxD и RxD через "правильный" преобразователь уровня с питанием 2,99 В на стороне модуля. "Фантомное" питание модуля через выводы TxD и RxD исключено. Вывод STATUS модуля не используется, однако питание 2,99 В на преобразователь уровня цепей TxD и RxD подается не ранее 8 с после включения модуля.

Цепь CTS не используется, цепи RTS, PWR_KEY и SIM подключены согласно руководству SIM300DZ_HD_V2.07. Используется режим синхронизации Xon/Xoff. К выводу RTC_BACKUP подключен конденсатор 100 мкФ. Процедуры включения и отключения модуля выполняются согласно руководству. Прошивка модуля - версии 16 (обновление отработано), но проблема проявляется и на предыдущих прошивках. Модули - различных партий. Проявление проблемы одинаковое на множестве экземпляров модулей.

[M_Z 0]

К выводу RTC_BACKUP подключен конденсатор 100 мкФ. Процедуры включения и отключения модуля выполняются согласно руководству.

Неоднократно писали, что стоит поменьше конденсатор поставить, а не 100мкФ. Хотя все это шаманство.

Но попробуйте.

Изменено 17 марта, 2009 пользователем M_Z

[av-master 0]

правильный преобразователь - отключаемый? а то даже 2.9 может быть много, питание ядра 1.8

Изменено 17 марта, 2009 пользователем av-master

[SV_TC 0]

правильный преобразователь - отключаемый? а то даже 2.9 может быть много, питание ядра 1.8

Извините, повторюсь: "...однако питание 2,99 В на преобразователь уровня цепей TxD и RxD подается не ранее 8 с после включения модуля."

Здесь "подается" - в том смысле, что пока не подано, напряжение равно нулю.

Неоднократно писали, что стоит поменьше конденсатор поставить, а не 100мкФ. Хотя все это шаманство.

Но попробуйте.

Казалось бы, если производитель (в руководстве) предлагает использовать для этой цели батарею или "large capacitance Capacitor" емкостью "0.2F to 0.3F", то чем же 100 мкФ хуже?

Однако попробовали 22 мкФ, затем 0,1 мкФ - проблема сохраняется.

Попутно вопрос: кто-либо пробовал или может опробовать выдачу через свой модуль на скорости 115,2 кбит/с в режиме UDP до 10-ти пакетов размером 512 байт - подряд (конечно, всякий раз - с подтверждением отправки)?

Напомню проблему: у нас модуль в этом случае перестает подтверждать отправку после 1...5 пакета. При передаче блока он ни разу не выдает Xoff, но выдает его примерно через 20 мс после передачи блока - и больше ничего: не передает Xon и не реагирует ни на какие команды. Помогает только рестарт питания модуля (конечно - правильный). Переводим модуль в режим RTS/CTS, наблюдаем за CTS: CTS в течение передачи блока находится в нуле, а примерно через 20 мс - переходит в единицу и модуль также "висит".

А вот на скорости 9,6 кбит/с этой проблемы нет.

[M_Z 0]

Попутно вопрос: кто-либо пробовал или может опробовать выдачу через свой модуль на скорости 115,2 кбит/с в режиме UDP до 10-ти пакетов размером 512 байт - подряд (конечно, всякий раз - с подтверждением отправки)?

Мы используем скорость 115,2 но TCP соединение. передаем подряд десятки пакетов естественно дожидаясь подтверждения SEND_OK, плюс подтверждения нашей программы на сервере что данные записаны в базу данных. и только после этого отправленные данные удаляем и шлем новый пакет.

Может у Вас какие то проблемы с оператором, но тогда не зависило бы от скорости передачи.

[SV_TC 0]

Мы используем скорость 115,2 но TCP соединение. передаем подряд десятки пакетов естественно дожидаясь подтверждения SEND_OK, плюс подтверждения нашей программы на сервере что данные записаны в базу данных. и только после этого отправленные данные удаляем и шлем новый пакет.

Может у Вас какие то проблемы с оператором, но тогда не зависило бы от скорости передачи.

В TCP соединении при скорости 115,2 отправляем этот же блок (512 байт). Иногда (1 раз из 5) в течение 30 с не дожидаемся SEND_OK. Но модуль реагирует на запросы. Переустанавливаем соединение - видим на удаленной стороне переустановку соединения - пытаемся снова отправить блок - SEND_OK нет (ждем 30 с). И так, пока не рестартуем модуль.

На скорости 9,6 этой проблемы и в TCP соединении нет.