Скорость передачи GPRS SIM800C Опции

[Mysteo]

Всем привет! Как нибудь можно повысить скорость передачи по GPRS? А то у меня колеблется около 0.8-1.5 килобайт в сек

Помимо данных команд:
AT+SAPBR=3,1,"CONTYPE","GPRS"

AT+SAPBR=3,1,"APN","mts.internet.ru"

AT+SAPBR=3,1,"USER","mts"

AT+SAPBR=3,1,"PWD","mts"

AT+SAPBR=1,1

Нужно ли изменять какие либо дефолтные настройки?

Вставляю симку в обычный телефон скорость передачи 5 килобайт в сек. Качество приема сигнала высокое в обоих случаях

[Short Circuit]

а вы используете порт - High Speed USB 2.0 ??

[Mysteo]

Нет, но и USB тут не причем, я учитывал скорость передачи уже после того как объемы данных загрузились в ОЗУ SIM800C а не всю процедуру передачи

[Harbinger]

Возможно, ограничивается оператором. Как правило, на передачу предоставляют один тайм-слот, изредка два (в Вашем случае с телефоном, похоже, так и есть - 2 тайм-слота при кодировке CS-4 дают 42,8 Kbps).

[CADiLO]

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

[Mysteo]

Да у меня пакет для умных устройств, но все равно они что-то хитрят, по началу скорость бывает 3-5 килобайт в сек , в момент передачи потребление высокое до 400мА доходит, так поработает минуту и все обрезается и потребление 220-290 мА делается, надо МТС звонить спрашивать.
Я сначала думал канал может просто загружен , но с телефоном без проблем всегда

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

Сообщение отредактировал Mysteo - Jan 17 2018, 04:57

[Harbinger]

Ещё, как вариант - телефон может работать в режиме EDGE.

[alex2103]

sim800c + lwip. Скачал файл 180кБ.

Код

Average bytes/s - 1062

m2m пакет от КС. CSQ -77dBm. Больше 1,5-2кБ/с никогда не видел, но специально это не тестировал.

[Mysteo]

Ещё, как вариант - телефон может работать в режиме EDGE.

Спасибо! Телефон как раз в EDGE, но я думал там одинаковые скоростя, буду разбираться в отличиях.

alex2103

Да я часто на форуме тут видел, что это нормальная скорость считается....но все же если читать характеристики GPRS сетей, скорость должна быть на порядок выше

[CADiLO]

Не читайте характеристики - просто запомните простую истину.

У оператора, если только у вас не выделенный канал, GPRS предоставляется по остаточному принципу. Все приоритеты разговорам.
Поэтому операторы выставляют принудительно для GPRS один слот, да и тот могут отобрать если возрастает разговорная нагрузка на соту.

Кроме того я не встречал еще сот где нормально выставлен GPRS class 12. Обычно везде 10, а в глухоманях, вообще 8.

[Mysteo]

Понял, а если соединение разорвется GPRS индикация у модуля тоже изменится? И что нибудь должен модуль сообщить? У меня уже второй раз соединение разрывается и никаких оповещений нет. Tолько индикация сообщает , что модуль просто зарегистрирован в сети

Сообщение отредактировал Mysteo - Jan 18 2018, 07:08

[CADiLO]

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

Поэтому если соединение рвется правильно - то и сообщения будут, а если оператор чикнет, то.....

[Mysteo]

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

[CADiLO]

Как вариант - перегружена сота и оператор тупо отдает слот под разговор обрывая GPRS.

[Alechek]

Есть такие ситуации когда коннект остается, а данные не идут или уходят как в черную дыру.

Эдуард, что подразумеватся под "данные идут в черную дыру"
Коннект TCP или UDP?
В TCP вроде как сложно провернуть такое при отсутствии канала от модема до БС...

[jcxz]

В TCP вроде как сложно провернуть такое при отсутствии канала от модема до БС...

Не сложно. Если другая сторона перед смертью объявила размер окна равным скажем 64К, то эти 64К как раз и есть та дыра.

[Alechek]

64К как раз и есть та дыра.

А как же "SEND OK", кто нам даст TCP ACK?

[CADiLO]

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

[jcxz]

А как же "SEND OK", кто нам даст TCP ACK?

Никто. Почитайте как работает TCP-сокет.
Любая из сторон TCP-сокета может передавать данные не дожидаясь подтверждений ранее переданного в пределах окна, которое было объявлено в последнем сообщении от 2-й стороны TCP-сокета.

[Alechek]

А причем тут TCP сокет?
Речь о TCP стеке МОДЕМА, причем конкретного производителя. Предлагаю обсуждать его а не какого-то сферического коня в нонэйм 3Г свистке.
Выдержка из "AN_SIM900_TCPIP_V1.02"

