micro-usb on radon detector - Page 1
Forum section: electronics / beginners

author: grahamW
author_rank: Newbie
timestamp: November 02, 2017, 05:19:46 pm
content: Hi all,I bought a $200 radon detector (Corentium Home by Airthings,https://airthings.com/us/home/) to monitor the radon levels in my basement prior to finishing the space. After 2 weeks of measurements, the results are boarderline. Some days the radon level is low, others it seems to spike. I noticed that it has a micro-usb connector on the case at that got me thinking about connecting the device to an arduino and logging the data for a few months. Unfortunately, the manufacturer claims "The micro-USB port on the side of the device can only be used for testing in case of technical issues." Based on this, there is no publicly available API. Of course, they also offer a higher-end device (https://airthings.com/us/plus/) for $1000 that can be connected via USB that you can use if money is no object.Does anyone have any suggestions on how to get started in determining if it is possible to download data from my 'cheap' detector?

author: ebclr
author_rank: Super Contributor
timestamp: November 03, 2017, 05:08:29 am
content: Post a picture of the PCB, will help on evaluated the possibility

author: mnisjk
author_rank: Newbie
timestamp: April 16, 2018, 02:41:32 am
content: Sorry to bump an old thread...Airthings has a "Plus" model that looks very similar but advertises USB functionality. I downloaded their Windows software for the Plus, and I noticed it installed FTDI drivers. I haven't popped off the case of the "Home" version to see if it has an FTDI chip, but perhaps this will help.

author: matteev
author_rank: Newbie
timestamp: February 27, 2019, 03:14:41 am
content: Had mine running for two years and got the low battery alarm so figured it was time to open it up. Here's a shot of the board:MCU is a Ti MSP430F4152 (http://www.ti.com/lit/ds/slas648e/slas648e.pdf). The test pads are connected to pins 11 and 10 (top row) and 21, 22, GND (bottom row). I watched them on my logic analyzer in analog and digital mode for around 500s and there weren't any state changes. 11 was low, 10 was high (2.226 +/- 0.001V), 21 was low, 22 was high (2.499V +/- 0.001V). Unit had 3 brand new AAA batteries. Plugging in to my Windows 10 laptop, changed the display to "SEr" which got my hopes up for a serial port and maybe there was but Windows didn't recognize it, claimed the device was malfunctioning. I didn't try it on linux to see if I could get any more info over USB. The right side of the PCB had a chrome plastic shield over it-you can see the outline on the board. There are no visible components other than the LCD on the backside. Hope this helps or inspires someone to do more digging in the future!One thought is that the missing uC by the micro usb is probably the FTDI chip. Might be able to look at the pinouts of those and guess which one of those pads is TX/RX and probe that on the off chance the main uC is blindly sending serial data.

author: WiredChaser
author_rank: Newbie
timestamp: May 05, 2020, 07:37:36 pm
content: Replying to old post for the Airthings Corentium Home radon detector thread. Any solutions yet? I’ve purchased one of these recently, and have the same question regarding hack to download data to my PC using the installed USB port. Does anyone think that sourcing and installing an FTDI chip will permit use of the port as one may do with their costlier model? Thanks in advance!

author: Gyro
author_rank: Super Contributor
timestamp: May 05, 2020, 09:49:54 pm
content: Impossible to say, unfortunately. It depends whether the firmware in the MCU is the same one that supports USB (well, serial by the time it's been through the FTDI chip) data.There seem to be a lot of empty footprints of unknown purpose.

author: lciummo
author_rank: Newbie
timestamp: July 24, 2023, 02:16:48 pm
content: That's a low end TI MSP430. There is a uart (check the datasheet for msp420f4152) but no usb.My guess is there may be a USB for those pads to the right of the usb connector. You might be lucky and the uart output would go to an DTFIand generate something on the micro usb.That would be my approach.You might suck out the code from the MSP430 and run it through a reverse-compiler (IDEPro) and see what's going on. Maybe there is code in there to drive to uart - maybe not.A debugging setup is fairly cheap - unknown if that chip has the ability to disable debugging and reverse engineering the code in the flash.My guess - try to FTDI on those pad, or just intercept the tx/rx lines from the MSP and run them into an external FTDI converter and see what happends.LArry

author: J0sh
author_rank: Newbie
timestamp: July 26, 2023, 05:15:36 pm
content: I actually picked up the same unit (Corentium Home) at Home Depot and was just looking online for the same answers.It makes no connection attempt when plugging it into my Windows PC, so the PCB picture makes sense that it's not populated. There's a lot of missing components there, but, after a bit of further research, I think they use the same board for the Corentium Home and the Corentium Plus units (not to be confused with the Corentium Pro unit).Here's an overview that I found of the differences between the two:https://www.radonmarketacademy.com/corentium-home-and-corentium-plus-what-are-the-differences/Other than USB support, the Corentium Plus has temperature, humidity, pressure, tilt (apparently to detect tampering during measurements), and extra memory. The only thing we care about is the USB comms, though, which should just be an FTDI IC and a few passives. All of the other pads are just for the extra sensors that we don't need.The easiest would be to get our hands on a Corentium Plus, or find a shot of the internals of one to match the missing components. Although, with all of the extra sensors missing, I wonder how different the firmware is? They do note that the USB is used during production of the Corentium Home (https://help.airthings.com/en/articles/3119869-corentium-home-can-i-use-the-usb-port-that-i-see-on-the-corentium-home). It's strange that they would populate the microUSB port at all, though, considering the cost. Perhaps because they use the same enclosure and don't want to have a gap?My oscilloscope broke so I have no way of pinging pads on the TI IC. Can any of you test to see if there's any activity on the UART pads to see if there's a chance of just populating the FTDI to get some data out of it?I was about to buy a Wave Radon unit from them to get BTLE data (I already wrote a library in Python for it), but I like having the LCD display on the unit.I'd like to record the data into Home Assistant or CSVs for trending analysis. Another alternative is to just tap the UART lines (if active) directly into an ESP8266 or something (I have a bunch and it may just fit in the enclosure) to make it send MQTT packets over WiFi, repurposing the USB port for power. I can write that software for that and share if successful.Thoughts?

author: ChrisE
author_rank: Newbie
timestamp: July 30, 2023, 06:54:49 pm
content: Hi,I've got one of these units and just cracked it open to scope some of the pins. From a cursory glance, it doesn't look there's any activity on any of the UART or SPI output/inputs. I did actually probe most of the pins, and aside from the LCD driving signals, I didn't see much of interest.There is the caveat that I reset it whilst opening it, so I'll try and again once the display has come back "online" after the inital data gathering period. If that's unsuccessful and I get some more time I might try attaching a debugger to see if the memory is accessible, but it's unlikely to be for a little while.I'm not ruling out that I've done something strange, so I'd still encourage others to have a go with a scope!Edit: I guess also, given the slow update time, I'll try and observe the TX lines when a reading is taken/updated, and on powerup/mode button press.

author: J0sh
author_rank: Newbie
timestamp: July 31, 2023, 06:01:13 am
content: I just got a new Siglent 1104X-E (now a 1204X-E, thanks to this forum) and have been checking out the board.I believe the FTDI IC is a FT230X and my PCB is less populated than Matt's - just some decoupling caps that I highlighted in light blue.I tapped some wires with the scope and haven't seen any data. I then looked into the user manual for the software of the Corentium Plus units (https://www.airthings.com/hubfs/Website/Manuals/CRA-User-Manual-English-PLUS.pdf?hsLang=en-us) and it doesn't look like the software has any real-time logging. Just historical logging. Which means that the comms must be challenge/response with an unknown protocol and there's no measurements just sent to the UART like I was hoping. At least, there doesn't appear to be.Considering that, I think I'm just going to get a Wave Radon or some other sensor. Since the Corentium Plus has no bluetooth functionality for real-time reading, and just the USB, it will only allow reading of the long-term (24 hr) measurements, going by their software, and not measurements every hour or less like I want. At least, not with the current firmware.Let me know if there's any other radon sensors you're aware of that we can look into. Other than the Wave Radon, another that I'm considering is the Ecosense RD200 which has bluetooth and ESP32/Arduino library on Github (https://github.com/romkey/esp32-arduino-ble-radoneye-rd200).

author: ChrisE
author_rank: Newbie
timestamp: October 01, 2023, 11:18:33 am
content: I persevered a little more with this, which might end up being a terrible side hobby...I'm not sure if this will be of interest or use to anyone else, but writing it out will encourage me to collect some thoughts!I scoped most of the pins and didn't see anything particularly exciting (a bunch of LCD driving signals on the pins you'd expect).I continuity tested the pads, and I think they're connected as below:The TX does seem to be high, so I figured what the heck, and soldered some headers on. Side note: I can certainly re-assemble the case, but the battery cover clip is slightly blocked so it's probably worth angling the headers, or using shorter ones/trimming if you want to do this:As J0sh figured out above, the comms does seem to be challenge/response. I figured I'd take a blunt approach to this, and just decided to hook up a random pattern generator, a logic analyser, and assault the RX with gibberish to see if something happened.A couple of things did happen:- Sometimes all the characters lit up on the display, I'm not sure if this is an error condition, or I was hitting some kind of test command.- It threw some data back at me with (I think) a bit duration of214us, so I'm assuming our baud rate is4800After staring blankly at the data for a while and trying to figure out which part of my random signal was responsible, I decided it would be easier just write a little utility to send some random bytes, or a sequence of bytes and stop when I got a response, logging the data.So far I've identified two different single byte "commands"- `0x6D` (m)- `0x77` (w)Sending either of these bytes will net you some response bytes, I'm not yet sure if the information is in any way useful, but here's a small summary of what I've seen so far.The0x77command will get you a 16 byte response:- From logging the data at different intervals, I think the message contains at least the following info:- 0) Message start, does seem to change for some reason, but not frequently, seems to initially be0x00when device is reset- 1) 0/Null- 2/3) Bytes seem to change rapidly, potentially one could be a checksum?- 4) Byte seems be0x80most of the time, maybe some kind of status?- 5) Timestamp Seconds- 6) Timestamp Minutes- 7) Timestamp Hours- 8 ) Command byte/Request Byte (0x77)- 9/10) 0/Null- 11) Seems to be0x60most of the time, but changes to0x40every ~6 seconds- 12/13) 0/Null- 14) Message length (0x10)- 15) Message terminator?0xA5Code:Message Start?,Null,?,?,Always 80?,Seconds (0-60),Minutes (0-60),Hours?,Command byte,Null,Null,?,Null,Null,Length,Terminator?0A,0,09,1F,80,39,37,0B,77,0,0,40,0,0,10,A50A,0,68,C3,80,3A,37,0B,77,0,0,60,0,0,10,A5This seems to be a sort of message footer which is also included in the response generated by the0x6Dmessage.The0x6Dcommand will get you a 128 byte response:- I haven't looked into at this one too much yet. Something to note here is that you actually get a 144 byte response back, but the first 16 bytes seem to be a repeat of the last 16 byte message footer from the previous message which I've removed in the examples below.- The last 16 bytes are a similar message footer to the above- The examples are taken from different times of day- I have seen this message be almost entirely 00s at device power up. I'm wondering if this is a serialised data structure, or a view on some device memory.Code:A5,32,33,34,35,36,37,38,39,3A,3B,3C,3D,3E,3F,40,41,42,43,44,45,46,47,48,49,4A,4B,4C,4D,4E,4F,50,51,52,53,54,55,56,57,58,59,5A,5B,5C,5D,5E,5F,60,61,62,63,64,65,66,67,68,69,6A,6B,6C,6D,6E,6F,70,71,72,73,74,75,76,77,78,79,7A,7B,7C,7D,7E,7F,80,81,82,83,84,85,86,87,88,89,8A,8B,8C,8D,8E,8F,90,91,92,93,94,95,96,97,98,99,9A,9B,9C,9D,9E,9F,A0,A1,0A,00,C4,8F,82,0E,03,01,6D,00,00,50,00,00,80,A5A5,32,33,34,35,36,37,38,39,3A,3B,3C,3D,3E,3F,40,41,42,43,44,45,46,47,48,49,4A,4B,4C,4D,4E,4F,50,51,52,53,54,55,56,57,58,59,5A,5B,5C,5D,5E,5F,60,61,62,63,64,65,66,67,68,69,6A,6B,6C,6D,6E,6F,70,71,72,73,74,75,76,77,78,79,7A,7B,7C,7D,7E,7F,80,81,82,83,84,85,86,87,88,89,8A,8B,8C,8D,8E,8F,90,91,92,93,94,95,96,97,98,99,9A,9B,06,07,08,09,0A,6D,50,00,B2,69,82,1F,06,04,6D,00,00,50,00,00,80,A5A5,B4,45,54,43,A0,40,48,3E,1B,3C,A8,39,82,37,DE,35,2C,34,70,32,E4,30,DB,2E,78,2D,28,2C,F3,2A,5A,29,22,28,12,27,C8,25,AE,24,AE,23,E6,22,71,21,DB,20,66,20,23,1F,BD,1E,EC,1D,46,1D,C5,1C,3A,1C,66,1B,F9,1A,2E,1A,E8,19,CC,19,1D,19,E8,18,AB,18,16,18,C1,17,33,17,47,17,AB,16,41,16,10,16,AD,15,8E,15,5D,15,74,15,48,15,11,15,03,15,BD,14,8F,14,AA,14,0A,00,D4,E9,82,2A,3A,0B,6D,00,00,40,00,00,80,A5A5,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,28,00,66,00,C5,00,41,01,BC,01,F1,01,40,02,D5,02,58,03,8C,03,AD,03,C6,03,89,04,8E,04,C9,04,A0,05,D5,05,75,06,73,06,DD,06,46,07,90,07,19,08,67,08,AA,08,1C,09,78,09,FE,09,3B,0A,98,0A,C7,0A,EB,0A,36,0B,97,0B,D1,0B,07,0C,70,0C,EC,0C,39,0D,8B,0D,DE,0D,0E,0E,06,0E,58,0E,9A,0E,E1,0E,0F,0F,3A,0F,0A,00,A1,A5,82,25,1A,03,6D,00,00,50,00,00,80,A5Some notes:- I'm currently collecting a large sample of the0x6Dmessages starting from a clean powerup, I'll see if anything within that piques my interest.- When I was sending it random data and the entire LCD lit up, I don't think I received a response. I'll do some more testing around this to see if I can figure out what the trigger condition is.- There may be longer commands, I might try some more systematic "random" messages.- I did go down a small rabbit hole of inspecting the CRA-SW app, and whilst I made some headway, internally it looks like it uses LabView to communicate with the device, so that'll may be a complex nut to crack. I think I did see a reference to an FT230X in there though (as J0sh thought).- I did hook up an FTDI cable, and whilst it does appear in the app, and you can click "Download data", nothing seems to appear comms wise; I suspect there's some kind of serial number/descriptor check for validity.- I'm happy to attach some of the collected data, but it's currently a bit rough and ready =D

author: Dan123456
author_rank: Regular Contributor
timestamp: October 01, 2023, 04:22:10 pm
content: Genuinely super interesting stuff mate!One of my first real electronics projects was building a Geiger counter as like prospecting / collecting radioactive minerals so this is right up my alleyKeep up the good work!I was gonna say, it might be useful to get a small piece of uranium ore to help you with your testing. That way you can sit it next to the detector and expect one value to jump which would be the radon reading (uranium decays into radon so you could expect the radon concentration to be higher when you place it next to the tester compared to background)I know it sounds kinda counter intuitive to suggest buying something radioactive when the whole point of a radon meter is to ensure you don’t come across to much radioactive gas but in all seriousness, uranium ore is actually pretty safe to handle (and some are really pretty, like Autunite)!Pretty much just don’t make a habit of sleep with it sitting on your chest every night or eating it and you will be fine (and wash your hands after touching it but that is due to uranium being treated a heavy metal in your body, not due to the radioactivity)As always, do your own research to make an informed decision rather than just trusting a random on the internet but think that would help you crack this thing wide open!

author: the-valued-customer
author_rank: Newbie
timestamp: October 02, 2023, 10:32:09 pm
content: @ChrisE So, I am also working on getting data out of the sensor, but taking the approach of reading the LCD_A pins on the back (front?) of the board. I had just assumed that the uart pins were a dead end. It seems like you'll beat me to the punch, but let me know if you want to chat maybe I can help.I am at least going to pause the work I am doing to explore the uart a bit. Thank you for posting your work.

author: MikeK
author_rank: Super Contributor
timestamp: October 02, 2023, 11:05:30 pm
content: Quote from: Dan123456 on October 01, 2023, 04:22:10 pmOr *any* smoke detector?

author: Dan123456
author_rank: Regular Contributor
timestamp: October 03, 2023, 02:10:25 am
content: Quote from: MikeK on October 02, 2023, 11:05:30 pmIndeed! The americium 241 source from an old ionising smoke detector (or more accurately “old style” compared to newer photo electric ones) probably would work! You can still find them new at the hardware store for like $10 each here in AusJust look for a little radiation symbol on the package and you will know it is ionising (plus the usually say it on the front of the box)Although, it looks like Am241 doesn’t “like” to decay to Rn as much as Uranium does. It looks like Rn is a side chain for Am241 while it is the main chain for U238.This may not matter but I’m not sure. I saw that the mentioned radon detector uses a passive diffusion chamber rather than a Geiger tube. I found a little summary on these as am not familiar with how they work and it says “ There is a photo diode located inside this chamber, which essentially counts the amount of "daughter" radon particles in the air sample”.If the passive diffusion tube can pick up all radiation (or all Alpha / beta / gamma whatever it looks for) a smoke detector would be perfect! However, if it somehow only specifically looks for radon / it’s daughter products, uranium ore might be a better bet as you should get a nice, repeatable, high reading each time you move it near the detector

author: ChrisE
author_rank: Newbie
timestamp: October 06, 2023, 10:13:19 pm
content: Haven't had a chance to explore this more yet, so not a great deal to add except for one observation that tallies with something I noticed previously.I reset the device and sent the0x6Dbyte every 30 seconds for about a day throughout the calibration procedure and beyond. When the calibration had finished, everything read 0, and continued to do so. I had previously seen my readings go down before trying this and had wondered if it was related to my pokery. I reset the device a second time and let it continue as nature intended, and have ended up with sensible readings again.If I can't make sense of the data, next step might be attaching a debugger ><@the-valued-customer: I think the LCD pins might be the sensible approach to this! Happy to provide any info I have, be delighted to hear if you make progress =D@Dan123456: I like the idea, this might slowly start to turn in to side science project. As an aside, Autunite looks great!

author: the-valued-customer
author_rank: Newbie
timestamp: October 07, 2023, 06:33:19 am
content: @ChrisE I am making some progress on the uart front. I attempted to pull apart their client a bit and found lots of cruft in their binaries relating to national instruments and the labview runtime, also msft studio refs, and maybe some other hints of their dev environment. I am working on that in-between looking at the `0x6d` messages.For the message decoding, I've kept my logger running since I last posted. In the beginning I did once a second to verify your conclusions on the `0x77` messages. Later I switched to once per 61 seconds and added a little jitter to attempt to not missing anything. I am not sure what crc16 scheme they used and am running out of things to try,but I agree about the checksum. I've tried IBM's implementation, MODBUS, and a few others but nothing is matching. I haven't gotten to a place where I want to post too much about the `0x6d` responses, in fear that I might provide incorrect information but this I'm fairly certain of: They start with a 16 byte copy of the tail of the previous message. The tail is always a `0x77` response. Sandwiched between those is a message that usually contains (I think) up to 16 variable length fields. They are labeled 00,01,..,0a. The way they achieved variable length without confusing the value for the next label is: label0, byte, label0, byte, label0, byte, label1, byte, label2, byte, label2, byte, label3, byte, etc. I haven't looked at those fields/values, but they are easy enough to decode and possibly match with something useful. Besides the variable length fields there is another optional message that shows up, it has a variable length, but seems to have a maximum length, I have no idea where to begin with it. The sandwiched message is a combination of the optional unknown message, at least two null bytes, a single unknown byte, then the variable length fields. The optional message is adjusted to the left and the variable length fields are justified to the right. The `0x6d` message is fixed length and they use null (0x00) bytes to pad to the specified length. Due to the two possible messages contained in the sandwiched portion of the `0x6d` response the padding is in the middle of those two messages. Regarding the variable length fields, labels are sequential but may have gaps, labels may be reused for different purposes, for example label 0x01 might be three bytes on some messages but only one in others.Regards the checksum: It might be a checksum but it seems hard to prove that. I hadn't done multiple requests in the same second, but on a whim I did and found messages with the same content yet different data in the supposed checksum area. I have an idea that they may mask portions of the message before sending to the uart but after calculating the checksum.If you reverse the captured messages they become more readable, with a start of frame, length, cmd, hours minutes, seconds, checksum, then newline as end of frame. It doesn't really matter, but I thought that was interesting.There may be a new command, 0x21 (exclamation mark). It seems to enter a mode after this, I haven't figured out what it wants. It doesn't seem to respond to characters. If you send 128 bytes it will exit the mode. Maybe it wants some bytes strung together. Not as interesting, but, if you send a 0x77 command after exiting, the checksum bytes become stable, they only change based on the previous 128 bytes that were sent before exiting the 0x21 command.If you connect a debugger I'd probably pause the uart stuff and get back to the LCD. I'm interested in having both the LCD prototype and uart working. For the LCD I've got all the signalling worked out and the static LCD drive pins mapped. Just need to program a mcu to do the adc. I grabbed an esp8266 b/c it has wifi and I'd like the freedom to place the detector in optimal locations. If anyone is interested I can post details on the LCD pin map. The driver is 3 mux straight from TI's LCD_A circuit. 32 pins gives 87 possible symbols, but I think the pin map has one symbol connected redundantly giving 86 symbols/segments on the LCD. The pin map is probably the most difficult part of the LCD and is complete.

