First of all I appreciate your continous effort to build an open sensor network. Please continue your work.

However, there are serious limitations of your sensor, based on your design considerations. I have done just a few hobby avr projects and browsed through your source code. I found a severe bug:

Every time you detect an event an interrupt is triggered. In the interrupt routine you call the buzzer for a beep, after a 5 milliseconds delay the functions return to the interrupt routine again where the status flag is cleared. So accidently you introduce a 5 milliseconds dead time (much larger as the 200 mikroseconds from the tube), where no events are detected. This limits your device on high radiation measurement, above 20cps really noticeable and for eg 100cps the real rate is two times the displayed one.

Second as other people complained about not working usb ports: Your firmware makes a request for only 50 mA power from the usb port. Most of mainboards to not care about this and deliver power as demanded but some have extra protection circuits (like my nforce board) that limit the current to the requested value. I doubt the detector works with buzzer and backlight on and heavy counts.

Thank you for pointing out the issues with the detector. It is through member feedback that the project grows and the devices are debugged and become more useful.

FWIW, at 20 cps or 100 cps, what is the dosage of radiation being received at that rate. Is this a dose that is realistically going to be seen? If so, how long before the person there is cooked?

The maximum dose 'allowed' is 20 mSv/yr. 20 milli sievert a year.

I am assuming one 'click' = .01 uSv/h

20 CPS assuming you mean 'clicks per second', If I am wrong correct me please.
That would be 12 uSv/min 720 uSv/hr..... Roughly 1 mSv/ per hour and a half.

1.25 days for your annual dosage.

If CPS is for Curies Per Second, again, big dose coming at you. The detector I believe was meant to be more of a background detector and if you are really in a high rad area, it becomes much more critical to know the amount for your health, so you might want to invest in a more accurate device.

If your detector sounds like the buzzer on your dryer, either way, accuracy not withstanding, you are in trouble.

Aaron
____________

I respect your input but encourage you to study the source code prior a reply.
With the implanted firmware function the detector is displaying for 20 counts per second a value of 7 micro Sieverts per hour. This value is easily achiveable with a radioactive sample.

However, measuring something with a geiger counter is all about statistics. Radioactive decay is THE classic example of a poisson process. There is no measuring trick to betray physics. The standard error in your measurements scales with 1/square root (N) where N is your number of detected counts. So to get a accurate reading with a deviation of lets say 5% you need at least 400 counts. Thats why all this fancy graphics in your signature are pretty useless for a background monitoring.

Thats why all this fancy graphics in your signature are pretty useless for a background monitoring.

I cant't test it as I do not own a detector yet (The sale was over before I found this project). But from your posted firmware

The interrupt routine

Thank you for your quick experiment. Do you know the frequency of your waveform generator? So you are using firmware v2.51 on a 1.0 platform, interesting. What are the exact differences between sensors version 1, 2, 2.5, 3 and how many subversions are there?

The source code archive is called "RadAc_V2.5.zip" so I assume this is the latest firmware, but who knowes? The beep function is used in the "v2 20MHz" folder. There are no v1 or v2.5 folders.

For a dead time correction normally you apply a correction factor of g =
1/ (1 − countrate · t_dead). (be sure to insert right units)

v2 was the first batch sent, the hardware between v2.5 and v2 is mostly the same, except the 2.5 had some (mostly) minor glitches fixed and a couple of new features introduced.

About the USB...
We don't know why USB connection hangs. But the 50mA limitation shouldn't be a problem...

I don't want to blame anyone, as this is a nice hobby project and a wonderful public science experiment. But I don't want to take your homework either:

Your displays specs:
LCD-AC-1602E-DLA A/KK-E12 C PBF
http://sklep.avt.pl/p/pl/486756/lcd+2x16+lcd-ac-1602e-dla+akk-e12+c+pbf+blackline.html ...20mA (they call it "eco")

buzzer http://www.tme.eu/html/EN/electromagnetic-sounders-_12mm-with-generator/ramka_1024_EN_pelny.html ....30mA

so 50mA already without the ATTiny4313, the DC-DC converter, iron losses of the trafo and the Opamp.

A quick survey on the device hangs up / USB connection gets lost problem:

How long did you run the device?
What is displayed on your device?
Is the backlight on? (even if you switched it off before)
Is the text and backlight static or flashing?
Is the device displayed in windows device manager?
What is the firmware version of your device? (you get it from device manager or stderr.txt)

Thank you!
Other users might want to share their experience?

I have my backlight on all the time.

The detector works like normal, it's just that it isn't sending the data to boinc, when you check the task, you can see that it has hours elapsed and no data to it.

Most of the time it appears to hang at zero percent, but I have seen on one or two occasion where it hung in the middle of a task, like at 26 percent or something.

Aaron
____________

Just want to share my observations in a real radiation field.
I have had the opportunity to test your device in a certified calibration laboratory for radiation detectors. There, they use Cs-137 and Co-60 sources from 70 MBq to 70 TBq to generate radiation fields between 10 µSv/h up to 10 Sv/h under well-defined geometries. With an optical camera you get the readings from the detector into the control room.

