Allow dumping original firmware via ATCtelink.py about atc_mithermometer HOT 75 OPEN

@michapr I bit the bullet and tried to integrate the EPD library into this project. Unfortunately it is not a trivial task (at least for me) to create a multi-targeted code, i.e. being able to select the device to build a custom firmware for - LCD-based or EPD-based. Therefore I forked this repo and replaced the LCD driver with EPD driver (a crude C++ to C conversion). The display is generally working, at least it is being correctly initialised when the device is powered up, but I'm still facing issues with the partial refresh when displaying changing temperature / humidity / battery values. I'll try to fix those issues in the coming weeks. Meanwhile, here is a little teaser of the latest code (with LCD driver changed for EPD), working on my MHO-C401:

Thinking forward, some of the ATC functions requiring quick display drawing/refresh will have to be dropped in the EPD variant (like blinking smiley, quick alternating battery / humidity values etc.). This is due to the fact that the EPD display is inherently slow - partial update takes about 600ms, full update is about 2 seconds. Also provisions should be made to re-initialise the display from time to time (original firmware does this after 32 partial updates). But at least this is a start, I'll publish my code changes soon so someone with better experience than me can step in.

from atc_mithermometer.

@znanev here you are.
b0e28c6e5932bba59fb19290e626b138_upd_miaomiaoce.sensor_ht.h1.bin.zip

from atc_mithermometer.

@michapr Here you are:

https://github.com/znanev/ATC_MiThermometer

Pushed my changes related to the EPD driver. Please note that due to the way the EPD display works, there are busy waits, halting the CPU for up to 6 seconds when initialising and up to 2 seconds when doing a full update. This makes the BLE connections to "hang" sometimes, so if you have troubles flashing to another (or the original) firmware via OTA, please be sure that you are prepared to do this via SWS. I couldn't connect via BLE after my first iteration of changes, that's why I changed the update interval to 12 seconds in the main loop (so the EPD can be updated and the CPU can have some time to "take a breath").

from atc_mithermometer.

Thank you, with the help of that i was able to Emulate that thermometer and get the right Model name

Model is: miaomiaoce.sensor_ht.h1

but unfortunately there is no update file available as i already guessed :-/ so waiting for the hardware is needed :D

from atc_mithermometer.

Indeed this is the case, I confirmed it with the logic analyser, it's also visible in the Excel spreadsheet above - SPI is 9-bit ;)

I couldn't identify the manufacturer of the display or its particular driver IC however. Traversing the datasheets of different IC manufacturers, I was able to confirm that most of the "backbone" commands are the same - like 0x00, 0x02, 0x04 etc.). Also I suspect that commands 0x20, 0x23, 0x24, 0x25 and 0x26 just load static tables for the waveforms. It will be command 0x18 that will need more attention in order to decipher the segments mapping:

(picture is not mine - it comes from this repo.

from atc_mithermometer.

Ah, no probs, it was just a heads up so you don't do the same again and lose time in the process ;)

from atc_mithermometer.

@apaperclip I personally don't own LYWSDCGQ, but have its "successor" - CGG1 (round body with e-ink display). Haven't opened it yet, but its turn will come soon, for sure!

Meanwhile I have good news about MHO-C401's display - I was able to capture all necessary communication from the MCU and have setup a quick proof of concept project using Wemos Mini (ESP8266 based board). I managed to map all the segments, so will publish my finding soon. Stay tuned!

from atc_mithermometer.

@apaperclip Thanks for those links, I haven't encountered those OEM versions, but by the looks of it the first one is not MHO-C401, but its "dumber" version - MHO-C201. I owned 3 of them and functionally are the same as MHO-C401, but lack any "smart" features like BLE. Indeed Celsius and Fahrenheit can be changed by that recessed button, but it's easier to just use the App to do this for the BLE-enabled devices.

The CGG1 device (manufatured by Qingping Technology (Beijing) Co., Ltd) seems to be registered with FCC:

https://fccid.io/2AQ3F-CGG1

I couldn't identify the ICs from the FCC photos, but if anyone is interested, I can make a teardown of my device.

from atc_mithermometer.

@znanev the CGG1 SOC is definitely an nRF51 or nRF52 looking at the parts around it and the significant label on it

so custom firmware is possible, just needs to be developed^^

Also it has an external SPI flash, but that not important.

from atc_mithermometer.

@atc1441 Just pushed the missing files, reformatted the Readme and added more details about the reverse-engineering of the MHO-C401's display: https://github.com/znanev/MHO-C401.

Give me a shout if/when you need more information about MHO-C401's display, I'd be happy to help :)