author: djnebs
author_rank: Contributor
timestamp: November 09, 2023, 02:42:41 am
content: I had a msp430 launchpad laying around so I took a crack at dumping the memory.The RST and TST pins are actually flipped around from ChrisE's pic.Code:C:\ti\MSPFlasher_1.3.20>MSP430Flasher.exe -r ["D:\Downloads\msp430_radon87.dump.hex",MAIN]* -----/|-------------------------------------------------------------------- ** / |__ ** /_ / MSP Flasher v1.3.20 ** | / ** -----|/-------------------------------------------------------------------- *** Evaluating triggers...done* Checking for available FET debuggers:* Found USB FET @ HID0019:COM7 <- Selected* Initializing interface @ HID0019:COM7...done* Checking firmware compatibility:* FET firmware is up to date.* Reading FW version...done* Setting VCC to 3000 mV...done* Accessing device...done* Reading device information...done* Dumping memory from MAIN into D:\Downloads\msp430_radon87.dump.hex...done** ----------------------------------------------------------------------------* Arguments : -r [D:\Downloads\msp430_radon87.dump.hex,MAIN]* ----------------------------------------------------------------------------* Driver : loaded* Dll Version : 20409001* FwVersion : 30394216* Interface : TIUSB* HwVersion : E 2.0* JTAG Mode : AUTO* Device : MSP430F4152* EEM : Level 1, ClockCntrl 2* Read File : D:\Downloads\msp430_radon87.dump.hex (memory segment = MAIN)* VCC OFF* ----------------------------------------------------------------------------* Powering down...done* Disconnecting from device...done** ----------------------------------------------------------------------------* Driver : closed (No error)* ----------------------------------------------------------------------------*/That was easy! No jtag fuse blown. Attached the hex file.I'll take a crack at decompiling this in ghidra but I don't really know what I'm doing so maybe one of you will beat me to it.EDIT:Made some progress... Here is the RX UART ISR decompiled (poorly)Code:/* WARNING: Globals starting with '_' overlap smaller symbols at the same address */undefined8UndefinedFunction_d22c(undefined2 param_1,undefined2 param_2,undefined2 param_3,undefined2 param _4){ushort uVar1;uart_rx_byte = UCA0RXBUF;if (DAT_0374 < 0x80) {uVar1 = (ushort)DAT_0374;DAT_0374 = DAT_0374 + 1;(&uart_tx_byte) = UCA0RXBUF;goto LAB_d2f8;}if ((DAT_0374 == 0x81) || (DAT_0374 == 0x80)) {if (UCA0RXBUF == ';') {DAT_0374 = 0x81;_DAT_0372 = _tx_byte_index;_tx_byte_index = 0;goto LAB_d2f8;}if (UCA0RXBUF == 'i') {_tx_byte_index = _tx_byte_index * 2 + 1;goto LAB_d2f8;}if (UCA0RXBUF == 'o') {_tx_byte_index = _tx_byte_index * 2;goto LAB_d2f8;}if (UCA0RXBUF == '!') {DAT_0374 = 0;goto LAB_d2f8;}if (UCA0RXBUF == 'X') {if (((0xf7ff < _tx_byte_index) && (_tx_byte_index < 0xfe00)) && (_DAT_0372 == 0x281e)) {_DAT_037a = _DAT_037a | 0x800;}delay(1);goto LAB_d2f8;}}reply_to_uart_msg();LAB_d2f8:return CONCAT26(param_4,CONCAT24(param_3,CONCAT22(param_2,param_1)));}It does stuff when receiving the following characters:; i o ! XCode:void reply_to_uart_msg(void){if ((DAT_036f != 0) && (DAT_036f < 0x13)) {DAT_036f = 0x13;}_DAT_020e = _DAT_020e | 0x10;_DAT_037a = _DAT_037a | 0x4000;if ((DAT_0374 == -0x7f) || (DAT_0374 == -0x80)) {if (uart_rx_byte == 'P') {if (DAT_036f == 0xff) {DAT_036f = 0x14;return;}}else {if (uart_rx_byte == 'm') {FUN_dd4e();DAT_0374 = -0x7d;_DAT_037a = _DAT_037a | 0x1000;}else {if (uart_rx_byte != 'w') {if (uart_rx_byte != 'x') {return;}FUN_e656(_tx_byte_index,_DAT_0372);return;}FUN_dcd0();FUN_ebdc(&uart_tx_byte,&tx_byte_index,0x10);DAT_0374 = -0x7e;_DAT_037a = _DAT_037a | 0x2000;}IE2 = IE2 | 2;DAT_037e = 1;UCA0TXBUF = uart_tx_byte;}}return;}In the reply function, the characters m and w are matched and the code does some things. P and x are found in there as well.I labelled a few other subroutines based on the registers they access:Code:uart_inite69cundefined uart_init(char param_1)70reply_to_uart_msgd834undefined reply_to_uart_msg(void)168read_adcdf8eundefined read_adc(short samples_to_avg)108MAIN_LOOPe8caundefined MAIN_LOOP(void)52main_loopcb1aundefined2 main_loop(ushort param_1, ushort param_2)308lcd_initea7aundefined lcd_init(void)30INITd3d2undefined INIT(void)176gpio_initdffaundefined gpio_init(void)104delayeb7aundefined delay(short param_1)20compute_checksum?e9baundefined compute_checksum?(byte * param_1, short param_2)42clock_inite930undefined clock_init(void)50adc_initeaccundefined adc_init(void)24CRC16 function:Code:void crc16(byte *param_1,short param_2){ushort crc;short sVar1;crc = 0;if (param_2 != 0) {do {crc = crc ^ (ushort)*param_1 << 8;sVar1 = 8;do {if ((short)crc < 0) {crc = crc * 2 ^ 0x1021;}else {crc = crc * 2;}sVar1 = sVar1 + -1;} while (sVar1 != 0);param_1 = param_1 + 1;param_2 = param_2 + -1;} while (param_2 != 0);}return;}This is about as far as I got. Might keep digging later.

author: ChrisE
author_rank: Newbie
timestamp: November 15, 2023, 10:43:34 pm
content: That's great! Looks like I might have goofed the image when scribbling stuff down.I've been busy for a while so I haven't had a chance to poke this further, but I do have a small amount of IDA experience, looks like it's time to give Ghidra a whirl!

author: djnebs
author_rank: Contributor
timestamp: November 15, 2023, 10:52:43 pm
content: Attached the ghidra archive. I managed to label a bunch of things, mostly based on the registers they access. Random other things like memcopy, delays, flash writing functions, ISRs.The structure for arranging the input and output uart data is still not clear to me.I was thinking to try hook up gdb to ghidra and do some live debugging to sort out the missing pieces. Seeing live memory while stepping through the code as it recieves a UART packet would be huge.Nebi

author: cb831a
author_rank: Contributor
timestamp: November 17, 2023, 05:28:23 pm
content: Quote from: ChrisE on October 01, 2023, 11:18:33 am6s seems to be exactly the frequency between the shifts of "1" day / "7" days display.Could it be that 9/10 and 12/13 are the actual readings and 11 indicates if one of them is 1 or 7 day avg ?The 0's could be due to the device being recently reset and hence is building up averages before displaying the values.When you reset the device the readings are blank for some hours before displaying anything.Quote from: ChrisE on October 01, 2023, 11:18:33 amIs the logic normal TTL 3.3V ?Would it be possible to directly attach a standard USB2TTL converter ?Great work BTW :-)

author: cb831a
author_rank: Contributor
timestamp: November 18, 2023, 04:33:44 pm
content: Quote from: cb831a on November 17, 2023, 05:28:23 pmI now have 3 wires coming out of the device and connected them an USB2TTL 3.3V and my ZOC terminal in hex mode can repro the aboveThe protocol is not fully stable - sending w/m sometimes returns ...E3 73 E3 73... gibberish (I think)Quote from: cb831a on November 17, 2023, 05:28:23 pmUnfortunately the 9/10 and 12/13 stays zero despite my device has been running for 447 days (soldered it without disconnecting).I also see that the 11 can have other values than 60/40 . I also see 64/44 - I think it is related to the 1/7 display and maybe also the heartbeat dot in the upper right corner of the display.Some observationsByte 0/1 of the w-package should be seen as a little-endian 16bit int.- Sending i changes the value by left-shifting a 1 into the int.- Sending o changes the value by left-shifting a 0 into the int.- Sending ; clears the value.Executing w command keeps the value of the intExecuting m will and int with FF80 if already initialized to FFxxByte 2/3 is not checksum - pressing two times w in rapid succession, I can receive two packages with same content and different checksum.Sending P shows "SEr 66 9" on the display for 20 seconds. Same message as when you connect the USB port or press the mode button on the back.

author: djnebs
author_rank: Contributor
timestamp: December 03, 2023, 03:12:10 am
content: I did not have much luck with live GDB connection. However I realized the MSP flasher tool can also dump RAM (previously I was only dumping flash).New plan:Throughout the day, dump the RAM periodically and record the "short term average" value of the LCD as it changes for each dump.Use this command to do it unintrusively without resetting the device every time:Code:MSP430Flasher.exe -a -n MSP430F4152 -z  -r ["D:\Downloads\msp430_fulldump.hex",0x0000-0xffff]Collect a bunch of these dumps (say 10 of them) and then diff them offline to find the RAM location that is changing and identify where the LCD value is stored.Then maybe figure out if/how that location maps to one of the uart return structures.Ultimately, I wanted to put a esp32 inside this and IOTify it.Worst case, if the uart path doesn't pan out, maybe I can bitbang spy bi wire protocol inside esp32 and read the ram location directly

author: djnebs
author_rank: Contributor
timestamp: December 06, 2023, 06:07:53 am
content: The short term average number on the LCD can be found at 2 addresses in RAM: 0x36c and 0x3e4I see that 0x36c is also incremented during boot time calibration so I will consider it a "LCD display value" used for general display purposes, rather than the internal representation of radon count.I have the metric version of this device in becquerels/m3 integer units. I don't know how they represent the floating point value in the american version. Considering it is not an american developed product and the fact that becquerels can be represented in integer form rather than float, makes me think that they would track everything internally in becquerels.I could not find any references to the other address 0x3e4 in the code so that one is still a mystery.Long term average value interestingly does not show up in RAM but rather in a FLASH address. I don't know why its different than the short term average value. Flash makes sense to store a slow moving number. On the other hand, the whole device resets itself after losing power, so I don't really understand the point of storing this in flash.Anyway, back to the short term average number... the 0x36c address is written to in a few places in the code, which I eventually narrowed down to this bit:Code:void FUN_e6e2(void){ushort uVar1;ushort local_4;local_4 = 0x18;uVar1 = FUN_d614(0x30,(ushort)&local_4);short_term_avg1 = get_becquerels_per_m3(0x360,uVar1,0,1,(undefined *)0x10b8,local_4);DAT_021c = uVar1;return;}Deciphering inside that function was beyond my skills.I tried tracing things backwards to the ADC reading. I know the function which reads the ADC10MEM register. That data must eventually propagate from ADC to the short term average reading. But there is many layers of math in between. You can imagine stuff like scaling, unit conversion, applying factory cal coefficients, boot time cal coefficients.... all sorts of possibilities.Next I checked the UART speaking functions. One can expect the short term average (or possibly the instantaneous value) to be reported inside one of the structures transmitted in UART.The protocol overall is still very unclear to me but it appears there are 2 data exfiltration functions:m command handler: can dump 128 bytes starting from RAM address 0x370. it can also set the RTC clock.w command handler: checks for CRC match, then writes stuff to FLASH if it matches. returns 16bytes read starting from RAM address 0x370Presumably there is a big struct located at 0x370 and it holds all the good stuff that you guys were trying to decipher earlier.As far as I can tell, neither of these routines have a CRC check for returning data, only for consuming data.My lcd display value 0x36c is not included in that range.No luck here.EDIT: 0x3e4 (that other ram address holding the short term average) IS actually included in the 128 byte range output by UART. It is byte 116 out of 128 in the 'm' command.I bet there is a path to trace back the get_becquerels_per_m3() function to the device's raw internal form. I bet that raw form value is also accessible from the 128 bytes dumped from 0x370. I just could not find itIt wouldn't be too hard to binary patch the UART routine to spit out the lcd value instead of whatever 128 bytes it currently gives, but this feels like cheating and I don't see much value in it.What do you guys think?

author: cb831a
author_rank: Contributor
timestamp: December 06, 2023, 01:16:30 pm
content: Cool work @djnebsI'm pretty deep into Ghidra as well but I haven't had time to write down a summary of my conclusions yet :-(I only have the c000-ffff dump above. Is it possible you could post your work until now, then I will correlate and try to merge - it seems you have analyzed from a different angle than me which is good as our result may complement each other.I have some conclusions that does not agree with your findings based on my initial study, and comparing to your analysis I can hopefully eliminate some of my errors before summarizing here.So if possible I would like to see both your full 0000-FFFF dump and your Ghidra analysis.Thanks

author: djnebs
author_rank: Contributor
timestamp: December 06, 2023, 07:38:29 pm
content: Great! I was hoping someone else would have a look at reversing it. I'm very new to this.Attached 3 memory dumps from 0-0xffff.First value in the filename is the long term average and second number is the short term average, as read from LCD when I took the dump.Let us know what you find.Added my latest ghidra archive. I never pulled in the new RAM contents, still just working off the flash dump.

author: ChrisE
author_rank: Newbie
timestamp: December 06, 2023, 10:46:07 pm
content: This is some great work!I managed to spend some time on one weekend poking through the dissassembly from scratch to see if I came up with similar conclusions. I got a reasonable way in (not as much useful info as has been provided here) but have hit a very busy spell and haven't had a chance to get back into it; hopefully I'll get some time over Christmas.On the plus side, I've actually ended up working on a project with an MSP430, so hopefully I'll be getting some helpful insights from that =D

author: djnebs
author_rank: Contributor
timestamp: December 06, 2023, 11:00:28 pm
content: I also found my past experience with MSP430 came in handy when digging into this. You really gotta know how to engineer before you can reverse engineer.I just realized that the short term average value (0x3e4) IS in fact dumped as part of the 'm'/0x6D command.It "should" be byte 116 out of 128 - havent actually tested it.Here is the relevant section where it memcopies 128 bytes from 0x370 to the UART buffer (same buffer is used for tx and rx it seems):Code:void m_command_handler(void){if ((short)DAT_0370 < 0) {if (((ushort)DAT_0370 & 0x4000) == 0) {if (((ushort)DAT_0370 & 0x1200) == 0) {if (((ushort)DAT_0370 & 0x2000) != 0) {set_RTC_clock();}goto LAB_ddb4;}if (((ushort)DAT_0370 & 0x1000) == 0) {DAT_0370 = (uint16_t *)((ushort)DAT_0370 & 0x280);}else {DAT_0370 = (uint16_t *)((ushort)DAT_0370 & 0x1080);}}else if (DAT_0370 < &DAT_f000) {DAT_0370 = (uint16_t *)&DAT_1080;}else {DAT_0370 = (uint16_t *)((ushort)DAT_0370 & 0xff80);}memcopy(&bidirectional_tx_rx_buffer_02e0.adc_reading,DAT_0370,128);}LAB_ddb4:length_bytes = crc16((byte *)&bidirectional_tx_rx_buffer_02e0,0x80);return;}

author: cb831a
author_rank: Contributor
timestamp: December 07, 2023, 02:43:42 pm
content: Thanks @djnebsThis was exactly one of the things I dissagreed on :-)