One big problem during the tests was - above 100µSv/h the LCD display was too dark to see any reading. At 10 µSv/h there was no problem to visually inspect it. My suspicion was the buzzer, which probably should be turned off at higher dose rates, because its simply needs too much juice.

The main outcome of the test: for Cs-137 (gamma-lines at around 600 keV) the detector reads 40% less than it should. At 1200 keV (mean) gamma of Co-60 it is only 20% less. Measured for dose rates between 1 and 100 µSv/h.

I have done some more testing with radioactive sources in the lab, i will post some pictures later. I will try to do a comparison test with an radioactive source (buzzer on vs. buzzer off)

My detector never hangs, the buzzer is always off, the backlight is always on. I asked the manufacturer of my motherboard, it does not restrict USB devices to the current they request.

@Aaron, the script I published monitors the R@H task. If the task hangs the script attempts to reset the USB port. If you try the script and it gets the task running again then that would be confirmation of sorts. I run the script but my R@H task never hangs so I can't tell if reseting the port helps or not.

@exsafs, good to hear from you!
____________

A quick survey on the device hangs up / USB connection gets lost problem:

1. How long did you run the device?
2. What is displayed on your device?
3. Is the backlight on? (even if you switched it off before)
4. Is the text and backlight static or flashing?
5. Is the device displayed in windows device manager?
6. What is the firmware version of your device? (you get it from device manager or stderr.txt)

My hangs tend to be on an older pentium class machine running xp. ehh. probably 7 or so years old. Beat to hell old laptop. The others rarely hang if at all.
Dagorath I will try to get the supporting software installed and give your script a shot this weekend and report back how it works. That computer hangs pretty reliably every two or so days so we should get a good test of your script there hopefully.

I do want to thank you for taking the time to do the script to help the project out.

Aaron
____________

So let's combine the things.

First I loaded the firmware into the Simulator and checked the routines. I found out that as Szopler pointed out pulse counting is done with hardware counter 1. However, the mentioned interrupt routine is still there and actually serves no purpose. I think in the hardware development INT1 was onetimes used for software counting but then forgotten. Now INT1 is connected with the USB D- port and USB uses interrupt INT0 (if D+ and D- are not switched again). So it's no serious bug, it might interfere with USB under rare conditions or not but the routine should be cleaned up from the source code.

Next there is the display dimming. As TJM pointed out the display contrast is controled with a resistor network, so a certain voltage is applied to the display controller. He said allready it is sensitive to the supply voltage, so why is the supply voltage changing? Because of the current spikes! And what is the biggest power consumer ... well maybe the buzzer, for a very short period of time after the detection maybe the HV curcuit. Buzzer of is a good idea.

Third there are this USB hangups. From the survey no one was reporting a rebooting device, the error is assumed on the PC side like an error the PC is sending data to a different USB adress and the device is not aware of the change. VUSB is recommonding the monitoring by implementing suspend mode on the wiki page. Then the device is aware of the USB state and eventually reconnect. The USB signaling is done on a different 3.7 voltage, zener diodes are limiting the voltage on the device side. If the supply voltage drops under this range during usb communication transmission errors occur.

Last there are the SMB-20 tube specs. It is calibrated against Co60 and from the datasheet you get a conversion factor of ~150 to uSv/h. But normally you are interested on the fallout from accidents and so you calibrate it against Cs133 (that has another mean gamma energy and slightly other crosssection for detection), one guy found the conversion factor of ~171. So why is your reading so much off? Dead time correction for the tube may give just 5% but is done in software easily and no other bugs are found in the software. So is the tube not so sensitive?

Actually you use old STS-5 tubes, a predecessor for the SMB-20. I did not find a datasheet. Are there any users around that are able to compare those two tubes? Then you can change the conversion factor accordingly if there are any differences (or they do not have the same voltage etc....). In the firmware the conversion is done by counting all impulses in 35 second and divide it by 100 (that is exactly 171). But why is the boinc client counting in a different timespan of ~40s? (Besides I allready mentioned it is more scientific to use a much higher sampling time for small dosis and a fast alarm mode if you leave the confidence intervall of the background)

The sensor returns raw data (pulse count and it's internal timer) so the actual sample time does not matter. I'm not a fan of short sample times myself, as it just fills the database with tons of records which do not represent anything anyway, just make parsing the data harder.

Yes, you could reduce the database to at least 1/10 its current size and provide some room for growth. Is there a disadvantage to that?

There is another disadvantage... the project demonstrates that it thinks sloppiness is OK. That does not instil confidence in the community you are trying to reach.

What disadvantage is there to altering a few constants in the science application, recompiling it and collecting meaningful samples?

What disadvantage is there to admitting a mistake was made and correcting it? What advantage is there to pretending there was no mistake?

Well intentioned but naive people will use your meaningless raw data and not realise it needs to be corrected. You could avoid that by providing good data. No, putting up warning notices won't always work. Good data will always work.


____________

Short samples are not meaningless. They have one huge advantage over longer samples, which is data resolution.

it just requires specifying start/end timestamps + a little math (mysql does that with single query).

Where's the problem ?

I'm not saying that the sample_time won't be changed in the future, as the 40s is an overkill and it's mostly a leftover from one of the first apps.

There was another idea - to get every single pulse with his strict GPS position & time.

Then if we do many of the detectors isolated from Earth coming gamma radiation we will have huge gamma rays eye!

Every of the tube will acts as a pixel in digital camera. But computing power and storage need to this is HUGE

and we will need more military GPSes ;)