from atc_mithermometer.

@znanev I know this github projekt.
I'm using OpenMQTTGateway and RPIEasy - that's why the integration of advertising data would be more simple here, even for other users ;)

Thank you, will wait, maybe the alternative firmware will be available in future ;)

from atc_mithermometer.

The .py script is unfortunately only one way so only data can be pushed from the PC to the MCU but not in the other direction.
ComSwireReader825x.py
https://github.com/pvvx/TlsrComSwireWriter

from atc_mithermometer.

Wooow very nice :)

from atc_mithermometer.

... (@znanev -- did you have any luck with getting yours opened up?).

@kelchm Mine is still intact, working with its original firmware. Haven't tried opening it up yet, as its MCU is nRF and I have no experience with those. But looking forward at the grim reality of long lasting lockdown(s) in the UK, I might as well dig into at least driving the EPD :) So your photo of all segments lit might come handy some day...

from atc_mithermometer.

Good to see there is another one with the TLSR8251 the Mosquito repellent has an TLSR8261 so its a bit different.

The .py script is unfortunately only one way so only data can be pushed from the PC to the MCU but not in the other direction.

However it is possible to use this https://github.com/pvvx/TlsrTools or this tool https://github.com/pvvx/TlsrComProg to dump the flash of an TLSR8266 that one does not have the same SWS protocol so one aditional byte needs to be send like in my script.

Ordered one of the MHO-C401 to get into it when its here but it takes a while

It should also be possible to intercept the web requests when its asking for a new firmware and get the flash that way. can you please send me what data is in the BLE characteristics maybe its possible to emulate the MHO-C401 and i can get the update file for you

from atc_mithermometer.

Thanks for this info, will look into the links that you provided!

Following are screenshots of all characteristics and their values of MHO-C401 sensor:

I couldn't find a way to get this information as plain text, hope the screenshots are fine?

from atc_mithermometer.

Thank you that does help, can you maybe as well send me one of the Advertising data packets?

The app does recognize the Model that way.

But as your firmware is 1.0.0 its very unlikely that there is one on Xiaomi servers :-(
when i receive mine will definitely dump the firmware

from atc_mithermometer.

Yeah, being a new device, that was exactly my thought - that there won't be a new firmware on Xiaomi's servers.

Anyway, here is a raw dump of two advertisements (some 15-20 minutes apart):

0x0201060F1695FE305887038937445338C1A40809094D484F2D43343031
0x0201060F1695FE305887039337445338C1A40809094D484F2D43343031

In fact this new device is quite similar (regarding BLE) to LYWSD03MMC - I added support for MHO-C401 to mitemp_bt custom component for Home Assistant a couple of weeks back, you can see details about the device ID and capabilities here.

from atc_mithermometer.

Thanks for trying that out, though!

I'll wait for the firmware dump before trying to upload anything to my device. But my curiosity gets bigger with the hour, so I might ping you again when I start playing with TlsrTools :)

from atc_mithermometer.

Oh great. Do you own one ? @vevsvevs

from atc_mithermometer.

Looks like the server only gives back update files if you fully added one to your account

from atc_mithermometer.

Flashed that file to one of the LYWSD03MMC and it does fully work except the LCD of course. so temperature and humidity is showing in the mi home app, and activation worked as expected.
So that means the I2C pins are on the same as the LYWSD03MMC.

@znanev can you maybe make some more picture including the back to trace some routes a bit more

Thank you @vevsvevs that way its already possible to reverse it a bit

from atc_mithermometer.

Activation and flashing did directly worked with the Web Flasher, so in theory its no problem to flash a custom firmware, if one exists.

will do a logic analyzer run to get infos about the display controlling

it still not showing an update file even with the fully registered device, wondering where the file comes from :)