author: djnebs
author_rank: Contributor
timestamp: December 08, 2023, 05:06:12 am
content: I'm just gonna keep dumping my daily progress here to stay motivated.Earlier I said that the 'm' command was memcopying 128 bytes from 0x370. Turns out, 0x370 holds a pointer to the data, its not a fixed location.Lets name 0x370 as "UART_PTR".There's this little bit shifting interface to set the address of UART_PTR, one bit at a time using ascii characters (which @cb831a also noticed earlier):Code:if (last_rx_byte == 'i') {UART_PTR = (uint16_t *)((short)UART_PTR * 2 + 1);goto LAB_d2f8;}if (last_rx_byte == 'o') {UART_PTR = (uint16_t *)((short)UART_PTR * 2);goto LAB_d2f8;}'i' represents a 1'o' represent a 0Seems we are to take whatever address that we want to read, encode it into binary, program it in using these 'i's and 'o's and then the 'm' command should dump out 128 bytes starting from it.I see some address sanitization which could be blacklisting certain address ranges.Similarly, 'w' looks to be the equivalent write command which includes a crc check, but otherwise writes the to the same address.I strongly suspect '!' and ';' are either some kind of terminator or preamble character, but so far I could not make sense of it in practice.The 'X' command lets you execute code from certain specified addresses. First checks the crc for a magic key 0x281e, then sets a flag to the main loop.Code:if (last_rx_byte == 'X') {if ((((uint16_t *)0xf7ff < UART_PTR) && (UART_PTR < s_bU5OYI_C_>~9_490_+_'_$[_s_z_q_fe00)) &&(crc_to_test == (uint16_t *)0x281e)) {DAT_037a = DAT_037a | 0x800;}delay2(1);goto LAB_d2f8;}The main loop detects the flag and executes instructions from that location:Code:void main(void){byte bVar1;init();do {bVar1 = IE1;IE1 = bVar1 | 0x32;if ((DAT_037a & 0x800) != 0) {IE1 = 0;IE2 = 0;FUN_ec8e(8);(*(code *)((ushort)UART_PTR & 0xfffe))();}delay2(500);} while( true );}I guess it could be a bootloader.

author: cb831a
author_rank: Contributor
timestamp: December 08, 2023, 01:31:17 pm
content: Just a quick comment: The specs for the device saysRadon specificationsRadon sampling: Passive diffusion chamberDetection method: Alpha spectrometryMeasurement range:0 – 500 pCi/L0 - 9999 Bq/m³Accuracy/precision at 5.4 pCi/L / 200 Bq/m3:After 7 days ~ 10 %After 2 months ~ 5%indicating that the radon reading must be at least a 2 byte short.

author: djnebs
author_rank: Contributor
timestamp: December 09, 2023, 09:57:18 am
content: Thankfully, I don't have enough radon in my room to fill the upper byte of that shortI got the m command (memory dumper) working.1. Start with a ';' character to reset the pointer.2. For example to read from address 0xff00 (flash), convert to bin: 1111111100000000. Translate 1s/0s into 'i's/'o's and send the characters3. Send the 'm' character to execute the read command4. It will return 128bytes from your requested 0xff00 address. plus an additional 16 bytes from a constant address 0x370So the full string looks like:;iiiiiiiioooooooomI compared the output and it matches with my JTAG ram dump.The only trouble it seems is that we cannot read from just any address. There are these range limits which restrict access. The ram addresses that hold the short term average (0x36c, 0x3e4) look to be in a restricted region.Code:void m_command_handler(void){if ((short)UART_PTR < 0) {if (((ushort)UART_PTR & 0x4000) == 0) {if (((ushort)UART_PTR & 0x1200) == 0) {if (((ushort)UART_PTR & 0x2000) != 0) {set_RTC_clock();}goto LAB_ddb4;}if (((ushort)UART_PTR & 0x1000) == 0) {UART_PTR = (uint16_t *)((ushort)UART_PTR & 0x280);}else {UART_PTR = (uint16_t *)((ushort)UART_PTR & 0x1080);}}else if (UART_PTR < &DAT_f000) {UART_PTR = (uint16_t *)&DAT_1080;}else {UART_PTR = (uint16_t *)((ushort)UART_PTR & 0xff80);}memcopy((uint16_t *)&bidirectional_tx_rx_buffer_02e0,UART_PTR,128);}LAB_ddb4:crc = crc16(&bidirectional_tx_rx_buffer_02e0.field0_0x0,0x80);return;}

author: cb831a
author_rank: Contributor
timestamp: December 10, 2023, 01:33:18 am
content: @djnebsCould you post some of your 128+16 bytes m-commands. I don't see the same as you but it may because my io; is different - I don't seem to get anything consistent out of changing the number.Here are some of my readings - _____ is instead of e3 73 which seems to be some kind of filler.Code:Debug: 4800 8N1 <- [86 25 65 25 2e 28 95 29 09 2b 7a 2c 56 2e b4 2f fd 30 40 32 7f 33 2c 35 bc 36 c5 37 4a 39 40 3a c6 3b ed 3c 47 3e 50 3f c2 40 ec 41 4a 43 99 44 2a 46 68 47 a6 48 fa 49 2d 4b 40 4c d3 4d 3b 4f 0b 50 5e 51 dc 52 03 54 2a 55 b6 56 00 58 41 59 17 5a 09 5b 93 5c d2 5d 9a 5e 25 60 af 61 42 63 b2 64 67 65 87 66 ac 67 d4 68 0a 6a 87 6b a8 6c ba 6d 21 6f 6d 70 ab 71 ad 72 db 73 _____ _____ 00 00 39 c1 82 0d 35 10 6d 00 00 50 00 00 80 a5 ]Debug: 4800 8N1 <- [63 1d 17 1e 93 20 e6 21 97 23 1b 25 ea 26 d0 27 fa 28 0f 2b 46 2c 87 2d 2b 2f 10 30 e0 31 0e 33 9a 34 c9 35 b9 36 f6 37 b3 39 c7 3a 54 3c 85 3d 84 3e ea 3f 59 41 8f 42 ec 43 1f 45 45 46 92 47 be 48 de 49 80 4b 9e 4c f1 4d 25 4f 64 50 07 52 17 53 5e 54 a2 55 cb 56 9d 57 98 58 20 5a 4a 5b 6f 5c e2 5d f6 5e 31 60 84 61 b3 62 19 64 5a 65 44 66 13 67 ec 68 25 6a 56 6b 79 6c 88 6d 0c 6f 00 00 4e af 82 0e 35 10 6d 00 00 50 00 00 80 a5 ]Debug: 4800 8N1 <- [30 19 40 1a 88 1c 87 1d 1d 1f 90 20 35 22 9f 23 a5 24 2e 26 69 27 35 29 45 2a ce 2b f8 2c b1 2e 04 30 5d 31 9d 32 e5 33 45 35 99 36 f0 37 80 39 4f 3a 9e 3b 14 3d 90 3e e9 3f 17 41 5d 42 3c 43 94 44 aa 45 30 47 54 48 db 49 84 4a e7 4b 97 4c 58 4e 83 4f 33 50 c5 51 3a 53 a0 54 35 56 1d 57 36 58 2f 59 ca 5a 40 5c 90 5d 4b 5e 9b 5f ca 60 f0 61 f8 62 56 64 54 65 fe 66 04 68 3d 69 67 6a 00 00 9e 73 _____ _____ _____ _____ _____ _____ ]Debug: 4800 8N1 <- [_____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ 00 00 d1 db 82 11 35 10 6d 00 00 54 00 00 80 a5 ]Debug: 4800 8N1 <- [00 00 d1 db 82 11 35 10 6d 00 00 54 00 00 80 a5 _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ 00 00 71 53 82 12 35 10 6d 00 00 50 00 00 80 a5 ]Debug: 4800 8N1 <- [2e 45 ba 46 28 48 18 49 31 4a 89 4b a0 4c 26 4e 71 4f 5b 50 a0 51 1c 53 81 54 d3 55 3c 56 91 57 04 59 32 5a 65 5b 7a 5c 05 5e 99 5e cd 5f 0a 61 bc 62 9f 63 02 65 54 66 1c 67 a0 68 ab 69 1a 6b 36 6c 0b 6d 47 6e 96 6f e7 70 4c 72 7b 73 _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ 00 00 f0 8c 82 14 35 10 6d 00 00 54 00 00 80 a5 ]Debug: 4800 8N1 <- [_____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ 00 00 d1 db 82 15 35 10 6d 00 00 54 00 00 80 a5 ]Debug: 4800 8N1 <- [00 00 d1 db 82 15 35 10 6d 00 00 54 00 00 80 a5 _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ 00 00 ed e5 82 17 35 10 6d 00 00 50 40 2d 86 2e ]Debug: 4800 8N1 <- [9d 37 04 36 f4 37 b9 3a 9e 3b 36 3d 9e 3e 23 40 86 41 fb 42 32 44 bc 45 6a 47 7c 48 b6 49 75 4b 24 4c 7d 4d 59 4f 5e 50 c3 51 c2 52 27 54 0b 55 d0 56 b3 57 f5 58 45 5a 6b 5b e6 5c 61 5e 3e 5f c2 60 a6 61 50 63 6b 64 36 65 4f 66 0d 68 1c 69 6b 6a 58 6b 70 6c f9 6d 6d 6f 43 70 26 71 de 72 _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ 00 00 32 52 82 18 35 10 6d 00 00 54 00 00 80 a5 ]Debug: 4800 8N1 <- [53 23 d9 22 5b 25 22 27 4f 28 e1 29 49 2b b0 2c 35 2e 90 2f 4a 31 b5 32 9d 33 00 35 9c 36 f7 37 7b 39 73 3a 82 3b 39 3d 6c 3e e8 3f 28 41 fa 41 91 43 aa 44 f7 45 77 47 93 48 b3 49 10 4b 34 4c e3 4d 52 4f 71 50 24 51 e9 52 d1 53 83 55 98 56 46 58 07 59 0a 5a 6f 5b 6d 5c _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ 00 00 48 af 82 1a 35 10 6d 00 00 54 00 00 80 a5 ]Debug: 4800 8N1 <- [25 69 93 6a bb 6b f0 6c 8e 6e 88 6f a4 70 b1 71 e9 72 e2 73 _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ 00 00 c3 df 82 1b 35 10 6d 00 00 54 00 00 80 a5 ]Debug: 4800 8N1 <- [00 00 c3 df 82 1b 35 10 6d 00 00 54 00 00 80 a5 e9 72 e2 73 _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ 00 00 80 9f 82 1d 35 10 6d 00 00 50 00 00 80 a5 ]Debug: 4800 8N1 <- [00 00 80 9f 82 1d 35 10 6d 43 7c 44 aa 45 3a 47 9c 48 34 4a 55 4b b6 4c 37 4e 64 4f 5e 50 c2 51 21 53 45 54 c5 55 fa 56 22 58 91 59 c0 5a 2f 5c 56 5d 80 5e c9 5f 87 61 48 62 32 63 fc 64 0f 66 35 67 40 68 95 69 a4 6a 44 6c 08 6d 2e 6e 7f 6f c1 70 31 72 7d 73 _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ 00 00 bb 82 82 1e 35 10 6d 00 00 54 00 00 80 a5 ]Debug: 4800 8N1 <- [40 17 54 17 79 1a f3 1b 58 1d e7 1e 32 20 6a 21 1f 23 9d 24 18 26 81 27 ac 28 35 2a 8a 2b b9 2c 22 2e 4f 2f a0 30 ee 31 4c 33 ea 34 0a 36 3b 37 d3 38 f7 39 25 3b d4 3c c1 3d 2d 3f 1d 40 53 41 c5 42 1b 44 83 45 94 46 f3 47 17 49 2d 4a 43 4b 81 4c 15 4e 3b 4f 88 50 8e 51 d5 52 e1 53 4c 55 64 56 71 57 fc 58 49 5a 62 5b 7c 5c 01 5e d6 5e 82 60 71 61 98 62 31 64 42 65 68 66 bf 67 16 69 00 00 cb 02 82 1f 35 10 6d 00 00 54 00 00 80 a5 ]Debug: 4800 8N1 <- [00 00 cb 02 82 1f 35 10 6d 00 00 54 00 00 80 a5 1f 23 9d 24 18 26 81 27 ac 28 35 2a 8a 2b b9 2c 22 2e 4f 2f a0 30 ee 31 4c 33 ea 34 0a 36 3b 37 d3 38 f7 39 25 3b d4 3c c1 3d 2d 3f 1d 40 53 41 c5 42 1b 44 83 45 94 46 f3 47 17 49 2d 4a 43 4b 81 4c 15 4e 3b 4f 88 50 8e 51 d5 52 e1 53 4c 55 64 56 71 57 fc 58 49 5a 62 5b 7c 5c 01 5e d6 5e 82 60 71 61 98 62 31 64 42 65 68 66 bf 67 16 69 00 00 8c a4 82 21 35 10 6d 00 00 50 00 00 80 a5 ]Debug: 4800 8N1 <- [00 00 8c a4 82 21 35 2b 8e 2d 1d 2f ac 30 77 32 2a 33 a9 34 6e 36 7d 37 03 39 31 3a d3 3b d5 3c e6 3d 50 3f b8 40 d8 41 ff 42 bf 44 c3 45 ec 46 39 48 9c 49 d5 4a 04 4c 40 4d 27 4f fc 4f f5 50 30 52 8f 53 e3 54 5e 56 a7 57 e7 58 e5 59 17 5b 90 5c e6 5d e2 5e 00 60 90 61 c1 62 d1 63 b5 64 c3 65 6f 67 86 68 7b 69 ed 6a 3f 6c 61 6d d7 6e fa 6f 05 71 43 72 98 73 _____ _____ _____ _____ 00 00 f6 3a 82 22 35 10 6d 00 00 54 00 00 80 a5 ]Debug: 4800 8N1 <- [ba 23 73 24 cf 26 81 28 29 2a 63 2b cc 2c 11 2e 6b 2f 92 31 6e 32 cf 33 2c 35 54 36 fd 37 40 39 8c 3a 9e 3b f5 3c 62 3e 08 40 09 41 d0 41 66 43 c5 44 8c 45 2b 47 74 48 db 49 62 4b 77 4c 11 4e 44 4f 1e 50 9d 51 b8 52 e7 53 25 55 5e 56 87 57 66 58 ad 59 d9 5a 30 5c c2 5d bb 5e 3c 60 8d 61 6e 62 e7 63 30 65 30 66 31 67 87 68 82 69 a0 6a 45 6c 6f 6d 73 6e c0 6f d6 70 59 72 9d 73 _____ 00 00 b8 f8 82 24 35 10 6d 00 00 50 00 00 80 a5 ]Debug: 4800 8N1 <- [a3 37 92 39 87 3a 55 3c 57 3d 9c 3e 74 40 69 41 a0 42 ed 43 44 45 63 46 b1 47 12 49 49 4a 60 4b bb 4c f5 4d 56 4f 9b 50 ce 51 e8 52 64 54 cb 55 ba 56 f3 57 30 59 27 5a 59 5b 0f 5d 44 5e 72 5f 7b 60 9a 61 a3 62 fc 63 56 65 2b 66 b4 67 04 69 e9 69 6b 6b 69 6c ca 6d ee 6e 31 70 0c 71 90 72 c5 73 _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ 00 00 5a 4d 82 25 35 10 6d 00 00 54 00 00 80 a5 ]Debug: 4800 8N1 <- [26 3a 4e 38 95 3a 77 3d b4 3e f0 3f 2d 41 94 42 66 44 88 45 2d 47 65 48 03 4a ef 4a 44 4c ce 4d 2c 4f 50 50 dd 51 f5 52 1a 54 67 55 a6 56 ed 57 67 59 80 5a e1 5b b8 5c 36 5e 6d 5f b7 60 09 62 4a 63 9f 64 a9 65 ee 66 44 68 51 69 9c 6a 3b 6c 03 6d 3d 6e 65 6f bc 70 e2 71 d0 72 _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ 00 00 65 d1 82 27 35 10 6d 00 00 50 00 00 80 a5 ]Debug: 4800 8N1 <- [00 00 65 d1 82 27 35 10 6d 00 00 50 00 00 80 a5 66 44 88 45 2d 47 65 48 03 4a ef 4a 44 4c ce 4d 2c 4f 50 50 dd 51 f5 52 1a 54 67 55 a6 56 ed 57 67 59 80 5a e1 5b b8 5c 36 5e 6d 5f b7 60 09 62 4a 63 9f 64 a9 65 ee 66 44 68 51 69 9c 6a 3b 6c 03 6d 3d 6e 65 6f bc 70 e2 71 d0 72 _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ 00 00 fe 3e 82 28 35 10 6d 00 00 50 00 00 80 a5 ]Debug: 4800 8N1 <- [f0 24 cb 24 a8 27 0c 29 80 2a dd 2b 52 2d 09 2f ff 2f 45 31 8a 32 cf 33 6b 35 3a 37 7c 38 d6 39 08 3b 6d 3c a0 3d a0 3e 57 40 96 41 81 42 ac 43 fc 44 44 46 d9 47 bc 48 11 4a 61 4b a4 4c 1c 4e 2a 4f 73 50 d7 51 1b 53 da 53 66 55 b2 56 b7 57 2f 59 3d 5a 87 5b 1c 5d dc 5d 0b 5f 6c 60 aa 61 0e 63 4a 64 6d 65 a4 66 c4 67 fe 68 02 6a 80 6b 80 6c 9d 6d 26 6f 0d 70 40 71 90 72 be 73 _____ 00 00 0c 44 82 2a 35 10 6d 00 00 40 00 00 80 a5 ]Debug: 4800 8N1 <- [00 00 0c 44 82 2a 35 10 6d 00 00 40 00 00 80 a5 ff 2f 45 31 8a 32 cf 33 6b 35 3a 37 7c 38 d6 39 08 3b 6d 3c a0 3d a0 3e 57 40 96 41 81 42 ac 43 fc 44 44 46 d9 47 bc 48 11 4a 61 4b a4 4c 1c 4e 2a 4f 73 50 d7 51 1b 53 da 53 66 55 b2 56 b7 57 2f 59 3d 5a 87 5b 1c 5d dc 5d 0b 5f 6c 60 aa 61 0e 63 4a 64 6d 65 a4 66 c4 67 fe 68 02 6a 80 6b 80 6c 9d 6d 26 6f 0d 70 40 71 90 72 be 73 _____ 00 00 fd 0e 82 2b 35 10 6d 00 00 50 00 00 80 a5 ]Debug: 4800 8N1 <- [05 2c 65 2c f3 2e 30 30 ba 31 18 33 9f 34 f7 35 98 37 e1 38 10 3a 45 3b 0d 3d 32 3e 41 3f 03 41 27 42 7b 43 8b 44 f2 45 1c 47 a7 48 6e 49 bc 4a 76 4c 29 4d 72 4e e1 4f df 50 6d 52 58 53 9b 54 50 56 55 57 02 58 da 59 05 5b 2e 5c 3d 5d 7b 5e bb 5f c7 60 00 62 0b 63 76 64 8c 65 8f 66 c2 67 09 69 37 6a e8 6b e6 6c d5 6d 18 6f 89 70 8f 71 ef 72 d6 73 _____ _____ _____ _____ _____ _____ 00 00 16 1e 82 2c 35 10 6d 00 00 54 00 00 80 a5 ]Debug: 4800 8N1 <- [_____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ 00 00 d1 db 82 2e 35 10 6d 00 00 54 00 00 80 a5 ]Debug: 4800 8N1 <- [aa 3b b8 39 60 3b 27 3e b4 3f 31 41 5a 42 19 44 31 45 fb 46 2a 48 d2 49 c2 4a 08 4c 2a 4d a0 4e ea 4f 27 51 85 52 df 53 0e 55 2a 56 3b 57 5f 58 45 5a 11 5b 69 5c bd 5d ee 5e 0c 60 9d 61 83 62 1c 64 7c 65 4d 66 bc 67 15 69 3a 6a 84 6b bf 6c 93 6d 33 6f 35 70 72 71 87 72 a4 73 _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ 00 00 90 a8 82 2f 35 10 6d 00 00 54 00 00 80 a5 ]Debug: 4800 8N1 <- [00 00 90 a8 82 2f 35 10 6d 00 00 54 00 00 80 a5 31 45 fb 46 2a 48 d2 49 c2 4a 08 4c 2a 4d a0 4e ea 4f 27 51 85 52 df 53 0e 55 2a 56 3b 57 5f 58 45 5a 11 5b 69 5c bd 5d ee 5e 0c 60 9d 61 83 62 1c 64 7c 65 4d 66 bc 67 15 69 3a 6a 84 6b bf 6c 93 6d 33 6f 35 70 72 71 87 72 a4 73 _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ 00 00 22 78 82 31 35 10 6d 00 00 50 00 00 80 a5 ]Debug: 4800 8N1 <- [00 00 22 78 82 31 35 10 6d 00 00 50 00 00 80 a5 31 45 fb 46 2a 48 d2 49 c2 4a 08 4c 2a 4d a0 4e ea 4f 27 51 85 52 df 53 0e 55 2a 56 3b 57 5f 58 45 5a 11 5b 69 5c bd 5d ee 5e 0c 60 9d 61 83 62 1c 64 7c 65 4d 66 bc 67 15 69 3a 6a 84 6b bf 6c 93 6d 33 6f 35 70 72 71 87 72 a4 73 _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ 00 00 17 b7 82 32 35 10 6d 00 00 50 00 2c 17 2d ]Debug: 4800 8N1 <- [cf 2e 61 2d f6 2f b7 31 42 33 c2 34 73 36 d4 37 d7 38 36 3a da 3b 31 3d 2c 3e 98 3f 1e 41 20 42 78 43 cb 44 c3 45 34 47 dd 48 53 4a 84 4b 38 4c d7 4d 26 4f 41 50 c3 51 52 53 20 54 a4 55 df 56 c8 57 4a 59 4d 5a c9 5b 3e 5d 4f 5e 6f 5f 03 61 f4 61 32 63 6d 64 b2 65 3d 66 9d 67 da 68 0e 6a 53 6b b5 6c d2 6d 7f 6f b5 70 b9 71 f3 72 cf 73 _____ _____ _____ _____ _____ _____ _____ _____ 00 00 89 3f 82 34 35 10 6d 00 00 50 00 00 80 a5 ]Debug: 4800 8N1 <- [90 30 11 31 76 33 f1 34 4e 36 00 38 ba 38 38 3a ec 3b 9f 3d d2 3e 2f 40 7b 41 c3 42 2d 44 43 45 d5 46 f6 47 28 49 b6 4a 8e 4b b3 4c 3a 4e a6 4f fc 50 59 52 66 53 ad 54 e9 55 0c 57 18 58 ac 59 dc 5a 2b 5c 5a 5d d3 5e 1b 60 63 61 4e 62 79 63 cb 64 cd 65 10 67 6f 68 91 69 a3 6a cd 6b f6 6c 4e 6e a6 6f 84 70 2f 72 55 73 _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ 00 00 d4 2d 82 35 35 10 6d 00 00 54 00 00 80 a5 ]Debug: 4800 8N1 <- [5f 0c a3 0d e2 0e 9b 10 d4 11 4c 13 6c 14 c0 15 f3 16 38 18 c0 19 1f 1b 8d 1c dc 1d 0c 1f 88 20 e1 21 47 23 ca 24 2a 26 50 27 33 28 b9 29 4c 2b 5f 2c b7 2d 16 2f 08 30 86 31 ba 32 2c 34 7b 35 d5 36 2b 38 81 39 86 3a 2d 3c 20 3d 1a 3e e5 3f 00 41 34 42 98 43 b7 44 e5 45 ed 46 69 48 e7 49 e5 4a ed 4b 58 4d b4 4e db 4f b0 50 3e 52 86 53 95 54 05 56 0e 57 53 58 6b 59 d7 5a c1 5b 1b 5d 00 00 96 2b 82 37 35 10 6d 00 00 50 00 00 80 a5 ]Debug: 4800 8N1 <- [00 00 96 2b 82 37 35 10 6d 00 00 50 00 00 80 a5 f3 16 38 18 c0 19 1f 1b 8d 1c dc 1d 0c 1f 88 20 e1 21 47 23 ca 24 2a 26 50 27 33 28 b9 29 4c 2b 5f 2c b7 2d 16 2f 08 30 86 31 ba 32 2c 34 7b 35 d5 36 2b 38 81 39 86 3a 2d 3c 20 3d 1a 3e e5 3f 00 41 34 42 98 43 b7 44 e5 45 ed 46 69 48 e7 49 e5 4a ed 4b 58 4d b4 4e db 4f b0 50 3e 52 86 53 95 54 05 56 0e 57 53 58 6b 59 d7 5a c1 5b 1b 5d 00 00 da b4 82 38 35 10 6d 00 00 50 00 00 80 a5 ]Debug: 4800 8N1 <- [ac 4d 57 4f 64 50 2c 51 be 52 17 54 2c 55 5f 56 ad 57 c5 58 00 5a 46 5b 74 5c 89 5d a6 5e 56 60 3b 61 40 62 bf 63 d8 64 15 66 13 67 38 68 30 69 7c 6a 7f 6b df 6c 68 6e 6b 6f 63 70 d5 71 0e 73 d8 73 _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ 00 00 f8 b2 82 39 35 10 6d 00 00 54 00 00 80 a5 ]Debug: 4800 8N1 <- [0a 33 af 34 c7 35 1c 37 67 38 cf 39 a1 3a 5b 3c 6a 3d 71 3e 66 3f 0c 41 2d 42 36 43 88 44 bd 45 e9 46 44 48 55 49 c3 4a b9 4b ed 4c fa 4d 47 4f 61 50 8c 51 ff 52 42 54 58 55 ba 56 b7 57 77 58 25 5a 78 5b d7 5c 47 5e 35 5f 80 60 7e 61 6b 62 d0 63 3e 65 0b 66 b2 67 cc 68 d2 69 fd 6a 4b 6c c2 6c 02 6f 28 70 c1 70 4e 72 4f 73 _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ 00 00 46 23 82 3b 35 10 6d 00 00 54 00 00 80 a5 ]Debug: 4800 8N1 <- [54 23 67 23 34 26 a9 27 f6 28 8a 2a 05 2c 43 2d a8 2e db 2f 68 31 8b 32 ce 33 5e 35 6b 36 ad 37 76 39 85 3a fd 3b 76 3d 56 3e eb 3f f6 40 30 42 bd 43 d4 44 13 46 70 47 aa 48 b1 49 1e 4b 63 4c 9e 4d 10 4f 11 50 70 51 8c 52 85 53 c7 54 31 56 64 57 1f 59 02 5a 01 5b 3d 5c c4 5d e3 5e 44 60 8e 61 5d 62 d8 63 db 64 eb 65 e3 66 54 68 7b 69 af 6a 25 6c 46 6d ac 6e a7 6f 18 71 ff 71 7c 73 00 00 97 92 82 00 36 10 6d 00 00 54 00 00 80 a5 ]

author: djnebs
author_rank: Contributor
timestamp: December 10, 2023, 04:10:23 am
content: Here's my dump from 0xff00. You'll find it matches the same contents as my hex files from before. This region is flash and it seems to be unchanging.The 16 byte region from 0x370 is quite volatile but you should always find the first 2 bytes are equal to the address you set with the ios.In all your dumps, 0x370 is reading as zero instead, not sure why.Python script:Code:import serialser = serial.Serial('/dev/ttyACM2', timeout=1, baudrate=4800)def io_address_write(addr):UART_PTR = 0addr = int('{:016b}'.format(addr)[::-1], 2) #reverse the orderfor i in range(16):if (addr >> i) & 1 == 1:ser.write(b'i')UART_PTR = UART_PTR * 2 + 1else:ser.write(b'o')UART_PTR = UART_PTR * 2#print(hex(UART_PTR))ser.read(256) #flush any remanentsaddr = 0xff00ser.write(b';')io_address_write(addr)ser.write(b'm')for idx, data in enumerate(ser.read(128)):print(hex(idx+addr), hex(data))for idx, data in enumerate(ser.read(16)):print(hex(idx+0x370), hex(data))Which returns:Code:0xff00 0xb0xff01 0x10xff02 0x90xff03 0x200xff04 0x90xff05 0x10xff06 0x90xff07 0x40xff08 0x90xff09 0x400xff0a 0xa0xff0b 0x40xff0c 0xa0xff0d 0x10xff0e 0x90xff0f 0x100xff10 0x80xff11 0x20xff12 0x70xff13 0x100xff14 0x70xff15 0x400xff16 0x80xff17 0x40xff18 0x80xff19 0x400xff1a 0x80xff1b 0x100xff1c 0x80xff1d 0x10xff1e 0x60xff1f 0x200xff20 0x60xff21 0x10xff22 0x60xff23 0x40xff24 0x60xff25 0x400xff26 0x70xff27 0x40xff28 0x70xff29 0x10xff2a 0x60xff2b 0x100xff2c 0x10xff2d 0x400xff2e 0xa0xff2f 0x200xff30 0x90xff31 0x20xff32 0x20xff33 0x400xff34 0x30xff35 0x40xff36 0x40xff37 0x40xff38 0x50xff39 0x400xff3a 0x80xff3b 0x200xff3c 0x70xff3d 0x200xff3e 0x60xff3f 0x20xff40 0xb0xff41 0x200xff42 0x40xff43 0x400xff44 0xff0xff45 0xff0xff46 0xff0xff47 0xff0xff48 0xff0xff49 0xff0xff4a 0xff0xff4b 0xff0xff4c 0xff0xff4d 0xff0xff4e 0xff0xff4f 0xff0xff50 0xc0xff51 0x00xff52 0xd0xff53 0x100xff54 0xe0xff55 0xb0xff56 0xa0xff57 0x1d0xff58 0xe0xff59 0xb0xff5a 0x00xff5b 0x1d0xff5c 0xe0xff5d 0x50xff5e 0x100xff5f 0x110xff60 0xe0xff61 0xc0xff62 0x1e0xff63 0x1f0xff64 0xe0xff65 0x100xff66 0x110xff67 0x110xff68 0xf0xff69 0xf0xff6a 0xf0xff6b 0xf0xff6c 0xe0xff6d 0xe0xff6e 0xe0xff6f 0xe0xff70 0xff0xff71 0xff0xff72 0xff0xff73 0xff0xff74 0xff0xff75 0xff0xff76 0xff0xff77 0xff0xff78 0xff0xff79 0xff0xff7a 0xff0xff7b 0xff0xff7c 0xff0xff7d 0xff0xff7e 0xff0xff7f 0xff0x370 0x00x371 0xff0x372 0x320x373 0x00x374 0x820x375 0x70x376 0x340x377 0x30x378 0x6d0x379 0x00x37a 0x00x37b 0x500x37c 0x00x37d 0x00x37e 0x800x37f 0xa5By the way, the very first address check:Code:if ((short)UART_PTR < 0)makes it so that we cannot read any address below 0x8000 using m command (apart from the 16 bytes from 0x370). So no RAM, only flash.

author: cb831a
author_rank: Contributor
timestamp: December 10, 2023, 08:24:07 pm
content: QuoteCan anyone hint me to how I get the .zip file into Ghidra. I have tried to unzip the .zip and then unzip the .gar and then try to open the .gpr file inside, but it says project not found selecting it.I can import and analyze a hex file into a fresh Ghidra project without issues, but then I need to readd all the symbols and comments again.

author: cb831a
author_rank: Contributor
timestamp: December 11, 2023, 12:20:37 am
content: I think I can now calculate the short term avg (1 day value) !!!The code reads the sensor 64 times in this code storing the values in the 2e0 bufferCode:*************************************************************** FUNCTION ***************************************************************void __stdcall FUN_df8e_ReadRadon0x40times(short param_1void <VOID> <RETURN>short R12:2 param_1undefined2 R13:2 param_2undefined2 R14:2 param_3FUN_df8e_ReadRadon0x40times XREF: FUN_d304:d324(c),FUN_d554:d57a(c),FUN_d554:d58a(c),FUN_da0a_IntPX:da26(c)df8e 0a 12 PUSH.W R10df90 0a 4c MOV.W param_1,R10df92 b2 d0 30 BIS.W #0x30,&DAT_01b0_ADC10CTL000 b0 01df98 b2 d0 03 BIS.W #0x3,&DAT_01b0_ADC10CTL000 b0 01LAB_df9e XREF: dfa2(j)df9e a2 b2 b0 01 BIT.W #4,&DAT_01b0_ADC10CTL0dfa2 fd 27 JEQ LAB_df9edfa4 1f 42 b4 01 MOV.W &DAT_01b4_ADC10MEM,R15dfa8 3c 40 64 00 MOV.W #0x64,param_1dfac b0 12 66 eb CALL #FUN_eb66 undefined FUN_eb66()LAB_dfb0 XREF: dfb4(j)dfb0 a2 b2 b0 01 BIT.W #4,&DAT_01b0_ADC10CTL0dfb4 fd 27 JEQ LAB_dfb0dfb6 1f 42 b4 01 MOV.W &DAT_01b4_ADC10MEM,R15dfba 1a 83 DEC.W R10dfbc 3d 40 e0 02 MOV.W #0x2e0,param_2dfc0 3c 40 40 00 MOV.W #0x40,param_1LAB_dfc4 XREF: dfea(j)dfc4 0e 4a MOV.W R10,param_3LAB_dfc6 XREF: dfca(j)dfc6 a2 b2 b0 01 BIT.W #4,&DAT_01b0_ADC10CTL0dfca fd 27 JEQ LAB_dfc6dfcc 1f 42 b4 01 MOV.W &DAT_01b4_ADC10MEM,R15dfd0 0e 93 TST.W param_3dfd2 07 24 JEQ LAB_dfe2LAB_dfd4 XREF: dfd8(j), dfe0(j)dfd4 a2 b2 b0 01 BIT.W #4,&DAT_01b0_ADC10CTL0dfd8 fd 27 JEQ LAB_dfd4dfda 1f 52 b4 01 ADD.W &DAT_01b4_ADC10MEM,R15dfde 1e 83 DEC.W param_3dfe0 f9 23 JNE LAB_dfd4LAB_dfe2 XREF: dfd2(j)dfe2 2d 53 INCD.W param_2dfe4 8d 4f fe ff MOV.W R15,-0x2(param_2)=>DAT_02e0_uart_tx_bytedfe8 1c 83 DEC.W param_1dfea ec 23 JNE LAB_dfc4dfec a2 e3 b0 01 XOR.W #2,&DAT_01b0_ADC10CTL0dff0 b2 f0 cf AND.W #0xffcf,&DAT_01b0_ADC10CTL0ff b0 01dff6 3a 41 POP.W R10dff8 30 41 RETIf I keep reading the 2e0 buffer and consider the buffer as ushorts I sometimes get lines where the calculated checksum matches the stored ditto and none of the 64 shorts is equal 0x73e3In that case I assume the buffer is the full result of running the code above and I create the average of the 64 ushorts and divide with 200.When I average this calculation over several reads the value stabilizes and matches my 1day reading (=88).Here are the last lines of my test runCode:calc stor line avg full avgcsum csum samples in decimal cal /200 cnt avg /200---- ---- ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- ---------- -----------------1d5b 1d5b 07690 07883 08480 08919 09247 09618 10066 10396 10839 11157 11519 11980 12267 12584 12913 13313 13698 13985 14213 14634 15022 15319 15623 15904 16318 16594 16861 17201 17520 17877 18236 18545 18923 19294 19472 19849 20160 20422 20809 21024 21426 21802 22054 22418 22652 23001 23292 23668 24026 24246 24511 24835 25193 25522 25837 26194 26429 26824 27116 27477 27788 28030 28344 28654 avg 18558 92,0 00663 17608 88,00b227 b227 00320 58000 12674 03865 00109 21504 00000 42368 10687 11073 11389 11716 12052 12362 12855 13097 13502 13857 14211 14638 14907 15282 15607 15923 16230 16635 16822 17182 17576 17891 18245 18589 18924 19131 19561 19879 20304 20534 20810 21135 21419 21718 22106 22376 22760 23017 23251 23537 23934 24269 24615 24897 25204 25634 25936 26185 26476 26845 27151 27457 27823 28030 28420 28665 avg 19580 97,0 00664 17611 88,003bd0 3bd0 00320 56273 01154 03866 00109 21504 00000 42368 10041 10303 10668 11019 11145 11522 11917 12145 12480 12873 13133 13477 13762 14056 14431 14703 14884 15317 15682 15961 16325 16566 16838 17133 17475 17758 18156 18442 18623 18947 19338 19603 19914 20229 20515 20818 21179 21472 21724 22109 22324 22598 22877 23270 23607 23861 24141 24527 24848 25047 25374 25685 25990 26284 26637 26852 avg 18159 90,0 00665 17612 88,00501a 501a 06750 06750 07435 07822 08159 08531 08860 09225 09505 09972 10258 10753 11100 11381 11737 12057 12401 12694 13067 13330 13681 14007 14455 14760 15094 15362 15659 16030 16405 16689 16914 17381 17620 17919 18293 18547 18864 19253 19520 19807 20155 20438 20661 21083 21402 21732 22002 22296 22535 22930 23219 23601 23945 24220 24610 24903 25215 25468 25745 26041 26382 26753 27018 27403 avg 17309 86,0 00666 17611 88,00f356 f356 06909 07009 07644 08041 08385 08716 09072 09381 09749 10097 10486 10874 11119 11466 11839 12131 12541 12963 13238 13534 13941 14155 14541 14904 15342 15540 15910 16189 16609 16906 17241 17476 17757 18053 18510 18740 18999 19353 19661 19975 20360 20640 21005 21364 21610 21962 22246 22530 22706 23143 23442 23803 24170 24457 24761 25082 25292 25663 25987 26212 26576 26902 27194 27606 avg 17495 87,0 00667 17611 88,0081fc 81fc 09061 08724 09365 09927 10182 10625 11046 11360 11713 12143 12451 12797 13099 13513 13921 14260 14488 14893 15210 15642 15926 16323 16574 16856 17158 17528 17861 18221 18474 18819 19158 19466 19739 20017 20355 20579 21030 21241 21564 21915 22189 22544 22867 23209 23470 23907 24138 24434 24769 25027 25332 25707 26004 26283 26755 26958 27276 27591 27874 28188 28466 28783 29080 29447 avg 19430 97,0 00668 17614 88,00caa8 caa8 08719 08734 09360 09892 10189 10637 10850 11222 11647 12036 12361 12710 13080 13361 13782 14118 14483 14807 15056 15396 15739 16034 16309 16643 17005 17411 17696 17980 18229 18538 18855 19177 19530 19834 20172 20477 20763 21132 21413 21711 22124 22364 22688 23018 23294 23637 23889 24143 24460 24846 25112 25467 25853 26040 26390 26800 27065 27423 27673 27975 28271 28628 28857 29155 avg 19254 96,0 00669 17616 88,0062b7 62b7 09069 09391 09902 10275 10693 11055 11354 11785 12129 12452 12799 13112 13418 13715 14077 14445 14781 15122 15494 15787 16096 16462 16805 17064 17485 17810 18136 18434 18736 18982 19286 19629 19907 20282 20539 20884 21146 21461 21845 22103 22396 22762 23166 23448 23737 24013 24344 24673 24979 25200 25630 25849 26199 26464 26769 26979 27339 27760 27914 28297 28545 28893 29203 29597 avg 19657 98,0 00670 17619 88,002d2c 2d2c 08474 08617 09296 09645 10045 10364 10781 11014 11411 11847 12123 12416 12821 13141 13526 13807 14174 14549 14942 15108 15455 15821 16161 16425 16775 17089 17358 17624 17951 18429 18741 18971 19312 19675 20046 20311 20552 20962 21201 21529 21788 22114 22490 22776 23098 23329 23638 23932 24253 24654 24959 25104 25474 25773 26149 26451 26743 26990 27400 27678 27919 28219 28575 28886 avg 19013 95,0 00671 17622 88,0080c5 80c5 04248 04674 05000 05293 05669 06085 06363 06722 07107 07407 07710 08105 08465 08842 09193 09477 09767 10113 10455 10830 11108 11301 11760 12073 12384 12819 13128 13424 13792 14053 14396 14775 15038 15411 15641 16173 16411 16678 17044 17276 17614 17909 18253 18407 18787 19350 19613 19894 20274 20404 20714 21146 21387 21700 21950 22322 22642 22983 23283 23563 23906 24167 24553 24898 avg 14780 73,0 00672 17617 88,0010b1 10b1 00320 32965 13698 03866 00109 21504 00000 42368 07107 07407 07710 08105 08465 08842 09193 09477 09767 10113 10455 10830 11108 11301 11760 12073 12384 12819 13128 13424 13792 14053 14396 14775 15038 15411 15641 16173 16411 16678 17044 17276 17614 17909 18253 18407 18787 19350 19613 19894 20274 20404 20714 21146 21387 21700 21950 22322 22642 22983 23283 23563 23906 24167 24553 24898 avg 15886 79,0 00673 17615 88,00da92 da92 06922 07056 07513 08030 08354 08687 09083 09502 09779 10260 10570 11024 11306 11617 11969 12280 12605 12939 13304 13627 13933 14279 14677 14893 15263 15681 15965 16265 16655 16971 17196 17568 17878 18204 18489 18778 19145 19413 19819 20219 20469 20834 21123 21405 21657 22059 22303 22609 22885 23194 23514 23881 24137 24490 24833 24999 25328 25771 26047 26320 26628 26876 27177 27466 avg 17558 87,0 00674 17615 88,00c472 c472 08982 09335 09688 10119 10555 10920 11157 11466 11821 12124 12523 12932 13146 13562 13859 14199 14541 14844 15191 15539 15809 16146 16415 16828 17092 17413 17718 17978 18521 18777 19001 19369 19586 20052 20390 20587 20885 21335 21637 22032 22230 22532 22808 23112 23444 23756 24002 24313 24708 25016 25274 25577 25978 26419 26701 26920 27243 27579 27833 28099 28618 28821 29065 29474 avg 19431 97,0 00675 17617 88,00afa2 afa2 08461 08861 09203 09475 09919 10108 10456 10917 11194 11467 11748 12097 12468 12796 13069 13295 13563 13991 14331 14660 14932 15149 15445 15839 16104 16487 16748 17094 17481 17670 18061 18369 18603 18969 19260 19549 19874 20279 20476 20811 21055 21365 21634 22037 22286 22574 22994 23226 23567 23899 24105 24471 24859 25098 25347 25678 25986 26192 26570 26876 27126 27443 27777 27996 avg 18428 92,0 00676 17619 88,003868 3868 00320 44962 03458 03867 00109 21504 00000 42368 11194 11467 11748 12097 12468 12796 13069 13295 13563 13991 14331 14660 14932 15149 15445 15839 16104 16487 16748 17094 17481 17670 18061 18369 18603 18969 19260 19549 19874 20279 20476 20811 21055 21365 21634 22037 22286 22574 22994 23226 23567 23899 24105 24471 24859 25098 25347 25678 25986 26192 26570 26876 27126 27443 27777 27996 avg 19041 95,0 00677 17621 88,006282 6282 06681 06835 07448 07852 08239 08673 08968 09324 09717 10098 10423 10712 11065 11471 11845 12179 12502 12821 13129 13463 13846 14085 14514 14852 15134 15418 15788 16211 16481 16797 17187 17449 17707 18091 18471 18713 19127 19383 19702 20062 20374 20691 21057 21303 21602 21984 22257 22590 22926 23256 23492 23869 24114 24456 24738 25077 25377 25749 26061 26320 26699 26960 27221 27549 avg 17471 87,0 00678 17620 88,00bc30 bc30 07531 07458 08132 08545 08898 09225 09645 10019 10313 10845 11086 11397 11792 12132 12529 12812 13075 13509 13846 14054 14469 14827 15150 15548 15836 16197 16545 16837 17134 17525 17759 18127 18445 18753 19124 19481 19723 20134 20433 20656 21022 21414 21664 21978 22268 22577 22891 23205 23566 23943 24151 24518 24779 25087 25504 25771 26047 26392 26682 26939 27230 27528 27888 28169 avg 18136 90,0 00679 17621 88,00fa60 fa60 09019 08898 09636 10124 10396 10782 11064 11570 11934 12212 12624 12962 13236 13612 14019 14362 14714 14955 15275 15672 16017 16350 16621 16932 17164 17641 17891 18209 18600 18851 19245 19531 19913 20214 20455 20797 21130 21429 21718 22084 22414 22692 23028 23414 23732 24057 24266 24675 24985 25288 25508 25878 26116 26459 26771 27035 27289 27723 27956 28306 28647 28868 29233 29613 avg 19559 97,0 00680 17624 88,00388c 388c 04901 05180 05580 05939 06259 06541 06925 07291 07563 07913 08199 08481 08819 09188 09456 09787 10123 10330 10874 11107 11360 11819 12138 12475 12733 13026 13298 13622 13942 14387 14637 14903 15195 15569 15843 16169 16497 16882 17013 17351 17652 18026 18370 18646 19005 19190 19543 19811 20154 20480 20922 21176 21411 21756 22075 22384 22622 22946 23379 23618 23901 24170 24490 24845 avg 14998 74,0 00681 17620 88,00df4d df4d 08283 08479 09048 09397 09722 10167 10444 10897 11241 11729 12027 12316 12650 13033 13322 13675 14005 14356 14744 15037 15432 15733 16021 16375 16682 16911 17394 17656 17962 18378 18622 18965 19254 19549 19922 20218 20444 20781 21204 21425 21778 22113 22376 22700 23011 23238 23534 23946 24229 24511 24840 25096 25391 25828 26090 26381 26771 26985 27306 27647 27917 28203 28541 28897 avg 18919 94,0 00682 17622 88,00Why the divider is 200 I don't know, but I think it is a result of self calibrating and the divider is stored somewhere.If the divider couldn't change the meter would not be able to show higher value than approx. 150 (0x73e3 reading) and it can - I have seen readings of >150 in my house long time ago.

author: djnebs
author_rank: Contributor
timestamp: December 12, 2023, 01:38:24 am
content: To import the .gar file, you can go to File->Restore Project in the project window.I see, so 0x2e0 is the location of the filtered ADC count? How are you reading the 0x2e0 location? I had convinced myself earlier that the m command could never read anything below 0x8000.Are you saying that the conversion factor to go from raw adc count to bq/m3 units was just 200 in your case? I was expecting some more complicated math there. I agree that it must be applying some calibration factors found during boot.

author: cb831a
author_rank: Contributor
timestamp: December 12, 2023, 10:29:52 am
content: Quote from: djnebs on December 12, 2023, 01:38:24 amThanksThe other day everything looked plausible, but not anymore, so I may have jumped the conclusions :-(Something weird happens the 1-day readings on the LCD on my Airthing. The numbers have dropped to a value I have never seen before (<30) and yesterday while the 1-day average was dropping the 7-day increasedAt the same time my serial readings stays almost the same (~80).It's is almost as if my extensive serial-port-reading (1 per sec) is affecting the operation of the deviceQuote from: djnebs on December 12, 2023, 01:38:24 amI think the serial transfer is always happening from 2e0. And if you set the value < 8000 nothing is copied to 2e0 meaning that you just read what is there which happens to be the working sampling buffer sometimes.Quote from: djnebs on December 12, 2023, 01:38:24 amI'm not sure - I haven't found the calibration code yet, but there is a lot of mult, div and shifts going on in part of the code. The calibration must happen ongoing so when the readings suddenly rises from 50 to 300 the scale is recalibrated.Sorry for the short reply, but I'm really pressed for time these days, but I hope I can find more time around XMas.

author: cb831a
author_rank: Contributor
timestamp: December 13, 2023, 01:35:44 am
content: It looks like I can find the long time average 91/0x5b in 0x10ba and the 7-day average 120/0x78 in 0x1090 reading flash in 0x1080.Repeating the command "; iioo oooo oooo oooo m" and verifying checksum and that DAT_0370 is actually 0x1080 in w-buffer I get a stable resultCode:Stamp checksum 1080 1082 1084 1086 1088 108a 108c 108e 1090 1092 1094 1096 1098 109a 109c 109e 10a0 10a2 10a4 10a6 10a8 10aa 10ac 10ae 10b0 10b2 10b4 10b6 10b8 10ba 10bc 10be 10c0 10c2 10c4 10c6 10c8 10ca 10cc 10ce 10d0 10d2 10d4 10d6 10d8 10da 10dc 10de 10e0 10e2 10e4 10e6 10e8 10ea 10ec 10ee 10f0 10f2 10f4 10f6 10f8 10fa 10fc 10fe w-buffer2023-12-13 01:13:39: | 1ca9 1ca9 | 01c0 8bea 015d 0094 7ba4 000d 348b 0000 0078 0a29 cb02 002b 000f 0000 fa41 0000 0ae3 0000 093e 0000 09b0 0000 0964 0000 2b7d 0000 357e 0000 1031 005b 34da 0000 0007 0004 0000 0596 1302 06b5 03a8 2a39 7fce 0004 0000 0000 8796 0001 0f21 0000 173d 0000 1dd7 0000 1619 0000 7636 0000 a16b 0000 2544 000a 27ae 0000 0243 0042 | 80 10 a9 1c 82 26 25 10 6d 00 00 50 00 00 80 a52023-12-13 01:13:41: | 1ca9 1ca9 | 01c0 8bea 015d 0094 7ba4 000d 348b 0000 0078 0a29 cb02 002b 000f 0000 fa41 0000 0ae3 0000 093e 0000 09b0 0000 0964 0000 2b7d 0000 357e 0000 1031 005b 34da 0000 0007 0004 0000 0596 1302 06b5 03a8 2a39 7fce 0004 0000 0000 8796 0001 0f21 0000 173d 0000 1dd7 0000 1619 0000 7636 0000 a16b 0000 2544 000a 27ae 0000 0243 0042 | 80 10 a9 1c 82 27 25 10 6d 00 00 50 00 00 80 a52023-12-13 01:13:42: | 1ca9 1ca9 | 01c0 8bea 015d 0094 7ba4 000d 348b 0000 0078 0a29 cb02 002b 000f 0000 fa41 0000 0ae3 0000 093e 0000 09b0 0000 0964 0000 2b7d 0000 357e 0000 1031 005b 34da 0000 0007 0004 0000 0596 1302 06b5 03a8 2a39 7fce 0004 0000 0000 8796 0001 0f21 0000 173d 0000 1dd7 0000 1619 0000 7636 0000 a16b 0000 2544 000a 27ae 0000 0243 0042 | 80 10 a9 1c 82 29 25 10 6d 00 00 50 00 00 80 a52023-12-13 01:13:47: | 1ca9 1ca9 | 01c0 8bea 015d 0094 7ba4 000d 348b 0000 0078 0a29 cb02 002b 000f 0000 fa41 0000 0ae3 0000 093e 0000 09b0 0000 0964 0000 2b7d 0000 357e 0000 1031 005b 34da 0000 0007 0004 0000 0596 1302 06b5 03a8 2a39 7fce 0004 0000 0000 8796 0001 0f21 0000 173d 0000 1dd7 0000 1619 0000 7636 0000 a16b 0000 2544 000a 27ae 0000 0243 0042 | 80 10 a9 1c 82 2d 25 10 6d 00 00 54 00 00 80 a52023-12-13 01:13:51: | 1ca9 1ca9 | 01c0 8bea 015d 0094 7ba4 000d 348b 0000 0078 0a29 cb02 002b 000f 0000 fa41 0000 0ae3 0000 093e 0000 09b0 0000 0964 0000 2b7d 0000 357e 0000 1031 005b 34da 0000 0007 0004 0000 0596 1302 06b5 03a8 2a39 7fce 0004 0000 0000 8796 0001 0f21 0000 173d 0000 1dd7 0000 1619 0000 7636 0000 a16b 0000 2544 000a 27ae 0000 0243 0042 | 80 10 a9 1c 82 32 25 10 6d 00 00 50 00 00 80 a52023-12-13 01:13:56: | 1ca9 1ca9 | 01c0 8bea 015d 0094 7ba4 000d 348b 0000 0078 0a29 cb02 002b 000f 0000 fa41 0000 0ae3 0000 093e 0000 09b0 0000 0964 0000 2b7d 0000 357e 0000 1031 005b 34da 0000 0007 0004 0000 0596 1302 06b5 03a8 2a39 7fce 0004 0000 0000 8796 0001 0f21 0000 173d 0000 1dd7 0000 1619 0000 7636 0000 a16b 0000 2544 000a 27ae 0000 0243 0042 | 80 10 a9 1c 82 36 25 10 6d 00 00 50 00 00 80 a52023-12-13 01:13:59: | 1ca9 1ca9 | 01c0 8bea 015d 0094 7ba4 000d 348b 0000 0078 0a29 cb02 002b 000f 0000 fa41 0000 0ae3 0000 093e 0000 09b0 0000 0964 0000 2b7d 0000 357e 0000 1031 005b 34da 0000 0007 0004 0000 0596 1302 06b5 03a8 2a39 7fce 0004 0000 0000 8796 0001 0f21 0000 173d 0000 1dd7 0000 1619 0000 7636 0000 a16b 0000 2544 000a 27ae 0000 0243 0042 | 80 10 a9 1c 82 39 25 10 6d 00 00 54 00 00 80 a52023-12-13 01:14:02: | 1ca9 1ca9 | 01c0 8bea 015d 0094 7ba4 000d 348b 0000 0078 0a29 cb02 002b 000f 0000 fa41 0000 0ae3 0000 093e 0000 09b0 0000 0964 0000 2b7d 0000 357e 0000 1031 005b 34da 0000 0007 0004 0000 0596 1302 06b5 03a8 2a39 7fce 0004 0000 0000 8796 0001 0f21 0000 173d 0000 1dd7 0000 1619 0000 7636 0000 a16b 0000 2544 000a 27ae 0000 0243 0042 | 80 10 a9 1c 82 00 26 10 6d 00 00 50 00 00 80 a52023-12-13 01:14:03: | 1ca9 1ca9 | 01c0 8bea 015d 0094 7ba4 000d 348b 0000 0078 0a29 cb02 002b 000f 0000 fa41 0000 0ae3 0000 093e 0000 09b0 0000 0964 0000 2b7d 0000 357e 0000 1031 005b 34da 0000 0007 0004 0000 0596 1302 06b5 03a8 2a39 7fce 0004 0000 0000 8796 0001 0f21 0000 173d 0000 1dd7 0000 1619 0000 7636 0000 a16b 0000 2544 000a 27ae 0000 0243 0042 | 80 10 a9 1c 82 02 26 10 6d 00 00 50 00 00 80 a52023-12-13 01:14:08: | 1ca9 1ca9 | 01c0 8bea 015d 0094 7ba4 000d 348b 0000 0078 0a29 cb02 002b 000f 0000 fa41 0000 0ae3 0000 093e 0000 09b0 0000 0964 0000 2b7d 0000 357e 0000 1031 005b 34da 0000 0007 0004 0000 0596 1302 06b5 03a8 2a39 7fce 0004 0000 0000 8796 0001 0f21 0000 173d 0000 1dd7 0000 1619 0000 7636 0000 a16b 0000 2544 000a 27ae 0000 0243 0042 | 80 10 a9 1c 82 06 26 10 6d 00 00 54 00 00 80 a52023-12-13 01:14:14: | 1ca9 1ca9 | 01c0 8bea 015d 0094 7ba4 000d 348b 0000 0078 0a29 cb02 002b 000f 0000 fa41 0000 0ae3 0000 093e 0000 09b0 0000 0964 0000 2b7d 0000 357e 0000 1031 005b 34da 0000 0007 0004 0000 0596 1302 06b5 03a8 2a39 7fce 0004 0000 0000 8796 0001 0f21 0000 173d 0000 1dd7 0000 1619 0000 7636 0000 a16b 0000 2544 000a 27ae 0000 0243 0042 | 80 10 a9 1c 82 0c 26 10 6d 00 00 54 00 00 80 a5

author: djnebs
author_rank: Contributor
timestamp: December 13, 2023, 07:12:07 am
content: QuoteYou are right. I understand now. I was focusing so much on the m command which memcopies to the 0x2e0 array, that I forgot there are all these direct writes everywhere to 0x2e0 as well (most look like they come from 0x1080 infoB region)If the m command fails an address check or if you dont provide it any address at all, it should skip the memcopy step and the contents will retain those direct writes as 0x2e0 gets dumped to UART.Good find on those values.Meanwhile, I took off in a side quest.I was disappointed by the address limitation of m command, I really wanted to read the full memory range so that we can read any good addresses we find later.I realized with the X (execute) command, there is really no excuse to be limitedI managed to...-craft a payload to read an arbitrary memory byte to UART-sorted out the CRC calculations-found a suitable location in flash to write to-uploaded it using w command-executed it with X commandIt seems to work! I can read the short term average address from earlier this way over UART.This is a pretty roundabout way of querying the device, but now there should be no limits.The code is here:https://github.com/ncicek/CorentiumHome-Hacking/blob/main/CorentiumHome.py

author: cb831a
author_rank: Contributor
timestamp: December 13, 2023, 11:20:32 am
content: Cool work @djnebsI'm kind of allergic to Python - but I'll manageI see quite a lot of data errors reading the device.Also sometimes the 370 address is not set correctly when io'ing data into it.Do you see the same ?

author: cb831a
author_rank: Contributor
timestamp: December 13, 2023, 02:28:57 pm
content: Just tried your code - worked in third attemptCode:C:\workSave\Airthings> python3.8.exe .\CorentiumHome.pywriting to flashcrc: 0xe0afrx_byte_idx: 129tx_byte_idx: 16flags: 0x4000reading from flashcrc: 0xe0afrx_byte_idx: 130tx_byte_idx: 128flags: 0x70000x370C:\workSave\Airthings> python3.8.exe .\CorentiumHome.pywriting to flashcrc: 0x62cerx_byte_idx: 128tx_byte_idx: 16flags: 0x4400Traceback (most recent call last):File ".\CorentiumHome.py", line 168, in <module>radon.write_to_flash(payload)File ".\CorentiumHome.py", line 87, in write_to_flashassert address == written_addressAssertionErrorC:\workSave\Airthings> python3.8.exe .\CorentiumHome.pywriting to flashcrc: 0xe0afrx_byte_idx: 129tx_byte_idx: 16flags: 0x4000reading from flashcrc: 0xe0afrx_byte_idx: 130tx_byte_idx: 128flags: 0x40000x45C:\workSave\Airthings>My reading is 69 decimal, so 0x45 is correct.Maybe the code can do more tests/repeat to ensure valid valueIs your code returning last sample or avg1day ?

author: djnebs
author_rank: Contributor
timestamp: December 15, 2023, 09:33:02 pm
content: Interesting, I'm not sure what went wrong there.Is it just the payload loading sequence that was finicky? We only have to do that once after device reboot (the device clears this region of flash during init, so payload is not persistent across resets).After you have the payload loaded, do you get any issues calling read_arbitrary_address_short() repeatedly? I was stressing this with some memory dumps and it was holding up okay.Sidenote: write_to_flash function only works once, so in order to load a different payload, need to reset the device. I tried to debug this for many hours but could never figure it out."Is your code returning last sample or avg1day ?" The 0x3e4 address read by my script is the avg1day value, same as shown on LCD.I'm still interested in finding the pre-averaged value.Where should we take this project next?Any interest in putting a ESP32 in it? Make a MQTT or ESPHome type IOT thing?I think I just want it to update faster and then log the result to a line graph.

author: cb831a
author_rank: Contributor
timestamp: December 15, 2023, 10:55:13 pm
content: Quote from: djnebs on December 15, 2023, 09:33:02 pmNo, after first read it seems stableCode:C:\workSave\Airthings> python.exe .\CorentiumHome.open portGet radonwriting to flashcrc: 0xe0afrx_byte_idx: 129tx_byte_idx: 16flags: 0x6030reading from flashcrc: 0xe0afrx_byte_idx: 130tx_byte_idx: 128flags: 0x70300x370 0xfd80 648960x372 0x281e 102700x374 0x3381 131850x376 0xe00 35840x378 0x58 880x37a 0x4830 184800x37c 0x0 00x37e 0xa510 422560x380 0x113 2750x382 0x1848 62160x384 0x221 5450x386 0x701 17930x388 0x151 3370x38a 0x2008 82000x38c 0x3082 124180x38e 0x0 00x3e0 0x24f 5910x3e2 0x1 10x3e4 0x49 730x3e6 0xc27c 497880x3e8 0xffff 655350x3ea 0xffff 655350x3ec 0xffff 655350x3ee 0xe80e 594060x3f0 0x4 40x3f2 0xcade 519340x3f4 0xffff 655350x3f6 0xffff 655350x3f8 0xffff 655350x3fa 0xffff 655350x3fc 0xe9ea 598820x3fe 0xec1a 604420x1080 0x1c3 4510x1082 0x8bea 358180x1084 0x15d 3490x1086 0x94 1480x1088 0x7ef1 324970x108a 0xd 130x108c 0x34a3 134750x108e 0x0 00x1090 0x49 730x1092 0xa2a 26020x1094 0xcf6a 530980x1096 0x2d 450x1098 0xf 150x109a 0x0 00x109c 0xfc2d 645570x109e 0x0 00x10a0 0xafc 28120x10a2 0x0 00x10a4 0x949 23770x10a6 0x0 00x10a8 0x9bb 24910x10aa 0x0 00x10ac 0x96a 24100x10ae 0x0 00x10b0 0x2b9a 111620x10b2 0x0 00x10b4 0x35cc 137720x10b6 0x0 00x10b8 0x1032 41460x10ba 0x59 890x10bc 0x33d6 132700x10be 0x0 00x10c0 0x7 70x10c2 0x4 40x10c4 0x0 00x10c6 0x596 14300x10c8 0x1302 48660x10ca 0x6b5 17170x10cc 0x3a8 9360x10ce 0x2a39 108090x10d0 0x7fce 327180x10d2 0x4 40x10d4 0x0 00x10d6 0x0 00x10d8 0x8796 347100x10da 0x1 10x10dc 0xf21 38730x10de 0x0 00x10e0 0x173d 59490x10e2 0x0 00x10e4 0x1dd7 76390x10e6 0x0 00x10e8 0x1619 56570x10ea 0x0 00x10ec 0x7636 302620x10ee 0x0 00x10f0 0xa16b 413230x10f2 0x0 00x10f4 0x2544 95400x10f6 0xa 100x10f8 0x27ae 101580x10fa 0x0 00x10fc 0x243 5790x10fe 0x42 667-day 73longterm 89Quote from: djnebs on December 15, 2023, 09:33:02 pmThat's a tricky one...Quote from: djnebs on December 15, 2023, 09:33:02 pmSame.To do 1-day/7-day averages, it needs to maintain one 24 item rolling average of 24h and another 7 entry rolling avarage for 7 days, but I found none of that.Long term is just a 64bit sum and a count.Also, browsing the entire code I find no references to 3e0..3e7, so how did you find that address. 3e8 and higher is heavily referenced ??Lastly, I still feel that accessing the device through the serial port gives me lower 1-day averages which now also have started to affect my 7-day and longterm averages.My device has been running 451 days (stored in 0x1080), and I have never seen lower values than 70 and my long time average is 89.Since I started poking around with it, my 1-day is dropped as low as 18 - which is definitely wrong.It was my impression from the code that the timer interrupt fired once every 1 sec and the raw radon value was sampled each time.But even if our heavy serial reading affects some of the reads I'm not sure how that would jeopardize the avarage ??!I also just noticed running the code to produce the above output made the long term average display alternate between 89 and bOE where the top line in E is removed. Maybe a weird way to write battery, because the battery-low symbol came on while writing this. I would use bAE (without E-topline) to indicate bAttery.Running 'w' or 'm' command does not provoke the bOt display so it's related to your short-reading-method.Quote from: djnebs on December 15, 2023, 09:33:02 pmGood question, I would love higher speed, but on the other hand radon changes slowly so a reading once every 10, 30 or 60 minute is probably fine for me and then this solution is fine. I don't think we can fit a ESP32 inside it.How would you connect ESP to the device ? Using the serial, it would probably not be much faster ?ESP also uses power. On the other hand it is wireless.You could change your code to return e.g. 64 bytes+ checksum.In that way we could read only once or twice to get the needed information.

author: cb831a
author_rank: Contributor
timestamp: December 15, 2023, 11:07:14 pm
content: BTW I tried to keep an eye on the flash in 1080 and it seems to update once a day when the h-m-s in the w-package resets to 0-0-0This is three readingsCode:upti 7day long2023-12-13 01:39:23: | 1ca9 1ca9 | 01c0 8bea 015d 0094 7ba4 000d 348b 0000 0078 0a29 cb02 002b 000f 0000 fa41 0000 0ae3 0000 093e 0000 09b0 0000 0964 0000 2b7d 0000 357e 0000 1031 005b 34da 0000 0007 0004 0000 0596 1302 06b5 03a8 2a39 7fce 0004 0000 0000 8796 0001 0f21 0000 173d 0000 1dd7 0000 1619 0000 7636 0000 a16b 0000 2544 000a 27ae 0000 0243 0042 | 80 10 a9 1c 82 16 03 11 6d 00 00 50 00 00 80 a52023-12-13 14:43:57: | 6876 6876 | 01c1 8bea 015d 0094 7d1b 000d 3493 0000 006b 0a29 350d 002c 000f 0000 fae5 0000 0aed 0000 0943 0000 09b4 0000 0968 0000 2b8f 0000 3599 0000 1032 005b 34d9 0000 0007 0004 0000 0596 1302 06b5 03a8 2a39 7fce 0004 0000 0000 8796 0001 0f21 0000 173d 0000 1dd7 0000 1619 0000 7636 0000 a16b 0000 2544 000a 27ae 0000 0243 0042 | 80 10 76 68 82 38 07 06 6d+13h/+784m != != +1 +375 +8 -13 != +1 +164 +10 +5 +4 +4 +18 +27 +1 -12023-12-14 09:51:10: | 1f9a 1f9a | 01c2 8bea 015d 0094 7d8e 000d 349b 0000 0053 0a29 2f49 002d 000f 0000 fb89 0000 0af2 0000 0945 0000 09b5 0000 0969 0000 2b91 0000 35aa 0000 1031 005a 33d7 0000 0007 0004 0000 0596 1302 06b5 03a8 2a39 7fce 0004 0000 0000 8796 0001 0f21 0000 173d 0000 1dd7 0000 1619 0000 7636 0000 a16b 0000 2544 000a 27ae 0000 0243 0042 | 80 10 9a 1f 82 0b 0f 01 6d 00 00 50 00 00 80 a5+19h/+1147m != != +1 +115 +8 -24 != +1 +164 +5 +2 +1 +1 +2 +17 +1 -1 -12023-12-15 08:37:10: | 43a6 43a6 | 01c3 8bea 015d 0094 7ef1 000d 34a3 0000 0049 0a2a cf6a 002d 000f 0000 fc2d 0000 0afc 0000 0949 0000 09bb 0000 096a 0000 2b9a 0000 35cc 0000 1032 0059 33d6 0000 0007 0004 0000 0596 1302 06b5 03a8 2a39 7fce 0004 0000 0000 8796 0001 0f21 0000 173d 0000 1dd7 0000 1619 0000 7636 0000 a16b 0000 2544 000a 27ae 0000 0243 0042 | 80 10 a6 43 82 0d 01 00 6d 00 30 54 00 00 80 a5+23h/+1400m != != +1 +355 +8 -10 != +164 +10 +4 +6 +1 +9 +34 +1 -1 -1

author: djnebs
author_rank: Contributor
timestamp: December 16, 2023, 06:23:07 am
content: QuoteI found it by diffing a few ram dumps from JTAG earlier and correlating them with the screen reading values. I also do not know the instruction that writes to it. Perhaps the destination of some larger memcopy.QuoteThat's annoying - I haven't been paying attention to notice this. Maybe some timer or counter is being shared between the UART and periodic running code. Quite unfortunate if true. I'll keep an eye out for it.Quote"bOE" displays whenever you send the X (execute) command (with correct magic key). It's outside of my payload. I was speculating X command could be intended as a bootloader to deploy firmware updates (during development perhaps). bOotloadEr? I dont know.451 days is seriously impressive!A small ESP32 board could be fitted inside the unit, sharing the battery for power, wired to the serial port. It could wake up every 10min or so from deepsleep, say the magic words to the meter to get a reading, then connect to wifi and send it so some server for logging/graphing. Seems like the next best thing to having the usb port working.I'm not caught up with the latest in IOT firmware world - seems ESPHome is popular for this sort of thing. Anyone have suggestions? The simpler, the better imo.Yes, the payload could be something more clever - anything that fits inside 128 bytes of asm. Currently it uses up 80 bytes.

author: cb831a
author_rank: Contributor
timestamp: December 16, 2023, 10:50:22 am
content: Quote from: djnebs on December 16, 2023, 06:23:07 amYes, if I can't trust the readings, I can't use it. Unless the error can be limited by only reading it 1-2-4 times a day.Quote from: djnebs on December 16, 2023, 06:23:07 amBecause of the battery change last night it is now 0 days.It is now calibrating and I will leave it alone until I got readings to see of the values gets back to "normal" meaning that the communications do affect the measurements.Quote from: djnebs on December 16, 2023, 06:23:07 amTrue, I was thinking of a prototype board, but a real appliance board doesn't take up more space than the ESP chip itself.Se still need to bring out some leads to reprogram the esp.Quote from: djnebs on December 16, 2023, 06:23:07 amI tried a lot on that on both windows and linux and freebsd, but it seems it either does not adhere to normal USB handshake or it presents itself as an unknown generic device type. I'm 100% sure that it can be used as serial port some way.

author: cb831a
author_rank: Contributor
timestamp: December 16, 2023, 05:37:46 pm
content: As I expected:After reset and recalibrating 18h the 1-day avg is back in the range 80-100 where it was before all the testing.And my post from December 11, 2023, 12:20:37 seems to be correct again.That sucks !As I readCode:************************************************************** FUNCTION*************************************************************undefined8 __stdcall FUN_ce7c_IntRTCTick1Sec (void )undefined8 R15:2,R14:2, <RETURN>FUN_ce7c_IntRTCTick1Sec XREF: ffe0 (*)ce7c 0f 12 PUSH.W R15ce7e 0e 12 PUSH.W R14ce80 0d 12 PUSH.W R13ce82 0c 12 PUSH.W R12ce84 0b 12 PUSH.W R11ce86 d2 53 75 03 INC.B &DAT_0375ce8a 5f 42 6f 03 MOV.B &DAT_036f ,R15ce8e 0f 93 TST.W R15ce90 0e 24 JEQ LAB_ceaece92 3f 80 14 00 SUB.W #0x14 ,R15ce96 28 24 JEQ LAB_cee8ce98 3f 80 eb 00 SUB.W #0xeb ,R15ce9c 2f 24 JEQ LAB_cefcce9e d2 83 6f 03 DEC.B &DAT_036fcea2 f2 90 80 CMP.B #0x80 ,&DAT_0374_SerialReadBufferIndex <------------------------00 74 03cea8 65 20 JNE LAB_cf74ceaa 32 d2 EINTceac 27 3c JMP LAB_cefcLAB_ceae XREF: ce90 (j)ceae f2 40 80 MOV.B #0x80 ,&DAT_0374_SerialReadBufferIndex00 74 03ceb4 b2 f0 ff AND.W #0xbeff ,&DAT_037abe 7a 03ceba b0 12 52 eb CALL #FUN_eb52 undefined FUN_eb52()cebe f2 43 6f 03 MOV.B #-1,&DAT_036fcec2 f2 90 10 CMP.B #0x10 ,&DAT_037900 79 03cec8 06 28 JNC LAB_ced6ceca 3c 40 0f 00 MOV.W #0xf ,R12cece 5c f2 79 03 AND.B &DAT_0379 ,R12ced2 b0 12 68 e7 CALL #FUN_e768 undefined FUN_e768()LAB_ced6 XREF: cec8 (j)ced6 c2 43 79 03 MOV.B #0,&DAT_0379ceda 3c 40 19 00 MOV.W #0x19 ,R12cede b0 12 7a eb CALL #FUN_eb7a_Loop1000xVal void FUN_eb7a_Loop1000xVal(shortcee2 b0 12 4c ec CALL #FUN_ec4c undefined FUN_ec4c()cee6 0a 3c JMP LAB_cefcLAB_cee8 XREF: ce96 (j)cee8 7c 40 80 00 MOV.B #0x80 ,R12ceec b0 12 9a ec CALL #FUN_ec9a undefined FUN_ec9a()cef0 5c 43 MOV.B #1,R12cef2 b0 12 9c e6 CALL #FUN_e69c undefined FUN_e69c()cef6 f2 40 13 MOV.B #0x13 ,&DAT_036f00 6f 03LAB_cefc XREF: ce9c (j) , ceac (j) , cee6 (j)cefc d2 b3 20 00 BIT.B #1,&P1INcf00 02 20 JNE LAB_cf06cf02 92 d3 0e 02 BIS.W #1,&DAT_020eLAB_cf06 XREF: cf00 (j)cf06 b0 12 94 c5 CALL #FUN_c594 undefined FUN_c594()cf0a b2 b0 00 BIT.W #0x400 ,&DAT_037a04 7a 03cf10 02 24 JEQ LAB_cf16cf12 b0 12 be db CALL #FUN_dbbe undefined FUN_dbbe()LAB_cf16 XREF: cf10 (j)cf16 b2 f0 ff AND.W #0xfbff ,&DAT_037afb 7a 03cf1c f2 90 3c CMP.B #0x3c ,&DAT_037500 75 03cf22 28 28 JNC LAB_cf74cf24 f2 80 3c SUB.B #0x3c ,&DAT_037500 75 03cf2a d2 53 76 03 INC.B &DAT_0376cf2e f2 90 3c CMP.B #0x3c ,&DAT_037600 76 03cf34 16 28 JNC LAB_cf62cf36 32 c2 DINTcf38 4c 43 MOV.B #0,R12cf3a b0 12 9a ec CALL #FUN_ec9a undefined FUN_ec9a()cf3e b0 12 c6 e5 CALL #FUN_e5c6 undefined FUN_e5c6()cf42 c2 43 76 03 MOV.B #0,&DAT_0376cf46 d2 53 77 03 INC.B &DAT_0377cf4a b0 12 e2 e6 CALL #FUN_e6e2_RunPerHour undefined FUN_e6e2_RunPerHour()cf4e f2 90 18 CMP.B #0x18 ,&DAT_037700 77 03cf54 04 28 JNC LAB_cf5ecf56 b0 12 90 c8 CALL #FUN_c890_RunPerDay undefined FUN_c890_RunPerDay()cf5a c2 43 77 03 MOV.B #0,&DAT_0377LAB_cf5e XREF: cf54 (j)cf5e b0 12 4c ec CALL #FUN_ec4c undefined FUN_ec4c()LAB_cf62 XREF: cf34 (j)cf62 5f 42 75 03 MOV.B &DAT_0375 ,R15cf66 5e 42 76 03 MOV.B &DAT_0376 ,R14cf6a 0e 5f ADD.W R15 ,R14cf6c 03 20 JNE LAB_cf74cf6e b1 c0 d0 BIC.W #0xd0 ,0xa (SP)00 0a 00LAB_cf74 XREF: cea8 (j) , cf22 (j) , cf6c (j)cf74 3b 41 POP.W R11cf76 3c 41 POP.W R12cf78 3d 41 POP.W R13cf7a 3e 41 POP.W R14cf7c 3f 41 POP.W R15cf7e 00 13 RETIIt will simply not count on time (DAT0_375,376,377,1080) if there are pending chars in the 2e0 buffer to be transmitted.I'm not sure how that impact the radon measurement, but stretching time will lower avg.

author: ChrisE
author_rank: Newbie
timestamp: December 16, 2023, 10:05:51 pm
content: Just catching up on the great work going on in this thread, I might actually get some time to do some more exploration myself =DQuote from: cb831a on December 13, 2023, 01:35:44 amProbably something I've missed whilst reading this through, how does the "iioo oooo oooo oooo" get you to 0x01080? That's not quite what I would have expected to send (but I might have just missed something).I can confirm from my observations what you're seeing in terms of the dropping average. I think I mentioned it in passing on the the first page, but didn't really draw enough attention to it. I had tried record data reasonably often to try and observe changes, and noticed that my average was slowly decreasing; I also did the same thing from startup whilst calibration was in progress, and even after waiting a few hours, I don't think the readings moved from 0.Going to read the thread a few more times and get my had back into this =D

author: cb831a
author_rank: Contributor
timestamp: December 16, 2023, 10:34:07 pm
content: Quote from: ChrisE on December 16, 2023, 10:05:51 pmYou will have to read the m_command_handler code mentioned in December 09, 2023, 09:57:18 am to understand that.Basically we provide a value that will copy (0x8000 bit set) and 0x4000 makes i select buffer 0x1080.Quote from: ChrisE on December 16, 2023, 10:05:51 pmGood, that my observations are not crazy.Not so good, as we cannot trust the readings.I tried since last post to only read the device once every ½h and yet my average has dropped from 90 to 61 over 3 hours - that makes no sense.Maybe we leave some state in the device that continues to affect the operation in between our reads ?!??!

author: cb831a
author_rank: Contributor
timestamp: December 17, 2023, 03:57:39 pm
content: Since my last post I let my device run without interacting with it and yet the 1-day average has kept droppeing and is now 8.I start to doubt we can get anything usable out of this project...!I consider resetting the device and let it recalibrate to normal values.Then I will read the w and m command and let it alone a day to see if that affected the readings.Next I will try to read using djnebs's script and again let it alone a day to see if that affected the readings.Maybe we can find out what is triggering the false measurements.Any other ideas ?Did anyone test some of this ?

author: cb831a
author_rank: Contributor
timestamp: December 17, 2023, 11:09:09 pm
content: It seems that just having the serialport CONNECTED to a USB2TTL3.3V makes the readings go down. When I completely disconnect they start to go up again

author: cb831a
author_rank: Contributor
timestamp: December 19, 2023, 04:56:11 pm
content: OK - without connecting the device at all, the 1-day avg. never returned to the expected ~90 value but only climbed to 60 and then back to 56.So I have now reset the device again, and when the readings look plausible I will try to connect the serial port briefly and see if that starts a decline.If not I will connect it and leave it connected without transferring any data and see if that start a decline.If not I will do a few w and m commands and see if that start a decline.If not I will try to read using djnebs' code and see if that start a decline.That will take several days, but I think we need to understand this to decide if this project is worth pursuing.I hope we will find that the error/decline is proportional to the time the serialport is physically connected.In that case we could make an ESP322/8266 project that will wake up - define IO as serial TX/RX - read the device - set IO back to not connected - and the send the data to some WiFi destination.If related to how many w/m commands is actually executed per day, we could limit the read to only 1/2/4 times a day.

author: djnebs
author_rank: Contributor
timestamp: December 20, 2023, 02:19:02 am
content: I could not find any references in the code for registers P6IN nor UCA0STAT. Therefore, I don't think the device has any way of knowing that a UART is simply hooked up unless it is receiving characters.It must be the message handlers or just random characters that is triggering this. 0x37A holds a bunch of binary flags that are written to in the UART handlers and read all over the place. It would be my first suspicion.

author: cb831a
author_rank: Contributor
timestamp: December 20, 2023, 09:02:46 am
content: Quote from: djnebs on December 20, 2023, 02:19:02 amI fully agree on your conclusions - I also noticed the mess around the 2e0 buffer.I did try to reset the int after use (;-command), but I didn't see any difference.After my reset my device now displays 80 which is plausible, so I will start testing...

author: cb831a
author_rank: Contributor
timestamp: December 21, 2023, 03:13:01 pm
content: It gets weirder - after my last reset using the "RESET" button on the back of the device - the initial calibration showed 80 which was kind of little low.But worse - without ever connecting the serial port the readings started dropping again and after dropping below 60 I reset the device again.This time, however, I did it by taking one of the batteries out for 10s and now after recalibrating again, the device seems to behave as before I started experimenting.I will let it run 1-2 days to verify and then execute my plan mentioned above.But basically it looks like we get the device into some state that is not cleared before power off-on

author: djnebs
author_rank: Contributor
timestamp: December 23, 2023, 02:11:51 am
content: Well, I can confirm that the RESET button does connect to the RST pin and its not some GPIO. There does seem to be some subtle differences between RST vs POR in MSP430 devices which I did chase down but did not turn up any leads.QuoteI didn't appreciate this earlier. I see it now, you are right.It decompiles to something like this:Code:undefined8periodic_1second_timer_isr(undefined2 param_1,undefined2 param_2,undefined2 param_3,undefined2 param_4){byte bVar1;seconds = seconds + 1;if (timer_seconds == 0) {rx_byte_idx = 128;flags = flags & 0xbeff;init_uart();timer_seconds = -1;if (0xf < DAT_0379) {FUN_e768(DAT_0379 & 0xf);}DAT_0379 = 0;delay2(0x19);FUN_ec4c();}else if (timer_seconds == 20) {FUN_ec9a(0x80);init_uart_timing('\x01');timer_seconds = '\x13';}else if ((timer_seconds != 255) && (timer_seconds = timer_seconds + -1, rx_byte_idx != 128))goto LAB_cf74;bVar1 = P1IN;if ((bVar1 & 1) == 0) {DAT_020e = DAT_020e | 1;}update_lcd?();if ((flags & 0x400) != 0) {FUN_dbbe();}flags = flags & 0xfbff;if (59 < seconds) {seconds = seconds - 60;minute = minute + 1;if (59 < minute) {FUN_ec9a(0);FUN_e5c6();minute = 0;hour = hour + 1;FUN_e6e2();if (23 < hour) {hourly_runner();hour = 0;}FUN_ec4c();}}LAB_cf74:return CONCAT26(param_4,CONCAT24(param_3,CONCAT22(param_2,param_1)));}rx_byte_idx (0x372) is set to 128 at init time and then the logic checks if it stays equal to 128 otherwise it stops timer counts and just gets stuck? Why would they program it to do that? I don't get it.I haven't checked what value rx_byte_idx ends up as after our commands have executed. There is this logic inside the tx uart isr which looks like it should be setting it to 128 after a command returns data, but I'm not certain.Code:undefined8 tx_uart_isr(undefined2 param_1,undefined2 param_2,undefined2 param_3,undefined2 param_4){byte bVar1;char cVar2;ushort _tx_buffer_idx;cVar2 = tx_buffer_idx + 1;_tx_buffer_idx = tx_buffer_idx & 0x7f;UCA0TXBUF = (&bidirectional_tx_rx_buffer_02e0.field0_0x0);tx_buffer_idx = cVar2;if (_tx_buffer_idx == 15) {if (rx_byte_idx - 0x80 < 3) {rx_byte_idx = 0x80;bVar1 = IE2;IE2 = bVar1 & 0xfd;}}else if (_tx_buffer_idx == 127) {if (rx_byte_idx == 131) {rx_byte_idx = 130;memcopy((uint16_t *)&bidirectional_tx_rx_buffer_02e0,(uint16_t *)&UART_PTR,16);}tx_buffer_idx = 0;}return CONCAT26(param_4,CONCAT24(param_3,CONCAT22(param_2,param_1)));}If this is the issue, we can certainly correct this by sending 128 bytes after we are done with our commands.A single; character! character followed by 128 characters of anything should satisfy that.

author: cb831a
author_rank: Contributor
timestamp: December 30, 2023, 02:43:33 pm
content: Late merry Christmas !My radon device has now been running >7 days meaning that it has started to alternate the 1-day and 7-day values on the display again.My Long term and 7-day averages looks reasonable around 90-100, but my short term 1-day value acts strange:In the entire 7 day timespan the 1-day value has been way lower (40-80) than the current averages (104), which makes no sense to me.Since reset, I have left the device alone - no serial communication what so ever.Could it be that the address space where we uploaded the poke-procedure to actually contained something used by the device.I assume that the power-off-reset does not change the upload buffer - and if it is not used, neither should the boot-up.However could it be that the address range contains something used during reboot to initialize something else like the calibration procedure ?If the area is not reset at boot up, the contained code could be completely wrong reference values, start values, whatever...Based on the dumps provided by djnebs earlier the upload buffer at 0xFD80 originally containsCode::10FD8000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF83:10FD9000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF73:10FDA000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF63:10FDB000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF53:10FDC000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF43:10FDD000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF33:10FDE000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF23:10FDF000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF13

author: djnebs
author_rank: Contributor
timestamp: December 31, 2023, 03:52:48 am
content: Merry Christmas cb831a!I can confirm that the 128byte region of flash at 0xfd80 is indeed erased to all 0xFs (it's typical for flash cells to clear to logic-high instead of logic-low) on every reset. I know my payload always disappears when I run a m command after reset. But now that I think about it, I don't see any refs to 0xfd80 in ghidra so I'm not sure how or where in the code this is happening.Based on this, I was pretty convinced that the poke procedure was fully reversible with a reset.The non-0xFF numbers you see in the raw hex file are just checksums or headers for each row (handy parser tool here:http://www.dlwrr.com/electronics/tools/hexview/hexview.html).It's worth pursuing the logic that clears 0xFD80 on boot to complete our understanding.

author: cb831a
author_rank: Contributor
timestamp: December 31, 2023, 02:18:41 pm
content: Quote from: djnebs on December 31, 2023, 03:52:48 amGood - I just wanted to make sure that the area was reset !I do understand the format and I read it as 128 0xff bytes :-)Quote from: djnebs on December 31, 2023, 03:52:48 amUnderstanding the full boot process would probably make us understand the entire beast :-)I'm not sure what happens to my device, but the 1-day values are jumping up and down a lot and I newer saw that before.On the other hand I don't really have a reference as I'm looking at a moving target and I don't really know what the real radon-measurement should read.Also all 3 averages seems to stabilize now around 90, so I will consider hooking the serial port up again.

author: cb831a
author_rank: Contributor
timestamp: January 01, 2024, 01:39:55 am
content: Just after my last post I connected the serial port to a USB2TTL33V and now the 1-day average has dropped from ~100 to 44.In the meantime absolutely no data have been sent or received !!Could it be that just conneting RX on the device to a TX on a USB2TTL33 will trigger some action in the code ?

author: djnebs
author_rank: Contributor
timestamp: January 02, 2024, 04:43:41 am
content: Perhaps the pin bounces and registers some noise when you connect to the USB converter? Enough for the MSP UART peripheral to register as a byte? It's a bit tricky to prove - ideally you'd need jtag dumps.Try sending;! followed by 128 bytes of any non-special character and leave the usb connected afterward. Be sure your pc is not going to any sleep mode or turning off the usb ports for power saving.See if the reading recovers.

author: cb831a
author_rank: Contributor
timestamp: January 04, 2024, 01:06:19 am
content: OK tried to hook up a repeating algorithm with this codeCode:main code in pythonser = serial.Serial('com21', timeout=1, baudrate=4800) # open serial portradon = CorentiumHome(ser)#payload = radon.read_mem_payload()#radon.write_to_flash(payload)#confirm payload was written successfully#assert radon.read_from_flash(radon.PAYLOAD_LOCATION) == payloadavg1 = radon.read_arbitrary_address_short(0x36c)avg7 = radon.read_arbitrary_address_short(0x1090)longterm = radon.read_arbitrary_address_short(0x10ba)updays = radon.read_arbitrary_address_short(0x1080)print("1-day=",avg1," 7-day=",avg7," longterm=",longterm," updays=",updays)ser.write(b";................................")ser.write(b"................................")ser.write(b"................................")ser.write(b"................................")ser.write(b"................................")wrapping powershellwhile (1){$stamp = ::Now.Tostring('o');$bytes = (.\SerialPort\bin\Debug\SerialPort.exe -cCOM21 -f1 w quit)$retries = -1do{$ok = 1$res = 1foreach ($line in python.exe .\CorentiumHome.py 2>&1){if ($line -match "AssertionError"){$ok = 0}elseif ($line -match "1-day"){$res = $line}}$retries++} while (!$ok)"$stamp $bytes $res (retries=$retries)"Start-Sleep 1800}and it ran like thisCode:C:\workSave\Airthings> .\loop.ps12024-01-03T19:03:02.5936951+01:00 00 00 f0 23 81 10 30 11 77 00 00 40 00 00 10 a5 1-day= 105 7-day= 90 longterm= 98 updays= 13 (retries=12024-01-03T19:33:14.3398364+01:00 00 00 5e bb 81 1c 12 12 77 00 00 40 00 00 10 a5 1-day= 96 7-day= 90 longterm= 98 updays= 13 (retries=0)2024-01-03T20:03:23.3557423+01:00 00 00 e3 73 e3 73 e3 73 e3 73 e3 73 e3 73 e3 73 1-day= 96 7-day= 90 longterm= 98 updays= 13 (retries=0)2024-01-03T20:33:32.3265276+01:00 00 00 d1 db 81 2e 12 13 77 00 00 44 00 00 10 a5 1-day= 93 7-day= 90 longterm= 98 updays= 13 (retries=1)2024-01-03T21:03:43.8651572+01:00 00 00 72 40 81 3a 30 13 77 00 00 40 00 00 10 a5 1-day= 93 7-day= 90 longterm= 98 updays= 13 (retries=1)2024-01-03T21:33:55.4607174+01:00 00 00 d1 db 81 09 13 14 77 00 00 44 00 00 10 a5 1-day= 91 7-day= 90 longterm= 98 updays= 13 (retries=0)2024-01-03T22:04:04.4195857+01:00 00 00 53 31 81 12 31 14 77 00 00 40 00 00 10 a5 1-day= 91 7-day= 90 longterm= 98 updays= 13 (retries=1)2024-01-03T22:34:16.0009786+01:00 00 00 b0 d9 81 1e 13 15 77 00 00 40 00 00 10 a5 1-day= 88 7-day= 90 longterm= 98 updays= 13 (retries=1)2024-01-03T23:04:27.6321434+01:00 00 00 d3 90 81 29 31 15 77 00 00 44 00 00 10 a5 1-day= 88 7-day= 90 longterm= 98 updays= 13 (retries=1)2024-01-03T23:34:39.2355073+01:00 00 00 32 34 81 35 13 16 77 00 00 44 00 00 10 a5 1-day= 86 7-day= 90 longterm= 98 updays= 13 (retries=0)2024-01-04T00:04:48.1998826+01:00 00 00 5e 0e 81 02 32 16 77 00 00 44 00 00 10 a5 1-day= 86 7-day= 90 longterm= 98 updays= 13 (retries=0)2024-01-04T00:34:57.2475481+01:00 00 00 6a 58 81 0b 14 17 77 00 00 44 00 00 10 a5 1-day= 82 7-day= 90 longterm= 98 updays= 13 (retries=0)2024-01-04T01:05:06.2101335+01:00 00 00 5a ce 81 14 32 17 77 00 00 40 00 00 10 a5 1-day= 82 7-day= 90 longterm= 98 updays= 13 (retries=1)After that the radon device diedHeatbeat in upper right corned was no longer blinking and device did not respond to pressing MODE button on the back.After 30 minutes - no change, so I had to reboot it, but pressing RESET on the back did not work.Hence I had to power reset it and it is now recalibrating.Please note that I had commented out the part of the python code that established the boot-code as it was already uploaded.Also note that the device was passing internal midnight and doing a updays++.Could it be that the hour-wrap triggered a boot-procedure reset ?Based on the display the minute-wrap code that updates the 1-day-avg did run.Other ideas?

author: cb831a
author_rank: Contributor
timestamp: January 07, 2024, 02:04:19 am
content: I repeated the experiment and the device went into bootup recalibrating at my first call to your peek procedure after internal clock passed 24h.So the conclusion must be that the 0xfd80 buffer is cleared or used for something else in the per-day-procedure.Now I reenabled your code to download the peek-code and I just passed the 24h wrap again without any weirdness.The interesting thing is now if the radon-value will keep dropping as it has done before.I'm currently sending ";" followed by 140 "." to make sure the buffer is reset, but I wondered if you really meant "!" (write buffer) instead of ";" ?Last thing, I decided to buy an Airthings Wave Plus (~$300) that allows you to read data via BLE and I setup a RPIZ0 and is successfully reading data.This allows me to have a reference when trying to establish whether the values read from the old device is good or not.The wave plus is quite nice and also reports other values:Code:Stamp StampO Co2level Humidity Pressure Radonltavg Radonstavg Temperature Voclevel----- ------ -------- -------- -------- ---------- ---------- ----------- --------2024-01-05 23.45.00 2024-01-05T23:45:00.0000000Z 851,00 21,00 1012,44 89,00 91,00 25,96 490,002024-01-05 23.48.00 2024-01-05T23:48:00.0000000Z 851,00 21,00 1012,44 89,00 91,00 25,96 490,002024-01-05 23.49.00 2024-01-05T23:49:00.0000000Z 866,00 21,00 1012,52 89,00 91,00 26,05 476,002024-01-05 23.53.00 2024-01-05T23:53:00.0000000Z 866,00 21,00 1012,52 89,00 91,00 26,05 476,002024-01-05 23.54.00 2024-01-05T23:54:00.0000000Z 884,00 21,00 1012,48 89,00 91,00 26,12 497,00::

author: djnebs
author_rank: Contributor
timestamp: January 07, 2024, 02:41:40 am
content: Good findings!I think you are right: if the 0xfd80 region was being overwritten by something internally after 24hrs, it would certainly explain your symptoms. It would likely try to execute a bad opcode and then halt the processor during the X command. The fact that the reset button didnt work, seems to support this even further.If you get a chance, maybe setup another 24 hr test, again comment out the payload writing, and run something like this:payload = radon.read_mem_payload()fd80_contents = radon.read_from_flash(radon.PAYLOAD_LOCATION)if fd80_contents != payload:print("Corruption detected!")print(fd80_contents)These will read the 0xfd80 program buffer and confirm that it is still holding it's contents. Otherwise print the new corrupted contents. I'm curious whether it's being zeroed or if it's actually writing some data there.The 24hr daily runner function is at 0xc890. I will take a closer look for anything that could be clobbering 0xfd80.It's not a showstopper if it turns out we have to reprogram the payload once every day. It might wear out the flash a bit faster but not enough to care.QuoteSorry, my mistake. Yes, it should be '!' to zero the rx_byte_idx and then send 128 bytes of any other character to count it back up to 128. That should satisfy the logic we found inside the 1 second timer ISR.Regarding your new purchase:https://en.wikipedia.org/wiki/Segal%27s_law

author: djnebs
author_rank: Contributor
timestamp: January 07, 2024, 05:48:33 am
content: I started looking closer at the measurement logic today.Originally, I imagined it would be a single analog voltage in the ADC representing the radon level. But after looking at the code, I realized it's not this way.They are actually counting discrete radon decay events and toggling a GPIO interrupt.The ADC reading is still used for the measurement but it's not directly representing the radon level. It might be some kind of calibration or compensation.In the circuit, I see a voltage multiplier to generate a high voltage. It DC biases the diffusion chamber sensor. Apparently there is a photodiode inside this thing.This GPIO interrupt looks to be incrementing a counter at 0x200 on every decay event (the very first RAM address of the device-it must be important!).They talk about the passive diffusion chamber sensor here:https://help.airthings.com/en/articles/3119759-radon-how-is-radon-measured-how-does-an-airthings-device-measure-radonWhich leads to some very legalese patents, painful to read but generally covers the theory of operation:https://data.epo.org/publication-server/pdf-document/EP12746381NWB1.pdf?PN=EP2734862%20EP%202734862&iDocId=5935917&iepatch=.pdfhttps://patentimages.storage.googleapis.com/0b/d5/34/bd2cd789fa35f3/US10534094.pdf

author: cb831a
author_rank: Contributor
timestamp: January 07, 2024, 01:41:51 pm
content: Quote from: djnebs on January 07, 2024, 02:41:40 amIncluded this in the codeCode:payload = radon.read_mem_payload()fd80_contents = radon.read_from_flash(radon.PAYLOAD_LOCATION)if fd80_contents != payload:print("Corruption detected! - reloading code")print(fd80_contents)radon.write_to_flash(payload)#confirm payload was written successfullyassert radon.read_from_flash(radon.PAYLOAD_LOCATION) == payloadQuote from: djnebs on January 07, 2024, 02:41:40 amFixedMy last measurement did not fail but 1-day-avg-radon fell from 115 to 25 in some 15h :-(Code:2024-01-06T23:28:11.7227324+01:00 00 00 07 a0 80 29 08 15 77 00 00 40 00 00 00 a5 1-day= 115 7-day= 0 longterm= 0 updays= 0 (retries=0)2024-01-06T23:58:21.8888672+01:00 00 00 d1 db 81 33 26 15 77 00 00 44 00 00 10 a5 1-day= 115 7-day= 0 longterm= 0 updays= 0 (retries=1)2024-01-07T00:28:33.2529053+01:00 00 00 d1 db 81 02 09 16 77 00 00 44 00 00 10 a5 1-day= 114 7-day= 0 longterm= 0 updays= 0 (retries=1)2024-01-07T00:58:46.2349309+01:00 00 00 f8 ab 81 0f 27 16 77 00 00 40 00 00 10 a5 1-day= 114 7-day= 0 longterm= 0 updays= 0 (retries=0)2024-01-07T01:28:55.9196314+01:00 00 00 d1 db 81 19 09 17 77 00 00 44 00 00 10 a5 1-day= 106 7-day= 0 longterm= 0 updays= 0 (retries=0)2024-01-07T01:59:05.5895380+01:00 00 00 ee db 45 26 4c 28 b1 29 05 2b 6d 2c b1 2d 1-day= 106 7-day= 0 longterm= 0 updays= 0 (retries=1)2024-01-07T02:29:17.0292897+01:00 00 00 4e 31 81 2e 09 00 77 00 00 40 00 00 10 a5 1-day= 99 7-day= 81 longterm= 81 updays= 1 (retries=0)2024-01-07T02:59:26.7514746+01:00 00 00 d0 9e 81 38 27 00 77 00 00 40 00 00 10 a5 1-day= 99 7-day= 81 longterm= 81 updays= 1 (retries=1)2024-01-07T03:29:38.3203730+01:00 00 00 d1 db 81 07 0a 01 77 00 00 40 00 00 10 a5 1-day= 69 7-day= 81 longterm= 81 updays= 1 (retries=1)2024-01-07T03:59:49.8821985+01:00 00 00 d1 db 81 13 28 01 77 00 00 44 00 00 10 a5 1-day= 69 7-day= 81 longterm= 81 updays= 1 (retries=1)2024-01-07T04:30:02.8869437+01:00 00 00 e6 db 81 20 0a 02 77 00 00 40 00 00 10 a5 1-day= 58 7-day= 81 longterm= 81 updays= 1 (retries=1)2024-01-07T05:00:14.2864591+01:00 00 00 a1 02 81 2b 28 02 77 00 00 44 00 00 10 a5 1-day= 58 7-day= 81 longterm= 81 updays= 1 (retries=1)2024-01-07T05:30:25.7099502+01:00 00 00 bc 44 81 37 0a 03 77 00 00 44 00 00 10 a5 1-day= 53 7-day= 81 longterm= 81 updays= 1 (retries=1)2024-01-07T06:00:37.6762408+01:00 00 00 43 34 81 07 29 03 77 00 00 44 00 00 10 a5 1-day= 53 7-day= 81 longterm= 81 updays= 1 (retries=1)2024-01-07T06:30:49.0730400+01:00 00 00 be 88 81 12 0b 04 77 00 00 40 00 00 10 a5 1-day= 48 7-day= 81 longterm= 81 updays= 1 (retries=1)2024-01-07T07:01:00.4344030+01:00 00 00 d6 03 81 1e 29 04 77 00 00 40 00 00 10 a5 1-day= 48 7-day= 81 longterm= 81 updays= 1 (retries=1)2024-01-07T07:31:11.8272303+01:00 00 00 75 a7 81 29 0b 05 77 00 00 40 00 00 10 a5 1-day= 44 7-day= 81 longterm= 81 updays= 1 (retries=1)2024-01-07T08:01:23.2031595+01:00 00 00 d1 db 81 35 29 05 77 00 00 40 00 00 10 a5 1-day= 44 7-day= 81 longterm= 81 updays= 1 (retries=1)2024-01-07T08:31:34.6123907+01:00 00 00 a6 21 81 04 0c 06 77 00 00 44 00 00 10 a5 1-day= 41 7-day= 81 longterm= 81 updays= 1 (retries=1)2024-01-07T09:01:46.0285546+01:00 00 00 03 8c 81 10 2a 06 77 00 00 40 00 00 10 a5 1-day= 41 7-day= 81 longterm= 81 updays= 1 (retries=1)2024-01-07T09:31:57.4909386+01:00 00 00 eb ca 81 1b 0c 07 77 00 00 44 00 00 10 a5 1-day= 37 7-day= 81 longterm= 81 updays= 1 (retries=0)2024-01-07T10:02:07.1087714+01:00 00 00 d1 db 81 25 2a 07 77 00 00 44 00 00 10 a5 1-day= 37 7-day= 81 longterm= 81 updays= 1 (retries=0)2024-01-07T10:32:16.7372782+01:00 00 00 bf 91 81 2e 0c 08 77 00 00 40 00 00 10 a5 1-day= 32 7-day= 81 longterm= 81 updays= 1 (retries=1)2024-01-07T11:02:28.1494097+01:00 00 00 f5 2f 81 3a 2a 08 77 00 00 44 00 00 10 a5 1-day= 32 7-day= 81 longterm= 81 updays= 1 (retries=1)2024-01-07T11:32:39.5535807+01:00 00 00 1c 10 81 09 0d 09 77 00 00 44 00 00 10 a5 1-day= 31 7-day= 81 longterm= 81 updays= 1 (retries=1)2024-01-07T12:02:51.0077355+01:00 00 00 37 a0 81 15 2b 09 77 00 00 40 00 00 10 a5 1-day= 31 7-day= 81 longterm= 81 updays= 1 (retries=1)2024-01-07T12:33:02.4054260+01:00 00 00 43 a6 81 20 0d 0a 77 00 00 44 00 00 10 a5 1-day= 28 7-day= 81 longterm= 81 updays= 1 (retries=0)2024-01-07T13:03:12.0281552+01:00 00 00 d1 db 81 2a 2b 0a 77 00 00 44 00 00 10 a5 1-day= 28 7-day= 81 longterm= 81 updays= 1 (retries=1)2024-01-07T13:33:23.4285070+01:00 00 00 d1 db 81 35 0d 0b 77 00 00 40 00 00 10 a5 1-day= 25 7-day= 81 longterm= 81 updays= 1 (retries=0)2024-01-07T14:03:33.2860668+01:00 00 49 76 4b 78 4c 9f 4d 07 4f 65 50 b0 51 2f 53 1-day= 25 7-day= 81 longterm= 81 updays= 1 (retries=1)I rebooted the device with the new code in place to reset the avg.Quote from: djnebs on January 07, 2024, 02:41:40 amAgree on thatQuote from: djnebs on January 07, 2024, 02:41:40 amThat should allow us to find the code that does the first initial statistical analysis.Quote from: djnebs on January 07, 2024, 02:41:40 amRead that !Quote from: djnebs on January 07, 2024, 02:41:40 amThat's very clear text for a patent :-)I had guessed most of the contruct from the part of the PCB under the shielded cover, but I thought - as you - that the counting could be detected from the DC value.I did notice the CPIO pin, but I thought it was start-stopping the sensor somehow.

author: cb831a
author_rank: Contributor
timestamp: January 11, 2024, 02:30:19 pm
content: Based on my most recent test the radon sensor simply stops counting when I communicate with it twice an hour.And hence the 1-day average drops to 0 after 24 hours (... of not counting)Also the code buffer at FD80 is filled with 0xFF's at each device-midnight.Code:C:\workSave\Airthings> .\loop.ps12024-01-10T12:17:03.6083532+01:00 d8 0f 03 1d 80 39 1f 15 77 00 00 74 00 00 10 a5 1-day= 72 7-day= 42 longterm= 42 updays= 2 (retries=2)2024-01-10T12:47:15.2896974+01:00 80 03 5f 67 80 09 02 16 77 00 00 70 00 00 10 a5 1-day= 66 7-day= 42 longterm= 42 updays= 2 (retries=1)2024-01-10T13:17:29.3351754+01:00 f6 03 62 f8 80 17 20 16 77 00 00 74 00 00 10 a5 1-day= 66 7-day= 42 longterm= 42 updays= 2 (retries=2)2024-01-10T13:47:44.4182882+01:00 80 fd 19 fb 81 26 02 17 77 00 00 50 00 00 10 a5 1-day= 60 7-day= 42 longterm= 42 updays= 2 (retries=2)2024-01-10T14:17:53.7448194+01:00 80 fd 9c da 80 30 20 17 77 00 00 44 00 00 10 a5 1-day= 60 7-day= 42 longterm= 42 updays= 2 (retries=0)Corruption detected! - reloading code b'\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff'2024-01-10T14:48:05.4656103+01:00 ec 07 dd 1b 80 3b 02 00 77 00 00 74 00 00 10 a5 1-day= 54 7-day= 46 longterm= 46 updays= 3 (retries=1)2024-01-10T15:18:17.9447486+01:00 80 fd 83 e9 80 0c 21 00 77 00 00 44 00 00 10 a5 1-day= 54 7-day= 46 longterm= 46 updays= 3 (retries=1)2024-01-10T15:48:31.9585376+01:00 18 00 0e a7 80 1a 03 01 77 00 00 70 00 00 10 a5 1-day= 49 7-day= 46 longterm= 46 updays= 3 (retries=2)2024-01-10T16:18:44.7246837+01:00 80 fd a1 b5 81 27 21 01 77 00 00 50 00 00 10 a5 1-day= 49 7-day= 46 longterm= 46 updays= 3 (retries=1)2024-01-10T16:48:59.9082621+01:00 80 fd cb 92 81 36 03 02 77 00 00 40 00 00 10 a5 1-day= 48 7-day= 46 longterm= 46 updays= 3 (retries=2)2024-01-10T17:19:13.4878305+01:00 80 fd 1a 20 81 08 22 02 77 00 00 50 00 00 10 a5 1-day= 48 7-day= 46 longterm= 46 updays= 3 (retries=1)2024-01-10T17:49:26.3831718+01:00 ec 07 7d 3d 81 15 04 03 77 00 00 50 00 00 10 a5 1-day= 45 7-day= 46 longterm= 46 updays= 3 (retries=1)2024-01-10T18:19:38.2226079+01:00 d8 0f f9 ea 80 20 22 03 77 00 00 74 00 00 10 a5 1-day= 45 7-day= 46 longterm= 46 updays= 3 (retries=1)2024-01-10T18:49:55.6179202+01:00 80 fd a1 b5 81 32 04 04 77 00 00 50 00 00 10 a5 1-day= 43 7-day= 46 longterm= 46 updays= 3 (retries=3)2024-01-10T19:20:12.0851908+01:00 80 fd 42 32 80 06 23 04 77 00 00 54 00 00 10 a5 1-day= 43 7-day= 46 longterm= 46 updays= 3 (retries=3)2024-01-10T19:50:21.4573193+01:00 80 fd f6 06 80 10 05 05 77 00 00 40 00 00 10 a5 1-day= 37 7-day= 46 longterm= 46 updays= 3 (retries=0)2024-01-10T20:20:37.8065642+01:00 80 fd 2e 94 80 20 23 05 77 00 00 74 00 00 10 a5 1-day= 37 7-day= 46 longterm= 46 updays= 3 (retries=3)2024-01-10T20:50:46.9784809+01:00 80 fd d1 db 80 2a 05 06 77 00 00 40 00 00 10 a5 1-day= 35 7-day= 46 longterm= 46 updays= 3 (retries=0)2024-01-10T21:20:56.3290982+01:00 80 fd 6e 96 80 33 23 06 77 00 00 40 00 00 10 a5 1-day= 35 7-day= 46 longterm= 46 updays= 3 (retries=0)2024-01-10T21:51:10.4048424+01:00 80 fd 46 5b 80 05 06 07 77 00 00 74 00 00 10 a5 1-day= 31 7-day= 46 longterm= 46 updays= 3 (retries=2)2024-01-10T22:21:23.1960574+01:00 80 fd 1a 20 81 12 24 07 77 00 00 40 00 00 10 a5 1-day= 31 7-day= 46 longterm= 46 updays= 3 (retries=1)2024-01-10T22:51:39.3844591+01:00 ec 07 7a 46 80 22 06 08 77 00 00 70 00 00 10 a5 1-day= 29 7-day= 46 longterm= 46 updays= 3 (retries=3)2024-01-10T23:21:53.2797638+01:00 07 00 6f 83 80 30 24 08 77 00 00 44 00 00 10 a5 1-day= 29 7-day= 46 longterm= 46 updays= 3 (retries=2)2024-01-10T23:52:06.2562773+01:00 80 7d 0d 7d 80 01 07 09 77 00 00 40 00 00 10 a5 1-day= 26 7-day= 46 longterm= 46 updays= 3 (retries=1)2024-01-11T00:22:19.1777662+01:00 80 fd 1a 20 81 0e 25 09 77 00 00 50 00 00 10 a5 1-day= 26 7-day= 46 longterm= 46 updays= 3 (retries=1)2024-01-11T00:52:28.5322743+01:00 80 fd fb 58 80 17 07 0a 77 00 00 44 00 00 10 a5 1-day= 24 7-day= 46 longterm= 46 updays= 3 (retries=0)2024-01-11T01:22:37.9519471+01:00 80 fd d1 db 80 21 25 0a 77 00 00 44 00 00 10 a5 1-day= 24 7-day= 46 longterm= 46 updays= 3 (retries=0)2024-01-11T01:53:01.1355285+01:00 80 fd 20 29 80 38 07 0b 77 00 00 70 00 00 10 a5 1-day= 23 7-day= 46 longterm= 46 updays= 3 (retries=6)2024-01-11T02:23:14.9533630+01:00 00 00 dc b3 80 0a 26 0b 77 00 00 70 00 00 10 a5 1-day= 23 7-day= 46 longterm= 46 updays= 3 (retries=2)2024-01-11T02:53:26.5932295+01:00 80 fd f8 be 80 16 08 0c 77 00 00 70 00 00 10 a5 1-day= 23 7-day= 46 longterm= 46 updays= 3 (retries=1)2024-01-11T03:23:38.2759787+01:00 d8 0f 04 b2 80 21 26 0c 77 00 00 74 00 00 10 a5 1-day= 23 7-day= 46 longterm= 46 updays= 3 (retries=1)2024-01-11T03:53:50.9910081+01:00 c0 7e d1 db 80 2e 08 0d 77 00 00 74 00 00 10 a5 1-day= 21 7-day= 46 longterm= 46 updays= 3 (retries=3)2024-01-11T04:24:05.0334851+01:00 80 07 fa 2a 80 00 27 0d 77 00 00 54 00 00 10 a5 1-day= 21 7-day= 46 longterm= 46 updays= 3 (retries=2)2024-01-11T04:54:14.4667043+01:00 80 fd d1 db 80 0a 09 0e 77 00 00 44 00 00 10 a5 1-day= 19 7-day= 46 longterm= 46 updays= 3 (retries=0)2024-01-11T05:24:26.0557627+01:00 d8 0f ad 97 80 15 27 0e 77 00 00 74 00 00 10 a5 1-day= 19 7-day= 46 longterm= 46 updays= 3 (retries=1)2024-01-11T05:54:39.7176739+01:00 80 fd 8f b2 81 23 09 0f 77 00 00 70 00 00 10 a5 1-day= 16 7-day= 46 longterm= 46 updays= 3 (retries=1)2024-01-11T06:24:52.5596260+01:00 80 fd a1 b5 81 30 27 0f 77 00 00 40 00 00 10 a5 1-day= 16 7-day= 46 longterm= 46 updays= 3 (retries=1)2024-01-11T06:55:04.1989046+01:00 c0 7e 5d 2e 80 3b 09 10 77 00 00 74 00 00 10 a5 1-day= 12 7-day= 46 longterm= 46 updays= 3 (retries=1)2024-01-11T07:25:13.4393569+01:00 80 fd 75 f6 80 09 28 10 77 00 00 40 00 00 10 a5 1-day= 12 7-day= 46 longterm= 46 updays= 3 (retries=0)2024-01-11T07:55:29.7512760+01:00 3f 00 31 b9 80 19 0a 11 77 00 00 54 00 00 10 a5 1-day= 8 7-day= 46 longterm= 46 updays= 3 (retries=3)2024-01-11T08:25:47.2072832+01:00 80 fd 96 d6 81 2b 28 11 77 00 00 40 00 00 10 a5 1-day= 8 7-day= 46 longterm= 46 updays= 3 (retries=3)2024-01-11T08:56:01.2194893+01:00 07 00 9a b3 80 39 0a 12 77 00 00 70 00 00 10 a5 1-day= 4 7-day= 46 longterm= 46 updays= 3 (retries=2)2024-01-11T09:26:15.2749379+01:00 b0 1f 35 f1 80 0b 29 12 77 00 00 70 00 00 10 a5 1-day= 4 7-day= 46 longterm= 46 updays= 3 (retries=2)2024-01-11T09:56:24.6202612+01:00 80 fd e4 36 80 14 0b 13 77 00 00 40 00 00 10 a5 1-day= 3 7-day= 46 longterm= 46 updays= 3 (retries=0)2024-01-11T10:26:38.1287075+01:00 80 0d 96 d6 81 22 29 13 77 00 00 70 00 00 10 a5 1-day= 3 7-day= 46 longterm= 46 updays= 3 (retries=1)2024-01-11T10:56:47.4493200+01:00 80 fd 04 14 80 2b 0b 14 77 00 00 44 00 00 10 a5 1-day= 1 7-day= 46 longterm= 46 updays= 3 (retries=0)2024-01-11T11:26:56.7955289+01:00 80 fd 2a f8 80 34 29 14 77 00 00 44 00 00 10 a5 1-day= 1 7-day= 46 longterm= 46 updays= 3 (retries=0)2024-01-11T11:57:08.3880657+01:00 80 10 4a 8c 80 04 0c 15 77 00 00 74 00 00 10 a5 1-day= 0 7-day= 46 longterm= 46 updays= 3 (retries=1)2024-01-11T12:27:20.0627042+01:00 80 fd 1a 64 80 10 2a 15 77 00 00 74 00 00 10 a5 1-day= 0 7-day= 46 longterm= 46 updays= 3 (retries=1)2024-01-11T12:57:29.3872377+01:00 80 fd cd 97 80 19 0c 16 77 00 00 44 00 00 10 a5 1-day= 0 7-day= 46 longterm= 46 updays= 3 (retries=0)2024-01-11T13:27:41.0351812+01:00 80 fd 0b a6 80 25 2a 16 77 00 00 54 00 00 10 a5 1-day= 0 7-day= 46 longterm= 46 updays= 3 (retries=1)2024-01-11T13:57:55.0993634+01:00 80 fd 4b ee 80 33 0c 17 77 00 00 74 00 00 10 a5 1-day= 0 7-day= 46 longterm= 46 updays= 3 (retries=2)2024-01-11T14:28:09.0958858+01:00 ec 07 35 5c 80 05 2b 17 77 00 00 74 00 00 10 a5 1-day= 0 7-day= 46 longterm= 46 updays= 3 (retries=2)Corruption detected! - reloading code b'\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff'2024-01-11T14:58:23.0736817+01:00 1f 00 7c b1 80 13 0d 00 77 00 00 50 00 00 10 a5 1-day= 0 7-day= 37 longterm= 37 updays= 4 (retries=2)

author: cb831a
author_rank: Contributor
timestamp: January 12, 2024, 10:36:19 am
content: Now I have been running an additional 12h without any communication on the serial port (but still connected) and the radon counting did not restart meaning the 1-day-avg is still 0.I just disconnected the serial port to see if that helps.

author: cb831a
author_rank: Contributor
timestamp: January 12, 2024, 03:52:50 pm
content: OK - have now climbed to 19 in 8h (target 57 in 24h), so it is the physical connection that interfers - not the communication.Have now reconnected GND and TX from the device to RX on the USB2TTL...

author: cb831a
author_rank: Contributor
timestamp: January 14, 2024, 03:47:59 pm
content: Update:Disconnecting the RX+TX on the Radon detector makes it work normally.Connecting RX only on the detector with TX on the USB2TTL stops the counting and makes the 1-day-avg go to 0Connecting both TX and RX - same as RX only.Connecting TX only let the dectector work normally.Connected scopeNot connected I seeTX on USB2TLL on 3.3V DC no AC/noiseRX on USB2TLL on 3.3V DC no AC/noiseRX on detector on 0V DC + 20-40mV 50Hz humTX on detector on 2.5V DC no AC/noiseConnected I seeTX on USB2TLL/RX on detector on 3.1V DC no AC/noiseRX on USB2TLL/TX on detector on 2.5V DC no AC/noiseSo no noise is introducing data towards the detector.However the USB2TLL lifts the detector-RX to 3.1V and apparently a current is flowing as the voltage drops 0.2V when connectedMaybe this current hinders the counting ...?I think next move would be to connect a ESP and make sure it changes the GPIO pin from 'TX' pin to high impedance 'INPUT' when idle.

author: djnebs
author_rank: Contributor
timestamp: January 14, 2024, 05:27:16 pm
content: Can we rule out any noise or spurious stuff coming out of the USBTTL by just pulling up RX on the detector to local 3.3V with a 1-10k resistor?See if it has the same effect?

author: cb831a
author_rank: Contributor
timestamp: January 14, 2024, 05:53:31 pm
content: Quote from: djnebs on January 14, 2024, 05:27:16 pmI now connected a 4V lion cell to GND-RX through a 33kohm resistor and I can measure 4.08V on the cell and 3.01V on the RX, so 32µA is flowing into RX.I used a cell to avoid noise from a powersupply.

author: cb831a
author_rank: Contributor
timestamp: January 20, 2024, 11:32:09 pm
content: Update:Found that the USB2TTL33V somehow affected the device. I still can't find any trace of noise on the RX pin with my 100MHz scope.I decided to hook up the RX/TX from the device directly to a 3.3V ESP32 - and guess what it works !I ported all your code and combined it with deep sleep in between samples, and I am now receiving syslog messages like below on my serverCode:2024-01-20 23:21:34.226 +01:00 10.7.14.157:4444 local0.info [] ESP32: 80 fd db 5d 81 31 24 09 77 00 00 40 00 00 10 a5 1-day=30, 7-day=57, longterm=43, updays=132024-01-20 23:22:05.559 +01:00 10.7.14.157:4444 local0.info [] ESP32: 80 fd db 5d 81 14 25 09 77 00 00 40 00 00 10 a5 1-day=30, 7-day=57, longterm=43, updays=132024-01-20 23:22:36.854 +01:00 10.7.14.157:4444 local0.info [] ESP32: 80 fd db 5d 81 33 25 09 77 00 00 40 00 00 10 a5 1-day=30, 7-day=57, longterm=43, updays=132024-01-20 23:23:08.170 +01:00 10.7.14.157:4444 local0.info [] ESP32: 80 fd db 5d 81 17 26 09 77 00 00 40 00 00 10 a5 1-day=30, 7-day=57, longterm=43, updays=132024-01-20 23:23:39.485 +01:00 10.7.14.157:4444 local0.info [] ESP32: 80 fd db 5d 81 36 26 09 77 00 00 40 00 00 10 a5 1-day=30, 7-day=57, longterm=43, updays=132024-01-20 23:24:10.803 +01:00 10.7.14.157:4444 local0.info [] ESP32: 80 fd db 5d 81 19 27 09 77 00 00 40 00 00 10 a5 1-day=30, 7-day=57, longterm=43, updays=132024-01-20 23:24:42.129 +01:00 10.7.14.157:4444 local0.info [] ESP32: 80 fd db 5d 81 39 27 09 77 00 00 40 00 00 10 a5 1-day=30, 7-day=57, longterm=43, updays=132024-01-20 23:25:13.454 +01:00 10.7.14.157:4444 local0.info [] ESP32: 80 fd db 5d 81 1c 28 09 77 00 00 40 00 00 10 a5 1-day=30, 7-day=57, longterm=43, updays=132024-01-20 23:25:44.757 +01:00 10.7.14.157:4444 local0.info [] ESP32: 80 fd db 5d 81 3b 28 09 77 00 00 40 00 00 10 a5 1-day=30, 7-day=57, longterm=43, updays=132024-01-20 23:26:16.085 +01:00 10.7.14.157:4444 local0.info [] ESP32: 80 fd db 5d 81 1f 29 09 77 00 00 40 00 00 10 a5 1-day=30, 7-day=57, longterm=43, updays=132024-01-20 23:26:47.402 +01:00 10.7.14.157:4444 local0.info [] ESP32: 80 fd db 5d 81 02 2a 09 77 00 00 40 00 00 10 a5 1-day=30, 7-day=57, longterm=43, updays=132024-01-20 23:27:18.717 +01:00 10.7.14.157:4444 local0.info [] ESP32: 80 fd db 5d 81 21 2a 09 77 00 00 40 00 00 10 a5 1-day=30, 7-day=57, longterm=43, updays=132024-01-20 23:27:50.038 +01:00 10.7.14.157:4444 local0.info [] ESP32: 80 fd db 5d 81 05 2b 09 77 00 00 40 00 00 10 a5 1-day=30, 7-day=57, longterm=43, updays=132024-01-20 23:28:21.367 +01:00 10.7.14.157:4444 local0.info [] ESP32: 80 fd db 5d 81 24 2b 09 77 00 00 40 00 00 10 a5 1-day=30, 7-day=57, longterm=43, updays=132024-01-20 23:28:52.683 +01:00 10.7.14.157:4444 local0.info [] ESP32: 80 fd db 5d 81 07 2c 09 77 00 00 40 00 00 10 a5 1-day=30, 7-day=57, longterm=43, updays=132024-01-20 23:29:23.994 +01:00 10.7.14.157:4444 local0.info [] ESP32: 80 fd db 5d 81 27 2c 09 77 00 00 40 00 00 10 a5 1-day=30, 7-day=57, longterm=43, updays=132024-01-20 23:29:55.324 +01:00 10.7.14.157:4444 local0.info [] ESP32: 80 fd db 5d 81 0a 2d 09 77 00 00 40 00 00 10 a5 1-day=30, 7-day=57, longterm=43, updays=132024-01-20 23:30:26.641 +01:00 10.7.14.157:4444 local0.info [] ESP32: 80 fd db 5d 81 29 2d 09 77 00 00 40 00 00 10 a5 1-day=30, 7-day=57, longterm=43, updays=13Right now its running every 15 secs, but I will now change it to twice an hour.I will post the code when I got it a little cleaned up.

author: coppercone2
author_rank: Super Contributor
timestamp: January 20, 2024, 11:40:57 pm
content: its normal. it has to do with temperature and ground hydrological pressure and other things. they are not consistent I noticed quite a large variation.

author: cb831a
author_rank: Contributor
timestamp: January 20, 2024, 11:48:12 pm
content: Quote from: coppercone2 on January 20, 2024, 11:40:57 pmNot sure what you are referring to - can you elaborate ?

author: djnebs
author_rank: Contributor
timestamp: January 21, 2024, 02:19:52 am
content: What chip is the usbttl? When you scoped it, did you leave a trigger on it for the whole 24hours? The only thing that comes to mind is that it's sending something very infrequently (like every 24hrs). Can't imagine why... especially in the case where you didn't plugin the usb data pins.Quite strange.

author: cb831a
author_rank: Contributor
timestamp: January 21, 2024, 11:09:58 am
content: Quote from: djnebs on January 21, 2024, 02:19:52 amhttps://auseparts.com.au/FT232RL-3.3V-5.5V-FTDI-USB-to-TTL-Serial-Adapter-ModuleQuote from: djnebs on January 21, 2024, 02:19:52 amNo, as I had nothing to trigger on - I did free-run at .2s/div at humspeed and at 4800baud speed - after that I scanned through all the speeds.Why would a once/24h trigger affect the whole day of operation. I would expect triggers within each hour ?!

author: coppercone2
author_rank: Super Contributor
timestamp: January 21, 2024, 08:53:15 pm
content: radon levels might average in a year. seasonal dependence too

author: cb831a
author_rank: Contributor
timestamp: January 28, 2024, 10:12:40 pm
content: OK, I wrapped it up in a proper box and my Radon-device is now sending Syslog messages every 15min - I will probably change the interval to 30 or 60 minutes as the meter only changes once per hourI added rechargeable battery and some logic to monitor battery level. Now the syslog looks likeCode:2024-01-28 18:15:05.001 +01:00 10.7.14.152:4444 local0.info [] RADONESP32: (1-0) [80 10 12 11 82 1e 0d 03 6d 00 00 50 00 00 80 a5] 1-day=56, 7-day=59, longterm=59, uptime=4:03:13:30, volt=4180 / USB2024-01-28 18:30:01.967 +01:00 10.7.14.152:4444 local0.info [] RADONESP32: (2-4) [80 10 12 11 82 1b 1c 03 6d 00 00 50 00 00 80 a5] 1-day=56, 7-day=59, longterm=59, uptime=4:03:28:27, volt=4196 / USB2024-01-28 18:44:59.585 +01:00 10.7.14.152:4444 local0.info [] RADONESP32: (3-4) [80 10 12 11 82 19 2b 03 6d 00 00 50 00 00 80 a5] 1-day=56, 7-day=59, longterm=59, uptime=4:03:43:25, volt=4176 / USB2024-01-28 18:59:57.865 +01:00 10.7.14.152:4444 local0.info [] RADONESP32: (4-4) [80 10 12 11 82 17 3a 03 6d 00 00 50 00 00 80 a5] 1-day=56, 7-day=59, longterm=59, uptime=4:03:58:23, volt=4178 / USB2024-01-28 19:14:57.956 +01:00 10.7.14.152:4444 local0.info [] RADONESP32: (5-4) [80 10 12 11 82 17 0d 04 6d 00 00 50 00 00 80 a5] 1-day=55, 7-day=59, longterm=59, uptime=4:04:13:23, volt=4172 / BAT2024-01-28 19:29:56.999 +01:00 10.7.14.152:4444 local0.info [] RADONESP32: (6-4) [80 10 12 11 82 16 1c 04 6d 00 00 50 00 00 80 a5] 1-day=55, 7-day=59, longterm=59, uptime=4:04:28:22, volt=4174 / BAT2024-01-28 19:44:55.638 +01:00 10.7.14.152:4444 local0.info [] RADONESP32: (7-4) [80 10 12 11 82 15 2b 04 6d 00 00 50 00 00 80 a5] 1-day=55, 7-day=59, longterm=59, uptime=4:04:43:21, volt=4156 / BAT2024-01-28 19:59:53.597 +01:00 10.7.14.152:4444 local0.info [] RADONESP32: (8-4) [80 10 12 11 82 13 3a 04 6d 00 00 50 00 00 80 a5] 1-day=55, 7-day=59, longterm=59, uptime=4:04:58:19, volt=4168 / BAT

author: FIB-Agent
author_rank: Newbie
timestamp: April 03, 2024, 05:04:57 am
content: Just wanted to thank you all for your work on this project. I picked up a unit on eBay because it was cheap, and searched the model name + "hack" because I wanted better access to data, and this is pretty much the best kind of result one could hope to find from that. I'm just too early, I guess! Good luck.Stupid question, but has anyone considered bypassing the computer and trying to read off the sensor directly?

author: cb831a
author_rank: Contributor
timestamp: April 07, 2024, 04:33:52 pm
content: Thanks, I'm happy you can use it.The TTL 3.3V port in the Airthings device is very picky and even small leak currents in TX/RX makes the device stop counting and hence deliver to low numbers.As you can see above my readings dropped to 0 whan I had a computer connected via a USB2TTL33 converter.We never found out exactly what happened, but I found that the ESP32 serial port was "accepted" by the device and as I wanted to build a standalone WiFi device I followed that route.My implementation has the serial port on ESP32 live/active approx. 20s 4 times an hour, and that may be why it does not affect the device.PS: My battery lasts > 2months on one charge. If I only polled the device 2 or 1 times an hour the "lifespan" could probably be much longer. The device is only updated internally every minute, so polling once a minute should be fine.

author: djnebs
author_rank: Contributor
timestamp: April 13, 2024, 08:59:08 pm
content: Personally, I've lost interest in this and moved on to the next project. Glad it helped those that took interest.Quote from: FIB-Agent on April 03, 2024, 05:04:57 amThe sensor measurement had some concept of counting pulses (radioactive decay events?) on a GPIO pin. I suppose you could sample that signal directly, but without reversing the full firmware algorithm and calibration scheme, we don't know how to translate it into a meaningful metric.

author: medb
author_rank: Newbie
timestamp: September 06, 2024, 01:06:25 pm
content: Fantastic work, this is exactly what I was looking for my radon meter.Quote from: cb831a on January 20, 2024, 11:32:09 pmSeems like it never got cleaned upI wouldn't mind getting the code even if it's not cleaned up.

author: cb831a
author_rank: Contributor
timestamp: September 09, 2024, 02:38:29 pm
content: Thanks for the positive feedback - it's nice that someone can use the work we did.I have attached the code I have been running for 8 month now - could be cleaned up - but it works :-)Please update the thread if you find errors or have improvements...!I used PlatformIO as development platform, but any platform including AduinoIDE will do.Claus

author: medb
author_rank: Newbie
timestamp: January 13, 2025, 09:23:00 pm
content: Finalized my take on this and got the code into a Trigboard with some small modifications.Got it nice and tidy by modeling and printing a box housing the Trigboard which snaps in place of instead of the battery lid.The Trigboard is configured to read every 4h and uses the power from the same battery source as the sensor.Once again many thanks for all the job done on this!

author: ozman
author_rank: Newbie
timestamp: February 04, 2025, 03:14:29 am
content: Incredible work reverse engineering this!I stumbled on your work today while looking for a solution to an efficiency problem...===Background:I recently installed an ERV in my crawlspace to reduce some numbers that were much too high. Thankfully, it appears to be working! Now I would like to make it efficient, only moving air when radon levels are high.Dream:I would like to be able to pull data from my Airthings Corentium, run the output through an ESP32 to trigger the ERV to reduce power or stop altogether, depending on the Airthings readings.Other solutions:Until I found your solution, the only other answer I could find was the $750 Radonova Robin (standalone Radon detector) whose output signal -- no screen, just a 1-10v output depending on Radon reading -- that can be translated to a motor control.===I would really like to try to build what you have made, but I could use a wiring diagram for your breadboard. Would you be willing to draw one up and share it -- even if its on the back of a napkin!Thanks!

author: cb831a
author_rank: Contributor
timestamp: March 23, 2025, 03:09:23 pm
content: Sorry I did not see your comment until now.Thanks for kind words !I have some notes somewhere, but a quick look did not reveal something.For now I do not have time to dig deeper, but if I find them I will post them.The code shows all pins used on the ESP32.The Veroboard is only to have a solid base for the additional components for the battery management and RS232 to the Airthings Radon Device.The trick is to solder only needed pins from ESP32 module to Veroboard allowing some pins on the non-battery side to be available on the component stripe near the battery without cutting the VeroboardThere is one extra circuitry is the two 1M+1M resistors that divide the battery voltage into half allowing me to measure it on a 3.3V analog input.There is also a 1M resistor between 5V next pin GPIO13 which allow the code to determine if the ESP32 is being fed from USB and hence is charging.On the the right side away from the battery the TX0, RX0 and second GND from top has a (high) pin to allow debugging of the ESP32 while running. Please not these three pins does not connect to the Veroboard.Be careful with the Lithium cell - if you short it or physically beat it it may blow up in fire.EDIT----I found one of my notes showing which ESP32 pins are connected to the veroboard (marked with a big dot).On the right is the list of signals available on the Veroboard.I don't remember why I connected EN to Veroboard it does not seem to be connected to anything.