[bingo 0]

Добрый день!
Пожалуйста, помогите с несколькими вопросами:

1. Можно ли идентифицировать чипсет с помощью AT-команд?
2. Насколько работоспособен Bluetooth  в SIM800L?
3. Насколько правомерно использовать ИП 5В (<800мА) ч/з LDO (например,  MIC29302)  для питания модуля SIM800L?
   Или же мощности явно не хватит?
4. Возможно, кто нибудь сумел отрисовать схему модуля? Поделитесь,  пожалуйста )

Заранее благодарю за ответы.

[CADiLO 1]

1. Можно ли идентифицировать чипсет с помощью AT-команд?

Нет. Но есть вариант.

Если CSD работает, то там MT6260

Если нет, то - MT6261

Илит снять крышечку и прочитать.

2. Насколько работоспособен Bluetooth  в SIM800L?
Зависит только от прошивки. Физически BT есть в любом модуле 800 серии.

 

3. Насколько правомерно использовать ИП 5В (<800мА) ч/з LDO (например,  MIC29302)  для питания модуля SIM800L?
   Или же мощности явно не хватит?
Теоретически можно, но может выключаться при регистрации в сети или плохих условиях, например на краю покрытия.

Поэтому идеально иметь гарантированные 2 ампера и лучше не от LDO. 

 

4. Возможно, кто нибудь сумел отрисовать схему модуля? Поделитесь,  пожалуйста )

А зачем? Можно конечно поискать типовое включение чипсета на китайских форумах, там именно так и сделано.

 

[bingo 0]

Спасибо за ответ!

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

Не смогли бы дать ссылки?

Там английский?

[CADiLO 1]

Там китайский. :) Но гугль его прекрасно переводит на английский.

Ссылки - да пожалуйста.

http://bbs.52rd.com/forum.php

http://bbs.16rd.com/forum.php

Или поиском по Baidu - BBS R&D

 

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

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

Ну и регистрация.

Нужно как минимум аккаутн в мессенджере QQ и очень желателен реальный китайский телефонный номер на который смогут прислать QR код подтверждения регистрации или скачивания.

 

 

[bingo 0]

Еще вопрос.

Не смогли бы Вы порекомендовать готовый подходящий (и бюджетный) блок питания.

IRM-30-12 Menn Well подойдет?

Или еще другие..

Габариты тоже важны

[CADiLO 1]

Готовый не порекомендую, просто не сталкивался с ними.

 

[rudy_b 1]

Возник вопрос про работу с UDP. Модем SIM800L, прошивка 1418B05SIM800L24, оператор Мегафон.

Запуск GPRS стандартный. По TCP работает прекрасно, пакеты на сервер ходят, пакеты от сервера принимаются.

При работе по UDP пакеты на сервер идут нормально, но вот пакеты от сервера не поступают.

Команда установки локального порта  AT+CLPORT="UDP",... - не влияет, можно задавать порт UDP, можно не задавать - не влияет.

Кто-нибудь может подсказать в чем проблема? 

 

 

[adnega 5]

5 часов назад, rudy_b сказал:

Кто-нибудь может подсказать в чем проблема?

Предположу: UDP работает без установления соединения. Если у модуля IP-белый, то все должно работать. Иначе - есть разные варианты.

[rudy_b 1]

Это понятно. Модуль получает локальный IP адрес и работает через прокси оператора. На сервер поступают пакеты с совершенно другого адреса и другого порта.

Но в режиме TCP, ответ, отправленный по этому адресу и порту, доходит до модуля, а режиме UDP - нет.

[adnega 5]

7 часов назад, rudy_b сказал:

Но в режиме TCP, ответ, отправленный по этому адресу и порту, доходит до модуля, а режиме UDP - нет.

Скорее всего, на стороне оператора для этого (TCP) соединения сделана запись NAT.

[rudy_b 1]

Похоже это проделки оператора.

Понятия connect нет в UDP. Оно вводится специально для прокси сервера, чтобы он запоминал параметры переадресации на время существования коннекта, а потом забывал.

