Radioactive@home + GQ GMC-300E Geiger Counter

[Skillz]

So I read on the Radioactive@home forums that the GQ GMC-300E Geiger counter can work with the project, you just need to run the app using the anonymous platform.

You can buy the detector here: https://www.amazon.com/gp/product/B00IN8TJYY/ref=ppx_yo_dt_b_asin_title_o02_s00?ie=UTF8&psc=1
($109 USD at the moment)

Download the files needed here: https://teamanandtech.org/download/radathome/Radioactive@home gmc-300.zip

The download includes instructions in a PDF on how to get the detector communicating with BOINC. I've only figured out how to get it to work on Windows, but I hope someone can find the Linux binary needed to get this to work on Linux. According to the forums it was developed, but the download link no longer works anymore.

 

[crashtech]

I'd be interested in the Linux version, for sure.

 

[StefanR5R]

The Windows version of the app for GQ Electronics devices is only still around because a user of it kindly uploaded his local copy of the files to Google drive. There were maybe one or two testers of the Linux version of the app when it was written, but as it happened, they didn't do the same. On a quick glance, one who tested the early Linux version had his last Radioactive@Home credit in 2014...

Maybe go to Universe@Home and ask Krzystof if he still has a means to contact TJM, the author of the app for GQ Electronics devices, project developer and admin.

