Alt.F4

А SIMCom модемы работают с VoLTE?

Возник вопрос о передаче голоса. Если будем использовать модем «2G + LTE Cat.1» и сеть 2G отключат, как будет осуществляться передача голоса, VoLTE?

Есть ли осциллограмма?

Здравствуйте. Возможно кто-то уже работал с eSIM в m2m, есть ли какие-нибудь подводные камни, можно ли отказываться от SIM-держателя?

Такую инфу надо в шапке прикреплять...

Нет, ничего не пробовали, все на бегу, появятся еще, проверим. Насколько помню, встроенные в модем емкости разряжаются до 0 дольше 10 секунд... А какой номинал шунта использовали?

А как это проявляется? За последние пару месяцев столкнулись с 5 модемами от разных клиентов (по 3-4 года в работе), после включения в UART мусор, осциллографом не было времени смотреть, просто перепаивали на новые.

Здравствуйте. Помнится в SIM900 был лимит на количество запусков/регистраций в сети модема, после чего встроенная FLASH приходила в негодность и модем на помойку. Есть ли такие ограничения в серии SIM800C и в новый модемах LTE/NB-IoT? Спасибо.

Сталкивались с подобным у себя в деревне. У одного опсоса симка изначально в 2G не хочет регаться, пока мобильником не зарегаем в 3G/LTE. Иногда пробивало через часа 4-5 постоянных попыток с ребутом модема. Решения не нашлось, скорее всего опсосы так защищают тарифы для телефонов от м2м, поэтому надо просто тарить м2м тарифы и не забивать голову.

Здравствуйте. Планируем заложить в устройство готовый БП 220В->12В на плату от MeanWell (который уже имеет кучу международных сертификатов). Возник вопрос, какой сертификат нам потребуется делать для продажи устройств через Интернет-магазин в страны ЕАЭС/ЕС? Спасибо.

Какие частоты можно объединить в одной печати? Если в продаже варианты с алиэкпресс, то они всегда где-то рядом или совсем далеко от указанных частот в описании.

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

Счетчик и xor юзаем с самого начала, думали накинуть еще чего для надежности, но по всей видимости, вариантов и нету..

Да углубляться особо и некуда, в массивах 64-битные числа (UNIX-метки времени в мс), массивы разбиты по суткам, т.е. в одном массиве может быть от 1 до 8.64млн меток в одном массиве, но это критические значения, в среднем порядка 100тыс. в массиве.

controller_m30, нет смысла углубляться в механизм синхронизации, вопрос заключается только в способе расчета КС для неупорядоченных чисел

Разброс от 1 мс до 24 часов, т.е. от 1 до 86400000.

jcxz, я писал на прошлой странице, что у нас таких данных с метками 100тыс порядка 50тыс и это только суточное разделение, т.е за каждый день накапливается еще столько же. Поэтому слишком дорого держать дополнительные массивы в ОЗУ. По этой же причине мы не можем ничего сортировать. Надо что-то максимально дешевое и максимально точное, чтобы гарантировано позволяло находить отличия в метках данных у разных серверов.

Выходит, остаётся только XOR...

Конечно, там же сдвиги! После 4-часовой объемного коддинга, совсем фильтровать перестал... Как Вам наш первоначальный вариант с умножением на константу и последующим XOR с КС: checksum(cs,num) {return cs^(num*X);} ?

На хабре нашлась статейка на тему контрольной суммы (не совсем понятно почему в ней везде в расчетах КС обозначается как CRC), вот несколько предложенных вариантов для КС 32 бит в разрезе нашей задачи: Метку времени timestamp сразу урезаем до младшего слова 32 бита, т.к. старшие у всех одинаковые, затем умножение на константу, в статье это 0x990C9AB5: cs=cs+(timestamp32*0x990C9AB5); cs=cs^(cs>>16); И второй вариант без умножения: cs=(cs<<5)+cs+timestamp32; cs=(cs<<5)+cs; cs=cs^(cs>>16);

У нас таких массивов порядка 50тыс, дорогое решение держать дополнительные массивы в ОЗУ. Стоит задача оперировать только 32-битной КС. По всей видимости будем писать тесты для выбора лучшего расчета КС с помощью умножения и XOR...

Есть еще такой момент, что при добавлении новой метки нет возможности заново проходить по всему массиву. Т.е. в работе мы оперируем только 32-битной КС, которую рассчитали ранее и по приходу новой метки 64-бита мы должны быстро и максимально дешево обновить КС.

Ruslan1, Вы невнимательно прочли первый пост, почему Вы решили, что там 64 числа? В каждом массиве планируется порядка 100тыс чисел и старшее слово как раз можно отбросить из-за его повторения во всех метках.

Просто сложение и просто XOR очень слабые КС, т.к. есть большая вероятность совпадения КС при разных значения меток времени. (см. 2+5=3+4)

Здравствуйте. Есть 2 сервера, у каждого массив с метками времени (64-битные числа), во время синхронизации, метки сохраняются без сортировки, т.е. на одном может быть [1,2,3], а на другом [2,1,3]. Задача посчитать 32-битную контрольную сумму (КС) у этих массивов, чтобы она сходилась, вне зависимости от порядка следования чисел. Исходя из задачи, доступны только операции сложения, умножения и XOR (+, *, ^). Подскажите, пожалуйста, как оптимальнее считать КС?... Спасибо. P.S. Пока остановились на варианте с умножением на константу (вопрос, какое значение брать за константу) и последующим XOR с КС: checksum(cs,num) {return cs^(num*X);} Добавлено: при расчете КС старшее слово 64-битной метки можно отбросить, т.к. оно будет одинаковое у всех.