from atc_mithermometer.

@znanev here you are.
b0e28c6e5932bba59fb19290e626b138_upd_miaomiaoce.sensor_ht.h1.bin.zip

Wow, thanks a ton, @vevsvevs !

@atc1441 Here's the back of the PCB:

I might try to flash it tomorrow with the firmware that @vevsvevs provided. I have another MHO-C401 ordered, so could sacrifice one for... research purposes ;)

from atc_mithermometer.

Just chiming back in to report, that I could't wait till tomorrow.. so I went ahead and flashed the custom firmware (ATC_Thermometer.bin). As expected, everything BLE-wise was working fine - I was able to read all characteristics, change values etc. The only thing not working was the display, as expected. It might be possible that the e-ink display uses SPI, or some other protocol, or just has another address if it uses I2C. I'll probably have to hold checking this out till the weekend.

Flashing back the stock firmware (thanks again, @vevsvevs !) brought the display back to life... so, I'm more than happy.

Thanks again for the wonderful work, I'll definitely dive into this deeper :)

Edit: just to confirm another observation (I saw it mentioned somewhere in this repo) - the custom firmware indeed reports the relative humidity 5% lower than the stock firmware. Is this calibration constant "hard", set at 5%, or is it somehow dependent on something else? Just curious ...

from atc_mithermometer.

Great to hear that.

The E-Ink display will be connected via spi plus busy, bs, reset and dc line. Most likely

The sensor data read in the custom firmware is simply what is comming from the sensor, so something is done by it on the stock firmware as its 5% different.
I added the offset setting in the custom firmware if someone wants to make it these 5% off again.

from atc_mithermometer.

Was able to find a software SPI function in the Firmware, and the pins also fit with the Chip pinout, so
PB7 = SPI Mosi
PD7 = SPI Clk

Also some init e-ink function is there, so most likely we will see these values again:

The first parameter of SPI pre seems to be for switching between data and command mode, but it does it via a pre clock pulse, dont know if that is correct

from atc_mithermometer.

Whoa, impressive detective work, @atc1441 !

How did you get those display functions from the dump (i.e. what is the disassembler used) ? They look too pretty, with nice symbol names :)

from atc_mithermometer.

That is with Ghidra, but renamed the variables/functions of course, its without any debug names on stock.
But looking at what registers it access it possible to get the functions reversed, also by comparing self compiled code its more easy to reverse.
Using this modul https://github.com/rgov/Ghidra_TELink_TC32

from atc_mithermometer.

@atc1441 You are waaay ahead of me! Tried the Telink-TC32 module for Ghidra, but didn't get any meaningful output, so I'm opting out from reverse engineering the original firmware :)

I hope I'll find some time during the weekend to hook some probes to the e-ink display to see what can I get. Sniffing the SPI bus with BusPirate is on my tasks list too :)

from atc_mithermometer.

Took a feew days to get into the TC32 and Ghidra

Good luck with sniffing the data :) waiting for any infos

from atc_mithermometer.

Following some poking with the logic analyser during the weekend, here are the conclusions about the display in MHO-C401:

