GeigerLog / Tickets / #14 GeigerLog does not detect a GMC-800 device with Rad Pro firmware

Oh dear, yes, this can't work :-(

Trying as GMCdeivce: of course, once you have overwritten the GMC firmware, you can't use the GMC commands anymore. So, this tells you that the firmware has in fact changed!

To be sure: The GMC device does seem to be working fully with that RadPro firmware?

The "getPortList" in line 5 shows the first problem: the MAC is hiding information which the USB does provide, and which I used to identify devices. Well, doesn't work because the info is not there.

I can't test on a Mac. I wonder if it has the same 'lsusb' command as Linux? If so, use it and post the output.

$ lsusb
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 003 Device 088: ID 248a:ff0f Maxxter Wireless Receiver
Bus 003 Device 089: ID 046d:c52b Logitech, Inc. Unifying Receiver
Bus 004 Device 028: ID 05e3:0626 Genesys Logic, Inc. Hub
Bus 005 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 005 Device 003: ID 0483:5740 STMicroelectronics Virtual COM Port

If this works, there may the also have the option for a more detailed list. On linux I can do 'lsusb -vs 5:3' (Bus 5 and Device 3 is the RadPro port) and get like:

$ lsusb -vs 5:3

Bus 005 Device 003: ID 0483:5740 STMicroelectronics Virtual COM Port
Couldn't open device, some information will be missing
Negotiated speed: Full Speed (12Mbps)
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               2.00
  bDeviceClass          239 Miscellaneous Device
  bDeviceSubClass         2 [unknown]
  bDeviceProtocol         1 Interface Association
  bMaxPacketSize0         8
  idVendor           0x0483 STMicroelectronics
  idProduct          0x5740 Virtual COM Port
  bcdDevice            1.00
  iManufacturer           1 Gissio
  iProduct                2 Rad Pro
  iSerial               254 018C7130
  bNumConfigurations      1
  Configuration Descriptor:
  (more lines following)...

Important is IManufacturer and iProduct. What are you getting?

Michel - 2026-06-04

O.K., this seems getting more complicated, and I'm afraid, becomes a MAC speciality.

To be sure: The GMC device does seem to be working fully with that RadPro firmware?

Yes, it seems working proper. At least I have not observed any issues up to now.

lsusb does not natively exist on a MAC. However, there are homebrew packages which enable a kind-of lsusb command by calling the system profiler.
In my case, this gives for the device:

USB 3.1 Bus: Location ID: 0x02000000 Connection Type: Built-in Driver: AppleT8122USBXHCI USB Serial: Location ID: 0x02100000 Connection Type: Removable Serial Number: Not Provided Link Speed: 12 Mb/s USB Vendor ID: 0x1a86 USB Product ID: 0x7523 USB Product Version: 0x0264 Power Allocated: 2.41 W (482 mA)

According to ChatGPT, the

USB Vendor ID: 0x1a86 USB Product ID: 0x7523

is a
CH340 / CH341 USB-to-Serial chip, common on ESP8266 / ESP32 dev boards, which maps to the usb-serial:

ESP board
↓ (CH340 chip: 1a86:7523)
macOS USB stack (AppleT8122USBXHCI)
↓
/dev/cu.usbserial-210

So a Gissio/RadPro product is not visible on a MAC
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

After some further checking with chatGPT :-) it may not necessarily be a MAC problem, since other connected USB devices do show a manufacturere/product in the system profiler. e.g.:

Bus: 0 Device: 1
Vendor ID : 0x152d
Product ID: 0x579
Manufacturer: Intenso
Product     : External USB-3.0
Serial      : 201803071010F
Class       : 0
Speed       : 4

But for the counter:

==============================
Bus: 2 Device: 1
Vendor ID : 0x1a86
Product ID: 0x7523
Manufacturer: None
Product     : USB Serial
Serial      : None
Class       : 255
Speed       : 2

Important points:

1. Manufacturer: None and Serial: None
This is not a macOS problem.
👉 Many CH340/CH341 chips simply do not expose USB string descriptors properly

So it may be a counter FW problem...

ullix - 2026-06-05

I realized that all GMC counters do show this:

Manufacturer: None Product : USB Serial

So, it could well be that RadPro missed, or failed setting these USB properties. Perhaps those CH340 chips don't allow modification by firmware code - I don't know.

But I am now using "USB Serial" for pre-selecting the ports, and then test for RadPro responses on those ports. We'll see what happens.

Attached is a new gdev_radpro.py. I expect it to work by just copying over the existing file.

Last edit: ullix 2026-06-05

gdev_radpro.py
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Thanks! This works (incl. e.g., reading the history from the device).