According to the respective forum thread, TJM took the source code of the proper Radioactive@Home app (http://radioactiveathome.org/boinc/download/sources/) and rewrote the I/O part based on the public protocol of the GQ Electronics devices (http://www.gqelectronicsllc.com/comersus/store/download.asp, GQ-RFC1201 GMC Communication Protocol). From what I read in the thread, it seems as if nothing substantial had to be done in the way of data conversion.

The main difference is that Radioactive@Home's home-grown hardware uses the USB HID device class (hence, is accessed like an input device), whereas the GQ devices use USB CDC (i.e., are built around an RS232 adapter and are accessed like a COM port = a TTY).

Here is a little demo (written by 'ullix') which periodically pulls the current CPM (count per minute) from the device:

Spoiler: geigerlog_simple.py

#!/usr/bin/python
# -*- coding: UTF-8 -*-

# Start program with 'geigerlog-simple.py'
# Stop program with CTRL-C
#
# Format of the log:
#   Year-Month-Day Hour:Minute:Second, CPM
#   2017-07-21 10:52:37, 574

import time                                     # time formatting and more
import sys                                      # system functions
import serial                                   # communication with serial port
import serial.tools.list_ports                  # allows listing of serial ports


def getCPM(ser):                                # get CPM from device
    ser.write(b'<GETCPM>>')
    srec = ser.read(2)

    if sys.version_info[0] == 3:                # correct for Py2 vs Py3
        rec = chr(srec[0]) + chr(srec[1])
    else:
        rec = srec

    return ord(rec[0])<< 8 | ord(rec[1])


# List the USB/Serial ports found on this system
my_ports =  serial.tools.list_ports.comports()
print ("Ports found on this system:")
for p in my_ports :     print (p)               # use the port found here for my_port
print()


# my settings
my_port      = '/dev/ttyUSB0'                   # likely USB/Serial port on Linux
#my_port      = 'COM3'                          # likely USB/Serial port on Windows
my_baudrate  = 57600                            # baudrate; mostly 57600 or 115200
my_cycletime = 1                                # seconds
my_logfile   = 'simple.log'                     # filename for the log file

ser = serial.Serial(my_port, my_baudrate)       # open serial port

while True:
    ts  = time.strftime("%Y-%m-%d %H:%M:%S")    # get time stamp
    cpm = getCPM(ser)                           # get CPM

    print (ts, ", CPM=", cpm)                   # print timestamp and CPM

    log = open(my_logfile, "a")                 # log the data
    log.write(ts + ", " + str(cpm) + "\n")      #
    log.close                                   #

    time.sleep(my_cycletime)                    # sleep for my_cycletime seconds

(from https://sourceforge.net/projects/geigerlog/files/)

(Edit: geigerlog_simple.py requires the package "python3-serial" on Linux Mint, and "python3-pyserial" on OpenSUSE)

From what I understood, the Radioactive@Home app does the same: Periodically read the CPM. Just that the R@H app is written in C/C++ instead of Python. On Windows and on Linux, a low-level language like C would certainly use rather different operating system interfaces for the device I/O, whereas the above Python code works on several operating systems.

The upshot: It seems as if reproducing what the project developer TJM did back then is more feasible than to establish contact with him or with one of the Linux testers from back then. However, unlike us, TJM obviously had extensive knowledge of the original R@H app and also of the project server side of all this.

 

[Skillz]

I've tried reaching out to TJM, but nothing as of yet.

Ian from GPUUG is going to see about using WINE to run this under Linux using your tutorial @StefanR5R

I, on the other hand, want a solution that allows the use of a Raspberry Pi as the host.

 

[StefanR5R]

Ian from GPUUG is going to see about using WINE to run this under Linux

This might work. The Windows version of the R@H/GMC-300 application needs to access a COM port. WINE should forward Linux' serial ports, including serial-over-USB which are called /dev/ttyUSB0 and so on, to Windows.
https://wiki.winehq.org/Wine_User's_Guide#Serial_and_Parallel_Ports

using your tutorial @StefanR5R

Wow, I wrote a tutorial on WINE + BOINC once? :-)
Hmm, indeed, there is a thread called Running Windows-only projects on Linux, using Wine.

 

[StefanR5R]

@Skillz, I looked at the stderr.txt of several results of host 45456. Every time, the application claims that it read a CPM of 13358 the first time, of 14136 the second time, and of 0 each time during the rest of the run time. This can't be right. (FWIW, these first four returned bytes correspond to ASCII 4 . 7 8.)

There should be random values all the time, always >0 unless your home is built of lead. The values should be <20 at most places, from what I see from some random sensors on the map.

Here is another host which uses the special GMC-300 app: host 41946. Right now, most of its results got 0 credit because the app couldn't open the COM port. But if you click further back in time in the results tables, there are a few results with nonzero credit, and they are showing random CPMs which are >0 and <20, as to be expected. Before the first <GETCPM>> is performed, the app says "<GETVER>> returned GMC-300Re 4.60" on this host.

On yours, the app says "<GETVER>> returned GMC-300E+V4Re" before the first <GETCPM>>. Maybe you have a device revision which returns a longer version string than specified in the protocol description. I.e., your entire revision string might actually be "GMC-300E+V4Re4.78", and the serial I/O gets confused by receiving a <GETCPM>> before all of the <GETVER>> output was flushed.

Do you get plausible data from your device if you use GQ's own application or a 3rd party software like Geigerlog?

 

[Skillz]

Yes, I think the device is reading the data incorrectly. I put it on my main desktop to see if I could get it working (or at least communicating) with the project. I talked with Ian and he mentioned his was doing the same thing until he power cycled his unit. My Optiplex was delivered today and that's what I intend to run the unit on so I will see about making sure the data is correct when I transfer it over to the new host when I get time after work sometime this week.

Two of those invalids (zero credit) tasks I had set the task time to run for 8 hours and they failed. No idea why, but when I set the run time back to 30 minutes the results were validated. The first result was invalid and that's what the instructions I read suggested might happen.

Also one thing I did notice and that's this unit uses a USB-C port which indicates it's a redesign from the older Mirco USB versions I've seen pictures of. Not sure if that means anything.

The LCD on the device reads 0 all the time. It doesn't change. Ian said his did the same, until he power cycled it. Something I didn't do. I just plugged it into the computer after installing the drivers and began using it. Thinking the data was good since the results were marked valid.

 

[StefanR5R]

The bogus results which I saw yesterday already received credit.
The most recent results are still the same:

Spoiler

<GETVER>> returned GMC-300E+V4Re
<GETCPM>> returned 52 46
CPM value: 13358
1000,667,2023-10-12 4:59:49,0,f,0
<GETCPM>> returned 55 56
CPM value: 14136
242000,57446,2023-10-12 5:3:50,0,n,0
<GETCPM>> returned 0 0
CPM value: 0
483000,57446,2023-10-12 5:7:51,0,n,0
<GETCPM>> returned 0 0
CPM value: 0
724000,57446,2023-10-12 5:11:52,0,n,0
Debug: trickle sent
Trickle sent
<GETCPM>> returned 0 0
CPM value: 0
965000,57446,2023-10-12 5:15:53,0,n,0
<GETCPM>> returned 0 0
CPM value: 0
1207000,57446,2023-10-12 5:19:55,0,n,0
<GETCPM>> returned 0 0
CPM value: 0
1448000,57446,2023-10-12 5:23:56,0,n,0
Debug: trickle sent
Trickle sent
<GETCPM>> returned 0 0
CPM value: 0
1689000,57446,2023-10-12 5:27:57,0,n,0
Debug: trickle sent
Trickle sent
Done - calling boinc_finish()

The validator marks this valid because... I dunno, because it isn't very smart?

Just now, I am seeing only three results which were marked invalid in the tables:

Spoiler

• Two of them had the very same sequence of data as the above valid one, except that they had ≈29,000 s run time instead of ≈1,700 s. Maybe the validator looks at the average of all CPMs, and the much larger number of 0 CPMs in the longer running workunits made the validator reconsider.
• One was a ≈1,700 s workunit but returned
  GMC-300E+V4Re
  52 46
  55 56
  -128 0
  0 0
  0 0 and so on. Evidently, the one -128 0 datum (0x8000, interpreted by the app as -32768 counts per minute) wasn't liked by the validator.

GUUG has mixed success:
Keith Myers' host has lots of failures to read/write on the COM port. But here is a result which passed validation:

Spoiler

<GETVER>> returned GMC-300E+V4Re
<GETCPM>> returned 52 46
CPM value: 13358
1000,667,2023-10-12 2:13:7,0,f,0
<GETCPM>> returned 55 57
CPM value: 14137
242000,57450,2023-10-12 2:17:8,0,n,0
<GETCPM>> returned 98 0
CPM value: 25088
483000,158220,2023-10-12 2:21:9,0,n,0
<GETCPM>> returned 7 0
CPM value: 1792
724000,165417,2023-10-12 2:25:10,0,n,0
<GETCPM>> returned 10 0
CPM value: 2560
965000,175699,2023-10-12 2:29:11,0,n,0
<GETCPM>> returned 11 0
CPM value: 2816
1206000,187009,2023-10-12 2:33:12,0,n,0
<GETCPM>> returned 18 0
CPM value: 4608
1447000,205517,2023-10-12 2:37:13,0,n,0
<GETCPM>> returned 12 0
CPM value: 3072
1688000,217856,2023-10-12 2:41:14,0,n,0
<GETCPM>> returned 16 0
CPM value: 4096
1929000,234308,2023-10-12 2:45:15,0,n,0
<GETCPM>> returned 17 0
CPM value: 4352
2170000,251788,2023-10-12 2:49:16,0,n,0
<GETCPM>> returned 14 0
CPM value: 3584
2411000,266183,2023-10-12 2:53:17,0,n,0
<GETCPM>> returned 16 0
CPM value: 4096
2652000,282635,2023-10-12 2:57:18,0,n,0
<GETCPM>> returned 12 0
CPM value: 3072
2893000,294974,2023-10-12 3:1:19,0,n,0
gmc_GetCPM(): failed to send data or no device on the other end
gmc_GetCPM(): read failed
gmc_GetCPM(): failed to send data or no device on the other end
gmc_GetCPM(): read failed
Error reading data
gmc_GetCPM(): failed to send data or no device on the other end
gmc_GetCPM(): read failed
gmc_GetCPM(): failed to send data or no device on the other end
gmc_GetCPM(): read failed
Error reading data
gmc_GetCPM(): failed to send data or no device on the other end
gmc_GetCPM(): read failed
gmc_GetCPM(): failed to send data or no device on the other end
gmc_GetCPM(): read failed
Error reading data
Lost sensor, trying to reopen....
Unable to open port COM1COM1 opened for read/write
gmc_GetVersion(): read failed
COM1 opened for read/write
gmc_GetVersion(): read failed
COM1 opened for read/write
gmc_GetVersion(): read failed
COM1 opened for read/write
gmc_GetVersion(): read failed
COM1 opened for read/write
gmc_GetVersion(): read failed
COM1 opened for read/write
gmc_GetVersion(): read failed
COM1 opened for read/write
gmc_GetVersion(): read failed
COM1 opened for read/write
gmc_GetVersion(): read failed
COM1 opened for read/write
gmc_GetVersion(): read failed
COM1 opened for read/write
gmc_GetVersion(): read failed
COM1 opened for read/write
gmc_GetVersion(): read failed
COM1 opened for read/write
gmc_GetVersion(): read failed
COM1 opened for read/write
gmc_GetVersion(): read failed
COM1 opened for read/write
gmc_GetVersion(): read failed
Done - calling boinc_finish()
20:22:27 (1400): called boinc_finish

So the first data from the device had the same bogus 52 46 55 57 values which I suspect still belong to the firmware version string. But then the device sent non-zero CPMs. The first one (98 00 = 0x6200) seems bogus. The next several ones look good. But alas, the byte order is evidently the other way around than the app expects:
E.g., 7 0 most likely should be taken as 0x0007 = 7, not as 0x0700 = 1792 as the app did. At such a level I'd worry about Keith's health. I suspect this trouble with byte order was because an uneven number of bytes should have been discarded before proceeding with <GETCPM>>.
After a while, the app gets unable to read/write the COM port.

Ian&Steve C. attached two hosts. Here is one random result which looks almost perfect:

Spoiler

<GETVER>> returned +V4Re 4.78
<GETVER>> returned string which is too long
<GETCPM>> returned 67 45
CPM value: 17197
1000,573,2023-10-11 22:47:20,0,f,0
<GETCPM>> returned 48 69
CPM value: 12357
242000,50206,2023-10-11 22:51:21,0,n,0
<GETCPM>> returned 52 82
CPM value: 13394
483000,104005,2023-10-11 22:55:22,0,n,0
<GETCPM>> returned 52 46
CPM value: 13358
724000,157659,2023-10-11 22:59:23,0,n,0
<GETCPM>> returned 0 16
CPM value: 16
965000,157723,2023-10-11 23:3:24,0,n,0
<GETCPM>> returned 0 13
CPM value: 13
1206000,157775,2023-10-11 23:7:25,0,n,0
<GETCPM>> returned 0 12
CPM value: 12
1447000,157823,2023-10-11 23:11:26,0,n,0
<GETCPM>> returned 0 11
CPM value: 11
1688000,157867,2023-10-11 23:15:27,0,n,0
<GETCPM>> returned 0 16
CPM value: 16
1929000,157931,2023-10-11 23:19:28,0,n,0
<GETCPM>> returned 0 12
CPM value: 12
2170000,157979,2023-10-11 23:23:29,0,n,0
<GETCPM>> returned 0 15
CPM value: 15
2411000,158039,2023-10-11 23:27:30,0,n,0
<GETCPM>> returned 0 18
CPM value: 18
2652000,158111,2023-10-11 23:31:31,0,n,0
<GETCPM>> returned 0 23
CPM value: 23
2893000,158203,2023-10-11 23:35:32,0,n,0
<GETCPM>> returned 0 10
CPM value: 10
3134000,158243,2023-10-11 23:39:33,0,n,0
<GETCPM>> returned 0 9
CPM value: 9
3375000,158279,2023-10-11 23:43:34,0,n,0
<GETCPM>> returned 0 20
CPM value: 20
3616000,158359,2023-10-11 23:47:35,0,n,0
<GETCPM>> returned 0 20
CPM value: 20
3857000,158439,2023-10-11 23:51:36,0,n,0
<GETCPM>> returned 0 12
CPM value: 12
4098000,158487,2023-10-11 23:55:37,0,n,0
<GETCPM>> returned 0 11
CPM value: 11
4339000,158531,2023-10-11 23:59:38,0,n,0
<GETCPM>> returned 0 19
CPM value: 19
4580000,158607,2023-10-12 0:3:39,0,n,0
<GETCPM>> returned 0 20
CPM value: 20
4821000,158687,2023-10-12 0:7:40,0,n,0
<GETCPM>> returned 0 21
CPM value: 21
5062000,158771,2023-10-12 0:11:41,0,n,0
<GETCPM>> returned 0 13
CPM value: 13
5303000,158823,2023-10-12 0:15:42,0,n,0
<GETCPM>> returned 0 21
CPM value: 21
5544000,158907,2023-10-12 0:19:43,0,n,0
<GETCPM>> returned 0 23
CPM value: 23
5785000,158999,2023-10-12 0:23:44,0,n,0
<GETCPM>> returned 0 14
CPM value: 14
6026000,159055,2023-10-12 0:27:45,0,n,0
<GETCPM>> returned 0 14
CPM value: 14
6267000,159111,2023-10-12 0:31:46,0,n,0
<GETCPM>> returned 0 17
CPM value: 17
6508000,159179,2023-10-12 0:35:47,0,n,0
<GETCPM>> returned 0 15
CPM value: 15
6749000,159239,2023-10-12 0:39:48,0,n,0
<GETCPM>> returned 0 21
CPM value: 21
6990000,159323,2023-10-12 0:43:49,0,n,0
<GETCPM>> returned 0 16
CPM value: 16
7231000,159387,2023-10-12 0:47:50,0,n,0
Done - calling boinc_finish()
20:47:50 (328): called boinc_finish

That is,

• The app did notice that there is something wrong with the version string.
• Yet the app nevertheless proceeded to read some bogus initial CPMs:
  67 45 = 'C' '-'
  48 69 = '0' 'E'
  52 82 = '4' 'R'
  52 46 = '4' '.'
• After that, all CPMs until the end of the workunit look plausible.
• The validator marked it invalid though, perhaps because of the initial few presumed high CPMs. Or perhaps because the device name wasn't understood.

Long story short, the existing "Radioactive@Home app rev $Rev: 585 $ for GMC-300" evidently needs more work: Figure out how to get the various different initial bogus data out of the way; figure out how to make the device return non-zero CPMs subsequently; give some better feedback when the COM port can't be accessed.

But as long as we don't have the source code, the only way is to start from scratch (based on the source code of R@H's original application for their own hardware, of course, so not truly from scratch).