1. The display is the same as the one used in the "dumber" version of this device - MHO-C201 (it just shows the temperature and humidity and doesn't have any radio built in). By display I mean the segmented EPD itself, without the driving IC.

2. The EPD driver ICs in MHO-C401 and MHO-C201 are however different - so are the pin assignments on the 10-pin flat flex connectors:

MHO-C201

MHO-C401

3. The protocol used to communicate with the EPD is 3-wire SPI (SPI enable - CSB, data - SDA and clock - SCL). Commands and data are denoted not by a dedicated wire (D/C as in other EPDs), but instead as first bit in the 9 bits sequence. Value of 0 denotes that following 8 bits are command byte. Value of 1 - following 8 bits are data byte. So SPI settings are as follows: Mode 0, 9-bits, MSB first. So this confirms @atc1441's suspicion above and matches the disassembly of function void init_E-Ink.

4. The SPI commands and LUT data are quite different from those used in MHO-C201. I have 3 good update captures so far and intend to do much more, especially start up and full refresh.

5. Found some really nice reverse-engineering resources for MHO-C201:

   Reverse Engineering a MHO-C201
   Mostly c++ code examples

   Those gave me a good starting point and inspiration to reverse-engineer the MHO-C401 display protocol. So all credits about MHO-C201 go to those two resources above.

6. I'll upload the SPI captures later. From the 3 updates I can clearly see a pattern of LUT tables load and data load, so knowing the exact commands meaning won't be necessary as long as it is clear how the segments are mapped in the data bytes. By the way those captures match exactly the code of init_E-Ink above. Most of the commands are the same in different EPD driver ICs implementations (Power on/off sequences, some LUT loads etc.), some are quite unique to MHO-C401's driver IC (0x18 seems to be the data load command) etc.

Hope my observations so far will be a good starting point in developing an EPD driver for MHO-C401 :)

Edited to add: Link to the TLSR8251 datasheet - the IC used in MHO-C401 is the 24-pin variant:

http://wiki.telink-semi.cn/doc/ds/DS_TLSR8251-E_Datasheet%20for%20Telink%20BLE+IEEE802.15.4%20Multi-Standard%20Wireless%20SoC%20TLSR8251.pdf

from atc_mithermometer.

These are some very nice infos. cool.

I didn't even knew the C201 does not have Bluetooth, good i didn't bought one

Still waiting for mine

EDIT:

As the 9th bit is indeed for D/C here is also the spi_send_pre function from the stock firmware.

from atc_mithermometer.

Nice disassembly of send_spi_pre !

Here I'm uploading the 3 partial display updates captures. Excel came quite handy for the initial analysis - at lest it's easy to see with a quick glance what changes and what not :)

MHO-C401-SPI-PartialUpdates-Captures.xlsx

Looking at the init_E-Ink function again, the captures confirm what is sent over SPI! I'll try capturing full display update and start up sequences later.

from atc_mithermometer.

Just found more info on the extra bit for D/C

It looks like the BS pin on that Display is pulled high so the SPI is in 3-wire SPI mode.

that means the 9th bit is just simply DC but in the SPI data.

see here at page 30 https://www.waveshare.com/w/upload/6/6a/4.2inch-e-paper-specification.pdf
so it seems to be still just normal EPD in general

The info about that is also very usefull for a different project right now so i am quite happy

from atc_mithermometer.

Ah yes sorry you did wrote it exactly that way, sorry for misunderstanding, just saw it because of the other project and that reminded me of the 9th bit here.

Reversing a 4.2" E-Paper Pricetag display a bit more right now

from atc_mithermometer.

@znanev replying here since your original comment mentioned other sensors. There is also the LYWSDCGQ, do you know if it contains the the TLSR8251? I did some searching and fcc id lookups but havent been able to find out.

There is a google sheet that maps the 4 sensors created by youtube user Chao-chao https://docs.google.com/spreadsheets/d/10qnYSn58TGHo94be__34PY7KUozqwq5Pr8S1KMtKvWY/edit#gid=934182368 I think it needs updated based on the work you guys are doing!

This has been great to follow!

from atc_mithermometer.

As far i know that one uses an nRF51 SOC. So in generall its possible to write a custom firmware but very different from this here

from atc_mithermometer.

Thank you atc1441, i dont think it would even need a custom fw based on how well it seems to work and lack of encryption but wanted to check.

Great news znanev, I'm going to order something just trying to see what I should get. Things like lack of battery on screen or via ble seems like obvious gaps but then again, if it stops working - just replace the battery. I love the eink screen of the CGG1 but the reporting times are less than ideal based on that google doc.

from atc_mithermometer.

i came across what appears to be some oem'd versions of two of the sensors. Perhaps you've seen them already. If not maybe there is some firmware, docs or fcc filings out there that could aid you.