Специально проверил - если отправляю несколько пакетов UDP после коннекта - они приходят на сервер с одного адреса и порта.

После disconnect-connect они приходят уже с другого адреса и порта.

Похоже, что Мегафон специально заблокировал ответные пакеты UDP, чтобы пользователь заплатил за использование фиксированного адреса. Это, в какой-то мере разумно, можно будет сразу посылать пакеты на модуль. Но могли бы и не блокировать, насколько я смотрел разные обсуждения - раньше это работало.

 

 

[adnega 5]

15 часов назад, rudy_b сказал:

Но могли бы и не блокировать

Это не принудительная блокировка, а свойство ограниченности диапазона IP-адресов. Когда модуль соединяется с сервером по TCP ему выдают не IP-адрес, а пару IP-ПОРТ (сокет). Оператор маршрутизирует пакеты, приходящие на этот сокет (IP-ПОРТ) до вашего модуля. На соседнем порту этого же IP-адреса может быть совершенно другое соединение для совершенно случайного клиента. Возможно, раньше выдавали временный IP-адрес вместо пары IP-ПОРТ - поэтому могло и работать. Если AT+CIFSR выдает IP, который отличается от того, с которого вам прилетает соединение на сервер (и скорее всего, он будет какой-нить 10.х.х.х), то с большой долей вероятности (скорее, 100%) соединения у вас будут через NAT.

[rudy_b 1]

У нас несогласованность в терминах. Под proxy я подразумеваю то же самое, что и вы под NAT, т.е. подмену адреса и порта при прямой и обратной трансляции пакетов. И все, что выговорите совершенно справедливо. И, ессно, обмен идет только через прокси (NAT).

 

При запуске GPRS я получаю локальный адрес 10.237.141.82. На сервер TCP/UDP приходит пакет с адреса 188.170.81.135, порт 61469.

 

В UDP, даже если сервер не запущен, при  CIPSTART я все равно получаю connect. Т.е. при UDP connect используется только для прокси (NAT), что естественно, наличие сервера на реальном адресе UDP даже не проверяется в отличие от TCP.

 

Но зачем блокировать ответные пакеты UDP? 

[Самоделкин 0]

Работа операторов совершенно не зависит от типа( марки) модема хоть SIM800C хоть  SIM900R  итд.

Там все просто и хитро. Операторы  типа "защищают" Вас от хакеров используя NAT,  прокси тут совершенно ни причем. Даже при наличии "белого" IP  адреса - реально получите извращение. Если Вам дадут (купили ) "белый" IP  220.,,,.,,,.  это не значит что на команду модема "запрос IP" Вы в ответе его и получите 220.,,,.,,,. Каждый сеанс GPRS соединения Вам будет назначен новый динамический !!!! IP .  И все данные которые Вы отправили будут "проброшены" на Ваш "белый" IP который Вам дали  по всем Вашим сокетам !!! И наоборот, все пакеты  которые придут на Ваш "белый" IP, будут  отправлены на тот IP  который Вам "выдали " на время сеанса GPRS . У операторов своя сеть и они там сами себе что хотят то и делают. Реально экономят на адресах IP(сеть адресов собственная  намного больше чем реальная физическая ) . Ну и денежку считают- только деньги кончились ... Все  "шлюз"   на "белый" адрес закрыт .   

[rx3apf 0]

Сперва попробовать сменить оператора. И заодно убедиться, что сервер отправляет отправляет ответы именно на тот порт, с которого получил очередную датаграмму UDP. Помню, когда я отлаживал логику обмена, вместо сервера у меня была терминалка, работавшая в связке с TCP-com (от Taltech). Сперва работает, через некоторое время - перестает работать (в TCP - работает). Стал разбираться - после соединения серверная часть запомнила ip и порт. Работает. Проходит некоторое время неактивности - у мобильного клиента меняется ip и порт. А софтина новый ip понимает и обновляет, а вот порт оставляет прежний. И, естественно, запросы идут в никуда...