Edit: GQ Electronics' protocol documentation obviously lacks a few crucial points. A look at the source code of other open source applications which deal with these device types may help.

 

[Skillz]

I showed Ian this thread and he should be showing up when he has time to add some information to it. Hopefully we can figure this out and get something working correctly with these devices.

 

[gsrcrxsi]

Hi Stefan. this is Ian&Steve here. I was the one to get this working with Wine (in part with help from one of your guides many years ago). I wrote a quick guide for it on the TAAT Discord server.

I came to many of the same conclusions about the problems with the output. especially about the bogus entries. But I didnt think to convert them to ASCII. i noticed the same bad entries at the beginning of every output and didnt make the connection that the RX buffer was overflowing with that extra data.

putting together what I usually get for bad entries, first 52 46, then 55 56 spells out "4.78" which indeed is the revision/firmware version of my model. using other scripts or programs will pull the whole string without issue, but either the <GETVER>> command is limited in how much data it pulls, or was programmed to only pull X amount of data for the string, and/or wasnt coded to clear the RX buffer before the GETCPM command. it's very likely that they got lucky in the string length of the early detector units and got away with the more lazy coding approach of just letting it ride.

Keith's output I believe has the same overflow, but that introduces an offset causing every read to overflow with the last bits of the previous line because his firmware is actually "4.79b" so the odd number of characters is pushing the offset like you theorized.

