FNIRSI GC-01: Custom HV profile error

[ullix]

I got strange results scanning the PWM settings, and then checked PWM with an oscilloscope, measuring on the tube facing side of R9. I see a clean square signal (when there is one). These are the results:

2500 Hz 15%     ok, Startup conditions for 470 V HV; counter works
1000 Hz 15%     No PWM signal at all, zero HV voltage
1000 Hz 50%     No PWM signal at all, zero HV voltage
1000 Hz 75%     No PWM signal at all, zero HV voltage
 300 Hz 75%     No PWM signal at all, zero HV voltage
 300 Hz 40%     Good PWM signal, however, not as set but with Freq=1.66kHz 
                and Duty 70% as shown by osci

Looks like a bug in setting the PWM values?

[TzOk83]

Which MCU do you have in your unit? GC-01 was produced with at least 3 different MCUs.

[ullix]

RadPro reports: FNIRSI GC-01 (CH32F103C8)

[TzOk83]

RadPro will report whatever you will flash, important is what physically sits inside your unit.

[ullix]

Ooopsie, really? Using my magnifying glass, the imprint on the chip says, on 4 lines:

CH32F103 R8T6 401546C10 WCH

[TzOk83]

Ok, so your MCU is WCH CH32F103-R8T6, and you are using the correct firmware. My unit has a Geehy/Apex MCU so I'm using a different firmware, built using a different toolchain. Although Geehy and Apex have the same MCU core, they differ in peripherals.

Today I have noticed, that on a discharged battery, the duty cycle regulation has a much smaller effect on the HV, than on a fully charged battery. Also - measured voltage differs significantly when you run the device with or without the Geiger tube. Apparently, the tube acts as an output capacitor.

[Gissio]

Fixed.

To test the fix, download and decompress this beta release: https://github.com/Gissio/radpro/actions/runs/9456284458/artifacts/1587392805

If you flash your device with the bootloader, flash the corresponding -install file.

If you flash your device with an STLINK, download the flashtool. In the flashtool's lib/firmware folder, delete all radpro- files, and replace with the ones in the .zip file.

[ullix]

I'm afraid it is NOT fixed.

Install seems ok.

Hardware ID:     FNIRSI GC-01 (CH32F103C8)
Software ID:     Rad Pro 2.0.1beta1

But the PWM data are wrong:

The frequency was set by GeigerLog software to 300 Hz (red curve, data as reported by Radpro).

The duty was scanned in 1% steps from 0 ... 100% (black curve, 10x, data as reported by Radpro).

The Anode-Voltage is measured by DMM (dark green). The Frequency is measured by 2nd DMM (light green), and confirmed by osci.

The measured frequency is either 1.66 kHz or zero Hz. At no point is it ever the same as the set, and Radpro confirmed, frequency of 300Hz.

The Anode-Voltage increases 4 times during this scan from zero Volt up to 1400Volt. While I find it impressive that a cheapo-device like the GC-01 can do a voltage as high as 1400V, it is not related to my settings.

[ullix]

Same as before except that Frequency had been set to 2.5kHz. The light green curve and the red curve should be identical.

[ullix]

Question: is the RadPro code based on Hardware-PWM or Software-PWM?

[Gissio]

There was another issue with the HV PWM timer.

It should be fixed now: https://github.com/Gissio/radpro/actions/runs/9473910151/artifacts/1591656185

[ullix]

Nope. Two more scans at 300Hz and 2500Hz; same colors as before. Red and Light-Green should be identical curves.

When the frequency collapses, the voltage, unsurprisingly, collapses as well.

I am wondering what kind of testing you do to make a "fixed" claim? It is not fixed as these simple tests easily show. I'll give you a copy of my GeigerLog code (the latest is not released yet) if you'd like to use it. All you need is a DMM which can be accessed by computer, via serial or Bluetooth.

[Gissio]

This issue only occurs when changing PWM parameters very rapidly.

Could you test https://github.com/Gissio/radpro/releases/tag/2.0.1beta3?

[ullix]

First observation: I cannot set the DateTime:

