#8 GeigerLog pre-release 1.5.1pre14 + FNIRSI GC-01 (Geehy)

[nonus]

I tried the new version. When connecting the FNIRSI GC-01 (Geehy) device, the tube voltage profile switches to a custom mode of 1.25 Hz and 50%, the Geiger tube stops working.

[nonus]

FNIRSI GC-01 (WCH) device the same.

[nonus]

Log...

[ullix]

Your graphs and log data show that GeigerLog opens ok, it closes ok, and in between it collects data ok, at a proper setting of the voltage!

Where is the problem? I don't see it.

If you measured "background" then the countrate is a bit on the high side. However, your collection period of a good minute is too short to draw any meaningful conclusions. Let it run overnight.

A word to the configuration files: While it is best to not touch the default geigerlog.cfg file, the custom.cfgfile should be edited to your specific situation. Delete every config in there which does not match your setup, and set only what is specific for you.

In your case the custom.cfg should consist of nothing but (plus any comments - i.e. lines beginning with '#' - you wish to keep/add):

# my helpful comment
[RadProDevice]
RadProActivation = yes

I noticed you were defining RadProPort = COM3. Was this necessary? GeigerLog is supposed to discover this automagically!

[nonus]

Ok, I'll try. The new version is good. In the old version, I installed many modules manually.

[nonus]

The problem remains.
https://youtu.be/xsRB3oAugqg

[nonus]

It worked, the geiger tube is powered by default.

[nonus]

Without transmitting radon data to the server, it is not possible to connect.

[ullix]

You have lost me - is it working or not?

If anything is NOT working, I do need to see the logfiles!

And if it is working, why do you switch off the auto-control of the RadPro-Counter's anode voltage? This is onw feature, where RadPro devices beat all other Geiger counters!

And, by the way, you cannot measure Radon concentrations with a Geiger counter; any Geiger counter!

[ullix]

I just noticed that there is a bug on GMCmap which results in an upload failure every now and then.

Attached file has a work-around for this issue; copy it over the existing one.

[nonus]

The program works, but there is a bug. When I connect the dosimeter to the computer, GeigerLog itself changes the voltage profile of the dosimeter and the Geiger tube stops working. If I return the voltage profile in the dosimeter settings back (to default), GeigerLog again changes it to non-standard after some time. I was able to remove this bug when I disabled the auto-control of the RadPro-Counter's anode voltage function.

[nonus]

Transfer of readings to the server works correctly, there is no radon data. The bug with the voltage profile remains.

[ullix]

Sorry, but I cannot see a "bug" in GeigerLog. I am running this on my FNIRSI GC-01 device, and all is running flawlessly!

Apparently the "Auto-Anode-Voltage-Setting" is working. This is, how GeigerLog is supposed to work; it is supposed to maintain a constant voltage of 430V at the anode even at very high count rates, where the voltage would collapse. As I had shown it works correctly at least up to CPM=5000, the highest I could manage.

It is noteworthy that this is a feature not available in any other Geiger counter nor software; GeigerLog is unique!

This action by GeigerLog overwrites any voltage setting done on the counter. When you then select "custom" on the counter, you reverses this setting. And then GeigerLog overwrites again ...

As you noticed, this feature can be inactivated from the RadPro menu, but the preferred way is to keep this automation!

However, does seem to not work on your device. You describe a phenomen, which I do not see. This suggests that there is a difference between your Geiger counter and mine.

