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
 Log data to the Raspberry Pi
 New Topic  Reply to Topic
 Printer Friendly
Author Previous Topic Topic Next Topic  

pws

9 Posts

Posted - 09/30/2021 :  04:28:57  Show Profile  Reply with Quote
Hi,
I just purchased a GMC500+ and connected it to the GMCmap. I want to log the data also locally to a file. I have a Raspberry Pi which can talk to the GMC500+ using the Python script but the values are incorrect (option --cpm provides wrong value).
Is there a way to read correct values over serial, WIFI or via GMCmap?

Thanks.
Reply #1

EmfDev

1645 Posts

Posted - 09/30/2021 :  10:28:54  Show Profile  Reply with Quote
hi pws, you can use > to get 4 bytes of CPM data from the device.
Go to Top of Page
Reply #2

pws

9 Posts

Posted - 09/30/2021 :  23:51:45  Show Profile  Reply with Quote
Thank you EmfDev, I should have been more specific with my question.

I'm using a "gq cmd control" python script from the Github. The script provides the readout option from the serial device.

When I request the value in "cpm", I get this:
pi@raspberry:~/scripts/gq-gmc-control-master $ python gq-gmc-control.py --cpm
device found: GMC-500+Re 2.2
93.1840 uSv/h

The value does not even change (same since yesterday). The actual value read by the device and sent to the GMCmap ranges between 80-180 nS/h (note the units).

I am capable to use the minicom or other clients but had mixed success. Any hint is appreciated.
Go to Top of Page
Reply #3

EmfDev

1645 Posts

Posted - 10/01/2021 :  09:48:11  Show Profile  Reply with Quote
Are you referring to this link?
https://github.com/chaim-zax/gq-gmc-control/blob/master/gq_gmc.py

The def get_cpm only processes 2 bytes. It should process 4 bytes. The code seems outdated.
You can edit the script to support the new changes from the protocol below.
http://www.gqelectronicsllc.com/download/GQ-RFC1801.txt
Go to Top of Page
Reply #4

pws

9 Posts

Posted - 10/01/2021 :  23:46:24  Show Profile  Reply with Quote
Yes, that was the script I was referring to. I've modified the def get_cpm function to read 4 bytes but I've not been successful.
I think the issue is that the output from the device is always the same (does not change). Do I need to send some command to instruct the device to update the value on a serial link?
I've also connected to it via minicom and was not able to get some reasonable response (e.g. <GETCPM>> or other commands).
Go to Top of Page
Reply #5

ullix

Germany
738 Posts

Posted - 10/02/2021 :  06:07:05  Show Profile  Reply with Quote
You can install GeigerLog on the Raspi and run the GMC500+ via USB cable. I tested on Buster and it works well. https://sourceforge.net/projects/geigerlog/


When you do install GeigerLog, make sure to read the Raspi Install chapter in the manual first, as the Raspi is (unfortunately) organized a bit different from the other Linuxes. (Approx page 119)

But GeigerLog is open source, so if you want to write your own code, then just guidance from the respective parts.
Go to Top of Page
Reply #6

pws

9 Posts

Posted - 10/17/2021 :  12:27:47  Show Profile  Reply with Quote
Thank you, ullix. I've been silent for a while since I managed to do logging via gmcmap. However, today the map is not accessible for a few hours already and I have no data...

I checked the GeigerLog and it looks like a perfect software! But my RPi (zero) does many other things in parallel and it's sitting outside somewhere so I just ssh to it.
I was trying to find a simple non-GUI logger option from the GeigerLog directory but without success. I might not be skilled enough to find it out.
I'm interested in getting data once per minute to a txt file, something like: <epoch>,<count>,<uS/h>
I just don't know why it doesn't work using a documented instruction. Maybe I forgot to enable something...
Go to Top of Page
Reply #7

ullix

Germany
738 Posts

Posted - 10/17/2021 :  23:38:06  Show Profile  Reply with Quote
@pws: the simplest version of GeigerLog by far is 'geigerlog_simple.py' https://sourceforge.net/projects/geigerlog/files/geigerlog_simple.py/download

It is really nothing but a demonstration using Python to read a GMC counter. It logs to file in the (easy to change) format:
# Format of the log:
#   Year-Month-Day Hour:Minute:Second, CPM
#   2017-07-21 10:52:37, 574

Since you use a 500+, you can also try one of the two slightly more complicated versions 'geigerlog_simple_500plus-*.zip', demonstrating how to use both tubes. The v0.2.2 version also demonstrates how to deal with 2-byte and 4-byte responses.

