search

chaim-zax / gq-gmc-control

Control tool for the GQ GMC Geiger Counters.
GNU General Public License v3.0
55 stars 18 forks source link

Extremely high first value in download #3

Open frankenstein91 opened 5 years ago

frankenstein91 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

how to check the firmware version?

chaim-zax commented 5 years ago

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 commented 5 years ago

my device tells me 2.04 grafik

dgtlmoon commented 4 years ago

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 https://github.com/chaim-zax/gq-gmc-control/issues/3#issuecomment-502448966 )

# ./gq-gmc-control.py -i -p /dev/ttyUSB0 
GMC-500+Re 2.2
dgtlmoon commented 4 years ago

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...

image

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 commented 4 years ago

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 commented 2 years ago

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 commented 1 year ago

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

ThomasHabets commented 1 year ago

I'm not sure it's maintained.

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