Jump to content

    

Alt.F4

Свой
  • Content Count

    1538
  • Joined

  • Last visited

Everything 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. Какие частоты можно объединить в одной печати? Если в продаже варианты с алиэкпресс, то они всегда где-то рядом или совсем далеко от указанных частот в описании.
  7. Было бы неплохо еще встраиваемые антенны обсудить, кто какие использует, напечатать по всей видимости уже не получится, как для 2G.
  8. Счетчик и xor юзаем с самого начала, думали накинуть еще чего для надежности, но по всей видимости, вариантов и нету..
  9. Да углубляться особо и некуда, в массивах 64-битные числа (UNIX-метки времени в мс), массивы разбиты по суткам, т.е. в одном массиве может быть от 1 до 8.64млн меток в одном массиве, но это критические значения, в среднем порядка 100тыс. в массиве.
  10. controller_m30, нет смысла углубляться в механизм синхронизации, вопрос заключается только в способе расчета КС для неупорядоченных чисел
  11. jcxz, я писал на прошлой странице, что у нас таких данных с метками 100тыс порядка 50тыс и это только суточное разделение, т.е за каждый день накапливается еще столько же. Поэтому слишком дорого держать дополнительные массивы в ОЗУ. По этой же причине мы не можем ничего сортировать. Надо что-то максимально дешевое и максимально точное, чтобы гарантировано позволяло находить отличия в метках данных у разных серверов.
  12. Конечно, там же сдвиги! После 4-часовой объемного коддинга, совсем фильтровать перестал... Как Вам наш первоначальный вариант с умножением на константу и последующим XOR с КС: checksum(cs,num) {return cs^(num*X);} ?
  13. На хабре нашлась статейка на тему контрольной суммы (не совсем понятно почему в ней везде в расчетах КС обозначается как 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);
  14. У нас таких массивов порядка 50тыс, дорогое решение держать дополнительные массивы в ОЗУ. Стоит задача оперировать только 32-битной КС. По всей видимости будем писать тесты для выбора лучшего расчета КС с помощью умножения и XOR...
  15. Есть еще такой момент, что при добавлении новой метки нет возможности заново проходить по всему массиву. Т.е. в работе мы оперируем только 32-битной КС, которую рассчитали ранее и по приходу новой метки 64-бита мы должны быстро и максимально дешево обновить КС.
  16. Ruslan1, Вы невнимательно прочли первый пост, почему Вы решили, что там 64 числа? В каждом массиве планируется порядка 100тыс чисел и старшее слово как раз можно отбросить из-за его повторения во всех метках.
  17. Просто сложение и просто XOR очень слабые КС, т.к. есть большая вероятность совпадения КС при разных значения меток времени. (см. 2+5=3+4)
  18. Здравствуйте. Есть 2 сервера, у каждого массив с метками времени (64-битные числа), во время синхронизации, метки сохраняются без сортировки, т.е. на одном может быть [1,2,3], а на другом [2,1,3]. Задача посчитать 32-битную контрольную сумму (КС) у этих массивов, чтобы она сходилась, вне зависимости от порядка следования чисел. Исходя из задачи, доступны только операции сложения, умножения и XOR (+, *, ^). Подскажите, пожалуйста, как оптимальнее считать КС?... Спасибо. P.S. Пока остановились на варианте с умножением на константу (вопрос, какое значение брать за константу) и последующим XOR с КС: checksum(cs,num) {return cs^(num*X);} Добавлено: при расчете КС старшее слово 64-битной метки можно отбросить, т.к. оно будет одинаковое у всех.
  19. Находил готовые модули Ebyte E18, но они на CC2530F256, по идее можно заливать стек и пример от TI, а Вы какой модуль использовали и где брали софт?
  20. PeterAwsmtek, на чем остановились по итогу?
  21. А что не устарело? По мне так наоборот набирает обороты, Xiaomi, IKEA, Philips и т.д.