I have not used a RPizero, and can't tell what it is capable of doing. I guess the counter is connected to it by USB cable, and the RPi sends the data via WiFi?

The next version of GeigerLog will be able to act as a WiFi server, but not qualify for the headless setup that you want.

Go to Top of Page
Reply #8

Damien68

France
680 Posts

Posted - 10/18/2021 :  01:19:04  Show Profile  Reply with Quote
@pws:
what I understood is that you are reading the CPS sent automatically by the GMC every second. this is what GQ calls the heartbeat. its format is fixed and cannot be changed. however, you can activate or deactivate the heartbeat with the functions
<HEARTBEAT1>>
<HEARTBEAT0>>

if you send a <GETCPS>> or <GETCPM>> command you will get one response indicating the current CPS or CPM.

to avoid interference between the heartbeat and the commands sent, one way to do this is to send <HEARTBEAT0>> command to deactivate the heartbeat, then send for example the <GETCPM>> command every minute and each time wait for the counter response.
you can also try sending the <GETCPM>> command every second, i don't know exactly how this was implemented nor if the CPM is refreshed every second, chances are it does.


you can also download history from counter flash memory containing recorded CPM or CPS with the command <SPIR[A2][A1][A0][L1][L0]>>
you can look at the reference example that can require adaptations:
https://github.com/chaim-zax/gq-gmc-control/blob/master/gq_gmc.py
to avoid interferences, it's important to disable the heartbeat at startup time when runing it

Mastery is acquired by studying, with it everything becomes simple

Edited by - Damien68 on 10/18/2021 01:59:30
Go to Top of Page
Reply #9

pws

9 Posts

Posted - 10/18/2021 :  11:44:59  Show Profile  Reply with Quote
I read through the Manual and your suggestion and theoretically know how I should manage the device. But in reality it just doesn't work :-(
Here is an example output:

pi@backyard:~ $ picocom -b 115200 /dev/ttyUSB2
picocom v3.1

port is        : /dev/ttyUSB2
flowcontrol    : none
baudrate is    : 115200
parity is      : none
databits are   : 8
stopbits are   : 1
escape is      : C-a
local echo is  : no
noinit is      : no
noreset is     : no
hangup is      : no
nolock is      : no
send_cmd is    : sz -vv
receive_cmd is : rz -vv -E
imap is        : 
omap is        : 
emap is        : crcrlf,delbs,
logfile is     : none
initstring     : none
exit_after is  : not set
exit is        : no

Type [C-a] [C-h] to see available commands
Terminal ready
#65533;#65533;#65533;#65533;#65533;#65533;#65533;#65533;#65533;#65533;#65533;#65533;
*** local echo: yes ***
#65533;<HEARTBEAT0>>
#65533;#65533;#65533;#65533;#65533;#65533;#65533;#65533;#65533;#65533;#65533;#65533;<GETCPM>>
#65533;#65533;



This character: #65533; is printed with non-periodic sequence. It's the same if using minicom or gtk-term on Ubuntu.
I have no idea what is wrong.
Go to Top of Page
Reply #10

pws

9 Posts

Posted - 10/18/2021 :  11:51:20  Show Profile  Reply with Quote
@ullix: I downloaded your python script - Thanks!
This is what I get:

pi@backyard:~/scripts $ python geiger-simple.py 
Ports found on this system:
/dev/ttyUSB2 - USB Serial
/dev/ttyUSB1 - USB2.0-Serial
/dev/ttyUSB0 - USB2.0-Serial
/dev/ttyAMA0 - ttyAMA0
()
('2021-10-18 21:47:47', ', CPM=', 65535)
('2021-10-18 21:47:52', ', CPM=', 0)
('2021-10-18 21:47:53', ', CPM=', 14)
('2021-10-18 21:47:54', ', CPM=', 0)
('2021-10-18 21:47:55', ', CPM=', 14)
('2021-10-18 21:47:56', ', CPM=', 0)
('2021-10-18 21:47:57', ', CPM=', 13)
('2021-10-18 21:47:58', ', CPM=', 0)
('2021-10-18 21:47:59', ', CPM=', 13)
('2021-10-18 21:48:00', ', CPM=', 0)
('2021-10-18 21:48:01', ', CPM=', 13)
('2021-10-18 21:48:02', ', CPM=', 0)
('2021-10-18 21:48:03', ', CPM=', 13)
('2021-10-18 21:48:04', ', CPM=', 65280)
('2021-10-18 21:48:05', ', CPM=', 0)
('2021-10-18 21:48:06', ', CPM=', 3328)
('2021-10-18 21:48:07', ', CPM=', 0)
('2021-10-18 21:48:08', ', CPM=', 3328)
('2021-10-18 21:48:09', ', CPM=', 0)
('2021-10-18 21:48:10', ', CPM=', 3839)
('2021-10-18 21:48:11', ', CPM=', 0)
('2021-10-18 21:48:12', ', CPM=', 15)
('2021-10-18 21:48:13', ', CPM=', 65280)
('2021-10-18 21:48:14', ', CPM=', 0)
('2021-10-18 21:48:15', ', CPM=', 3840)
('2021-10-18 21:48:16', ', CPM=', 0)
('2021-10-18 21:48:17', ', CPM=', 3840)
('2021-10-18 21:48:18', ', CPM=', 0)
('2021-10-18 21:48:19', ', CPM=', 3840)
('2021-10-18 21:48:20', ', CPM=', 0)
('2021-10-18 21:48:21', ', CPM=', 4351)
('2021-10-18 21:48:22', ', CPM=', 0)
('2021-10-18 21:48:23', ', CPM=', 16)
('2021-10-18 21:48:24', ', CPM=', 0)
('2021-10-18 21:48:25', ', CPM=', 16)
('2021-10-18 21:48:26', ', CPM=', 65280)