==== RadPro Device Info ===============================
Configured Connection:        Port:'/dev/ttyACM0' Baud:115200 Timeouts[s]: R:0.5 W:0.5
Device is connected           
Hardware ID:                  FNIRSI GC-01 (CH32F103C8)
Software ID:                  Rad Pro 2.0rc3
Device Clock Drift:           1546832305 sec  (checked @ Computer Time: 2024-06-18 11:22:40)
                              **Device Clock is slower than Computer's by 1546832305 sec**
Tube HV PWM frequency:        9207.10 Hz
Tube HV PWM duty cycle:       75.00 %

==== Setting RadPro DateTime =======================
**RadPro Datetime was set to Computer DateTime**

==== RadPro Device Info =========================
Configured Connection:        Port:'/dev/ttyACM0' Baud:115200 Timeouts[s]: R:0.5 W:0.5
Device is connected           
Hardware ID:                  FNIRSI GC-01 (CH32F103C8)
Software ID:                  Rad Pro 2.0rc3
Device Clock Drift:           1546832349 sec  (checked @ Computer Time: 2024-06-18 11:23:29)
                              **Device Clock is slower than Computer's by 1546832349 sec**
Tube HV PWM frequency:        9207.10 Hz
Tube HV PWM duty cycle:       75.00 %

This is the GC-01 time:

Device Time:                  1975-06-13 06:44:43  timestamp: 171870283

[ullix]

Next observation: History saves negative(!) count numbers: (see youngest Hist entry)

18 11:45:09.688419 DEVEL  : ...425    queryRadPro: GET datalog 1718703609       [B]:W:24  R:111  Dur[ms]:W:0.06  R:9.21  Ttl:12.06 [kB/s]:W:418 R:12  Ttl:9    resp:b'OK time,tubePulseCount;1718703633,711842;1718703693,733994;1...'
18 11:45:09.688648 DEVEL  : ...426       getRadProHist: 
18 11:45:09.688878 DEVEL  : ...427          getRadProHist: Total no of records: 5 (+ 1 for header)
18 11:45:09.689008 DEVEL  : ...428          getRadProHist: index:   0  header: 'time,tubePulseCount'
18 11:45:09.689209 DEVEL  : ...429          getRadProHist: index:   1  time:1718703633 2024-06-18 11:40:33  pulse_count: 711842  delta_time: nan  delta_pulse_count:nan   . sixty:0      >:0    nan%   <:0    . CPM:nan
18 11:45:09.689322 DEVEL  : ...430          getRadProHist: index:   2  time:1718703693 2024-06-18 11:41:33  pulse_count: 733994  delta_time:  60  delta_pulse_count:22152  . sixty:1      >:0    0%     <:0    . CPM:22152.0
18 11:45:09.689422 DEVEL  : ...431          getRadProHist: index:   3  time:1718703753 2024-06-18 11:42:33  pulse_count: 754319  delta_time:  60  delta_pulse_count:20325  . sixty:2      >:0    0%     <:0    . CPM:20325.0
18 11:45:09.689525 DEVEL  : ...432          getRadProHist: index:   4  time:1718703813 2024-06-18 11:43:33  pulse_count: 776436  delta_time:  60  delta_pulse_count:22117  . sixty:3      >:0    0%     <:0    . CPM:22117.0
18 11:45:09.689620 DEVEL  : ...433          getRadProHist: index:   5  time:1718703873 2024-06-18 11:44:33  pulse_count:  79745  delta_time:  60  delta_pulse_count:-696691  . sixty:4      >:0    0%     <:0    . CPM:-696691.0
18 11:45:09.689696 DEVEL  : ...434          getRadProHist: Hist: get Dur:12.6 ms  processing: plus:0.8 ms

[ullix]

Next observation: Anode-Voltage is way too high and wildly fluctuating.

So far I have changed as little as possible on the Radpro settings. The PWM values as per "factory default" are:

Tube HV PWM frequency:        9207.10 Hz
Tube HV PWM duty cycle:       75.00 %

What is the reason for such an odd fre setting? The DMM measured values - confirmed by osci - are f=9.206 kHz and 75% duty. (i.e the same)

