GQ Electronics Technical Support Forum Active Users: / Visits Today:
Highest Active Users:
GQ Electronics Technical Support Forum
Home | Profile | Register | Active Topics | Members | Search | FAQ
Username:
Password:
Save Password
Forgot your Password?

 All Forums
 GQ Electronics Forums
 2.GQ Geiger Muller Counter
 GMC320+V4 pulsative high CPM

Note: You must be registered in order to post a reply.
To register, click here. Registration is FREE!

Screensize:
UserName:
Password:
Format Mode:
Format: BoldItalicizedUnderlineStrikethrough Align LeftCenteredAlign Right Horizontal Rule Insert HyperlinkInsert EmailInsert Image Insert CodeInsert QuoteInsert List Spell Checker
   
Message:

* HTML is OFF
* Forum Code is ON
Smilies
Smile [:)] Big Smile [:D] Cool [8D] Blush [:I]
Tongue [:P] Evil [):] Wink [;)] Clown [:o)]
Black Eye [B)] Eight Ball [8] Frown [:(] Shy [8)]
Shocked [:0] Angry [:(!] Dead [xx(] Sleepy [|)]
Kisses [:X] Approve [^] Disapprove [V] Question [?]

   Insert an Image File
Check here to include your profile signature.
    

T O P I C    R E V I E W
harley Posted - 07/10/2019 : 20:00:59
I have been using my GMQ320+V4 for 10 days, and have been realtime- monitoring both indoor and outdoor ionizing radiation level. There have been so many high readings in realtime data, which range from 150 to 400 CPM, and each episode lasts about 1 minute. When looking at downloaded data, 128 and 192 CPM of one second length could be found associated with most of the high readings.But such high readings could not be found in downloaded history data. I do not know the reason for this, is it false reading or true record of radiaiton level?
31   L A T E S T    R E P L I E S    (Newest First)
bradcarnage Posted - 12/14/2023 : 04:21:54
hardware is being detected as GMC 300 Re 6.7
bradcarnage Posted - 12/05/2023 : 15:59:01
I am also getting the occasional erroneous readings of 128CPM on option GMC-300Re 2.0x, and with the GMC-300 option. App program states STD V2.65
EmfDev Posted - 07/19/2019 : 10:28:40
The first batch contains 8 bits, first two bits are 10/11, and other 6 are also data so other 6 + 8 = 14 bits of data sent to the software.
harley Posted - 07/19/2019 : 10:09:07
But you have mentioned previously that 'These are 16 bits data being sent in 2 batches with 8 bits each'. What I preceive is that the first batch 'obrrxxxxxxxx'is responsible for quality of data and the second bacth for CPS.
quote:
Originally posted by EmfDev

I'ts 16 'bits' and not 8 bits. so maximum CPS can be up to 65536.

EmfDev Posted - 07/19/2019 : 09:04:59
I'ts 16 'bits' and not 8 bits. so maximum CPS can be up to 65536.
harley Posted - 07/19/2019 : 03:13:43
When calculated on the scale of second, the intensity of radiation dose exposure level is at least hundred-fold higher than normal, such as when filming a chest X-ray. I don't know what the actual reading is, when my GMC320plus is exposed to a standard medical X-ray. Would the CPS be much higher? Since the last eight bytes sent to software represent CPS recorded by the device, 10000000/11000000 is already very big number,there seems only very limited capacity for even bigger numbers to be displayed. Is that correct?
EmfDev Posted - 07/18/2019 : 12:03:54
In data set #2, the CPS is still correct. As the saved data doesn't have 10/11 in the beginning. It doesn't add it when saving. It only adds them to the data being sent to the software. Maybe they can be created but the software now needs to check for the 10/11 at the beginning to check if data is valid or not.
harley Posted - 07/18/2019 : 11:47:02
When invalid data are created, say 128, what CPS can be found in relevant #2 history data set? Can other numbers, for example 123,125 or 127 also be created theoretically?
quote:
Originally posted by EmfDev

1. That is correct, 'recorded in the device' is data set #2. The one you use "Download History" for. It's in the GMC unit.
2. The GMC300/320 unit sends 16 binaries to the software. Lets say unit detects 0 CPM for 1 second, then it will send either 1000000000000000 or 1100000000000000. These are 16 bits data being sent in 2 batches with 8 bits each. First is 11000000 and then next is 00000000. 128/192 appears because the software received it as 00000000 first then 11000000 so the data became 0000000011000000 and the software didn't check the 10/11 in the beginning.
3. The 0b isn't sent it just signifies that the next digits are in binary. I think it's from the orientation of the device. 11 if it's upside down. The unit always sends the correct data so the unit is never wrong. That's why the software is updated because it didn't check those bits when receiving data.

EmfDev Posted - 07/18/2019 : 11:25:23
1. That is correct, 'recorded in the device' is data set #2. The one you use "Download History" for. It's in the GMC unit.
2. The GMC300/320 unit sends 16 binaries to the software. Lets say unit detects 0 CPM for 1 second, then it will send either 1000000000000000 or 1100000000000000. These are 16 bits data being sent in 2 batches with 8 bits each. First is 11000000 and then next is 00000000. 128/192 appears because the software received it as 00000000 first then 11000000 so the data became 0000000011000000 and the software didn't check the 10/11 in the beginning.
3. The 0b isn't sent it just signifies that the next digits are in binary. I think it's from the orientation of the device. 11 if it's upside down. The unit always sends the correct data so the unit is never wrong. That's why the software is updated because it didn't check those bits when receiving data.
harley Posted - 07/18/2019 : 10:23:36
Thank you so much. It seems that key point in understanding the operational mechanisms is being approached.Please allow me to form a package of questions that, if solved, would facilitate the progress.
1. By stating"Every second the unit detects a count/radiation/s, these numbers are stored in the history data within the device every second/minute/hour depending on your save settings", you are indicating history data set #1 (CPS) or #2? From my understanding, history data set #1 is stored in the software, while #2 is recorded in the device, so it should be #2. Is it right?
2. How are invalid binaries 10000000/11000000 (Decimal 128/192) created and why only these two binaries are seen?
3. What is the mechanism controlling whether 10/11 should be added after 0b? Why, in case of such invalid data, is the real-time monitoring still showing false high readings rather than indicating error,since the internal feedback mechanisms should have informed about the bug?
quote:
Originally posted by EmfDev

Every second the unit detects a count/radiation/s, these numbers are stored in the history data within the device every second/minute/hour depending on your save settings. In addition to that, if connected to the pc, it will also send this data (counts per second) the the pc software, however, this data is modified to add the 0b11 or 0b10 at the beginning of the data so we can make sure it's a real data when the software receives it.

EmfDev Posted - 07/18/2019 : 08:49:51
Every second the unit detects a count/radiation/s, these numbers are stored in the history data within the device every second/minute/hour depending on your save settings. In addition to that, if connected to the pc, it will also send this data (counts per second) the the pc software, however, this data is modified to add the 0b11 or 0b10 at the beginning of the data so we can make sure it's a real data when the software receives it.
harley Posted - 07/17/2019 : 20:39:28
Hi, so glad that my understanding of the key facts is advancing with your help. How could you tell if the 128/192 is valid without my raw data, eg. where could we find the "data" sent by the unit to the software? Thanks.
quote:
Originally posted by EmfDev

Yes we are talking about different things. You are referring to the data set #2 as the history data from the device where you can't find the 128/192 (second image) correct? This history data has nothing to do with the 128/192 count. The 128/192 has something to do with the real-time monitoring software (the Data Viewer or Data Logger Pro which ever you are using for real-time monitoring). When you are using it, the software receives a 'data' from the unit every second or which we can call 'Count Per Second' or CPS. So in my previous comment, I was referring to this data (CPS) from the unit that the PC software is receiving. This 'data' contains 2 bytes and these bytes are the one we are checking if they're valid or not with the method above.

EmfDev Posted - 07/17/2019 : 14:16:19
Yes we are talking about different things. You are referring to the data set #2 as the history data from the device where you can't find the 128/192 (second image) correct? This history data has nothing to do with the 128/192 count. The 128/192 has something to do with the real-time monitoring software (the Data Viewer or Data Logger Pro which ever you are using for real-time monitoring). When you are using it, the software receives a 'data' from the unit every second or which we can call 'Count Per Second' or CPS. So in my previous comment, I was referring to this data (CPS) from the unit that the PC software is receiving. This 'data' contains 2 bytes and these bytes are the one we are checking if they're valid or not with the method above.
harley Posted - 07/17/2019 : 12:17:03
I feel kind of puzzled by the way we call two different data sets. When realtime monitoring data is downloaded, we name the corresponding data set #1. Then the other downloaded non-realtime data set is #2. The 128/192s can be traced to their original record in #1, but not in #2. Is it from this difference that you arrived at the conclusion of messed-up data?
quote:
Originally posted by EmfDev

We can differentiate it from the data being sent by the device to the pc software. As I explained earlier if the data didn't have the 0b10 or 0b11 in the beginning, it is invalid whatever the number is. It's just a software problem and not the unit. The GMC unit still records the correct data internally and can be downloaded. The pc software will be updated in the future to make it more reliable.

0b0000000011000000 ==>> invalid 192
0b1000000011000000 or 0b1100000011000000 ==>> valid 192


EmfDev Posted - 07/17/2019 : 11:02:01
We can differentiate it from the data being sent by the device to the pc software. As I explained earlier if the data didn't have the 0b10 or 0b11 in the beginning, it is invalid whatever the number is. It's just a software problem and not the unit. The GMC unit still records the correct data internally and can be downloaded. The pc software will be updated in the future to make it more reliable.

0b0000000011000000 ==>> invalid 192
0b1000000011000000 or 0b1100000011000000 ==>> valid 192
harley Posted - 07/17/2019 : 10:50:19
So many thanks. The explanation is crystal clear. But by which means can we differentiate the valid real-time 128/192 from invalid ones? Furthermore, Under what circumstances are invalid high readings prone to appearing, since their frequencies varied with time even in the same place?
quote:
Originally posted by EmfDev

Nope. The data for 300/320+ are 2 bytes or 16bits (0brrxxxxxxxxxxxxxx where r are reserved). The first 2 bits are reserved as either hex 0b10 or 0b11 . If the first 2 bits are neither of those, then the data is not valid. In your case, the data became 0b0000000010000000 for the 128 and 0b000000001100000 for the 192. These data are invalid. But if the data is 0b1000000011000000 then it is a valid 192 count.

EmfDev Posted - 07/17/2019 : 10:14:51
Nope. The data for 300/320+ are 2 bytes or 16bits (0brrxxxxxxxxxxxxxx where r are reserved). The first 2 bits are reserved as either hex 0b10 or 0b11 . If the first 2 bits are neither of those, then the data is not valid. In your case, the data became 0b0000000010000000 for the 128 and 0b000000001100000 for the 192. These data are invalid. But if the data is 0b1000000011000000 then it is a valid 192 count.
harley Posted - 07/17/2019 : 09:30:40
So you mean 128 and 192 should have been shown as two-digit numbers. Because they are above zero, there are high readings actually?
quote:
Originally posted by EmfDev

If there really is high reading then (byte1 | h0x80) > 0 or (byte1 | h0xC0) > 0 otherwise data got messed up.

EmfDev Posted - 07/17/2019 : 09:01:02
If there really is high reading then (byte1 | h0x80) > 0 or (byte1 | h0xC0) > 0 otherwise data got messed up.
harley Posted - 07/16/2019 : 22:46:29
Your presumption is thought-provoking. It is better to see if more details could fit in the frame before the surmise could finally prove true, especially triggering condition identified and verified. Is there any possibility from the intensity of the CPMs recorded or other pecularities that experimental radioactive equipment might be operated in the near surrounding? Thanks.
quote:
Originally posted by EmfDev

The 128 (h0x80) and 192 (hxC0) are supposed to be start bits of 2 bytes data. But looks like it got messed up and was read as a real data.

EmfDev Posted - 07/16/2019 : 12:57:25
The 128 (h0x80) and 192 (hxC0) are supposed to be start bits of 2 bytes data. But looks like it got messed up and was read as a real data.
harley Posted - 07/16/2019 : 12:27:25
I think I can understand a little bit now. Here I provide some observations of the problem in case further optimal modifications are needed.The intervals between high values are not random but are as multiples of 5 minutes, such as 10,15,25,30 minutes. Sometimes 2 spikes can show up in 2 successive minutes. The main componants of spikes are 128 or 192 CPMs, all are various mutiples of 64 and last no more than 1 second. Test environment affect the frequencies of high value readings, while indoor condition is a stable loci to have high frequency results.Wish more users may find the discription and discussion helpful.
quote:
Originally posted by EmfDev

It's ok, this problem occurred because the data from the device was not synced with the software. The software thought it took the right data but actually that data/bits were suppose to signify the start of the data.

EmfDev Posted - 07/16/2019 : 11:11:38
It's ok, this problem occurred because the data from the device was not synced with the software. The software thought it took the right data but actually that data/bits were suppose to signify the start of the data.
harley Posted - 07/16/2019 : 10:17:33
Sincerely hope that the new version stemed from prosepctive of function improvement and thourough analysis of reported problems, of which my cases and other similar ones may have consisted parially, and not simply deleting such "outliers".Thank you for your help and
please forgive me for being straightforward.
quote:
Originally posted by EmfDev

It's more likely that people who used the 2.59 encountered same problem. The software won't affect the sensitivity of the device.

EmfDev Posted - 07/16/2019 : 09:12:33
It's more likely that people who used the 2.59 encountered same problem. The software won't affect the sensitivity of the device.
harley Posted - 07/16/2019 : 06:37:07
Thanks a lot. I wonder if the problem I have encountered has happened to anyone else? What seems to be the underlying mechanisms and how is the characteristics been outlined? I have updated to the version 2.60, and the spikes of readings disappear all at once. My hope is that any revision of software would not influence the sensitivity of detection power of the device.Thanks again.
quote:
Originally posted by EmfDev

We will upload a new version software today or Monday, hopefully it fixes the problem.

If the reading is that high depends on how long and if you think about it, it is like 6-10 times the background CPM so you are absorbing 6x radiation than normal. Probably not that bad if only for a few seconds.

EmfDev Posted - 07/12/2019 : 12:40:06
We will upload a new version software today or Monday, hopefully it fixes the problem.

If the reading is that high depends on how long and if you think about it, it is like 6-10 times the background CPM so you are absorbing 6x radiation than normal. Probably not that bad if only for a few seconds.
harley Posted - 07/12/2019 : 10:16:35
quote:
Originally posted by EmfDev

Seems like it's the pc software issue and not the tube. May I ask what version of software you're using?



Hi,Thanks a lot. My current version of GQ GMC Data Viewer is Re2.59, and most of the data are recorded indoors. One of my concern is how severe the ionizing radiaiton of this level is, if it does reflect the situation. Thanks.
EmfDev Posted - 07/12/2019 : 09:36:35
Seems like it's the pc software issue and not the tube. May I ask what version of software you're using?
harley Posted - 07/11/2019 : 23:58:51
Hi, EmfDev,thank you for your reply. I post an image to get my question more clear. The upper part is downloaded data for realtime monitoring, from which we can see high readings at several time points.At 22:03, a 192 could be seen, which contributed mostly to the high reading of 210 at that specific moment. But when I tried to look for this in non-realtime history data, as is shown as lower part of the inserted image, everything seemed OK. I don't know if there are problems with the systemic clock, which cause unmatched data,since nearly all data at same time points are not identical.

Image Insert:

459633 bytes
EmfDev Posted - 07/11/2019 : 09:03:19
Hi harley, what do you mean that you can't find the high readings in the history data and by saying when looking at downloaded data?

Have you tried to factory reset the device? Does it happen when you put the device in just one place?
Even if it's false reading, it should still record it to the history data.

But if you're seeing it within 1 minute means there is one high pulse within that minute. Could be that it's a tube issue.

If problems are not fixed, you can email support for warranty.

GQ Electronics Technical Support Forum © Copyright since 2011 Go To Top Of Page
Generated in 0.08 sec. Snitz's Forums 2000