Extremely high first value in download

[frankenstein91]

When I load the values from my device (GMC-500+Re 2.0), I get as first value an extremely high CPM value.
the following two values are also not correct, since the maximum value in the device has only risen to 51.

		2019/05/11 14:26:24	every minute
280655	CPM
77	CPM
69	CPM
26	CPM
18	CPM
19	CPM
23	CPM

[frankenstein91]

Update:
it is every hour

		2019/05/11 17:16:17	every minute
280655	CPM
77	CPM
69	CPM
22	CPM
21	CPM
30	CPM
31	CPM
15	CPM

[chaim-zax]

I did a similar test (GMC-500Re 1.06) and I do see something is off. I'm not sure if this is a firmware issue or my misunderstanding on how it should work. The recording I made started with measurements every second, switched to recording every minute, and finally to every hour. The resulting file showed expected results for the second (CPS) and minute (CPM) values, but the values taken once a hour (CPH) did look like counts per minute (CPM). When checking the history on the device I see the same values. So most likely the hourly recordings only take a recording of one minute in total. Which might be a firmware bug, or not. In any case, when converting the count values (CPH) to uS values the calculation is wrong (it expects CPH but it seems to be CPM) and the resulting values are way to low (60 times). Perhaps GQ Electronics can shed some light on this.

[frankenstein91]

I've been able to analyze it a little deeper in the past. This is a misinterpretation of the comments. I entered the location "Home" in the device and the problem started.
Another software uses this field and reads out the measured values correctly.

[chaim-zax]

This makes things more clear. I redid the test but now adding a "Note/Location" with the message "Home", except the count values for hours the result is as I would expected. The csv file shows:

,,2019/05/27 19:12:33,every hour
,,,,Home
20,CPH

Perhaps the difference is in the firmware. Can you describe the steps to reproduce this issue?

[frankenstein91]

There's not much to describe. I bought the device after I saw that there are Linux tools for the export to CSV. I set the saving interval to every minute. Furthermore I tested the comment function in the menu and entered Home. After that I took the device with me for a working day and read it out, which led me to the strange values. I then tested another software which outputs the text string and the values are correct, but unfortunately the software cannot export to CSV. The other software is called Geigerlog.

[chaim-zax]

Thanks for the feedback. Most likely this is an issue with different firmware versions. I'll need to update to a new firmware version and see if the issues indeed pops up. I will update the hourly count values too to reflect CPM values.

[frankenstein91]

how to check the firmware version?

[chaim-zax]

When connecting to the device the tool typically shows the device type and firmware (or by requesting explicitly "./gq-gmc-control.py -i"). In your case GMC-500+Re 2.0 (firmware revision 2.0), and in mine GMC-500Re 1.06 (revision 1.06).

[frankenstein91]

my device tells me 2.04

[dgtlmoon]

I can confirm the same...

./gq-gmc-control.py -a -p /dev/ttyUSB0 
device found: GMC-500+Re 2.2
4992.0000 uSv/h
0.0000 uSv/h
99.8400 uSv/h
0.0000 uSv/h
99.8400 uSv/h
0.0000 uSv/h
0.0000 uSv/h
0.0000 uSv/h
0.0000 uSv/h
0.0000 uSv/h
0.0000 uSv/h
0.0000 uSv/h
0.0000 uSv/h
0.0000 uSv/h
^C0.0000 uSv/h

When I look at the device i'm in the 0.18uSv/h range.

With the -C command I get this number which never changes...

root@acer:/tmp/gq-gmc-control# ./gq-gmc-control.py -C -p /dev/ttyUSB0 
device found: GMC-500+Re 2.2
83.2000 uSv/h
root@acer:/tmp/gq-gmc-control# ./gq-gmc-control.py -C -p /dev/ttyUSB0 
device found: GMC-500+Re 2.2
83.2000 uSv/h
root@acer:/tmp/gq-gmc-control# ./gq-gmc-control.py -C -p /dev/ttyUSB0 
device found: GMC-500+Re 2.2
83.2000 uSv/h
root@acer:/tmp/gq-gmc-control# ./gq-gmc-control.py -C -p /dev/ttyUSB0 
device found: GMC-500+Re 2.2
83.2000 uSv/h

So something with the protocol is horribly wrong

@chaim-zax I see 2.2 here (replying to #3 (comment) )

# ./gq-gmc-control.py -i -p /dev/ttyUSB0 
GMC-500+Re 2.2

[dgtlmoon]

By the way, I'm on GMC-500+Re 2.2... I'm wondering if this python project does not support the 500+'s protocol,

http://www.gqelectronicsllc.com/comersus/store/download.asp seems to mention an entirely different protocol...

On the project page here "Currently the GMC-280, GMC-300, GMC-320 and GMC-500 models are supported." .. but I cant find any evidence that the gmC280/300/320's share the same protocol with the 500's ?

[chaim-zax]

Thanks for the feedback. Indeed, they changed to protocol. I've compared the specs and the differences are apparent.

In the previous version:
Command: GETCPM Return: A 16 bit unsigned integer is returned.

With the new one:
Command: GETCPM Return: A 32 bit unsigned integer is returned.

This shouldn't be hard to fix. I'll need to update the firmware of my device first tough (unfortunately I need a Windows machine for this). Thanks again.

[ThomasHabets]

I'm getting believable numbers from the binary dumps after modifying a bit in my fork with my GQ GMC-500+ Re 2.29

Both the binary dumps extracted with my fork, and the binary exported by the Windows tool give believable graphs.

Reading the CPM value straight out does not, though.

$ ./gq-gmc-control.py -p /dev/ttyUSB0 -C -M
device found: GMC-500+Re 2.2
WARNING: Clearly wrong! Raw value 0x39
57 CPM

Currently it should be showing about 13 CPM, but the raw output is hex 0x00000039 every time.

I made a separate parse script that reads the binary dump and creates a CSV file that kinda looks like the one the Windows tool exports. See the top of the file for example use.

Looks like there are 180 values per minute, meaning three (sensor values) per second? Anyway, because clicks are discrete (especially when on the ground not near a radiation source) at under one per second it's best to just average over a minute anyway. Which seems to be what the Windows tool does. So that's what my tool does, too.

It's giving me believable numbers, in any case, and good enough to graph.

Oh, and I've overridden the config offsets, so that -l correctly lists the settings for GQ GMC-500+. Or mine, at least.

[raleighlittles]

@ThomasHabets are there any plans for your changes to be upstreamed?

[ThomasHabets]

I'm not sure it's maintained.

Feel free to create a PR with my commits. :-)