| T O P I C R E V I E W |
| Sonicmixmaster |
Posted - 09/26/2019 : 19:48:13
https://www.gmcmap.com/historyData.asp?Param_ID=31921055058
This is my counter and I am getting unexplained spikes on my counter. I have looked at other counters in my area and do not see spikes like mine. I get the spike of above 100 approximately once every hour. Frequently they are above 500 CPM which is impossible. |
| 9 L A T E S T R E P L I E S (Newest First) |
| Sonicmixmaster |
Posted - 10/02/2019 : 23:38:43
I have noticed several problems with the software in the past. It seems that whoever is in charge of programming it does not double check his/her work. I have seen spelling mistakes and also the way it functions. So I’m not surprised that it is the software problem here. I am going to mention this again as I have said it before that paying $300+ for any equipment should have a bit more of a professional feeling when trying to use it. I am beyond frustration at this point and have yet been able to reliably use it as I intended based on how the device has been advertised and based on my research of the features of the device on the GQ Electronics website. |
| ullix |
Posted - 10/02/2019 : 22:34:00
Looks like an agreement to my gut feeling. The GQ software seems to have made the spikes!
|
| Sonicmixmaster |
Posted - 10/02/2019 : 17:32:23
Before my counter was killed by the new 1.32 firmware, I set it up to upload data through WIFI and there were no spikes. If you look at the link from the first post you will see that the most recent history data was all done with WIFI and there were no spikes. While on WIFI I first had it sending readings every 2 minutes (default), then I changed it to 5 minutes and then to 10. Then I updated the data viewer software to latest version and my counter no longer was able to perform any real time readings with the USB cable connection. And as of yesterday the counter is dead. I am now on email support with Mark and we will see what happens next. So before the firmware killed the counter I think there is a problem with the software reading the device with spikes in the 100+ CPM range. On WIFI I don't think it hit even 50 CPM but I did not waste time reading all the history recorded. I did see a few of 40+ CPM readings in there but those I would consider the counter's margin of error. 100+ with software is unacceptable. |
| ullix |
Posted - 10/02/2019 : 09:21:36
@Sonicmaster: There isn't that much more to understand between two simple statements:
1) Regular spikes are there, coming every hour
2) The counter otherwise seems to be functioning ok
Question remains: are the spikes coming from external sources, or are they part of the counter PLUS its software utilities.
I have no answer, but my gut feeling is: it has to do with the interaction of counter and desktop-software, i.e. the spikes are created in the reading out and/or processing of the data by the software on the computer.
I suggest a few tests; each one running for a few hours (~6h?).
1) disconnect the counter from the computer - use it stand-alone! - then download the data. Still spikes?
2) Use GeigerLog to download the data
3) Use GeigerLog and do connect the counter, and let GeigerLog do the logging.
Good luck.
|
| Sonicmixmaster |
Posted - 10/01/2019 : 04:59:18
Model GMC-600+
Revision 1.141
Serial xxxxx |
| EmfDev |
Posted - 09/30/2019 : 10:29:44
What is the firmware version in you unit? |
| Sonicmixmaster |
Posted - 09/28/2019 : 13:36:02
To ullix: Thanks for the detailed analysis but honestly I am having trouble understanding most of it. I can tell you that I am using the cable that came with the unit and the computer is next to my back yard window where the counter is sitting on the window ledge. I will try to find a longer cable and see if I can move the counter a bit higher and away from pc.
To EmfDev: The pc that is running this is a i7-7700K stock speeds, 32 gb ddr4 ram 512 gb ssd and has amd rx580 gpu. I do not have any software set to run every hour and I am using GQ GMC Data Viewer STD V2.57. I will download the new one and change cable to a longer one and try to see if anything changes. Thanks.
By the way. your new 2.60 software was showing readings of 4000+ as soon as I upgraded. I am sending data now every 2 minutes over WIFI. Something is wrong with your 2.60 version. Also, the map sever clock is off by on hour. My readings are showing 1 hour behind on the map and I have my user profile correctly set to my time zone and I synced the counter time with pc with your software. |
| EmfDev |
Posted - 09/27/2019 : 09:48:11
Hi Sonicmixmaster, do you see the spikes on your unit? or just on the website? The 2.57 has a CPM bug. There is new software version uploaded on the website. |
| ullix |
Posted - 09/27/2019 : 05:17:39
Indeed, the first look confirms that something is awfully wrong with the data!
I was curious whether the underlying background (was it background or some source?) data were proper, just overlaid with the spikes, or whether the background data themselves indicate a deeper problem.
Fortunately, the map website allows downloading the data in CSV format, so I downloaded "this page" - about 42h worth of data - fed it to GeigerLog, and pressed the FFT button. Result is in next picture.
Image Insert:
152983 bytes
The top left figure shows the usual Time Course of CPM over time. The spikes are obvious, as is their regularity. Thus doing an FFT and Autocorrelation is appropriate.
The bottom left figure shows the autocorrelation (BLUE scale!), and the peaks at 1 and 2h are designated with golden "Easter eggs" markers. Similarly, the right side shows the FFT amplitudes over time (top), and over frequency (bottom). The markers show the 1h basic period, plus the harmonics.
The spikes occur regularly at close to 1h intervals.
Next step was to remove the spikes, and reanalyze the presumed background data. The open source SQL database browser "DB Browser for SQLite" (my recommendation, see GeigerLog manual for details) does a wonderful job in analyzing a file like GL's *logdb files.
The background data reach a max of 45, then comes a jump to spikes from 152 to 1170 CPM. I deleted all spikes and reloaded the cleaned db file into GeigerLog. Result in next picture, together with a Poisson-Test image.
Image Insert:
104601 bytes
The average of 29.5 CPM may be a bit on the high side when I compare this to my data, though it may be expected in your area. Is that so or is it high for you too?
Otherwise, there is nothing to complain about the data. The Poisson curve (thick red line) give a good fit, r² is reasonable at 0.935, and an average of 29.51 is in almost perfect identity to the variance of 29.25. And lastly, the residuals (thin red curve at the bottom, data minus Fit) jitter across the zero line with no discernible patter.
So, the background data look good. very good actually, except that they may be high.
My first expectation was a hardware defect of the counter, but now I am wondering, whether external effects played a role: air-conditioner? machinery? mobile-phone access?
But none seem to make such a regular pattern? (You did check for light sensitivity?)
|
|
|