But the resulting Anode-Voltage ranges - during the "steady" phase - from a minimum of 670V up to 1100V. Even the minimum is too high for this tube! The wide fluctuation is seen the first time, and surely also not good!

It had not been this bad before, what happens?

[ullix]

Next problem: you have inactivated the option to change PWM settings; neither freq nor duty can be changed, and stay at their default:

==== RadPro Device PWM Settings ================================
RadPro reported PWM Frequency:9207.10 Hz
RadPro reported PWM Duty Cycle:75.00 %

A scan is not possible any more; this is all I can show (magenta is CPS, dark-green is Anode-Voltage):

The average Anode-voltage is 891 Volt! Not acceptable!

[ullix]

I just noticed one thing. In 2.0rc05 you made the statement:

Changed data communications end of line to "\r\n".

However, I am now seeing that in Rad Pro 2.0rc3 you are back to LF only: queryRadPro: request: >SET deviceTime 1718785362< response: >b'OK\n'< However, neither use of LF-only, nor CR&LF, allow for setting the device time; it remains what I reported above.

I prefer LF-only, but what ever your choice, please stay with it! Which one is it from now on?

[ullix]

I have reversed all instances of "CR&LF" in my code and replaced with "LF"-only. And voila, I can set the time again:

queryRadPro: request: >SET deviceTime 1718788111<  response: >b'OK\n'<
queryRadPro: request: >GET deviceTime<  response: >b'OK 1718788111\n'<

However, PWM still cannot be set:

queryRadPro: request: >SET tubeHVFrequency 5000.00<  response: >b'ERROR\n'<
queryRadPro: request: >SET tubeHVDutyCycle 0.2000<  response: >b'ERROR\n'<
queryRadPro: request: >GET tubeHVFrequency<  response: >b'OK 2500.00\n'<
queryRadPro: request: >GET tubeHVDutyCycle<  response: >b'OK 0.2300\n'<

Attempt to set 5000Hz and 20% duty returns errors, and the back-reported setting is 2500Hz and 23%.

Apart from CR&LF - what else has changed?

[alfmck]

What version are you testing? According to your examples it is radpro2.0rc3, non radpro 2.0.1test3. About time: When logging instant data with geigerlog, I see on graph time values of 1 hour less, than really is on GC-01 and PC. But after saving that data in CSV file, the time values on the file are correct - the same as in GC-01 and PC. About frequency and duty cycle settings: My geigerlog version have no function for freq and duty cycle settings. So I used PUTTY. Everything works. About HV dependences from freq and duty cycle: I made and placed data file in HVsettings.xlsx for discussion #60. I've repeated measurements today with calibrated digital oscilloscope and 2.2gOm resistor. The data on both cases are very common. About HV fluctuation: I tested that on radpro 2.0.1test3 and on original FNIRSI v1.5. I've found that on FNIRSI v1.5 HV is about 850V. The fluctuation highly depends on the tube. When I use HH614 tube, there isn't fluctuations, but if I use old high sensitive tube, the fluctuations are about 100V. On radpro 2.0.1test3 is the same situation. But as you showed in your examples, the fluctuation level depends on the HV you set and exists only for high HV values. If I set HV 440v, there is not any fluctuations for both of my tubes. It also depends on the flow of particles, coming thru the tube - after the particle comes - the HV is decreasing for a short time.

[ullix]

@alfmck : I always used the latest version available at the time of testing. What are versions with "test" in their name? I have never seen those, I saw only rcX and betaX versions.

The stated time issue in GeigerLog may have to do with timezone settings. It has nothing to do with RadPro, but if you file an issue at the GeigerLog site I'll investigate.

The latest GeigerLog does have the freq and duty function, so your are obviously not using it. Which version are you using? Install the latest, and also check if your timezone issue still exists. The latest stable version is currently 1.5.0.

The voltage fluctuation is a necessary consequence of the count rate. At higher count rate the average current through the tube is higher, and due to a HV generator with a high internal resistance of 23MOhm (measured by me, is in line with other brand counters) the voltage drops. This is normal, and basically an ohmic effect. Thus when measuring voltage I use the lowest count rate situation possible, i.e. background only.

What is not normal is that the voltage breaks down completely. But this time due to a PWM frequency of zero.

