Кот про NB-IoT. Часть 2

Автор: kotgav
Опубликовано 23.12.2020
Создано при помощи КотоРед.

Привет, товарищи!

Как говорится, "по многочисленным просьбам трудящихся", продолжаем мучать NB-IoT.

Ч.1 - тут:
Кот про NB-IoT. Часть 1

Вообще, NB-IoT хорош тем, что может мало потреблять и о-о-очень долго спать в режиме PSM. Как настоящий кот.
Но про сон - в части 3, а здесь мы будем передавать классические TCP пакеты по сети NB-IoT.
Да, кстати, SIM-карту нужно использовать специальную, с обычной не зарегистрируется в сети, увы.

Используем всё ту же отладочную плату Neoway N21.
Чтобы пообщаться с TCP-сервером, нам нужно будет:

• убедиться, что модуль зарегистрировался в сети;
• прописать настройки APN;
• установить PPP-соединение;
• установить соединение с TCP-сервером;
• отправить/принять TCP-пакеты;
• возможно, в процессе нам захочется проверить состояние TCP-соединения;
• закрыть TCP-соединение.

Ну-с, начнем!

1. Предположим, наша плата успешно включилась и светодиод NET загорелся.
По идее горящий NET говорит о том, что плата зарегистрировалась в сети NB-IoT.
Но мы хотим проверить это при помощи команд.
Для этого используем команду AT+CEREG?

На всякий случай напомню, что любая команда (ну, почти любая) должна заканчиваться символом возврата каретки, в простонародии - r
Вообще, варианты ответов зависят от того, оставили ли мы значение по умолчанию AT+CEREG=1 или же устанавливали какое-нибудь другое значение. При значении по умолчанию основные варианты ответов следующие:

а) модуль зарегистрировался в NB-IoT:
AT+CEREG=0,1

б) вариантов, когда нет регистрации, несколько:
AT+CEREG=0,0 - модуль или пытается найти сеть, или вообще не собирается зарегистрироваться. Может, забыли вставить SIM-карту? Сканирование диапазонов занимает порядка двух минут (правда, если раньше модуль с этой SIM-картой уже был зарегистрирован в сети, то он сохранит информацию о частотных каналах и сначала попробует пообщаться с сетью, используя эти знания. В таком случае регистрация в сети может пройти очень быстро).
AT+CEREG=0,2 - модуль находится в процессе регистрации, нужно подождать... Реально такого не видел.
AT+CEREG=0,3 - что-то пошло не так в процессе регистрации. Возможно, что-то не то с SIM-картой, тарифом, настройками на стороне оператора. Когда у меня было такое, модуль не мог зарегистрироваться в сети и выдавал AT+CEREG=0,3, то помогло обращение к оператору (сотрудники МТС подкрутили что-то на своей стороне).
AT+CEREG=0,4 - этот код выдается, когда модуль не может обнаружить сеть или потерял сеть. Кстати, если модуль не смог зарегистрироваться и показывает AT+CEREG=0,4, среди прочего полезно будет проверить, какие частотные диапазоны установлены. Делается это командой AT+NVSETBAND?
В Европе и РФ используются 3, 8, 20, поэтому стоит установить:
AT+NVSETBAND=3,3,8,20
первый параметр - количество диапазонов, за ним идет перечисление номеров диапазонов.

2. Чтобы двигаться дальше, нужно прописать настройки APN (Access Point Name).
Для NB-IoT МТС сгодятся настройки:
AT+CGDCONT=1,"IP","iot"
или
AT+CGDCONT=1,"IP",""

Если вместо "iot" прописать что-нибудь другое, то модуль скажет "OK", но не сможет установить PPP-соединение.

3. Если с предыдущими шагами всё в порядке, можно устанавливать PPP-соединение с сетью. Это нужно сделать до установления соединения с TCP-сервером.
Чтобы установить соединение PPP, используется команда:
AT+XIIC=1
После неё рекомендуется проверить, что всё получилось, при помощи команды
AT+XIIC?
если при этом мы получили IP-адрес, отличный от 0.0.0.0, то можно двигаться дальше.

