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.