Is this expected output? Looks a bit messy (e.g. CPM=65280).

I will check the other examples, too.
Go to Top of Page
Reply #11

ullix

Germany
738 Posts

Posted - 10/19/2021 :  01:33:52  Show Profile  Reply with Quote
@pws: No, this surely isn't right. My guess is, this is because you used geiger-simple.py unmodified and are reading 2-bytes chunks, while your 500+ has a firmware, which delivers 4 bytes instead of 2!

Can you please give the firmware version of your counter?

I just verified:

The 'geigerlog_simple_500plus-v0.1.zip' package is also hard-coded for a 2-byte response, as this was what the 500+ originally offered.

The newer 'geigerlog_simple_500plus-v0.2.2.zip' can distinguish, based on the counter's version, which GL-simple first reads from the counter, whether to use 2 or 4 bytes. It also accounts for more problems due to changed firmwares. But as you see, the code has become a lot more complex.

Needless to say, now this part of the GeigerLog code is even more complex :-((

To add to the confusion: when you read Counts-Per-Second you have to mask-off the high bits for the 2-byte response, but not for the 4-byte response :-))

The heartbeat is yet a different beast: It spits out CPS every second, so if you want to know CPM, you must make sure to read every second to not miss a beat and add it all up! If you want to read GETCPM in between, you may get as response a mix of HEARTBEAT bytes and GETCPM bytes, and have no idea which is which. As heartbeat is CPS, the masking-bit rules also apply.

I wholeheartedly suggest to never, ever use heartbeat!

It might be a good idea to install GeigerLog on a desk/laptop computer, just so you can verify what the counter sends, before you create the simple code for your purpose.

Go to Top of Page
Reply #12

pws

9 Posts

Posted - 10/19/2021 :  10:50:04  Show Profile  Reply with Quote
The firmware version of the counter is 2.28 I think. I purchased it few weeks ago.

This is the output of the v0.2.2 script:

pi@backyard:~/scripts $ python simple_500plus.py 

USB-to-Serial Ports found on this system:
     /dev/ttyUSB2 - USB Serial
     /dev/ttyUSB1 - USB2.0-Serial
     /dev/ttyUSB0 - USB2.0-Serial
     /dev/ttyAMA0 - ttyAMA0
 
my Version of geigerlog_simple_500plus.py          : 0.2.2
my Python Version                                  : 2.7.16
 
my Serial Port                                     : /dev/ttyUSB2
my Serial Baudrate                                 : 115200
my Serial Timeout (sec)                            : 3
my Cycle time (sec)                                : 1
my Log file                                        : simple.log
('DEBUG:', ('getExtraByte: Bytes waiting: 1',))
('DEBUG:', ('getExtraByte: xrec:', '8\xff\xff'))
('DEBUG:', ('Raw GETVER answer is:',))
('DEBUG:', ('GMC-500+Re 2.28\xff\xff',))
('DEBUG:', ('Processed GETVER answer is:', 'GMC-500+Re 2.28\xff\xff'))
my Counter Version                                 : GMC-500+Re 2.28#65533;#65533;

ERROR:
    The Geiger counter gave incomplete answer to the version request.
    Cannot continue without proper version. Try restarting geigerlog.
    Perhaps the counter needs to be rebootet or even Factory resetted!
    
