Мульти-системный NB-IoT/eMTC/GSM - SIM7000E, от SIMCom Wireless Solutions Опции

[Hub]

Друзья,

Вот и вышел долгожданный модуль SIM7000E.
Модуль выполнен в компактном 24x24x2.6 mm корпусе с LCC-контактами, форм-фактор совместим по посадочному месту с 2G и 3G модулями: SIM800, SIM800F и SIM5300E.
SIM7000E поддерживает различные интерфейсы (UART, USB, I2C и др.), имеет встроенный стек TCP/IP, а по посадочным местам и АТ-командам высоко совместим с модулями SIM800/SIM800F/SIM5300E(A), что позволяет, с учетом небольших отличий, использовать их на одной плате.
Поддержка eMTC/NB-IOT+GSM гарантирует повсеместную работу, даже без наличия покрытия LTE-сетей низких категорий, а встроенный GNSS-приемник может быть использован для определения местоположения и синхронизации времени.
Основные характеристики модуля SIM7000E можно посмотреть на сайте MT-System: www.mt-system.ru/SIMCom/SIM7000E

И да, 9 микроампер это реально круто!

[Mihail Gluhowche...]

Друзья,
успешно провел тесты SIM7000E в реальной сети NB-IoT, при поддержке очень хороших людей. Что проверил:
- данные TCP/IP ходят туда и обратно;
- UDP/IP проверил только в сторону сервера (не дали внешний IP);
- в режим PSM модуль заходит с таймерами 3324 и 3412, заданными модулем, что есть хорошо. Также модуль адекватно просыпается по POWERKEY(можно и по RTC если писать приложение на EAT) и шлет TAU, т.е. выходит на связь принудительно, раньше чем задает таймер 3412;
- в режим eDRX модуль тоже зашел успешно, но с параметрами ММЕ. Параметры, переданные от модуля, ММЕ видит, но ставит в attach accept свои значения, которые модуль обязан принять. Может так будет для всех, а может быть скважность можно будет менять для каждого клиента отдельно. Не вижу большого смысла в этой фиче для устройств, которые хотят жить по 5-10 лет, только если для устройств, которые постоянно должны быть запитаны и быть готовы принять данные в разумные сроки, но не прямо "он-лайн"-"он-лайн". Скажем обычные телефоны имеют пейджинг с интервалов 1.28сек, то в SIM7000E/E-N* можно будет настроить до 6 часов. Т.е. можно настроить модуль так, чтобы он ел батарейку, но выходил на сеанс приема раз в 60 сек.

Что будет с данными, которые идут от сети в модуль в режимах PSM и eDRX? Не проверял, но теоретически, в PSM данные должны накопиться в ММЕ(вопрос к оператору) и прийти в модуль при следующем сеансе TAU. В режиме eDRX, данные должны накопиться в ММЕ и прийти в модуль в моменты пейджинга, к примеру, раз в 60 сек.

* уточняйте у дистри

eDRX работает несколько по другому. Сеть должна запомнить настройки терминала и работать с увеличенными интервалами . Главное запомнить настройки, это сокращает потребление и время работы конечного устройства. Время RRC и Context/Security много больше чем передача пакетика данных. Что же вы там испытали?

да нет реальных сетей ни у кого брат

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

Есть тестовые вещи на которых можно попробовать кейс.
Дорогой но вполне для Smart модулей как универсальный комбайн для всех технологий пойдет.

Ждем до конца года недорогой NB-IoT на MT2625...

Они будут у всех дешевые если на одну технологию но без резерва на 2G, не очень надежно, на заре запуска технологии. Да и на все технологии, будут по вкусной цене.

[Цырен.]

eDRX работает несколько по другому. Сеть должна запомнить настройки терминала и работать с увеличенными интервалами . Главное запомнить настройки, это сокращает потребление и время работы конечного устройства. Время RRC и Context/Security много больше чем передача пакетика данных. Что же вы там испытали?

нет, не верно. Сеть не должна ничего запоминать, она либо примет параметры eDRX в Attach request, идущий от модуля во время RRC, либо нет. В моем случае сеть не приняла мои настройки eDRX и поставила свои. (вроде я писал об этом)



"это сокращает потребление и время работы конечного устройства." - не могу не согласиться и решительно не буду спорить

"Время RRC и Context/Security много больше чем передача пакетика данных." - разве я утверждал обратное? верно, это время не зависит от модуля, этот процесс в моем случае занял примерно 30 сек, как мне сообщил инженер оператора.

"Что же вы там испытали?" - сквозит сарказмом, а у меня правило не реагировать на провокации. Однако, поясню по сути вопроса. Тест с eDRX выглядел так: я на стороне модуля SIM7000E ввожу АТ команды, которые пишут в память параметры Cycle length и PTW; перезагружаю модуль(ради процедуры Attach), жду когда модуль получит регистрацию(CGREG) и аттач(CGATT) и одновременно получаю от инженера оператора подтверждение, что пакеты Attach Request и Attach Accept содержат данные о eDRX и на стороне сети режим eDRX подтвержден. Не могу показать логи оператора, боюсь они могут обидеться. Есть еще вопросы? Если есть - задавайте, по горячим следам и пока память свежа, отвечу. Тема интересная, готов обсуждать.

[Mihail Gluhowche...]

нет, не верно. Сеть не должна ничего запоминать, она либо примет параметры eDRX в Attach request, идущий от модуля во время RRC, либо нет. В моем случае сеть не приняла мои настройки eDRX и поставила свои. (вроде я писал об этом)



"это сокращает потребление и время работы конечного устройства." - не могу не согласиться и решительно не буду спорить

"Время RRC и Context/Security много больше чем передача пакетика данных." - разве я утверждал обратное? верно, это время не зависит от модуля, этот процесс в моем случае занял примерно 30 сек, как мне сообщил инженер оператора.

"Что же вы там испытали?" - сквозит сарказмом, а у меня правило не реагировать на провокации. Однако, поясню по сути вопроса. Тест с eDRX выглядел так: я на стороне модуля SIM7000E ввожу АТ команды, которые пишут в память параметры Cycle length и PTW; перезагружаю модуль(ради процедуры Attach), жду когда модуль получит регистрацию(CGREG) и аттач(CGATT) и одновременно получаю от инженера оператора подтверждение, что пакеты Attach Request и Attach Accept содержат данные о eDRX и на стороне сети режим eDRX подтвержден. Не могу показать логи оператора, боюсь они могут обидеться. Есть еще вопросы? Если есть - задавайте, по горячим следам и пока память свежа, отвечу. Тема интересная, готов обсуждать.

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

No IP data transfer, я так понимаю вы не проверили?