My device is:
Hardware: FNIRSI GC-01 (CH32F103C8) (yellow case)
Software: Rad Pro 2.0.1beta3
Your device is:
Hardware: FNIRSI GC-01 (APM32F103CB) (blue case)
Software: Rad Pro 2.... (I think I saw it in your posts, but can't find it again?)

I doubt the hardware is the cause, but there could very well be a regression in the software? There is also the possibility that the feature used by GeigerLog had been removed from the firmware code, who knows.

As the beta code is no longer offered for download - the closest is 2.0.1 - I wonder whether you can install this on your counter and rerun the tests (starting GeigerLog with GeigerLog.bat -dvw devel trace)?

But before you do, let's get some other checks done, from the RadPro Series menu:

• click on "Show Extended Info" and post result here.
• click on "Set RadPro Anode Voltage". Can you change the voltage in the range 300...800V according to what GeigerLog reports?
• do you have equipment (a DVM and GigaOhm resistor) to measure true Anode voltage? If yes, please do so. Can you confirm to get similar values to what GeigerLog reports?
• you can also experiment with the RadPro's PWM settings. While easy to do, it is complicated to interpret, but does the device respond at all with the same values as you have entered?

[nonus]

Thanks for the answer. I want to say that the new functions are good, but it is better to write about them in advance. I think this is a very dangerous function that can kill your geiger tube if it works at a voltage of no more than 400 V (most tubes). I have a version of gc-01 with both chips (different firmware, yellow and blue housing) and the "bug" is on both versions. Now I am afraid to use the sbt-10 geiger tube, because its working voltage is 360 V. In my opinion, it is better to turn off this function by default.

[nonus]

RadPro 2.02

[ullix]

You do realize that you are downloading from a "devel" site a software labelelled "pre-release"? If you don't want an occasional surprise, then do not use development versions. Of course, then you also can't get the freatures maturing in those development versions!

You can't damage a Geiger tube with low voltage, including zero voltage when the tube is in storage. But you can damage a tube with high voltage. What "high" means depends on the tube; some tubes require 1000V for proper function.

I didn't expect that somebody would venture into un-soldering the built-in tube ;-) but this could easily be accomodated. The auto-voltage control can also be made optional. However, it is at present not established that the implemented voltage-control-curve is the same with a different tube.

For the time being, if you want to fiddle with the voltages, you can apply these changes to the code. Open file gglobs.py and find these lines near line number 1030:

RadProVoltageDefault = 430   # in Volt - Anode Voltage of the Geiger tube
RadProVoltageControl = True  # True  - allow controlling the voltage

and change to your desired setting, possibly like:

RadProVoltageDefault = 360   # in Volt - Anode Voltage of the Geiger tube
RadProVoltageControl = False # True  - allow controlling the voltage

If you are interested in helping to figure out the problem in firmware 2.0.2 then please do the checks referred to in https://sourceforge.net/p/geigerlog/tickets/8/#b564

[nonus]

RadProVoltageControl = False # True  - allow controlling the voltage

This works, but when you first connect the dosimeter, the profile settings are merged with custom ones. After returning the dosimeter voltage settings to default, the function is not active.

RadProFrequencyDefault      = 168              # in Hz - PWM Frequency of the HV Generator

Why is the frequency 168 Hz? The Geiger counter (j 321) operates at a frequency of 2500 Hz and 8-35%.

[ullix]

Why is the frequency 168 Hz? The Geiger counter (j 321) operates at a frequency of 2500 Hz and 8-35%.

Not correct. It is the counter and its firmware, which allows its PWM to be set with a frequency from 100 Hz --- 100kHz and a duty cycle of 0...100%. There are multiple settings possible for a given voltage. My investigation showed that a duty cycle of 50% is the most reliable, and the frequency-voltage relationsship is almost linear. GeigerLog uses a 2nd degree parabolic fit for setting the voltage.

If you want more details read this thread https://www.geigerzaehlerforum.de/index.php/topic,2277.0.html It is in German, but Google will help in the translation.

[ullix]

I have now tested firmware RadPro 2.0.1beta3, 2.0.1, and 2.0.2 on a yellow FNIRSI GC-01. Each works as expected.

There is no such bug, neither in GeigerLog nor in any of those firmwares!

To demonstrate, GeigerLog allows some even more complex operations with RadPro devices, e.g. one can scan for countrate versus anode voltage, like:

1. Set the voltage (e.g. to 300V)
2. measure countrate for some time (e.g.100 cycles of 1 sec each)
3. Increase the voltage by plus 10 V; repeat #2
4. When 800 V is reached, reverse voltage change to minus 10V, and measure countrate
5. When 300 V is reached, reverse voltage change to plus 10V, and measure countrate
6. continue endlessly

Result is shown in the picture, where firmware 2.0.2 is installed on the FNIRSI GC-01 (yellow).

An anode voltage of 300 V is below the low (left) edge of the Geiger plateau, and no counts result. From approx 410 V up to 800 V the countrate increases along the plateau (which obviously is not a perfectly flat plateau). Then the voltage is reversed and decreased back to 300 V, with the countrate "sliding down" the plateau.

This is as expected; the RadPro does a really nice job!

[nonus]

Need another tester of the new program feature to be sure. Maybe the problem is caused by the computer port. I will try another laptop and python version.

[nonus]

The bug repeated itself on another laptop.

[nonus]

The problem remains. You need to set a higher default frequency value: 141.6 Hz is too low for the Geiger tube to work.

[nonus]

I found how to change the duty cycle to 35% instead of 50%. It remains to find the frequency values.

[ullix]

The situation is a bit more complicated.

I have received a 2nd GC-01 counter, this time it has the Geehy processor, instead of the WCH made one in my1st counter. I verified that the RadPro works the same: when GeigerLog sends a PWM command, the firmware translates it into the proper PWM signal, with correct Frequency and Duty Cycle, verified by Osci. So, no bug neither in RadPro firmware nor in GeigerLog.

I scanned the circuit board of each counter by magnifying glass, and found no difference. Though this is surely not conclusive, in particular with a SMD board.

But: the anode voltage outcome on both devices is very different, whatever the cause is. And this is what you experience.

The additional problem is that I can also not rule out that devices with the same chip will behave the same; the future will tell ...

For now I am wondering whether you could help figuring this out. Do you have equipment to measure anode voltage? It needs a Digital Volt Meter with a 10 MOhm impedance, and a 1 GigaOhm resistor. If you need a good instrument, I recommend this one as high quality and low cost (had been mid $30) at Amazon or AliExpress: https://www.amazon.de/Pawmate-Multimeter-Amperemeter-Multitester-Spannungsstromwiderstand/dp/B08NJT38SF

If you are not familiar with the issues, there is an explanation in the chapter "The Anode Voltage" if my article GeigerLog-Radiation-v1.1(CAJOE)-Support on the GeigerLog site https://sourceforge.net/projects/geigerlog/files/Articles/ .

If you are setup for measuring it, please keep Duty cycle at 50%, and change frequency to end up with anode voltages between 200 and 600 V, and post results for frequ vs volt.

[ullix]

The clouds are lifting, see this explanation for the different voltage behaviour of the GC-01 devices:
https://github.com/Gissio/radpro/discussions/145#discussioncomment-11506845

Different inductivities of 1mH vs 10mH

[nonus]

Ok, I'll look at my board later and I can find out my inductance. I ordered a 1GOhm resistor, I can do voltage measurements later.