ATTENTION Firmware Bugs
    Another reason for the failure could be a firmware bug. Recently discovered:

    Device GMC-500+
    If it has firmware 1.18 then it will report an empty version on the first connect.
    Start this 'geigerlog_simple_500.py' program again, and it should work.
    It is recommended to upgrade the firmware (current new version: 1.21).
    Contact GQ support for the upgrade.

    If your counter has a newer firmware than 1.21, you can adapt this
    'geigerlog_simple_500.py' program by adding a new entry under the
    'Customize Here' section beginning at about line 55 of the program code.
    



I restarted the script but same output.
Go to Top of Page
Reply #13

ullix

Germany
738 Posts

Posted - 10/20/2021 :  01:19:43  Show Profile  Reply with Quote
Oh dear, another firmware change? I have not yet tested a device with firmware 2.28, which seems to be the very latest, but I also had nobody complain about GeigerLog not working with it.

Is there anyone getting strange results using GeigerLog on a device with firmware 2.28?

@EmfDev: are there any changes to the GETVER command in firmware 2.28?

It is also hard to believe that anything at the GETVER command would have been changed, but this needs to be tested again. Use a Serial-Monitor program to test the response to the '<GETVER>>' command. In particular, what is the length of the response in bytes?

GeigerLog also includes a Serial-Monitor program called GLsermon.py in its gtools directory. This does give details on response bytes. First read the Help info by command 'GLsermon.py -h'. Then start with 'GLsermon.py -P <Port> -B <Baudrate> gmc' (note the gmc at the end!).

Is there any chance that you had given the HEARTBEAT command, and that this is still active, interfering with other commands???
Go to Top of Page
Reply #14

pws

9 Posts

Posted - 10/20/2021 :  02:37:07  Show Profile  Reply with Quote
@ullix, I want to thank you again for your engagement in helping me with this issue.

I confirm I did not send the <HEARTBEAT1>> command.

I tried the GLsermon.py script. The issue I see is that the device throws some values of unknown (?) content. Using the <GETVER>> or <GETCPM>> commands I can get data (4 B). Sending <HEARTBEAT0>> and <HEARTBEAT1>> also works (I see periodic 1-second output or not).
What comes inbetween, I don't know. Here is an example output with
<HEARTBEAT0>> and doing nothing, just let the script run for 30 seconds:

pi@backyard:~/scripts $ python3 GLsermon.py -P /dev/ttyUSB2 -B 115200 gmc
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Start with: 'GLsermon.py -h' for Help Info
Start with: 'GLsermon.py -P <Port> -B <Baudrate>' to set Port and Baudrate
Stop  with: CTRL-C

Connecting with Port: /dev/ttyUSB2 , Baudrate: 115200
Connection successful


R-Bytes:   1: (Non-decodeable) b'\xff'
R-Values HEX: 0xFF 
R-Values DEC:  255 
R-Values ASC:     



R-Bytes:   4: (Non-decodeable) b'\xff\xff\xff\xff'
R-Values HEX: 0xFF 0xFF 0xFF 0xFF 
R-Values DEC:  255  255  255  255 
R-Values ASC:                 



R-Bytes:   2: (Non-decodeable) b'\xff\xff'
R-Values HEX: 0xFF 0xFF 
R-Values DEC:  255  255 
R-Values ASC:         



R-Bytes:   1: (Non-decodeable) b'\xff'
R-Values HEX: 0xFF 
R-Values DEC:  255 
R-Values ASC:     



R-Bytes:   1: (Non-decodeable) b'\xff'
R-Values HEX: 0xFF 
R-Values DEC:  255 
R-Values ASC:     



R-Bytes:   1: (Non-decodeable) b'\xff'
R-Values HEX: 0xFF 
R-Values DEC:  255 
R-Values ASC:     


^CKeyboardInterrupt




Further example when I send commands (approximately 30 seconds of connection):

pi@backyard:~/scripts $ python3 GLsermon.py -P /dev/ttyUSB2 -B 115200 gmc
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Start with: 'GLsermon.py -h' for Help Info
Start with: 'GLsermon.py -P <Port> -B <Baudrate>' to set Port and Baudrate
Stop  with: CTRL-C

Connecting with Port: /dev/ttyUSB2 , Baudrate: 115200
Connection successful

<GETVER>>

R-Bytes:  15: GMC-500+Re 2.28
R-Values HEX: 0x47 0x4D 0x43 0x2D 0x35 0x30 0x30 0x2B 0x52 0x65 0x20 0x32 0x2E 0x32 0x38 
R-Values DEC:   71   77   67   45   53   48   48   43   82  101   32   50   46   50   56 
R-Values ASC:    G    M    C    -    5    0    0    +    R    e         2    .    2    8 