Есть небольшая хитрость: если не хочется каждый раз после включения устанавливать PPP-соединение, можно попросить модуль делать это автоматически с помощью команды:
AT+NEONBIOTCFG=1,0,0,0

4. Как только PPP установлено, можно налаживать связь с TCP-сервером.
Если вы - счастливый обладатель белого статического IP-адреса, то можно настроить "проброс" нужных портов на роутере (или роутерах!), разрешить обращение к этим портам в ОС, запустить программу или скрипт, имитирующие TCP-сервер, и попробовать пересылку TCP-пакетов.
Чтобы упростить эту задачу и просто попробовать передачу и прием TCP-пакетов, можно отправлять пакет, имитирующий HTTP-запрос, на какой-нибудь сайт.
Простой HTTP-запрос будет выглядеть, например, так:
'HEAD / HTTP/1.1rnHost: ya.rurnUser-Agent: Mozilla/5.0rnAccept: text/htmlrnConnection: closernrn'
Важно, чтобы в конце шли два перевода строки - по ним сервер определяет конец запроса.
В этом примере запрашивается не сама HTTP-страница, а только HTTP-заголовки (HEAD).
Команды для этого примера следующие:

а) установление TCP-соединения с сервером ya.ru, стандартный порт TCP - 80:
AT+TCPSETUP=1,"ya.ru",80

б) отправить 95 байт:
AT+TCPSEND=1,95
В ответ на эту команду модуль должен выдать приглашение в виде симола '>', после чего необходимо передать по UART требуемое количество байт (в данном случае - 95):
HEAD / HTTP/1.1rnHost: ya.rurnUser-Agent: Mozilla/5.0rnAccept: text/htmlrnConnection: close

тут r - символ возврата каретки, n - символ перевода строки.

в) после этого мы должны получить ответ HTTP-сервера, который будет начинаться с +TCPRECV:. Примерно как на картинке:

Это сервер передал нам заголовки HTTP, как мы и просили.
Код ответа 302 означает, что запрошенный документ доступен по другому адресу, указанному в заголовке в поле "Location".

В этом примере удаленный сервер сразу закрыл наше соединение TCP. Если "Connection: close" в запросе заменить на "Connection: open", то оно останется открытым ещё какое-то время.

Если нужно проверить состояние соединения, то можно использовать команду:
AT+IPSTATUS=1
Ответы:
+IPSTATUS: 1,CONNECT
или
+IPSTATUS: 1,DISCONNECT

Небольшое пояснение по поводу приема пакетов TCP/UDP.
Режим приема можно настраивать, для этого есть команда AT+RECVMODE.
При приеме пакета TCP/UDP данные могут или сразу выдаваться на UART, или сохраняться в буфере, а на UART будет выдаваться только уведомление типа: "+TCPRECV: 1,42" (1 - номер сокета, 42 - количество байт данных в буфере).
Кроме того, байты данных могут выдаваться или "как есть", или преобразованные в текстовые "HEX-сообщения". Текстовые "HEX-сообщения" - это, например, если приходит один байт - 0x77, ASCII-символ "w", то он преобразуется в два байта - 0x3737, соответствующие ASCII-символам "77", в результате в терминальной программе вместо "w" мы увидим текстовое представление его шестнадцатеричного кода - "77".
Идея, думаю, понятна.

Варианты такие:
AT+RECVMODE=1,0 - принятые данные выдаются на UART "как есть";
AT+RECVMODE=1,1 - принятые данные выдаются на UART в виде текстовых "HEX-сообщений";
AT+RECVMODE=0,0 - принятые данные сохраняются в буфере "как есть";
AT+RECVMODE=0,1 - принятые данные сохраняются в буфере в виде текстовых "HEX-сообщений".

Узнать, какой вариант включен:
AT+RECVMODE?

Но с режимом, когда данные сохраняются в буфере, нужно быть осторожными: если сокет закрывается, то данные из буфера удаляются! То есть, если, например, пришли данные, сохранились в буфере, мы их не считали, а сервер TCP на том конце закрыл соединение, то сокет закроется и считать это данные из буфера мы уже не сможем!

Все вопросы в Форум.