This looks like the MHO-C401 to me https://www.amazon.com/Homidy-Hygrometer-Thermometer-Industrial-Temperature/dp/B07P6L3356/ref=sr_1_1?dchild=1&keywords=homidy&qid=1600542809&sr=8-1

This looks like the CGG1 https://www.amazon.com/Homidy-C9-Thermometer-Professional-Temperature/dp/B07WZNWWJK/ref=sr_1_19?dchild=1&keywords=humidity+bluetooth&qid=1600542959&sr=8-19

One thing that is interesting is that both can toggle C/F with a long press of the recessed button.

from atc_mithermometer.

A short teaser ;)

Display is attached to an ESP8266-based board (WeMos D1 mini), running adapted version of this code. I will publish it once I tidy it up a little, as it's all a mess now :)

from atc_mithermometer.

Perfect!

from atc_mithermometer.

@znanev the CGG1 SOC is definitely an nRF51 or nRF52 looking at the parts around it and the significant label on it

so custom firmware is possible, just needs to be developed^^

Also it has an external SPI flash, but that not important.

The CGG1 model has a horrible refresh time, so it would be great if it would have this custom firmware.

Thanks!

from atc_mithermometer.

It is more than likely that they save battery by refresh not so periodigly.

I havent ordered a CGG1 for now. Will think about doing so.

Currently i am waiting for the C401 and the Mosquito reppelent to arrive to hack

from atc_mithermometer.

Git my C401 today 👍

Unfortunately i will not have time in the next days to "hack"

But the display looks really nice

from atc_mithermometer.

@atc1441 Good, good!

I'll have to wrap what I've written so far and push it.. so you have a head start. Maybe I'll just leave the detailed process description for later..

from atc_mithermometer.

I've just pushed my findings and code to https://github.com/znanev/MHO-C401.

There are some final touches missing (segments diagram, PCB photos and data captures), but I'll update the repo in due course.

from atc_mithermometer.

Very nice library !

from atc_mithermometer.

Thanks!

Credits for the library go to https://github.com/GitJer/XiaomiMiaoMiaoCe.

That's the repo that I forked and adapted for the display of MHO-C401 :)

Hope you'll find it useful when you find some time to play with your C401 device ;)

from atc_mithermometer.

Hi,
@atc1441 is there any progress or work on a custom firmware for MHO-C401?
It would be really great! I have some such sensors - and all of them have empty battery after 2-3 months about - if make a request every 8 minutes. Get the data from advertising information (like for LYWSD03MMC ) would be really nice...
I know about the e-ink "problem", that's why asking ;)

Thank you for your work and time!

from atc_mithermometer.

Hi @michapr ,

you could use the current firmware as is, if you don't need your sensors to visualise the readings (i.e. they are in attic, cupboard etc.). The BLE part is working fine and you can use the advertising data, without the need to connect to the sensors and thus drain the battery.

from atc_mithermometer.

You can also use the activation method to get a sign key so you can use the stock firmware with advertising for now.

I havent worked on the custom firmware till now

from atc_mithermometer.

You can also use the activation method to get a sign key so you can use the stock firmware with advertising for now.

But they are only sending the temp data once every 10-15 minutes, right? If no missing any advertising...
I wanted to use it in HA, in other cases I get the data from other sensors (Z-Wave, 433MHz, BLE) very often.
That's why was thinking about new firmware.

Is it not the same case as for LYWSD03MMC ? It was working also with sign key via advertising, right? Or is here any difference I do not know?

if you don't need your sensors to visualise the readings

Sensors are room sensors - so would be nice to see the temp. That's why I choose this sensor, because of the good display.
LYWSD03MMC you cannot read in some cases.

Thanks!

from atc_mithermometer.

@michapr Check this out, regarding HA:

https://github.com/custom-components/sensor.mitemp_bt

I use this custom component in order to passively listen to advertisements sent by LYWSD02, MHO-C303 and MHO-C401. For MHO-C401 you'll just have to configure the encryptor key (Mi Bind Key). Indeed MHO-C401 advertises once every 10 minutes, but that's why there are efforts here to provide alternative firmware for it.

from atc_mithermometer.