When even the factory default anode voltage is 850 V, then this is way too high for ALL tubes in the hobbyists sphere, and too high for most tubes!

If you have a DMM with a computer link (serial, Bluetooth, other) I might be able to give a custom GeigerLog which allows to read the DMM. With the myriad of DMMs out there, it is not possible to make a generic interface, but with a bit of luck it might work.

[TzOk83]

I just noticed one thing. In 2.0rc05 you made the statement:

Changed data communications end of line to "\r\n".

However, I am now seeing that in Rad Pro 2.0rc3 you are back to LF only

2.0rc3 is OLDER than 2.0rc5, so how could he be "back"? The current version is 2.0.1b3, not 2.0rc3.

[ullix]

@TzOk83 I noticed this as well ...

In my first post on the recent discussions I had shown Software ID: Rad Pro 2.0rc3 but neither did I realize its meaning, nor did anyone else. The CR&LF issue should have been an immediate give-away, but also wasn't. What happened was that for flashing I picked the wrong "rc3" file instead of the "beta3" file. I apologize for the resulting confusion :-/

Now the data when using the right version, please check:

==== RadPro Device Info ==============================================================
Configured Connection:        Port:'/dev/ttyACM0' Baud:115200 Timeouts[s]: R:0.5 W:0.5
Device is connected           
Hardware ID:                  FNIRSI GC-01 (CH32F103C8)
Software ID:                  Rad Pro 2.0.1beta3
Device Clock Drift:           -1 sec  (checked @ Computer Time: 2024-06-21 09:26:17)
                              Device Clock is same as Computer's within 1 sec

In the first runs with beta3 I had set the PWM frequency to either 300Hz or 2500Hz, and scanned the duty from 0% to 100% in +1% steps, measuring CPS, Anode-Voltage, and Frequency, and continued the scan with -1% steps.

CPS (magenta, left scale) shows up only when voltage is >350V. Ok. Duty Cycle (black, right scale) is set by GeigerLog and shown is the value returned by Radpro; as it was set, it goes from 0% to 100%. Frequency (right scale) in red is the Radpro reported frequency, in light-green is the DMM measured frequency. They were offset manually to make both traces visible, as they are exactly the same, except for the extremes of duty 0% and 100%, which of course is to be expected. Anode-Voltage (dark green, right scale) is measured by DMM with 1GOhm in series.

At 300Hz the voltage smoothly increases up to a maximum of 570V and then slowly but equally smoothly declines. The voltage is zero at extremes of duty 0% and 100%, ok. At 2500Hz the voltage more or less smoothly increases up to a maximum of 1567V(!) and then declines at the same pace. The high symmetry between the up and down parts suggests good reproducibility. There is some "crumbling" in voltage on both sides of the maximum and it is not exactly symmetrical. But I think this might have more to do with the GC-01 electronics than with any Radpro setting?

Overall: excellent performance of Radpro!

I'll do frequency scans soon.

[ullix]

I have now also completed my freq scans, and it is looking good.

The duty was set to 10%, 50%, and 90%, and the freq scanned in the supported range of 100Hz to 100 000 Hz. Everything else as before, except that freq is shown as log(freq) due to its wide range.

In every run the frequency as set by GeigerLog, as reported by Radpro, and as measured were all the same!

In every run from from 10 to 50 to 90% the voltage climbed to a maximum which shifted slightly from approx 1500Hz to 2000Hz. The maximum increased from 450V, to 1100V, to 1500V.

The breakdown of the voltage at 90% and 11793 Hz is a bit odd; but I'll blame the electronics for it ;-).

The high voltages are nevertheless impressive, but they are not needed for any of the tubes I can imagine to see in such a counter.

Instead, what is needed is a voltage in the range 400V to 800V. This range is marked with a light-green box in the bottom-right graph. The curve can easily be fitted with a linear fit.

With that I suggest an update to the firmware with a command like "set voltage 430V" instead of the two PWM settings. In PWM the effect of changes is nearly impossible to predict unless you have these graphs at hand.

This also opens the possibility for Anode Voltage controlling to keep the voltage at the preferred setting independent of the count rate! This could easily be done both at GeigerLog and in the firmware.