Note [3]: For TCP, “SEND OK” means data has been sent out and received successfully by the
remote server, due to the TCP connection-oriented protocol; for UDP, “SEND OK” just
means data has been sent out from the serial port of module, not meaning data reaching
the server, due to the UDP simpler message-based connectionless protocol.

Я лично понимаю так, что окно может быь любым, но SEND OK я получу только тогда, когда на все отправленные пакеты получу ACK.

[CADiLO]

Не всегда.

Например тут SEND OK не будет (SIM800 Series_TCPIP_Application Note_V1.01)

When command AT+CIPQSEND=1, it is in quick sending mode.
When the data is input to the serial port of module by AT+CIPSEND, it will respond DATA ACCEPT, while not respond SEND OK.
In such case, user can continuously use AT+CIPSEND to send data to the server.

[Baser]

Любая из сторон TCP-сокета может передавать данные не дожидаясь подтверждений ранее переданного в пределах окна, которое было объявлено в последнем сообщении от 2-й стороны TCP-сокета.

Т.е. если это соединение Модем <-> Сервер, то размер для окна пакетов модема назначает сервер?

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

[jcxz]

А причем тут TCP сокет?

При том что мой ответ был на Вашу конкретную фразу о TCP вообще. И фраза ваша была о TCP вообще, а не о каком-то модеме.

Т.е. если это соединение Модем <-> Сервер, то размер для окна пакетов модема назначает сервер?

У TCP нет понятия "модем". Есть понятие "клиент" (тот кто инициировал открытие сокета) и есть "сервер" (тот кто принял запрос открытия сокета).
И размеры окон назначают обе стороны независимо, каждая - в свою сторону.

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

Он должен его (размер окна) запросить у клиента (того, кто послал модему команду открытия соединения). Или, если такого в API нет, то думаю - неявно принять равным размеру внутреннего приёмного буфера сокета в модеме. Обычно это размер некоего буфера.

Сколько бы сервер ни прислал данных, модем обычно тут-же подтверждает.

Нет, всё не так. TCP ack - это одно, а окно - другое. С ack-ом приходит новый размер окна. Пока он не пришёл - можно слать не более чем было указано в последнем ack-е.
Ack приходит всегда (если данные корректно приняты), но с задержкой. Приёмная сторона, приняв порцию данных, может её не сразу подтвердить, а через некоторое время. Это для сокращения пустого траффика.
Если же отправитель, будет отправлять данные малыми порциями и после каждой такой порции ждать ack (как делают многие криворукие программёры), то передача будет очень медленной.
Это всё описано в описании TCP-протокола.

[Baser]

Нет, всё не так. TCP ack - это одно, а окно - другое. С ack-ом приходит новый размер окна. Пока он не пришёл - можно слать не более чем было указано в последнем ack-е.
Ack приходит всегда (если данные корректно приняты), но с задержкой. Приёмная сторона, приняв порцию данных, может её не сразу подтвердить, а через некоторое время. Это для сокращения пустого траффика.
Если же отправитель, будет отправлять данные малыми порциями и после каждой такой порции ждать ack (как делают многие криворукие программёры), то передача будет очень медленной.
Это всё описано в описании TCP-протокола.

Спасибо за разъяснения. Все никак не могу добраться до изучения RFC
Сдается мне, что это и реализованно в стандартном режиме посылки данных по TCP, поэтому у всех и получается всего 1-2 кбайта/сек

Там сейчас добавлен еще один режим передачи, AT+CIPQSEND=1 (quick sending mode),
вот я его как раз хочу попробовать.

When command AT+CIPQSEND=1, it is in quick sending mode.
When the data is input to the serial port of module by AT+CIPSEND, it will respond DATA ACCEPT, while not respond SEND OK.
In such case, user can continuously use AT+CIPSEND to send data to the server.

Эдуард, не могли бы прояснить, не совсем понятно, как в этом режиме определить, что еще можно "пихать" модему данные на передачу.
Как можно узнать что заполнен приемный буфер и модем больше не может принимать данные?

[Цырен.]

Как можно узнать что заполнен приемный буфер и модем больше не может принимать данные?

HW/SW flow control, см. AT+IFC

[wild.hamster]

Если примерно знать протокол TCP, можно использовать Wireshark все становится ясно, кто в чем виноват. Протестировал SIM800c, работает корректно. Как было сказано, есть операторы, которые перестают обслуживать GPRS канал после определенного времени простоя и никаких признаков не подают, мертвый канал определяет противоположная сторона несколькими попытками ретрансмита. Лечится это PING'ом, но я использую keepalive (SIM800 имеет настройку - 1 команда и проблем нет).