Sieverts (Ionizing Radiation)

[Clay Jackson]

Here's one a bit "off the wall" - I happen to live near Hanford, WA (2nd largest radiation cleanup site in the world, behind Chernobyl) and I'm also interested in "Space Weather".  So, when mightyohm (www.mightyohm.com) put their Geiger counter on sale last year, I snapped one up.  I have it connected to a pi and reporting microSieverts/hour to MQTT and on the weewx.   

Right now, I'm using signal1 as the "bucket" to hold the data; but, I got to thinking about adding it as a data type with units.  Looks pretty straightforward and I'll certainly share.  I was wondering if anyone else has thought about this, or perhaps has already done it.

One "interesting side effect" is that right now there's already a database field named "Radiation", which might be more accurately named "Insolation".  Not sure yet what I'm going to do about that.

Anyone have any thoughts/suggestions?

[Greg Troxel]

Clay Jackson <cl...@n7qnm.net> writes:

> Here's one a bit "off the wall" - I happen to live near Hanford, WA (2nd
> largest radiation cleanup site in the world, behind Chernobyl) and I'm also
> interested in "Space Weather". So, when mightyohm (www.mightyohm.com) put
> their Geiger counter on sale last year, I snapped one up. I have it
> connected to a pi and reporting microSieverts/hour to MQTT and on the
> weewx.
>
> Right now, I'm using signal1 as the "bucket" to hold the data; but, I got
> to thinking about adding it as a data type with units. Looks pretty
> straightforward and I'll certainly share. I was wondering if anyone else
> has thought about this, or perhaps has already done it.

Great to hear this. I have a mightyohm kit I need to build.

> One "interesting side effect" is that right now there's already a database
> field named "Radiation", which might be more accurately named
> "Insolation". Not sure yet what I'm going to do about that.

Or it should be called "Solar Radiation". But that and your uSv/h data
are both radiation; one is EM and one is ionizing. And then there's
radiative heat transfer.

However, 1) the name is already in use and changing it seems out of the
question and 2) weewx is a *weather* program that can also do other
things, so it makes sense that terms are interpreted in a "weather
first" way.

> Anyone have any thoughts/suggestions?

So the question is what to call it. I would call the field
ionizing_radiation and add uSv/h as a unit, unless somebody has a better
idea.

[Cameron D]

" ionizing_radiation " would be an obvious and unambiguous choice.

I'd be reluctant to rely on the uSv/hour value, unless you know the source.  The Geiger-Muller tube electronics looks like it is just reporting ionisation events per second, with no measure of the energy.  Any "calibration factor" used will be assuming a specific source of radiation, which is unlikely to be appropriate to this situation.

So long as you keep his in mind I guess you can use whichever unit you prefer - it's the change that would be important.

[Greg Troxel]

"'Cameron D' via weewx-development" <weewx-de...@googlegroups.com>
writes:

> " ionizing_radiation " would be an obvious and unambiguous choice.

I guess there are two observations, one is counts/s and the other some
estimate of uSv/s. But given the weewx approach, I think it makes
sense to let the input device attempt to estimate into some standard units.

> I'd be reluctant to rely on the uSv/hour value, unless you know the
> source. The Geiger-Muller tube electronics looks like it is just reporting
> ionisation events per second, with no measure of the energy. Any
> "calibration factor" used will be assuming a specific source of radiation,
> which is unlikely to be appropriate to this situation.

That's fair, but lots of people measure illuminance and estimate solar
irradiance, or ther other way around, and that's structurally simiar.

So there's still the best estimate you have, which is true, for various
values of "not quite right", for everything.

> So long as you keep his in mind I guess you can use whichever unit you
> prefer - it's the change that would be important.

I think it's good if there are at least standard names so when multiple
people do this, they can share skin code.

[Glenn McKechnie]

Hi Clay,