==== Connect RadPro Device ============================================================
Device 'RadPro' successfully connected

==== Device Mappings ==================================================================
Mappings as configured in GeigerLog's configuration file:
Device     : CPM  CPS  CPM1st CPS1st CPM2nd CPS2nd CPM3rd CPS3rd Temp  Press Humid Xtra 
---------------------------------------------------------------------------------------
RadPro     : -    -    -      -      -      -      M      M      -     -     -     -    
Mapping is valid
No need for correcting clock drift:

==== RadPro Device Info Extended ======================================================
Configured Connection:        Port:'/dev/cu.usbserial-210' Baud:115200 Timeouts[s]: R:0.5 W:0.5
Connected Device:             GQ GMC-800  Chip:WCH  'Yellow Case'
Firmware Version:             Rad Pro 3.1.1/en
Device Clock Drift:           1 sec  (checked @ Computer Time: 2026-06-05 19:13:25)
                              Device Clock is same as Computer's within 1 sec
Configured Anode Voltage:     380 V
Configured Variables:         CPM3rd, CPS3rd
Applicable Tube Sensitivity:  
   CPM3rd / CPS3rd:           108.345 CPM / (µSv/h)

Extended:                     
Anode Voltage under Control:  
   Voltage Control Target:    Off
   Voltage Control Time Cnst: Off
   Voltage Control Strength:  Off
Scanning:                     Off
Tube Freq(Volt) @ DC=50%:     Freq = -317 + 1.52 * Volt + 0 * Volt² + 0 * Volt³
Tube PWM Frequency:           260.6 Hz
Tube PWM Duty Cycle:          50 % 
Device Time:                  2026-06-05 19:13:24  timestamp: 1780679604
Device ID:                    5e9c33343738040052383737
Device Battery Voltage:       4.136 V
Tube life time:               88309
Tube life pulse count:        45398
Tube rate:                    44.939 CPM
Tube conversion factor:        CPM/(µSv/h)
Tube dead time:               0.0001010 s
Tube dead-time compensation:  0.0000000 s
Tube background compensation:  CPM

On the USB properties, it may well be that the counter is using a clone chip/ESP. I had a similar experience with Arduino boards recently. Some boards seem to use a China clone ATMega not supporting all features of an original ATMega...

ullix - 6 days ago

Good News!

Though I still see some flaws, and hope you can help:

The reported Anode voltage of 380 V seems rather low. Do you know/remember what it had been und the GMC firmware? Are you able to measure the anode voltage - you need a DVM and a 1 GigaOhm resistor?

The Chip-Type is likely wrong. Next time you have run the thing please start GL with:
./GeigerLog.sh -d and post file geigerlog.proglog.devel or if not found geigerlog.proglog.

