Replies: 2 comments
-
|
Well I tried using wake on GPIO - the uart takes a long time to get ready, and it misses 3 bytes of data so that can't work. Next I tried an osal timer which fires to wake up the system shortly before the data is expected and that works well. |
Beta Was this translation helpful? Give feedback.
0 replies
-
|
Flashing requires temporarily cutting a trace, but is otherwise trouble free. The test points on the other side of the board with the same names appear to be incorrectly labeled (G is VDD for example) |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment

Uh oh!
There was an error while loading. Please reload this page.
-
I made a first cut of IBS-TH1 support, it's working well for me [but I expect it'll have unacceptable battery drain]
I have a few of these devices (Inkbird IBS-TH1) they're useful because they have an AAA battery and a magnet with a temperature sensor on a 1.2m wire (so you can stick them on eg. heaters and push the sensor into a thermostat tube). They've 6222 based, but with an architecture more usually found on the Tuya wifi devices: There's a uC handling the sensors which reports in packets over serial, and then the phy6222 forwards that over BLE.
The serial protocol almost exactly follows the format of the data on the characteristic from the stock firmware.
the characteristic from the stock firmware is:
be_uint16_t temp; // in 0.01C (you get external if there is a probe, otherwise the internal)
be_uint16_t humid; // in 0.01%
uint8_t sensor_flag; //0 for internal sensor, 1 for external sensor
be_uint16_t modbus_crc16;
the serial protocol is
uint8_t header==0x52;
be_uint16_t internal_temp; //in 0.01C
be_uint16_t external_temp; //in 0.01C
be_uint16_t humid; // in 0.01%
uint8_t external_probe_present; //0 for false, 1 for true
uint8_t battery_ok?; //1 for battery ok (I think)
uint8_t battery_pct; //battery %
be_uint16_t modbus_crc16;
uint8_t trailer=0x45;
I was too lazy to implement the crc checking
There's a boost converter on the power supply so using the ADC to read an output pin doesn't give a good indication of battery state.
I'm not familiar with this platform, but I found that the 6222 UART didn't wakeup and receive characters in sleep mode, so I took a powermgr lock between start_measure and one valid packet being received. I expect there's a better way of doing this (I had a quick look through the datasheet to see if the UART supported wake, and I assume using a GPIO wake won't work since the uart needs to be configured before the start bit arrives). Failing that the data arrive at known intervals - any better ideas welcome.
I expect I've committed some white space sins, so please let me know.
Beta Was this translation helpful? Give feedback.
All reactions