I did even shoot an email off to the GQ support team and they just got back to me as I was reading your posts to confirm the cause is from not clearing the RX buffer. but without the source code for the app, I think we're kind of stuck. I dont know about you but I'm not sure where to begin with editing their source code.

You mentioned interest in the source code for some other apps and scripts that can manage this device, and I can at least share those with you. I used this program to do the device initialization to get data flowing over the USB. https://sourceforge.net/projects/gqgmc/files/

and then there was this really old python2 script that also works fairly well.
https://github.com/chaim-zax/gq-gmc-control

maybe you could figure out what bits to add to the stock radathome source, but I really don't know where to start with that. BOINC science apps are always so complex.

I've asked the GQ support team if there's any way to modify the firmware to shorten that GETVER string, but I'm doubtful. I also bought a different GMC-300S device, and maybe that one has a string short enough that it'll work? if not, or if it doesnt work at all with the app, I'll just return it.

 

[biodoc]

I found a source that might be useful. https://github.com/vurdalakov/gmc-300/blob/master/README.md?plain=1

EDITED

 

[StefanR5R]

I found a source that might be useful. https://github.com/vurdalakov/gmc-300/blob/master/README.md?plain=1

Its I/O part, gmc-300/src/gmc300/Gmc300.cs, was last edited 7 years ago assumes that the device name and firmware version from <GETVER>> consist of 7+7 bytes as per protocol specification. This bit aside, it looks like helpful example code indeed.