I am surprised to hear that even reading the history does work! Another user just tolf me that this does NOT work, because - as Gissio said - some changes were done to the code which made it incompatible with existing software. Wonderful, nobody asked for it, but you make a change anyway that renders existing options useless :-((. I need to verify this. Please, do:

Download the current History. Should give a file with ending ".hisdb"; please post.
Then delete History (at the device), and start logging for a long run (like overnight). When finished, post files ".logdb" and download ".hisdb".

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Michel - 6 days ago

I've set the HV profile in the counter to "Factory default" and removed the automatic call to setRadProVoltage in initRadPro() for now (since it always overwrites the "Factory default" ) :

### set the default Anode voltage dprint(defname, f"Set Anode Voltage to: {g.RadProVoltageDefault} V") setIndent(1) # setRadProVoltage(g.RadProVoltageDefault) setIndent(0)

The Factory default seems:

Tube PWM Frequency: 2500 Hz Tube PWM Duty Cycle: 16.3 %

This gives 380 ... 400 V when measured with a 1 GOhm. These are quite the same as I measured some time ago with the original FW.

When I use the setRadProVoltage, I measure always around 500 V....independent on how I set the Anode Voltage in the geigerLog menu (even when set to 200V in geigerLog I measure ~500V with the multimeter).

I am surprised to hear that even reading the history does work!

Not reliably. ...I don't know what I did yesterday, but I also can't download the history now. The current history is just rubbish and has only about 40 seconds, although I'm logging with 1 minute.

TEST3.hisdb
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Michel - 4 days ago

Attached are some history files from the same session --- from logging with GeigerLog, download with GeigerLog, and download with the RadPro tools. Some small time periods seem to work fine; others miss the data.

On the anode voltage setting at startup/connection of the counter, it would be cool if this could be switched off in the config file. I think the GMC-800 may have a loosely regulated step-up converter and may not need this.

My ~380 V measurement may include some artefacts, but measuring the original GMC-800 with the same equipment gave the same result. The RadPro "Factory Default" settings seem just fine.

For my (old) GMC-500+ I measure only ~ 320 V....which measures a background of around 22 CPM on average. With the GMC-800 (both, original FW and RadPro) the same background is about 30 CPM. Both have a M4011 printed on the tube. Also with some gas mantle, the GMC-500+ measures quite lower than the GMC-800.

TEST.csv

TEST.hisdb

TEST.logdb

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

ullix - 4 days ago

Thx, I looked at the details.
Please, always start GL with the option "-d", i.e. command is: "./Geigerlog.sh -d". This will create a proglog file with important info. Post file geigerlog.proglog.devel .

File TEST.csv:
where does this come from? It is not from GL. Its content is weird, to say the least. Many data missing, and many multiple lines, identical in timestamp and other. This gives hundreds of lines with no information???

File TEST.logdb:
Looks ok. Poisson test reveals some potential problems, but this might still be a statistical effect due to low total counts. It might clear up with even longer collection times.

File TEST.hisdb:
Good Lord, what is this? Looks like total crap. You did Reset the History (i.e. clear it out completely) at the device before this recording?

Anode-Voltage:
Your voltage measurements don't look right!Such measurements aren't trivial. What is your exact setup?

However, having 320V at the GMC-500 and getting counts seems impossible. See the pic, which I measured some time ago. 320V should already be below the cliff. As the voltage declines with increasing count rate, a start voltage between 450 and 500 V is recommended!

I'll make the voltage setting an option; will post later.

Selection_013.png

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

ullix - 4 days ago

Attached an update. Make sure to copy over the existing same-name files!

test.zip

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Michel - 4 days ago

Thanks for the update. It seems GeigerLog cannot understand the string "off" (default voltage settings are still send to the device):

08 21:01:07.835 ...198 EXCEPTION: RadProVoltageDefault setting: '{t}' >'could not convert string to float: 'OFF''< in file: gsup_config.py in line: 2151

See attached log file.

Some additional observations:
It seems the following two RadPro commands are obsolete in RadPro 3.1.1:
https://github.com/Gissio/radpro/blob/main/docs/comm.md

GET tubeConversionFactor GET tubeBackgroundCompensation

They show up as

Tube conversion factor: ERROR CPM/(µSv/h) Tube background compensation: ERROR CPM

in the plot window,

A new command seems to be:

GET tubeType

File TEST.csv:
where does this come from? It is not from GL. Its content is weird, to say the least. Many data missing, and many multiple lines, identical in timestamp and other. This gives hundreds of lines with no information???

This is downloaded using the RadPro Tools:
https://github.com/Gissio/radpro/tree/main/tools

python3 radpro-tool.py --port /dev/tty.usbserial-210 --download-datalog datalog.csv

File TEST.hisdb:
Good Lord, what is this? Looks like total crap. You did Reset the History (i.e. clear it out completely) at the device before this recording?

Yes, I deleted the history before connecting the counter.

On my HV voltage measurements:
I use a 1 GOhm resistor (1%/5W):
https://www.amazon.de/dp/B0193168BG?ref_=ppx_hzsearch_conn_dt_b_fed_asin_title_2
in series with my Fluke multimeter:

HV (GMC-800) ---[ 1 GΩ resistor ]------------ Multimeter + GND (GMC-800) -------------------------------- Multimeter –

The measurement is likely too low. As far as I can see, the high-voltage converter in the GMC counters (both 500+ and 800) has an extremely high output impedance, so even a 1 GOhm load pulls the voltage down by a measurable amount. That's why I prefer to be conservative with such "measurements" and the default settings seem just about right (except for my 500+ which is likely a bit too low), but obviosuly, seems sufficient.

a start voltage between 450 and 500 V is recommended!

That looks too high for a M4011. Based on various sources, it seems about 360 – 440 V
(e.g., https://github.com/Gissio/radlab/tree/main/simulations/m4011/specs)

geigerlog.proglog
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

ullix - 3 days ago

Thanks for the update. It seems GeigerLog cannot understand the string "off" (default voltage settings are still send to the device):
08 21:01:07.835 ...198 EXCEPTION: RadProVoltageDefault setting: '{t}' >'could not convert string to float: 'OFF''< in file: gsup_config.py in line: 2151

Darn, I forgot to also include modified file gsup_config.py; now attached.

gsup_config.py

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
- Michel - 2 days ago
  
  Thanks! This seems to work now. GeigerLog does not overwrite the HV profile when connecting.
  
  If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

ullix - 3 days ago

Your HV measurement is what it should be! I had elaborated on those measurements in my article https://sourceforge.net/projects/geigerlog/files/Articles/GeigerLog-Radiation-v1.1%28CAJOE%29-Support-v1.0.pdf/download
see chapter §The Anode Voltage". The internal resistance of the HV Generator typically comes out near 20MOhm. I have not seen a counter with much lower internal resistance, not even in those old clunkers of counters! One easy test: Touch the terminals of the built-in and powered tube with 2 fingers of one hand - if you don't get a shock it is 20 MOhm ;-))

The M4011 specs referred to on RadPro are strangely identical to a reference on my site, see file M4011... on https://sourceforge.net/projects/geigerlog/files/Supporting%20Documents/
These data are from UNKNOWN sources. Whether they have any value, I don't know!

But note they both suggest a starting voltage of 350V and a work range of 380 to 550V. Depending on intensity of your sources, the voltage from background to Hi counts may decline by 50V, or even 100V! With no voltage control - which was possible in RadPro at least with the 2.X versions - you have no choice but to start with Hi-Voltage. And as the Count rate depends on the voltage, you get a non-linear relationship between intensity and count rate!

You can increase the voltage to such high levels (>770V) that your tube becomes fluorescent lamp - look at my video and enjoy ;-) https://www.youtube.com/watch?v=IbL_AeD6jAA

I have now removed references to the obsolete values; they weren't much of help anyway. Though the wisdom of removing values from one release to the next escapes me. New radpro attached.

I notice in your log that you have set custom values for tube sensitivities. I have never seen these values before, what are they based on? This issue had recently become a topi on another forum (in German) for the GMC-800 counter: https://www.geigerzaehlerforum.de/index.php?msg=41961
Result: Cs-137 Kalibrierung nach NIST/NRC-Standard : 96 CPM / (µSv/h) For me this is the Gold-Standard, as it is a real measurement. GQ has long pretended that 154 is their "calibrated" standard, but that is a lie, they had never measured anything.

gdev_radpro.py

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
- Michel - 2 days ago
  
  I notice in your log that you have set custom values for tube sensitivities. I have never seen these values before, what are they based on?
  
  These are the RadPro 3.1.1 default values for the M4011. They are based on numerical simulations from RadLab:
  https://github.com/Gissio/radlab/tree/main
  The tube type can be selected in the Menue. A Source Compensation based on RadLab can also be selected.
  
  The GMC-800 had its original 1st calibration point at 98.6 (for up to 10 uSv/h). So a calibration factor of around ~100 seems a reasonable value. But I think the final calibration factor does not depend solely on the physical properties of the tube (e.g., HV factory settings).
  
  My GMC500+ with FW 2.53 has now also 6 calibration poins (3 per tube). They kept the 1st point at 154 (for up 1 usV/h). However, the 2nd is now also 99.3 (100 uSv/h) and the 3rd is 94.14 (500 uSv/h)...
  
  If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

ullix - 3 days ago

RadPro in GL now has an option to run a RadPro command. GL must have been started with option "-d". Then in the RadPro menu you find Run RadPro Terminal Command.

E.g. Command 'GET deviceId' may print into the NotePad:

==== Run RadPro Command ========================================== Running Command: 'GET deviceId' 0 FNIRSI GC-01 (APM32F103CB) 1 Rad Pro 2.0.2 2 7907521b

Last edit: ullix 3 days ago

gdev_radpro.py
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Michel - 2 days ago

I cannot see this menue. Am I looking at the wrong place (see attached screenshot)?

I can see the runRadProCommand() in gdev_radpro.py (and I do start GL with -d option)

By the way, what should be shown for the "unknown chip"?

Connected Device: GQ GMC-800 Chip:unknown 'GQ GMC-800'

Is this the MCU? If so, this seems a STM32 (but likely a clone...)

Screenshot 2026-06-10 at 08.22.02.png
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

ullix - 2 days ago

Sorry, another fault of mine. It is getting complex with multi-file changes. But it seems it is all working now? Time for another full pre-release?

The chip is "unknown" because this info comes from RadPro - and there is none :-(. Looking at my own GMC-800 device I see all chip-labels being sanded off! It likely is a STM or clone, because this is what all currrent RadPro supported devices are.

I doubt that the chip info cannot be seen by the firmware, so chances are it is also hidden with intend by the firmware. Or have you seen a command to read out the chip ID?

P.S. Your screenshot shows exceptionally nice fonts!

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

ullix - 2 days ago

I have uploaded v2.2pre07:
https://sourceforge.net/p/geigerlog/discussion/devel2/

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

GeigerLog does not detect a GMC-800 device with Rad Pro firmware

Python program for Geiger counters and Environmental Sensors

Milestone

Searches

Help

#14 GeigerLog does not detect a GMC-800 device with Rad Pro firmware

Discussion