I got a GPS on my boat, just your standard that's accurate to a bout 2 to 3 M. Even my 5 year old handheld is good to 3M. Getting a signal inside a building depends on structure etc, however I am finding that the newer devices can lock on a LOT faster than the older ones. My old handheld used to take about a minute to wind up, the new one in maybe 20 seconds it's already locked and honing in on accuracy.

Aaron
____________

Sorry, I should have given a citation. I got the 20 meter number from this wikipedia article . See the 10th paragraph in the section titled History, partially quoted below.

Initially, the highest quality signal was reserved for military use, and the signal available for civilian use was intentionally degraded (Selective Availability). This changed with President Bill Clinton ordering Selective Availability to be turned off at midnight May 1, 2000, improving the precision of civilian GPS from 100 meters (330 ft) to 20 meters (66 ft).

Now tell me, what a 50m jump means while creating radiation map ?

I'm not sure if you noticed, but even our data export has no such accuracy, as the last digits are removed to protect privacy (still, the map and test123 both report exact position I believe).

So...where do we stand? Is this project going to change its stance and allow meaningful background radiation noise measurements (according to Dagorath/Phys and others), or should I contribute money towards another radiation project that has a better understanding of radiation decay?

I'm not a radiation expert, but from what I've read so far from Phys/Dagorath and others, the way this project is set up, it does not allow meaningful background radiation measurements as the sensor does not take reliable samples to make out the whole picture. I don't know how to try to explain it to you, as others have already put it more eloquently than I can.

The data is not meaningless if you have a different aim, like making a random password generator with input of the recorded data etc. The data IS meaningless *right now* if the aim is to measure background radiation, because it is NOT set up to accurately measure background radiation. That's my take on it anyway.

It's unfortunate that there isn't some middle-ground we can agree on and make this project better. It would be a shame to realize after many years that the project was just wasting resources instead of contributing something useful to the community.

But anyways, I will continue to watch and hope that this project will somehow be successful, whatever that mission may be. :-)

Interesting thread. I find the comments from phys very constructive and the developers should use his expertise to improve the project. Were those bugs corrected in the software?

On the other hand, Dagorath's loud mouth is very offensive and I'm frankly surprised he was not banned form here. His comments are totally off mark and he scared some potential volunteers away (Tino Ruiz).

On the other hand, Dagorath's loud mouth is very offensive

and I'm frankly surprised he was not banned form here.

His comments are totally off mark

and he scared some potential volunteers away (Tino Ruiz).

I'm no going to tolerate being caller lier and being insulted as an American.

How much longer Dagorath is going to insult new members with moderators not intervening?

The rules clearly state:
"No messages intended to annoy or antagonize other people, or to hijack a thread.
No messages that are deliberately hostile or insulting.
No abusive comments involving race, religion, nationality, gender, class or sexuality."

My enthusiasm for this project is rapidly disappearing. I saw another active USA member who severed his ties with this project just because of this BS being allowed to happen.

Over and out.

Bingo! You insult me first then whine about me insulting you. ROFLMAO!

I think you and Tino Ruiz are the same person. I think you created the Tino entity just so he could tell the project he's not joining which would then allow the jacek entity to bring up this bogus claim that I am a loudmouth and the cause for volunteers not joining. Like I said, that kind of nonsense is de rigeur in the USA but the rest of the world just laughs at it and now they laugh at you. This project can't keep up with the demand for detectors from new participants and Tino is the only potential volunteer to have said he's not joining yet here you are screaming blue murder about me driving participants away by speaking the truth. You and your straw man argument are hilarious! Don't stop, please. We all want to see what your next stroke of brilliance will be.

____________

Hello, I'm new here trying to get up to speed quickly.

I assume the following question pertains to revision 2.xx of your usb device but correct me if I'm wrong:

Out of all the conversation about current requested from the USB port, what is the reason for choosing such a low value? Can this value not be increased for more of a "buffer" to eliminate the debate of the buzzer or the screen taking too much current at peak usage?

Is this "issue" irrelevant to current productions of the current 3.xx series?

USB is a complicated specification and I am far from being an expert on it so I could be wrong but since nobody else seems willing to take a crack at the answer I'll give it a try on the condition that if you quote me I'll deny everything ;-)

USB is able to supply only small amounts of current, 500mA IIRC. If the sum of the currents required by all of the USB devices on any leg (say node) exceeds the limit then I believe that leg protects itself by shutting down. I think each device on any given leg must declare how much current it needs and if the sum of the declarations exceeds the limit then the last device is assumed to be the offender and is denied access, or something like that.

That concern is part of the USB limitation (it's intended primarily for comms not power supply) so it will be a concern for any detector that uses USB. I don't know why it was a potential issue for this project's device. Please refresh my memory if I seem to have forgotten or appear to be unaware of previous discussions/concerns.
____________