Hi Stefan. this is Ian&Steve here. I was the one to get this working with Wine (in part with help from one of your guides many years ago). I wrote a quick guide for it on the TAAT Discord server.

Hi, welcome!
Thanks for sharing your work with those of us in the chat. (I'm not there yet myself... yet, for some reason or another...)

either the <GETVER>> command is limited in how much data it pulls, or was programmed to only pull X amount of data for the string, and/or wasnt coded to clear the RX buffer before the GETCPM command. it's very likely that they got lucky in the string length of the early detector units and got away with the more lazy coding approach of just letting it ride.

To be fair, it's the newer device firmware which violates the public spec.

maybe you could figure out what bits to add to the stock radathome source, but I really don't know where to start with that. BOINC science apps are always so complex.

I looked at it today and I think I can write a new gmc300 app based on this.

One HUGE caveat: I am chronically lacking spare time.

I will order one or another GQ GMC and then try this. But don't expect any real progress before November.

I've asked the GQ support team if there's any way to modify the firmware to shorten that GETVER string, but I'm doubtful. I also bought a different GMC-300S device, and maybe that one has a string short enough that it'll work? if not, or if it doesnt work at all with the app, I'll just return it.

Which lets me think: One could write a "man-in-the-middle" helper which does the talk to the real device on one side, and provides a pseudo serial port to the existing gmc300.exe on the other side. The more robust device startup and cleanup of the device's responses would be implemented in the helper, which would then forward protocol spec compliant messages to gmc300.exe. — However, at this point, recreating gmc300.exe from scratch probably amounts to the same kind of effort. And it would have the benefit that native binaries for Linux-x86 and Linux-ARM and whatever other desired platform could be provided.

And in the long run, it would be nice to combine the native app and the gmc300 app into a combined app with device type auto-detection (should be straightforward), and then submit this to the R@H project owners for adoption as their standard app.

A difference between the GQ Electronics devices and Radioactive@Home's own hardware is that we get CPM (count per minute) from the former, but a time stamp and a count from the latter. However, this can trivially be converted in both directions, obviously. What's not trivial, AFAIK, is to convert from CPM to µSv/h. But the latter is shown on R@H's map. I wonder if R@H's developer TJM extended the R@H server-side code to have an extra µSv converter for GMC 300, back at the time when he came up with the existing gmc300 app. I furthermore wonder if one and the same µSv/h conversion is applicable to the whole range of GQ devices.

 

[gsrcrxsi]

Thanks Stefan, and no worries about a delay in attempting to write a new app. take your time.

and to no surprise, the manufacturer replied that they were unwilling to change the firmware. but after reading your previous replies a little more in depth, I took their own documentation about usage of the protocol and sent back a request to see if they would adjust it if they were aware that the way the unit is operating is not in line with their documentation. either they will update the firmware, or the documentation. I would guess the latter though .

edit. i guess not either.
"The documentation is old now and we have different models that have different length with the <GETVER>> like the GMC-500+."

so i guess they can't be bothered to change anything.

 

[gsrcrxsi]

the GMC-300S unit is "better". doesnt solve the problem completely, but only gets a small bad first update instead of the huge ones from the E+V4 units.

<GETVER>> returned GMC-300SRe 1.1
<GETCPM>> returned 51 98
CPM value: 13154
1000,657,2023-10-16 19:8:40,0,f,0
<GETCPM>> returned 0 20
CPM value: 20
242000,737,2023-10-16 19:12:41,0,n,0
<GETCPM>> returned 0 17
CPM value: 17
483000,805,2023-10-16 19:16:42,0,n,0

I can live with this until a proper fix is available.

 

[StefanR5R]

I used this program to do the device initialization to get data flowing over the USB. https://sourceforge.net/projects/gqgmc/files/

and then there was this really old python2 script that also works fairly well.
https://github.com/chaim-zax/gq-gmc-control

That is, your procedure is to plug in the device, use one of these external tools to power it up(?) or reset(?) it, then let BOINC fetch work from Rad@home?

@Skillz, @biodoc,
do the µSv/h values which the server puts on the map correlate with what your sensors show on their display?

 

[gsrcrxsi]

That is, your procedure is to plug in the device, use one of these external tools to power it up(?) or reset(?) it, then let BOINC fetch work from Rad@home?

@Skillz, @biodoc,
do the µSv/h values which the server puts on the map correlate with what your sensors show on their display?

yes. for whatever reason, the application can only seem to get data from the device if it's been kind of initialized first. it does the same thing on Windows (you need to open the GQ app and get some readings and check the port number before running BOINC). but subsequent tasks will pick it up fine, only necessary the first time you start BOINC, until you restart the system.

but the way I did it on Linux at least binds the device to a static device in /dev/gqgmc, and you bind that static /dev/gqgmc to COM1 in Wine, so you don't need to worry about ever changing the port like you do when running it on Windows native.

if you look at the "last sample" number in @Skillz and @biodoc readings on the map, that should be in line with what their devices read regularly, but the "average" value in the range one 2-11+ uSv/h is heavily skewed because of the huge initial samples from each WU. .

 

[Skillz]

I'm gonna order a 300S here soon and give it a run, but I hope we can figure out a better solution.

 

[gsrcrxsi]

this will undoubtedly be helpful at some point:

// clearUSB is public method to clear the read (input) buffer of
// the serial port. This method exists due to vagaries of the
// turn_on_cps_cmd. Since there is no protocol for the returned
// data (ie, no start, no stop, no ack, no nak), the synchronization
// of the getAutoCPS() method with the GQ GMC is flakey. Consequently,
// when the turn_off_cps_cmd happens, there may be left over
// data in the USB input buffer. So this method simply reads the
// USB input buffer until it is empty.
void
GQGMC::clearUSB()
{
uint32_t rcvd(0);
char inp;

// Assume that there isn't that much left over from any previous
// read. In other words, we couldn't ever get that far off.
// So read only 10 bytes.
const
uint16_t kMaxtries(10);

// Read returned data until input buffer is empty as indicated by
// rcvd = 0 or not. If rcvd = 0 then the buffer empty and that is
// what we want.
for(uint16_t i=0; i<kMaxtries; i++)
{
rcvd = read(usb_serial, &inp, 1);
if (rcvd == 0) break;
} // end for

// Not good, there are still more characters in input buffer,
// so declare error.
if (rcvd > 0)
error_code = eClear_USB;

return;
}// end clearUSB()

using a GMC-300 for a project detector? Add sensor

 

[biodoc]

As @gsrcrxsi pointed out in previous posts, the data reported using the GMC-300E+ detector is significantly influenced by the first 2 <GETCPM>> commands. Data collected from these first 2 commands are ~13,000 CPM. Normal background CPM is usually greater than 0 and less than 50 CPM depending on your location. If you choose a short task time (0.25 hours), the 24 h average of uSv/h will be abnormally high. As you increase the task times the 24 h average of uSv/h will drop but will still be higher than the actual average displayed by the detector (~0.13 uSv/h). The plot below from the map at radioactive@home shows uSv/h over time from my detectors. You can see as I increase the task times, uSv/h decreases when using the 300E+ detector. When I switched to a 300S detector, I'm seeing a 24 h average of 0.13 uSv/h which is what the detector shows on the screen. Also, the plot after I switched to the 300S is flat (no abnormally high peaks). As @gsrcrxsi mentioned above, the 300S only has abnormally high reading after the first <GETCPM>> command. Subsequent readings are in the normal range. The 300E+ detector shows abnormally high readings in the first 2 <GETCPM>> commands. Perhaps the program removes the first data point before processing the data?



EDIT: I believe the red line is the 24 hour average of uSv/h which is calculated from the raw data (blue data points).
EDIT2: I have the detector connected to my laptop and the OS is Win 11.

 

[StefanR5R]

As @gsrcrxsi mentioned above, the 300S only has abnormally high reading after the first <GETCPM>> command. Subsequent readings are in the normal range. The 300E+ detector shows abnormally high readings in the first 2 <GETCPM>> commands. Perhaps the program removes the first data point before processing the data?

The first CPM reading isn't removed, but it is treated differently.

The native rad@h app radac_1.78 does not read CPM (counts per minute) from their original hardware, it rather periodically reads

• a monotonically increasing milliseconds timer (from the hardware's clock), and
• total count (from the hardware's tube).

And this is also what the app reports to the server. When a task starts, the first reading is flagged with an "f" = as first reading; all subsequent readings are flagged with an "n" = next readings. Several of such readings are sent to the server periodically via BOINC trickle messages.

I suppose the server then proceeds to compute µSv/h for each "n" reading based on (count_at_this_reading − count_at_previous_reading) / (timestamp_this_reading − timestamp_at_previous_reading) · some_conversion_factor. The first µSv/h datum from a task is based on the "f" reading and on the first "n" reading of the task, and the next µSv/h data from the subsequent pairs of "n" readings.

The existing gmc300.exe evidently emulates radac_1.78 behavior: It periodically reads current CPM values from the GQ GMC. At first, it creates a reading with a fake timestamp and a fake total count and the flag "f". (I am not sure how the first timestamp and total count are computed by gmc300.exe. On a few computers of TAAT and GUUG at which I have looked at so far, first timestamp always seems to be 1000; first total count is 477 after CPM=14336, 657 after CPM=13154, 665 after CPM=13312, 667 after CPM=13358.) Every subsequent ≈4m1s, gmc300.exe creates a new reading with new_timestamp = previous_timestamp + ≈4m1s, and new_total_count = previous_total_count + current_CPM * ≈4m1s, and flag = "n".

(So there is a certain error of measurment in gmc300.exe's reports, because it takes "current CPM" (which is a moving average computed by the device firmware) to mean the same as "average CPM during the past four minutes".)

Anyway; gmc300.exe sends one "f" record and several "n" records to the server like radac_1.78 does. The server cares for deltas between f…n…n…n…n…, and if gmc300.exe has got a correct CPM in its second try, already its first n and therefore the first delta will be fine.

 

[StefanR5R]

My progress so far:

I received a GMC-300S, GMC-320+V4, and GMC-500+ for good measure yesterday.
Today I tried them out with the existing gmc300.exe in Windows and in Linux+Wine, and got that working — to the extend at which gmc300.exe works, see previous discussion.

Spoiler: notes of my various steps and missteps

• Tried GMC-500+ in BOINC on an old Windows laptop, using the anonymous platform files which @Skillz linked to. It sort of works, although gmc300.exe is plagued by the following three problems:
  • The first <GETCPM>> still reads remaining bytes from the earlier <GETVER>>. (Already discussed in this thread.)
  • Subsequent <GETCPM>> have their byte order inverted because <GETVER>> returned an odd number of bytes. (Also already discussed in this thread.)
  • gmc300.exe takes every other <GETCPM>> as 0x00 0x00, because it expects two bytes in return as per GQ-RFC1201, but GMC-500/500+/600/600+ return four bytes as per GQ-RFC1801.
• Tried GMC-300S on an OpenSUSE Linux computer.
  • geigerlog_simple.py from post #3 works right away. Before, I gave all users read-write permission to /dev/ttyUSB0 which belongs to the device, and I switched the device on via its physical button.
  • Wine links /dev/ttyUSB0 to ~/.wine/dosdevices/com33. I therefore entered <portnumber>33</portnumber> in gmc.xml, started wine gmc300.exe in a temporary directory which also contains gmc.xml, but the program fails with "Unable to open port COM33". It isn't a permission error, see above.
  • Same "Unable to open port COM33" if I let gmc300.exe process a real Radioactive@Home task in BOINC, using a little wine wrapper based on my older recipe.
  I haven't used Wine on this computer for anything else before and am therefore not sure what other problems this Wine installation might have, besides the inability to access COM33 in gmc300.exe.
• Tried GMC-300S on a Linux Mint computer.
  • At first, /dev/ttyUSB0 didn't get created in the first place because of some obscure conflict. From dmesg:
    

    [   81.832462] usb 1-9: new full-speed USB device number 6 using xhci_hcd
    [   81.981524] usb 1-9: New USB device found, idVendor=1a86, idProduct=7523, bcdDevice=81.34
    [   81.981536] usb 1-9: New USB device strings: Mfr=0, Product=2, SerialNumber=0
    [   81.981544] usb 1-9: Product: USB Serial
    [   82.021285] usbcore: registered new interface driver usbserial_generic
    [   82.021302] usbserial: USB Serial support registered for generic
    [   82.023013] usbcore: registered new interface driver ch341
    [   82.023032] usbserial: USB Serial support registered for ch341-uart
    [   82.023050] ch341 1-9:1.0: ch341-uart converter detected
    [   82.023525] usb 1-9: ch341-uart converter now attached to ttyUSB0
    [   82.040670] input: PC Speaker as /devices/platform/pcspkr/input/input13
    [   82.573818] input: BRLTTY 6.4 Linux Screen Driver Keyboard as /devices/virtual/input/input14
    [   82.579304] usb 1-9: usbfs: interface 0 claimed by ch341 while 'brltty' sets config #1
    [   82.579741] ch341-uart ttyUSB0: ch341-uart converter now disconnected from ttyUSB0
    [   82.579753] ch341 1-9:1.0: device disconnected

    Based on a random web search result, I worked around this by means of sudo apt remove brltty.
  • After this and sudo chmod a+rw /dev/ttyUSB0, geigerlog_simple.py works right away.
  • Wine links /dev/ttyUSB0 to ~/.wine/dosdevices/com33 on this computer too. After putting <portnumber>33</portnumber> into gmc.xml, wine gmc300.exe fails with "Unable to open port COM33" like on the OpenSUSE computer.
  • So I removed all com* symlinks from ~/.wine/dosdevices, linked ttyUSB0 as com1, made ~/.wine/dosdevices read-only, reverted to <portnumber>1</portnumber> in gmc.xml, and wine gmc300.exe works!
  • Went back to the OpenSUSE computer, manhandled Wine's COM port assignment the same way, gmc300.exe failed with "gmc_GetVersion(): read failed" at first, tried geigerlog_simple.py once more (works) tried gmc300.exe again, works!
  • Manipulated /var/lib/boinc/.wine/dosdevices in the same way, and gmc300.exe works in BOINC now too with GMC-300S on OpenSUSE.
• Attached the GMC-320+V4 to the Mint computer.
  • At first, geigerlog_simple.py timed out on its first getCPM(). I changed the port speed from the default 115200 baud to 57600 baud, and then geigerlog_simple.py worked.
  • Standalone gmc300.exe worked too. The manipulated ~/.wine/dosdevices was still in place.
  • In /lib/systemd/system/boinc-client.service, I changed ProtectHome from true to false and ProtectSystem from strict to false. Otherwise, Wine wouldn't be able to populate /var/lib/boinc/.wine.
  • Started and aborted a first wine-encapsulated gmc300.exe task. Manipulated /var/lib/boinc/.wine/dosdevices. Started another task with gmc300.exe and it works. (With the common problem of the first two <GETCPM>> containing garbage.)

Spoiler: my BOINC files for Linux+Wine

app_info.xml

<app_info>
   <app>
      <name>radac</name>
      <user_friendly_name>Radioactivity Monitor</user_friendly_name>
   </app>
   <file_info>
      <name>gmc300.sh</name>
      <executable/>
   </file_info>
   <file_info>
      <name>gmc300.exe</name>
      <executable/>
   </file_info>
   <file_info>
      <name>gmc.xml</name>
   </file_info>
   <app_version>
      <app_name>radac</app_name>
      <version_num>170</version_num>
      <file_ref>
         <file_name>gmc300.sh</file_name>
         <main_program/>
      </file_ref>
      <file_ref>
         <file_name>gmc300.exe</file_name>
      </file_ref>      
      <file_ref>
         <file_name>gmc.xml</file_name>
         <copy_file/>
      </file_ref>
   </app_version>
</app_info>

gmc300.sh

#!/bin/bash
exec /usr/bin/wine /var/lib/boinc/projects/radioactiveathome.org_boinc/gmc300.exe

 

[StefanR5R]

N00b question: How to add a host to the map?

I went to the host details web page of the host which I wanted to add, entered the longitude in decimal notation in the "Long: [______]" input, the latitude in decimal in the "Lat: [______]" input, hit "[Add sensor!]" … and nothing really happened. When I go to the host details page again, the same inputs are presented and are empty. (User ID and Host ID are filled and can't be edited.) The host doesn't show on the map, yet.

Did I already do everything what I am supposed to, and do I just need to wait some time for Rad@Home's database to be refreshed for the host to show up on the map?

Notes:

• Google Maps and OpenStreetMap show the latitude first and the longitude second, and so I put that second value into the first input and the first value into the second input.
• I looked at Rad@home's map around the Gulf of Aden, which is where a European location would end up if longitude and latitude were mistaken for each other. There are indeed a few European hosts there at the moment, but not mine.

Edit:
According to a post in SETI.Germany's forum, the labels are swapped at Rad@Home's host details page! That is, we supposedly need to enter "Long: [ latitude ]" and "Lat: [ longitude ]".

Edit 2:
Although my host isn't shown on the map yet, it is at least already getting double credit for its results (which happens when a host was added to the map).

 

[biodoc]

According to a post in SETI.Germany's forum, the labels are swapped at Rad@Home's host details page! That is, we supposedly need to enter "Long: [ latitude ]" and "Lat: [ longitude ]".

Yes, they are swapped. We believe nodes are added to the map once per day. I made a comedy of errors before @gsrcrxsi pointed out my location was in the wrong place. I started out in Kyrgyzstan (latitude and longitude entered in the right boxes but I left the "-" sign on the longitude. I reentered the correct values in the right boxes (mislabeled) and ended up in Antarctica. I finally got it right and ended up in Massachusetts.

 

[StefanR5R]

From the HTML code of the page:

Long: <input id='lat' name='loc1' />
Lat: <input id='lng' name='loc2' />

#-)

 

[Markfw]

Noob question. Aside from giving you BOINC credits, what does this app accomplish ?