The original UradMon A3 (https://www.uradmonitor.com/) had, along with
various other environment sensors, a gieger counter that registered in
cpm.

I've recently updated the driver
(https://github.com/glennmckechnie/weewx-uradmon) for it to return
microSieverts/hour rather than its default of cpm.

Rather than use the inbuilt group_radiation which defaults to W/m2 I
created group_ion_radiation (ionizing) and set cpm, micro_sievert as
its units (which probably should have been micro_sievert/hour -
Bugger).
That gave the flexibilty to enforce its unusual, but default, cpm
value; convert to micro_sievert/hour and keep it all self contained
(for the driver only). It also uses other units which are now in
weewx, but weren't when the driver was written. I've kept them for
backwards compatability.

https://github.com/glennmckechnie/weewx-uradmon/blob/master/bin/user/uradmon.py

> --
> You received this message because you are subscribed to the Google Groups
> "weewx-development" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to weewx-developm...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/weewx-development/46f8b906-e84f-4243-b907-9b1e91caf5a2n%40googlegroups.com.
>


--


Cheers
Glenn

rorpi - read only raspberry pi & various weewx addons
https://github.com/glennmckechnie

[glenn.m...@gmail.com]

The topic has advanced a little since my first post that went MIA. Now that it has been released from group quarantine (Thanks Tom)  I'll attempt to add a little more to the discussion.

I've since updated the uradmon driver to use micro_sievert_hour (as it should have been from the start)

The group is still group_ion_radiation - that's one for Tom to sort out, if it makes it into weewx. It certainly can't be group_radiation as that's taken.

I had a look at the mighty Ohm unit and it also appears to output cpm, rather than micro_sievert_hour. A conversion is used in the original tutorial of approx 190:1 (up to 230:1 within the larger dataset given) to get to micro_sievert_hour.

I then found a link to some perl software for the Mighty Ohm where a value of approx 175:1 (cpm * 0.0057) is used.

The original UradMon Kit1 unit which is open source uses 158:1 for the SBM-20 tube.

When I was adding micro_sieverts_hour to the uradmon driver I found it can only be (as mentioned in previous posts) an approximation. There's a link in the uradmon driver with a couple of references, one states that.

'Note 2:
In the case of your updated question in the comments, technically there isn't
really a direct equation converting counts per minute (CPM) to microsieverts
because CPM is an electron count and microsieverts is a count of bodily damage.'

Which is a pretty good summary.

But that said, they still give a measure. Plus, whatever it is, we're after a low value, whether that's in clicks or sieverts!

[Glenn McKechnie]

Clay,

I've extracted the group_ion_radiation entries from the uRadMon driver
and copied them to /user/extensions.py (which itself is from
weewx-4.6.0)

If you save your copy and replace it with the attachment, then place
the following stanza wherever it's needed (under whatever skin you're
using in weewx.conf) then you should have working values for
micro_sieverts_hour in that skin.

[[[Units]]]
[[[[Groups]]]]
# Radiation options are 'cpm' or 'micro_sievert_hour'
group_ion_radiation = micro_sievert_hour

Anywhere else and they'll show up as cpm as that is the default under
that extensions.py example (because the uRadMon driver it was taken
from emits cpm)

Finally, change the weewx.units.conversionDict.update entries in
extensions.py to reflect your values (mine are 0.00909 & 110) and
you'll get the micro_sievert_hour value to suit your setup.

On 18/03/2022, glenn.m...@gmail.com <glenn.m...@gmail.com> wrote:
> The topic has advanced a little since my first post that went MIA. Now that
>
> it has been released from group quarantine (Thanks Tom) I'll attempt to
> add a little more to the discussion.
>
> I've since updated the uradmon driver

> <https://github.com/glennmckechnie/weewx-uradmon/blob/master/bin/user/uradmon.py>

>
> to use micro_sievert_hour (as it should have been from the start)
>
> The group is still group_ion_radiation - that's one for Tom to sort out, if
>
> it makes it into weewx. It certainly can't be group_radiation as that's
> taken.
>
> I had a look at the mighty Ohm unit and it also appears to output cpm,
> rather than micro_sievert_hour. A conversion is used in the original
> tutorial

> <https://mightyohm.com/blog/2012/02/tutorial-geiger-counter-data-logging/>

> of approx 190:1 (up to 230:1 within the larger dataset given) to get to
> micro_sievert_hour.
> I then found a link to some perl software

> <https://mightyohm.com/forum/viewtopic.php?f=15&t=3504&p=10357&hilit=cpm#p10357>

>
> for the Mighty Ohm where a value of approx 175:1

> <https://www.chankly.com/geiger/usv.html> (cpm * 0.0057) is used.
>
> The original UradMon Kit1 unit <https://github.com/radhoo/uradmonitor_kit1/>

>
> which is open source uses 158:1

> <https://github.com/radhoo/uradmonitor_kit1/blob/master/code/geiger/detectors.cpp>

>
> for the SBM-20 tube.
>
> When I was adding micro_sieverts_hour to the uradmon driver I found it can
> only be (as mentioned in previous posts) an approximation. There's a link
> in the uradmon driver with a couple of references, one states that.
>

> *'Note 2:*
>
>
> *In the case of your updated question in the comments, technically there

> isn't really a direct equation converting counts per minute (CPM) to
> microsieverts because CPM is an electron count and microsieverts is a count
>

> of bodily damage.'*

>
> Which is a pretty good summary.
>
> But that said, they still give a measure. Plus, whatever it is, we're after
>
> a low value, whether that's in clicks or sieverts!
>
> On Friday, 18 March 2022 at 11:01:48 am UTC+11 glenn.m...@gmail.com wrote:
>
>> Hi Clay,
>>
>> The original UradMon A3 (https://www.uradmonitor.com/) had, along with
>> various other environment sensors, a gieger counter that registered in
>> cpm.
>>
>> I've recently updated the driver
>> (https://github.com/glennmckechnie/weewx-uradmon) for it to return
>> microSieverts/hour rather than its default of cpm.
>>
>> Rather than use the inbuilt group_radiation which defaults to W/m2 I
>> created group_ion_radiation (ionizing) and set cpm, micro_sievert as
>> its units (which probably should have been micro_sievert/hour -
>> Bugger).
>> That gave the flexibilty to enforce its unusual, but default, cpm
>> value; convert to micro_sievert/hour and keep it all self contained
>> (for the driver only). It also uses other units which are now in
>> weewx, but weren't when the driver was written. I've kept them for
>> backwards compatability.
>>
>>
>> https://github.com/glennmckechnie/weewx-uradmon/blob/master/bin/user/uradmon.py