Coincidence Detector
9 years 3 months ago - 9 years 3 months ago #530
by mw0uzo
That's not difficult to write, even easier if the initlal version is limited to 2 tubes for L and R channels. It's interesting enough to me to decide about starting the changes to RadLog v0.42. RadLog for Android has been started too, got the settings screen done before Christmas - but I have not had any time to continue that yet. Maybe first version would write to a text log in RadLog shared data to view possible coindicent events. If several detectors across radmon.org registered the same time, that would certainly be an event? We could decide what the time window should be and see what sort of time reporting accuracy can be got. Then perhaps version after that could decide for itself if a solar event was detected.
Great ideas everyone, four of us running two counters should get this started
We won't have a great resolution for a long time, but I disagree about data from a non-uniform detector network. It is easy to process/normalise/detect % change/use uSv/hr/apply statistical functions etc. The more data the better, and a variety of detector types is a bonus IMO as you can compare between tube models. The processing would still have to be done on a 'uniform' detector network, because of natural variability of tubes etc. And for a properly uniform detector network, each tube would have to be carefully tested and selected, then calibrated with a point source in laboratory conditions with regularly calibrated test equipment and source checking which is beyond the means of any civilian network operating at this time. And returned for calibration every 12 months!
Replied by mw0uzo on topic Coincidence Detector
Celestial events radiate in all directions spherically, but the intensity will vary due to magnetic and gravitational influences, and what kind of an event it is, but when they reach us, they are enough that pairs not only will exist, but can be detected. We are bombarded from all directions so it might be difficult to decide WHAT might be matching incidents. (even expensive particle detectors have a impossible time with amplitude and direction of the same particle. And the problem of different tube types... Its more a novelty. But at the same time, I don't doubt at all that a sunspot wave could be detected like this. We have very little resolution and not a uniform detector network so the data isn't really useful for much more than curiosity. And might not be worth the coding work, unless you really wanna make the front page of hackaday.com, if the data can be parsed.
That's not difficult to write, even easier if the initlal version is limited to 2 tubes for L and R channels. It's interesting enough to me to decide about starting the changes to RadLog v0.42. RadLog for Android has been started too, got the settings screen done before Christmas - but I have not had any time to continue that yet. Maybe first version would write to a text log in RadLog shared data to view possible coindicent events. If several detectors across radmon.org registered the same time, that would certainly be an event? We could decide what the time window should be and see what sort of time reporting accuracy can be got. Then perhaps version after that could decide for itself if a solar event was detected.
Great ideas everyone, four of us running two counters should get this started
We won't have a great resolution for a long time, but I disagree about data from a non-uniform detector network. It is easy to process/normalise/detect % change/use uSv/hr/apply statistical functions etc. The more data the better, and a variety of detector types is a bonus IMO as you can compare between tube models. The processing would still have to be done on a 'uniform' detector network, because of natural variability of tubes etc. And for a properly uniform detector network, each tube would have to be carefully tested and selected, then calibrated with a point source in laboratory conditions with regularly calibrated test equipment and source checking which is beyond the means of any civilian network operating at this time. And returned for calibration every 12 months!
Please Log in or Create an account to join the conversation.
9 years 3 months ago #531
by Frank
Replied by Frank on topic Coincidence Detector
What made me think of this project some time ago, when I first started with the radiation/geiger counter and at work sitting in my truck at lunch. I was still kinda new to it and when I happen to be checking out my GMC-080 model, I popped the top cover and was checking out the circuit and was a bit of a cloudy day so I moved it near the window for more light and it went nuts. At that time, I didn't know the effects of the sun had a impact on the tube. I inquired, I believe here about it and was told oh ya, that will happen if exposed to the light from outside. That gave me the idea to maybe make some sort of half moon shaped dome, line it with some different shades or tint, enough to get the tube somewhat quiet. Then I could use it for some solar events to monitor. I already have a SID setup running here now so I'm use to solar events with that system. 
Please Log in or Create an account to join the conversation.
9 years 3 months ago - 9 years 3 months ago #538
by Frank
Hum, after reading this last paragraph, I can understand that. Good point Dan! Ya, there is one network now running the same type unit so all the ones out there "assuming" provide data from the same type of unit. Can't wait to try the BETA of .42. My spare PC, which at this time is not connected to the LAN due to the lack of ports on my current router can test the dual audio channel version locally. Matter of fact, going to try it with the current version we are running now. Frank
Replied by Frank on topic Coincidence Detector
Celestial events radiate in all directions spherically, but the intensity will vary due to magnetic and gravitational influences, and what kind of an event it is, but when they reach us, they are enough that pairs not only will exist, but can be detected. We are bombarded from all directions so it might be difficult to decide WHAT might be matching incidents. (even expensive particle detectors have a impossible time with amplitude and direction of the same particle. And the problem of different tube types... Its more a novelty. But at the same time, I don't doubt at all that a sunspot wave could be detected like this. We have very little resolution and not a uniform detector network so the data isn't really useful for much more than curiosity. And might not be worth the coding work, unless you really wanna make the front page of hackaday.com, if the data can be parsed.
That's not difficult to write, even easier if the initlal version is limited to 2 tubes for L and R channels. It's interesting enough to me to decide about starting the changes to RadLog v0.42. RadLog for Android has been started too, got the settings screen done before Christmas - but I have not had any time to continue that yet. Maybe first version would write to a text log in RadLog shared data to view possible coindicent events. If several detectors across radmon.org registered the same time, that would certainly be an event? We could decide what the time window should be and see what sort of time reporting accuracy can be got. Then perhaps version after that could decide for itself if a solar event was detected.
Great ideas everyone, four of us running two counters should get this started
We won't have a great resolution for a long time, but I disagree about data from a non-uniform detector network. It is easy to process/normalise/detect % change/use uSv/hr/apply statistical functions etc. The more data the better, and a variety of detector types is a bonus IMO as you can compare between tube models. The processing would still have to be done on a 'uniform' detector network, because of natural variability of tubes etc. And for a properly uniform detector network, each tube would have to be carefully tested and selected, then calibrated with a point source in laboratory conditions with regularly calibrated test equipment and source checking which is beyond the means of any civilian network operating at this time. And returned for calibration every 12 months!
Hum, after reading this last paragraph, I can understand that. Good point Dan! Ya, there is one network now running the same type unit so all the ones out there "assuming" provide data from the same type of unit. Can't wait to try the BETA of .42. My spare PC, which at this time is not connected to the LAN due to the lack of ports on my current router can test the dual audio channel version locally. Matter of fact, going to try it with the current version we are running now.
Frank Please Log in or Create an account to join the conversation.
9 years 3 months ago #541
by bethsalem
I'm really pleased that this is becoming a viable project
Replied by bethsalem on topic Coincidence Detector
Started some changes for the coincidence detector this evening. Got the two channels sampling and displaying on the audio graph.
I'm really pleased that this is becoming a viable project
Please Log in or Create an account to join the conversation.
Moderators: Gamma-Man
Time to create page: 0.249 seconds