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

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

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

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

Я работаю вместе с 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 (обновление отработано), но проблема проявляется и на предыдущих прошивках. Модули - различных партий. Проявление проблемы одинаковое на множестве экземпляров модулей.

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

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

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

Казалось бы, если производитель (в руководстве) предлагает использовать для этой цели батарею или "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 кбит/с этой проблемы нет.

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

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

подключите какойнить телефон в режиме модема к компу, и с этой карты попробуйте реальную скорость, может оператор больше 2400 не дает )) (2400 образно)

используете внутренний стек?
ИМХО для такой нагрузки лучше свой внешний

Скорость с которой Вы беседуте по Юарту с модулем не имеет отношения к скорости передачи по радиоканалу(которой занимается оператор). Так что оператор не может ограничить скорость передачи по внутреннему юарту.

Я к тому, что в проблемме все признаки переполнения буфера, и в следствии зависание самого модуля, кто его знает какой буфер там реально, а если от модуля в сеть уходит медленно, то вот вам и проблемма...

Декларируют килобайт, и вроде похоже на правду.
Но, если и килобайт за секунду через GPRS не передать, тогда уж пардон... придётся задействовать какие-то альтернативные каналы.

Какой проц используете? Если Мега128 - надеюсь кварц стоит? А то от внутреннего генератора такие косяки и будут вылетать. Попробуйте меньше пакет слать, по- моему где -то ошибка в частоте UART, не любит SIMCOM этого.