Jump to content

    

Alt.F4

Свой
  • Content Count

    1538
  • Joined

  • Last visited

Posts posted by Alt.F4


  1. Цитата

    А перед пайкой прошить не пробовали?

    Нет, ничего не пробовали, все на бегу, появятся еще, проверим.

     

    Цитата

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

    Поставили разрядный резистор чтобы вогнать времена в норму и все вылечилось.

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

  2. Цитата

    Но при правильном подходе модуль скорее умрет физически

    А как это проявляется?

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

  3. Здравствуйте.

    Помнится в SIM900 был лимит на количество запусков/регистраций в сети модема, после чего встроенная FLASH приходила в негодность и модем на помойку.

    Есть ли такие ограничения в серии SIM800C и в новый модемах LTE/NB-IoT?

    Спасибо.

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

    Решения не нашлось, скорее всего опсосы так защищают тарифы для телефонов от м2м, поэтому надо просто тарить м2м тарифы и не забивать голову.

  5. Здравствуйте.

    Планируем заложить в устройство готовый БП 220В->12В на плату от MeanWell (который уже имеет кучу международных сертификатов).

    Возник вопрос, какой сертификат нам потребуется делать для продажи устройств через Интернет-магазин в страны ЕАЭС/ЕС?

    Спасибо.

  6. 12 минут назад, Aner сказал:

    Можно напечатать многодиапазонку для LTE, расчет и точность нужна при изготовлении. Да и много таких вариантов уже есть в продаже. 

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

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

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

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

  9. Конечно, там же сдвиги! После 4-часовой объемного коддинга, совсем фильтровать перестал...

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

  10. На хабре нашлась статейка на тему контрольной суммы (не совсем понятно почему в ней везде в расчетах КС обозначается как 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);

  11. 1 час назад, jcxz сказал:

    Тогда держите массив M всё время в памяти и просто обновляйте его с приходом каждой новой метки и пересчитывайте CRC от результата.

    У нас таких массивов порядка 50тыс, дорогое решение держать дополнительные массивы в ОЗУ.

    Стоит задача оперировать только 32-битной КС.

     

    По всей видимости будем писать тесты для выбора лучшего расчета КС с помощью умножения и XOR...

  12. Есть еще такой момент, что при добавлении новой метки нет возможности заново проходить по всему массиву.

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

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

  14. Здравствуйте.

    Есть 2 сервера, у каждого массив с метками времени (64-битные числа), во время синхронизации, метки сохраняются без сортировки, т.е. на одном может быть [1,2,3], а на другом [2,1,3].

    Задача посчитать 32-битную контрольную сумму (КС) у этих массивов, чтобы она сходилась, вне зависимости от порядка следования чисел.

    Исходя из задачи, доступны только операции сложения, умножения и XOR (+, *, ^).

    Подскажите, пожалуйста, как оптимальнее считать КС?...

    Спасибо.

    P.S. Пока остановились на варианте с умножением на константу (вопрос, какое значение брать за константу) и последующим XOR с КС: checksum(cs,num) {return cs^(num*X);}

    Добавлено: при расчете КС старшее слово 64-битной метки можно отбросить, т.к. оно будет одинаковое у всех.

  15. 6 часов назад, PeterAwsmtek сказал:

    NXP JN516x

    Я запустил на модуле с AliExpress код координатора из примеров, удостоверился, что к этому координатору подключается розетка Xiaomi

     

    Находил готовые модули Ebyte E18, но они на CC2530F256, по идее можно заливать стек и пример от TI, а Вы какой модуль использовали и где брали софт?