micro-usb on radon detector

[cb831a]

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 ?

[cb831a]

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 

[cb831a]

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.

[djnebs]

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.

[cb831a]

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.

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

[cb831a]

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 

[djnebs]

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.

It will simply not count on time (DAT0_375,376,377,1080) if there are pending chars in the 2e0 buffer to be transmitted.

I didn't appreciate this earlier. I see it now, you are right.
It decompiles to something like this:

Code: [Select]

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

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];
  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.

[cb831a]

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 contains

Code: [Select]

:10FD8000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF83
:10FD9000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF73
:10FDA000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF63
:10FDB000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF53
:10FDC000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF43
:10FDD000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF33
:10FDE000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF23
:10FDF000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF13



[djnebs]

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.

[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

Good - I just wanted to make sure that the area was reset !
I do understand the format and I read it as 128 0xff bytes :-)

It's worth pursuing the logic that clears 0xFD80 on boot to complete our understanding.

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

[cb831a]

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 ?

[djnebs]

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.

[cb831a]

OK tried to hook up a repeating algorithm with this code

Code: [Select]

main code in python

    ser = serial.Serial('com21', timeout=1, baudrate=4800) # open serial port
    radon = 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) == payload

    avg1 = 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 powershell

    while (1)
    {
        $stamp = [DateTime]::Now.Tostring('o');
        $bytes = (.\SerialPort\bin\Debug\SerialPort.exe -cCOM21  -f1 w  quit)[1]
        $retries = -1
        do
        {
            $ok = 1
            $res = 1
            foreach ($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 this

Code: [Select]

C:\workSave\Airthings> .\loop.ps1
2024-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=1
2024-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 died



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

[cb831a]

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

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,00
2024-01-05 23.48.00 2024-01-05T23:48:00.0000000Z   851,00    21,00  1012,44      89,00      91,00       25,96   490,00
2024-01-05 23.49.00 2024-01-05T23:49:00.0000000Z   866,00    21,00  1012,52      89,00      91,00       26,05   476,00
2024-01-05 23.53.00 2024-01-05T23:53:00.0000000Z   866,00    21,00  1012,52      89,00      91,00       26,05   476,00
2024-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
:
:


[djnebs]

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.

I wondered if you really meant "!" (write buffer) instead of ";" ?

Sorry, 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 

[djnebs]

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-radon

Which 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=.pdf
https://patentimages.storage.googleapis.com/0b/d5/34/bd2cd789fa35f3/US10534094.pdf

[cb831a]

If you get a chance, maybe setup another 24 hr test, again comment out the payload writing, and run something like this:

Included this in the code

Code: [Select]

        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 successfully
            assert radon.read_from_flash(radon.PAYLOAD_LOCATION) == payload


Sorry, my mistake.

Fixed

My last measurement did not fail but 1-day-avg-radon fell from 115 to 25 in some 15h :-(

Code: [Select]

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.

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.

Agree on that

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

That should allow us to find the code that does the first initial statistical analysis.

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-radon

Read that !

Which 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=.pdf
https://patentimages.storage.googleapis.com/0b/d5/34/bd2cd789fa35f3/US10534094.pdf

That'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.

[cb831a]

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

C:\workSave\Airthings> .\loop.ps1
2024-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)


[cb831a]

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.

[cb831a]

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

[cb831a]

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 0
Connecting both TX and RX - same as RX only.
Connecting TX only let the dectector work normally.

Connected scope

Not connected I see
TX on USB2TLL on 3.3V DC no AC/noise
RX on USB2TLL on 3.3V DC no AC/noise
RX on detector on 0V DC + 20-40mV 50Hz hum
TX on detector on 2.5V DC no AC/noise

Connected I see
TX on USB2TLL/RX on detector on 3.1V DC no AC/noise
RX on USB2TLL/TX on detector on 2.5V DC no AC/noise

So 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 connected
Maybe 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.

[djnebs]

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?

[cb831a]

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?

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

[cb831a]

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 server

Code: [Select]

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=13
2024-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=13
2024-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=13
2024-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=13
2024-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=13
2024-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=13
2024-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=13
2024-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=13
2024-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=13
2024-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=13
2024-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=13
2024-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=13
2024-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=13
2024-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=13
2024-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=13
2024-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=13
2024-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=13
2024-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=13

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

[coppercone2]

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.