Результаты поиска

А я ещё раз повторю - пока неизвестно. Есть ли там мембрана в конструкции... Я их не покупал - жду кто другой проверит, т.к. пока не нужны.

PCF85163 = AT85163 (Китай, Питание 1.0..5.5V)

Поменять DS1307 на что-то более современное.

В даташите на DS1307 указано 4.5..5.5 В. А у вас питание DS1307 ниже чем вход от батарейки CR2032 (новая дает более 3.2В без нагрузки при +25С).

Слепил чтение идентификаторов в SerialNumberString и оказалось, что в TS0201 стоит flash GD25LQ80C (1Мбайт) :unsure: BLE SerialNumberString: 556202-C86014-AP3A181 556202 - SoC ID, ver: 5562 - SoC ID: TLSR8258, все TLSR825x 02 - SoC revision: ver 2, все TLSR825x C86014 - Flash JEDEC...

Время реакции на изменение температуры c +10 до -20С у TS0201: Примерно 1 градус С в минуту... А влажность реагирует быстрее. П.плата и прочие детальки в TS0201 слишком массивные и прогрев или охлаждение занимают много времени.

Требуется помощь зала: Странные показания влажности с датчика CHT8305: Непонятные прыжки на 0.3%. Или это интеграция BTHome в HA балдит? Опрос датчика производится раз в пару секунд. _attribute_ram_code_ __attribute__((optimize("-Os"))) int read_sensor_cb(void) { uint32_t _temp, i = 10...

Тут калибруй или нет - ещё неизвестно, может ли датчик работать с водой. На "импортный" кристалл, как пишет китаец-продавец, в даташите писано: для использования с неагрессивными, неионогенными газами, такими как воздух и другие сухие газы.

Flash в TLSR825x у Tuya закрыта на запись. Снимается программатором. Остальные данные по ZigBee TS0201: Разъем: 1 RST 2 SWS 3 vdd 4 gnd 5 B1 (TX) 6 B7 (RX) Что и куда: C3 - I2C_SCK C2 - I2C_SDA C0 - key (gnd) B4 - LED (gnd) D7 - Alert (CHT8305) Кнопку использую для соединения в Legacy...

Отнес я этот Tuya ZigBee в сарай и всё – никто его не видит. В общем, грохнул эту Tuya прошивку, т.к. это очередной ZigBee, который по дальности, стабильности и длительным паузам между передачами всегда хуже WiFi, а WiFi хуже BLE. Прошил BLE c LongRange – сразу полет нормальный – все его видят...

Этот ZigBee TS0201 имеет странную прошивку - два куска: Один с 0x00000..0x6A00 и второй с 0x08000..0x3cba0. Первый кусок не подписан CRC, второй - подписан. https://disk.yandex.ru/d/Fin-7-daOMUGZQ Жрет много - предварительный замер - более 0.1 мА

Для вычисления реальной компенсации требуется калибровка на реальных давлениях и температурах - а это время и цена поделия.

Есть же какая-то программа - в disasm её... Если свернута чем - вынуть работающую из памяти.

А это неизвестно - что угодно может быть :) Может его ХОR с чем-то А буфер примерно так: unit8_t inpbuf[5]; unit8_t *p = inpbuf; unit16_t x; unit16_t hhdlc, lhdlc, cladr; hhdlc = ((*p++)>>1)<<7; hhdlc |= (*p++)>>1; lhdlc = ((*p++)>>1)<<7; lhdlc |= (*p++)>>1...

0x5444=101010001000100 Вынем бит 0 и 8, получим: UHDLC: 1010100100010b=0x1522=5410 0x086f=100001101111b Вынем бит 0 и 8, получим: LHDLC: 1000110111b=0x237=567

В примере (на картинке) дан код UHDLC: 0x1234=0001001000110100b Младшие 7 бит: 0110100b Старшие 7 бит: 0100100b Собираем: к каждым 7 битам добавим 1 бит равный 0 справа: Итого: 0100100001101000b Получаем аналогичный итог с картинкой.

Выше неверно - биты не в ту сторону :) LSB...MSB unit16_t decode_sn(uint16_t s) { int i = 7; uint16_t x = 0; s >>= 1; while(i--) { x <<= 1; x |= s & 1; s >>= 1; } s >>= 1; i = 7; while(i--) { x <<= 1; x |= s & 1; s...

unit16_t decode_sn(uint16_t s) { int i = 7; uint16_t x = 0; while(i--) { x |= s & 0x8000; x >>= 1; s <<= 1; } s <<= 1; i = 7; while(i--) { x |= s & 0x8000; x >>= 1; s <<= 1; } x >>= 1; return x; }...

21021839=0x140C48F ? Это только HDLC из двух номеров? С каким "индейцем" (BYTE_ORDER = LITTLE_ENDIAN ? BIG_ENDIAN)?

Т.е. обратная задача? И пишите с уточнением - где HEX, а где DEC Всё уточняйте, т.к. пишу занимаясь другими делами и голова на 3-ю задачу работает кое-как :) (обычно сокращая и забывая что-то вписать)