micro-usb on radon detector

[grahamW]

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?

[ebclr]

Post a picture of the PCB, will help on evaluated the possibility

[mnisjk]

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.

[matteev]

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.

[WiredChaser]

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!

[Gyro]

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.

[lciummo]

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

[J0sh]

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?

[ChrisE]

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.

[J0sh]

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).

[ChrisE]

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 of 214us, so I'm assuming our baud rate is 4800


After 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.

The 0x77 command 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 be 0x00 when device is reset
  - 1) 0/Null
  - 2/3) Bytes seem to change rapidly, potentially one could be a checksum?
  - 4) Byte seems be 0x80 most 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 be 0x60 most of the time, but changes to 0x40 every ~6 seconds
  - 12/13) 0/Null
  - 14) Message length (0x10)
  - 15) Message terminator? 0xA5

Code: [Select]

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,A5
0A,0,68,C3,80,3A,37,0B,77,0,0,60,0,0,10,A5
This seems to be a sort of message footer which is also included in the response generated by the 0x6D message.

The 0x6D command 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: [Select]

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,A5
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,06,07,08,09,0A,6D,50,00,B2,69,82,1F,06,04,6D,00,00,50,00,00,80,A5
A5,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,A5
A5,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,A5
Some notes:
- I'm currently collecting a large sample of the 0x6D messages 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

[Dan123456]

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 alley 

Keep 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!

[the-valued-customer]

@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.

[MikeK]

I was gonna say, it might be useful to get a small piece of uranium ore to help you with your testing.

Or *any* smoke detector?

[Dan123456]

I was gonna say, it might be useful to get a small piece of uranium ore to help you with your testing.

Or *any* smoke detector?

Indeed! 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 Aus  Just 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

[ChrisE]

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 the 0x6D byte 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!

[the-valued-customer]

@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.

[djnebs]

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: [Select]

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: [Select]

/* WARNING: Globals starting with '_' overlap smaller symbols at the same address */

undefined8
UndefinedFunction_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)[uVar1] = 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 ! X

Code: [Select]

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: [Select]

uart_init e69c undefined uart_init(char param_1) 70
reply_to_uart_msg d834 undefined reply_to_uart_msg(void) 168
read_adc df8e undefined read_adc(short samples_to_avg) 108
MAIN_LOOP e8ca undefined MAIN_LOOP(void) 52
main_loop cb1a undefined2 main_loop(ushort param_1, ushort param_2) 308
lcd_init ea7a undefined lcd_init(void) 30
INIT d3d2 undefined INIT(void) 176
gpio_init dffa undefined gpio_init(void) 104
delay eb7a undefined delay(short param_1) 20
compute_checksum? e9ba undefined compute_checksum?(byte * param_1, short param_2) 42
clock_init e930 undefined clock_init(void) 50
adc_init eacc undefined adc_init(void) 24

CRC16 function:

Code: [Select]

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.

[ChrisE]

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!

[djnebs]

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

[cb831a]

- 9/10) 0/Null
 - 11) Seems to be 0x60 most of the time, but changes to 0x40 every ~6 seconds
 - 12/13) 0/Null

6s 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.

The TX does seem to be high, so I figured what the heck, and soldered some headers on.

Is the logic normal TTL 3.3V ?
Would it be possible to directly attach a standard USB2TTL converter ?

Great work BTW :-)

[cb831a]

Is the logic normal TTL 3.3V ?
Would it be possible to directly attach a standard USB2TTL converter ?

I 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 above

The protocol is not fully stable - sending w/m sometimes returns ...E3 73 E3 73... gibberish (I think)

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.

Unfortunately 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 observations

Byte 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 int
Executing m will and int with FF80 if already initialized to FFxx

Byte 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.

[djnebs]

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: [Select]

MSP430Flasher.exe -a -n MSP430F4152 -z [VCC] -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

[djnebs]

The short term average number on the LCD can be found at 2 addresses in RAM: 0x36c and 0x3e4
I 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: [Select]

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 0x370

Presumably 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 it

It 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?

[cb831a]

Cool work @djnebs

I'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