Well the dose depends on several factors, that include energy and type of radiation.
The geiger tubes are unable to provide such information, so calculating the dose using a Geiger tube is only possible for known radiation.
This is why their datasheets often indicate a CPM to R/h factor, but always for a specific isotope, with a discrete number of emissions (like Ra226, Cs137, Co60, etc).
For convenience, uRADMonitor webpage shows a value in uSv/h, which is only an approximation, and should be considered so. On the other hand, the exact readings in CPM are provided, and the tube type for all measurements.

It is know that a geiger tube also expresses a non-linear response to energy, due to the absorption coefficient of any material that increases with decreasing energy. Practically everything below 150keV will trigger a relatively higher response in a Geiger tube.

The context for what we do here is extremely important: remember that uRADMonitor measures background radiation. This background is composed of cosmic radiation, of very high energy, and three main terrestrial components of background gammas that are K-40 1462 keV, Bi-214 1760 keV from the U decay series, and Tl-206 from the Th decay series. Smaller contributions to total background come from Pb-212 239 keV, Bi-209 609 keV, Tl-208 908 keV and Bi-214 1120 keV. The most serious non-linearity of energy response in uncompensated GM tubes occurs below 150 keV – and most of that below 100 keV – so none of the background emissions listed above will be seriously affected, nor will the majority of cosmic rays.
The most seriously affected – and, in many ways, the most interesting – part of the background gamma spectrum that will fall within the GM tube’s most non-linear energy response region is skyshine – the radiation scattered by the air above both natural and man-made sources like particle accelerators, reactors, and high-level waste dumps. Most skyshine falls below 500 keV, and most of that below 100 keV.
So this means that CPM to Gray/hr conversions, using manufacturers data based on either Cs-137 or Co-60 will not be too inaccurate to be of use across the natural background gamma spectrum.

Regarding the conversion made in uRADMonitor, the following aspects have been used:
– the uRADMonitor units send radiation measurements as CPM
– the server calculates the approximation in Sv/h, to serve as a reference, using the CPM value and the specific tube type information.
– any changes in this calculation will be done on the server, and doesn’t impact in any way the units already deployed

To derive the best conversion value, the following approach has been performed, separately for all tubes used:
– measure the background radiation in CPM, over a long time interval (>4h) and scale it against measurements in uSV/h done with calibrated dosimeters (Three have been used: Gamma Scout, Terra-P, Radex 1706)
– measure the radiation in CPM when exposed to different radioactive samples (Th232, Cs137, Ra226), scale it against measurements done with calibrated dosimeters. Repeat for different geometries (increasing distance).
– average the results, and compute a linear factor to use with the CPM readings.

• This reply was modified 10 years, 9 months ago by uRADMonitor.

Peter’s list for Germany: http://en.wikipedia.org/wiki/List_of_power_stations_in_Germany

@Erik, is it possible.

The problem is the packages from both units reach the uradmonitor.com server, but they come with malformed headers (something is modifying them, maybe a proxy / antivirus / firewall, like you said). Because of the incorrect headers, the server drops these HTTP requests with HTTP 400 (bad request).

Yes!

We should start this discussion and decide how to handle such events / alarms.

The temperature is the internal temperature of the unit, as the DS18B20 sensor is mounted inside.
It is equal to the ambient temperature plus a few degrees added by internal electronic component heating (especially the Ethernet module).

It does look normal, but the header is missing. This results in the 400 Error code. The image shows a dash on each row. For other units there’s the user agent there.

What’s strange is that a few days ago, 11000016 was working fine . Did anything change in the network setup?

For Rick’s unit, 11000009 the problem was from the beginning.

But both units worked perfectly here, while running the tests.