[alfmck]

I'm glad you've cleared the issue, and the results are impressive! Thank for the link about geigerlog 1.5.0 you give me - it is great! I red user manual and had a good time - you know much more about the theme. I hope we soon will see this version in Geigerlog radpro releasees.

[TzOk83]

With that I suggest an update to the firmware with a command like "set voltage 430V" instead of the two PWM settings. In PWM the effect of changes is nearly impossible to predict unless you have these graphs at hand.

I'm afraid, that without a feedback circuit, it is impossible. The scale is valid for your unit, and only for your unit. It may greatly vary among different units (even the same model).

P.S. J321 requires 380VDC, so for my unit 2,5kHz and 0,75% are a perfect match.

[ullix]

I'm afraid, that without a feedback circuit, it is impossible.

True, but you do have a feedback, which is the count rate. I have established the relationship between count rate and voltage drop e.g. here https://www.geigerzaehlerforum.de/index.php/topic,2277.msg29993.html#msg29993 noting that for each CPM=10000 there is 50V voltage drop on the FNIRSI GC-01.

One problem could be to verify proper functioning of such a measure, because it is not easy to get your hands of sources of this strength ;-)

[TzOk83]

Don't quite understand what you mean by "for each CPM=10000 there is 50V voltage drop on the FNIRSI GC-01".

From my understanding how this circuit works is that the output voltage depends mainly on absolute (thus in ms, not in %) pulse width, and the switching frequency impacts mainly the recovery time. Geiger tube is basically a capacitor, which shorts when a gamma particle penetrates it. Instrument sees the voltage drop and counts a particle. Then, the PSU needs to re-charge the tube, and the cycle repeats.

Tube capacity greatly depends on its construction, and may vary even across units of the same type.

Some GC-01 have an additional load resistor in the PSU, others does not, this difference would greatly affect your U=f(fs, th) characteristics.

[ullix]

@TzOk83 The Geiger tube is anything but a capacitor! It is best described as a simple switch: without any counts the switch is "open" and its resistance is infinite. With a count it conducts, and its resistance is (close to) zero. During the count-event current is flowing through the tube, limited by the anode resistor. Assume this is 5MOhm, and the anode voltage is 500V, then 100µA is flowing. The pulse length for tubes like used in the GC-01 is near 150µs, tooth-shaped. I approximate this with a rectangular pulse of 100µs length.

So, assume a count rate of CPM=10000, equal to CPS=167 (high compared to what hobbyists mostly can get!) you get an average current for 1 sec of: 167/s 100µs 100µA = 1.67µA.

I have measured the internal resistance of the HV generator as 23MOhm. Then from the 500V you get a voltage drop of 23M * 1.67µA = 38V. My actual numbers made me estimate a 50V drop.

For CPM=20000 you then have 50*2=100V voltage drop, and so on, 50V additional drop for each additional CPM=10000.

The recharging happens within the capacitors of the voltage multiplier in the GC-01. I wish I had a SPICE model of this circuitry, so I could study its behavior more easily. Can anyone help with SPICE?

[TzOk83]

My J614 tube has a capacitance of ~2pF, with this voltages and impedances this is not nothing. Try to run GC-01 without a tube, and then measure the voltage.

Schematic for GC-01 is available, however, it is missing some component values, especially capacitors, and inductors.

[ullix]

Sure, there are stray capacities, from tube, leads, circuit board, etc., and those can lead to problems. The less you have, the better; however, you need to have an order of magnitude more capacitance to see it. Here is an old post of mine, where I tested influence of capacities, see Reply #10 and following in https://www.gqelectronicsllc.com/forum/topic.asp?TOPIC_ID=9518.

Without having some SPICE model available, the best model for a tube is still a plain switch.

I have now built a voltage controller into GeigerLog, which keeps the anode-voltage constant, depending on the count rate.

Geigerlog sets the voltage in the GC-01, and adjusts it up or down to achieve constant voltage independent of count rate CPS.

Very simple; could easily be built into firmware.

My problem now is testing: my highest source brings CPM=5000. But ten-fold more is needed for decent testing. Can anyone help with stronger sources?