Very nice work! If you have any (beta-) code available, tell me, I would like to have a look at it and test it, of course ;)

from atc_mithermometer.

halting the CPU for up to 6 seconds when initialising and up to 2 seconds when doing a full update

really such a long time? 6 seconds only once while starting - or also periodically?
I am wondering about the battery drain.

Thanks for the "warning" about possible failed OTA update will prepare the SWS solution then ;)

from atc_mithermometer.

The active waiting can be changed to deepsleep waiting so that is not a big dealbreaker, should also be implemented for the current custom firmware as while it shows the mac address on boot it is also draining the battery for about 6 seconds

To the sws flashing, i really wish there would be and official flasher available it goes very fast with it to test stuff.
with the uart method it is working good but also a bit slow

from atc_mithermometer.

@michapr 6 seconds is indeed while starting. Also when re-initialising the display (because it needs to do this from time to time in order to de-energise the particles, otherwise they get "stuck").

Normal (partial) update takes about 2 seconds, but it is still not working as expected - i.e. black segments are not properly cleared. It is something to do with returning form deepsleep - I noticed similar effect on my test board and will investigate this when I have some spare time.

As @atc1441 mentioned, current sleep can be changed for deepsleep and this will then have negligible effect on the battery.

from atc_mithermometer.

@atc1441 It seems that Victor (@pvvx) has implemented something like uart-based SWS flasher, but I haven't been successful in using it:

https://github.com/pvvx/TLSRPGM

All my USB-to-serial adapters are FTDI based and there is something stopping them to be used with that code. I'll have to source some PL2303 or CH430 based once and try again :)

from atc_mithermometer.

@znanev
pvvx's flasher is not compatible to TLS8251 as far i know it uses a minimal different SWS protocol( one more address byte )
I made this very simple usb to uart flasher based on his one that is compatible, if you dont know it already.
https://github.com/atc1441/ATC_MiThermometer/blob/master/ATCtelink.py

from atc_mithermometer.

@atc1441 Indeed I'm using your ATCtelink.py - it saved my a** when I soft-bricked my sensor with the first OTA flash :)

I was just exploring recent code changes in pvvx's repos and from the commit messages at least I got the impression that the code should work with 8251. Not a deal breaker for me though, as I can use the OTA flashing again, which is quite fast.. but just wanted to have some other quick options for flashing.. just in case ;)

from atc_mithermometer.

Thanks for the "warning" about possible failed OTA update will prepare the SWS solution then ;)

@michapr You can try the firmware binary from my fork - it generally works OK now. The EPD is updated correctly, firmware can be uploaded via OTA, but code is still sub-optimal. Will optimise it when I have some time.

from atc_mithermometer.

@znanev here you are.
b0e28c6e5932bba59fb19290e626b138_upd_miaomiaoce.sensor_ht.h1.bin.zip

Is this a valid backup of original firmware for C401?

BTW: while partial update unit take about 90ms energy from battery (original FW)

(take y-value/10 to get mA)

from atc_mithermometer.

b0e28c6e5932bba59fb19290e626b138_upd_miaomiaoce.sensor_ht.h1.bin.zip

Is this a valid backup of original firmware for C401?

Yep, I flashed that binary several times while comparing the communication protocol. It's safe to flash it either via OTA, or via SWS.

Can you measure an update cycle of the custom firmware? I kept the timings as close as possible to the original ones so in theory the CPU shouldn't be doing something different (apart from ATC's firmware inner workings, that is :)

Edit to add: by the way, if you are just looking at the power consumption - this is non-conclusive of the display refresh time. When turning on the charge pump via command POWER_ON (0x04), this is when the internal capacitors are loaded and a lot of energy is consumed instantaneously. The display has a BUSY_N signal, which indicates when it is ready, i.e. while updating it this signal is asserted and we can do nothing but wait for it to be freed :)

from atc_mithermometer.

one time unit = 200ms (!)

It is completely other timing...
after 4 short peaks (every 1.8 seconds - advertising) the measurement (?) is going over about 1.4 seconds.
I cannot detect any additional difference for partial update in this time.