R-Bytes:   1: (Non-decodeable) b'\xff'
R-Values HEX: 0xFF 
R-Values DEC:  255 
R-Values ASC:     


<GETCPM>>

R-Bytes:   4: 
R-Values HEX: 0x00 0x00 0x00 0x0E 
R-Values DEC:    0    0    0   14 
R-Values ASC:                 



R-Bytes:   1: (Non-decodeable) b'\xff'
R-Values HEX: 0xFF 
R-Values DEC:  255 
R-Values ASC:     



R-Bytes:   1: (Non-decodeable) b'\xff'
R-Values HEX: 0xFF 
R-Values DEC:  255 
R-Values ASC:     


<GETCPM>>

R-Bytes:   4: 
R-Values HEX: 0x00 0x00 0x00 0x0E 
R-Values DEC:    0    0    0   14 
R-Values ASC:                 


<GETCPM>>
R-Bytes:   1: (Non-decodeable) b'\xff'
R-Values HEX: 0xFF 
R-Values DEC:  255 
R-Values ASC:     



R-Bytes:   1: (Non-decodeable) b'\xff'
R-Values HEX: 0xFF 
R-Values DEC:  255 
R-Values ASC:     




R-Bytes:   4: 
R-Values HEX: 0x00 0x00 0x00 0x11 
R-Values DEC:    0    0    0   17 
R-Values ASC:                 



R-Bytes:   1: (Non-decodeable) b'\xff'
R-Values HEX: 0xFF 
R-Values DEC:  255 
R-Values ASC:     


<GETCPM>>

R-Bytes:   4: 
R-Values HEX: 0x00 0x00 0x00 0x10 
R-Values DEC:    0    0    0   16 
R-Values ASC:                 



R-Bytes:   1: (Non-decodeable) b'\xff'
R-Values HEX: 0xFF 
R-Values DEC:  255 
R-Values ASC:     


^CKeyboardInterrupt


Go to Top of Page
Reply #15

Damien68

France
680 Posts

Posted - 10/20/2021 :  03:21:06  Show Profile  Reply with Quote
in GMC500+ go to Menu
in ''MainMenu/Other'', scroll down and select Third Party Output.
Set it to off (it's the default heartbeat enable state), I think it should work, there must be a bug.

Mastery is acquired by studying, with it everything becomes simple

Edited by - Damien68 on 10/21/2021 01:37:52
Go to Top of Page
Reply #16

pws

9 Posts

Posted - 10/20/2021 :  10:57:16  Show Profile  Reply with Quote
I disabled the 3rd Party Output and now it works... how much confusion I brought here... apologies to all.

I will now use the simple_500plus script and other scripts to log data to my files.

Many thanks!
Go to Top of Page
Reply #17

EmfDev

1645 Posts

Posted - 10/20/2021 :  11:19:23  Show Profile  Reply with Quote
There is no change in the command protocol for the latest version.
Go to Top of Page
Reply #18

ullix

Germany
738 Posts

Posted - 10/20/2021 :  23:44:45  Show Profile  Reply with Quote
What on earth is this supposed "Third Party" function for?

It seems to be auto-activated. every now and then it throws in one or more FF bytes, is documented nowhere, and in the most recent manual (from Sep 2018) there is no peep of it.

The only thing that I can see it doing successfully is to ruin every proper measurement!

Edited by - ullix on 10/20/2021 23:45:02
Go to Top of Page
Reply #19

Damien68

France
680 Posts

Posted - 10/21/2021 :  00:58:27  Show Profile  Reply with Quote
@ullix:
apparently Third Party Output sends an FF to the com port every time it count a new particle (I made a mistake, this is not the default heartbeat enable command).

I make a search with the forum Search engine with "Third Party Output" keywords, I found this following posts:

look EmfDev reply 1 below:
http://www.gqelectronicsllc.com/forum/topic.asp?TOPIC_ID=7285

ihab17 reply 20 below:
http://www.gqelectronicsllc.com/forum/topic.asp?TOPIC_ID=6771

http://www.gqelectronicsllc.com/forum/topic.asp?TOPIC_ID=8855

Mastery is acquired by studying, with it everything becomes simple

Edited by - Damien68 on 10/21/2021 02:43:34
Go to Top of Page
  Previous Topic Topic Next Topic  
 New Topic  Reply to Topic
 Printer Friendly
Jump To:
GQ Electronics Technical Support Forum © Copyright since 2011 Go To Top Of Page
Generated in 0.22 sec. Snitz's Forums 2000