from atc_mithermometer.

You make in every loop an "epd_write_display()" - is this needed? Or only when value was changed?

Edit: I think same for "epd_init(&c, 0);" after wakeup, maybe it is not needed if no changes to write to display?
Would save battery...

from atc_mithermometer.

@michapr Please have in mind that the only significant change that I made is replacing the LCD driver for EPD. No functionality from the "ATC" firmware is touched whatsoever.

Indeed updating the display (epd_write_display()) can be tailored better for the EPD - i.e. only update it if there is any change (digits, set / clear of some of the symbols etc.). This is currently not the case, that's why it is not implemented.

Your observation about epd_init(&c, 0) is also spot on - it is required to be invoked following wake up from deep sleep in order to initialise the peripherals, but only if an update of the display is also required.

Please feel free to propose your changes with a Pull Request :)

from atc_mithermometer.

Maybe to continue in your forked repo?

I have made some experiments, (moved the epd_write_display() to value changed condition ...) and have seen that all the long energy consuming time is related to this procedure only (see above: 1.5 seconds <-> 100ms).
You have much more experience with the EPD procedure, any idea what can be the difference here?

from atc_mithermometer.

@michapr Agree, please open an issue in the forked repo in order not to pollute this issue here :)

The difference is probably that the version that you used to measure the energy performs "busy wait":

while(condition_is_false)
  sleep_ms(1);

What this does is halting the CPU in high-energy, active state for as long as the condition is not met, i.e. in the case of updating the EPD - it waits the BUSY_N signal to be de-asserted for about 1.5 - 1.9 seconds.

Today I've changed the function sleep_ms() for cpu_stall_wakeup_by_timer0() - it should be functionally the same (waits the specified time before continuing with the following instructions), but instead of halting the CPU in active state, the CPU should "wait" while in deep sleep mode. If you have some time to spare - you can test the most recent binary from my fork to see if there is any noticeable change to the consumed energy.

from atc_mithermometer.

no, I have used the latest repo... with cpu_stall_wakeup_by_timer0() ...

Will continue at forked repo.

from atc_mithermometer.

@atc1441 - how deep is your knowledge about the CPU and their sleep states? ;)
Maybe you could check the znanev#7 ?

Thanks!

from atc_mithermometer.

This looks like the CGG1 https://www.amazon.com/Homidy-C9-Thermometer-Professional-Temperature/dp/B07WZNWWJK/ref=sr_1_19?dchild=1&keywords=humidity+bluetooth&qid=1600542959&sr=8-19

I can confirm that this is indeed a CGG1 as expected. The one I purchased earlier this week arrived with firmware version 1.1.2_0020.

I think the CGG1 is the best looking device of this type and it would definitely benefit from custom firmware given the slow reporting rate that was previously discussed in this thread.

As far as I can tell, there isn't a non-destructive way to take apart the CGG1 (@znanev -- did you have any luck with getting yours opened up?). I may end up going ahead with tearing mine down at some point here in the near future given that I haven't seen any clear photos posted of the PCB.

EDIT: here's a quick photo of all the segments available on the eink screen (hold the rear button for 8 seconds).

from atc_mithermometer.

I've managed to disassemble my CGG1 (without destroying it!) and have found that it is using an NRF52832 SoC, so definitely outside the scope of this project. 😅

I don't want to derail this thread further, but to anyone who is interested, I have created a repository kelchm/cgg1-thermometer-firmware to document my progress with the CGG1. At this point there's not much there yet beyond some quick disassembly instructions, but please check it out if you are interested in helping me dig into it further.

from atc_mithermometer.

@kelchm did you see that?
https://github.com/NZSmartie/MeshTemp

It is for the LYWSDCGQ and @NZSmartie replaced nRF51802 QFAA for a nRF51822 QFAC, but it is something for the nRF based trmp/humidity sensors.

from atc_mithermometer.

SmartGadget: nRF51822 + SHT31
nRF52832 Small CR2032 battery driven BLE beacon with Sensirion's humidity and temperature sensor
...

from atc_mithermometer.