Rad Pro support [is now fully supported!]

[Gissio]

Hello everyone,

I have just released a patch for GeigerLog 1.4.3 which adds support for Rad Pro (https://github.com/Gissio/radpro) devices. It is available here:

https://github.com/Gissio/geigerlog-radpro

Could this be merged into GeigerLog?

[ullix]

Well, look at this! Interesting. What actually is a RadPro?

For this being mergeable it needs to be compatible with Python 8 (!) and later. GeigerLog needs to be able to discover the counter by identifying a specific USB-To-Serial device.

It also has to fit into the latest 1.5 development. You find pre-releases here:
https://sourceforge.net/p/geigerlog/discussion/devel/

[Anonymous]

[ullix]

I looked at the 3 mentioned Geiger counters, and if I am not mistaken none of them has any kind of data output? So, where does the signal come from, what are you doing with it, and in what form does it become available to GeigerLog?

GeigerLog on Sourceforge has no pull mechanism. I would have to copy the code into my sources. It would not qualify as it is, as it seems you have hardcoded the USB device?

[Gissio]

Hi ullix:

first things first, I have a message for you: https://www.geigerzaehlerforum.de/index.php/topic,1068.msg29007.html#msg29007

The FNIRSI GC-01 does not do data logging with the factory firmware; but it has a USB interface, and with the Rad Pro firmware, it can send data to GeigerLog.

The Bosean FS-600 factory firmware does not have data logging either; but it comes with a CH-340E USB serial port adapter, which the Rad Pro firmware can use to send data to GeigerLog. Likewise with the Bosean FS-1000.

The FS2011 does not have any PC connectivity as is, but on the project page I published instructions for installing a serial port USB converter, which can stream data to GeigerLog.

I'm sending you attached the files I modified and added, so you can apply the patch if you see it fit.

For the FNIRSI GC-01, I am using as VID and PID 0483:5740, which is an "ST Electronics" serial port device which should not appear in any consumer electronics device.

For the Bosean FS-600/FS-1000, I'm using the CH-340E (a USB serial port adapter) VID and PID values 1a86:7523. This might appear in other consumer devices with a CH-340E, but I'm also sending an id request over the serial port, so it does not connect if the test fails.

I'm not supporting the FS2011 in GeigerLog as I doubt many people will perform the hardware modification I mentioned before (if they are able to hack the hardware, they should be able to hack GeigerLog as well).

The data that gets streamed is the instantaneous CPM value (the average from Rad Pro's adaptive averaging algorithm) and cumulative pulse count. The instantaneous CPM value is available in GeigerLog as "CPM" data, and from the cumulative pulse count I derive a difference signal, which I make available in GeigerLog as low-level "CPS" data.

There is also support for downloading Rad Pro datalogs, available in the "History" menu under "Rad Pro Series". The "Get New History from Device" does a differential download, downloading only data that has not been downloaded so far. The "Get All History from Device" downloads all the history available in the device. I store the timestamp of the last download in a geigerlog-radpro-history.conf file, which stores the timestamp of the last download for every Rad Pro deviceId that was connected to GeigerLog.

On connection, the patch also syncs the Rad Pro device clock. This can be disabled in the geigerlog.cfg file. There is also device information available in the "Device" menu > "Rad Pro Series" > "Show Info" option.

I tried to keep your programming style as best as I could.

If you want to test this patch under Windows without a Rad Pro device, you can download the Rad Pro simulator here: https://github.com/Gissio/radpro/releases. When started, it connects to the COM1 serial port. If you install the com0com null modem driver (https://com0com.sourceforge.net/), you can connect to the virtual Rad Pro device on COM2.

Let me know what you think of all this.

ps: my last message is marked as "awaiting moderation"!

[ullix]

I now took a deeper dive into your github site, and I must say I am mightily impressed! Compliments!

These low and very low cost counters are interesting, but their value is limited, as long as you can't communicate with those devices. You seem to have changed this fundamentally. Is that all your work, or are there multiple people involved?

The manufacturers of those cheapos would greatly increase the value of their products by delivering this firmware factory installed. Is there anything in your license to the firmware that would prevent them doing that?

Other counters which would benefit from a better firmware are the whole breed of GQ's GMC counters. Do you see any chance of ever touching those?

I have already integrated your Python code into the latest GeigerLog 1.5 pre-release (now pre75). It had been pretty complete on your side, but some adaptations were needed. If you could run some test now report back:

Start GeigerLog with ./GeigerLog.sh -dvw devel and post files geigerlog.proglog.devel and the database after a dozen cycles runtime, then exit GL.

[ullix]

I have a FNIRSI GC01 and look forward teaching it to speak. I read that the firmware can only be uploaded under Windows. But things are puzzling to me:

• The gc01 is off, and I connect it to the Win11 computer. Nothing happens. A short press on the ok button, and the file manager shows me a drive D: with name "GC01 BOOT". Its only content is a file "Readme.txt" with 0 bytes. So? I now copy the firmware file into this drive, next to the Readme file?

• On the same computer, doublebooting into Linux Mint LMDE 6: The gc01 is off. Upon plugging in it is mounted and drive "GC01 BOOT" show a single file "Readme.TXT" with 0 bytes. Seemingly the same as Win11 had showed. On pressing the OK button on the gc01 the drive mounts, next press the drive unmounts, etc.

Looks like the same to me, but I must not upload the firmware to Linux?

[Gissio]

Hi ullix:

thanks for the compliments. Likewise, my compliments for developing GeigerLog for free. And as I think you are the only one developing GeigerLog, I'm the only one developing Rad Pro (even though the community helps a lot).

The Rad Pro's license is MIT, so there should be no problem for manufacturers to use Rad Pro, as long as it is credited.

It should not be too difficult to port Rad Pro to the GQ devices, but there are some obstacles:

• I would need to get my hands on the original firmware.
• Designing the HV feedback control algorithm might require a lot of testing (the devices supported so far by Rad Pro are open-loop).
• Right now I'm out of time.

I have been able to try v1.5.0pre75, but ran into the following problems.

In gdev_radpro.py, line 348, I had to modify:

                    if abs(cpsDeltaTime - g.logCycle) < 5:

to:

                    if abs(cpsDeltaTime - g.LogCycle) < 5:

for datalogging to work.

Also, the "History" > "Rad Pro Series" menu options are not enabled when a device gets connected.

One more thing. The next Rad Pro release will have background compensation. In the gdev_radpro.py file, the following modification should be made, around line 149:

        "Tube dead-time compensation": str(
            self.query("GET tubeDeadTimeCompensation")) + " s",
        "Tube background compensation": str(
            self.query("GET tubeBackgroundCompensation")) + " CPM",
        "Tube HV PWM frequency": str(
            self.query("GET tubeHVFrequency")) + " Hz",

Regarding your question about the FNIRSI GC-01, could we take that conversation to the Rad Pro forum (https://github.com/Gissio/radpro/discussions)? It's not that I earn something from the forum; it's just that this conversation might help other Rad Pro users.

Best wishes,

Gissio.-

[ullix]

Thanks, I put in the corrections for the next prerelease.

Is your simulator also available for Linux? I use socat for a "Simul_GMCcounter.py" simulator for GMC counters. See in the gtools dir of GeigerLog.

Looking at your discussion site, I see a whole lot of FNIRSI topics; it sure isn't straight forward :-(

[Gissio]

Yes, it works under Linux (but you have to compile it yourself).

Most of the FNIRSI GC-01 bugs were already fixed. A remaining issue is the bootloader. There seem to be at least four different bootloaders in the wild, each of which with a different behaviour. Some work with all OSes, and some only on Windows (and there goes the answer to your previous question).

[ullix]

I have just created a different simulator, which runs under Linux, based on socat. Is almost the same as the existing Simul_GMCcounter.py .

What I'd like to know is the meaning and typical response on your various GET commands. I took your getInfo(self): as holding all the existing commands, and put those in my simulator. I am ignoring the history stuff at the moment.

What is the algorithm / reason behind tubeRate and tubePulseCount?

Looks like the latter is cumulative counts, and you get CPS by taking deltas of count and time. I find this a bit awkward. What is the reason for making it this way, and not returning clean CPS and CPM?

[ullix]

After the USB connection could be made, a recording was possible. Result attached.
What I see so far is that the two failures resulted from a serial-write timeout, which closed the serial connection, and never re-opened it.

The CPS is Poissonian, while the CPM clearly is not (as you said).

Why can the calls to CPS and CPM not made to result in single, clean values, and both resulting in Poissonian values? GQ's GMC counter have a bunch of issues, but at least this CPS/CPM thing is done right.

If CPM makes a problem - GeigerLog does not need it. CPS suffices as long as it is a clean value, and GL will create a CPM from it.

If calculating CPM and CPS in those low-power µ-computer-chips is a problem, there is an alternative: Look into the GeigerLog manual for "SerialPulse Device". All what is needed is that the µ-chip writes a single byte (any value) into the serial pipeline. GL will read this every second and length of byte sequence == CPS. Works well beyond CPS=10000, more than any of these Geiger tubes can ever deliver.

[ullix]

Another question to the attached pic:
RadPro's CPS is the orange curve at the bottom. RadPro's CPM is the green curve. GeigerLog's CPM, created from RadPro's CPS, is the brown curve in the middle of the green.

Why does the green curve show such huge fluctuations? It is inappropriate for CPM. Orange and brown both are correct (and Poissonian), but green is not. How are these numbers created?

Variable  [Unit]       Avg ±StdDev    ±SDev%  Variance     Min ... Max    Recs
CPM3rd  : [CPM]    725.444 ±28.39     ±3.9%        806     644     803    1342
CPS3rd  : [CPS]     12.083 ±3.5271    ±29.2%     12.44       1      24    1342
Xtra    : [x]      748.663 ±156.99    ±21.0%     24646  230.39  1298.4    1342

[ullix]

What is the purpose of the "geigerlog-radpro-history.conf" file? File ending suggests it is a configuration file? Could this RadPro configuration be relocated into GeigerLog's configuration file?

[Gissio]

All responses in one message:

• What is the algorithm / reason behind tubeRate and tubePulseCount?

For tubeRate (from https://github.com/Gissio/radpro/blob/main/docs/users.md): "The instantaneous rate is estimated by dividing the number of pulses within a time window, minus one, by the time between the first and last pulse within that window.

The time window is adaptively adjusted, aiming for a confidence interval below ±50 %. On radiation levels above 1 µSv/h, the time window is limited to 5 seconds to ensure a fast response."

tubePulseCount is cumulative pulse count.

• For a definition of all comm commands, consult https://github.com/Gissio/radpro/blob/main/docs/comm.md

• Rad Pro sends cumulative pulse counts in order to avoid loss/bias of information.

Let me give you a counter-example. In Rad Pro, data is updated once per second. If you were to poll a CPS value from your computer once per second, since the device and PC clocks are not precisely synchronized, it is possible to receive the same value twice, or to even miss a value. The same would happen if you were to poll a CPM value, even though the problem would be less severe due to the 60-second averaging.

By sending cumulative pulse count, the problem disappears as no pulses will be missed or duplicated. This also means that you can correctly calculate dose from the logs.

• The CPS and CPM GeigerLog values are just labels for two data channels: raw data, and the instantaneous rate that Rad Pro shows on the display. If you consider that the instantaneous rate is more confusing than helpful, remove it.

• The reason the instantaneous rate does not follow a Poisson distribution is quite straightforward. The averaging window depends on the previous instantaneous rate. As this is subject to noise, the averaging window will vary a bit. That's why the statistics do not comply with Poisson.

• There is an error in Rad Pro 2.0beta2 which may break the USB connection. It should be fixed in the next release.

• I have quite some processing power available in Rad Pro. I do not plan to change the API.

• In your last message you state that the CPM value (green) is very noisy. Could it be that you made a mistake and that the green curve is actually the CPS value, scaled by 60 s / 1 s? The dark red curve (CPM3rd) looks more like the tubeRate signal.

• Regarding the geigerlog-radpro-history.conf file, let me cite my previous message:

"There is also support for downloading Rad Pro datalogs, available in the "History" menu under "Rad Pro Series". The "Get New History from Device" does a differential download, downloading only data that has not been downloaded so far. The "Get All History from Device" downloads all the history available in the device. I store the timestamp of the last download in a geigerlog-radpro-history.conf file, which stores the timestamp of the last download for every Rad Pro deviceId that was connected to GeigerLog."

I did not add this to geigerlog.cfg, as it changes every time a datalog is downloaded.

[Gissio]

My response made me aware of an error in gdev_radpro.py.

Line:

cpsDeltaPulseCount = cpsPulseCount - g.RadProDevice.lastCPSPulseCount

should be changed to:

cpsDeltaPulseCount = (cpsPulseCount - g.RadProDevice.lastCPSPulseCount) & 0xffffffff

in order to avoid overflows.

[ullix]

The overflow issue would have been my next question ;-)

No, the data association of the curves is correct. CPS3rd is derived from you cumulative CPS counts, CPM3rd is my creation of CPM from your CPS data, and (green) Xtra is your CPM aka "tuberate".

Both my CPM/CPS curves are Poissonian.

GeigerLog has various functions in its Formula Interpreter, including CPMWITHFET(vname, N) which allows to make a CPM calculation based on the last N datapoints of CPS variable vname. This told me that your tuberate was based on only 2(!) data points. Hence the wild fluctuations.

The missing or double-counting of CPS is really not an issue. Missing values are a normal occurrence in data gatherings, and GeigerLog expects to receive a NAN (Not A Number) value, and knows it is a missing value.

To avoid double counting I set my values to NAN once they are read. So again, no harm is ever done.

I have played with the ESP family of processors quite a bit, but not with what is in those range of cheap and super-cheap counters. You say the all run the same Radpro code? Impressive!

These µchips have timers and hard- and software interrupts, I suppose? So, you could count the Geiger events on an interrupt into a buffer, and once a timer fires after 1 sec transfer the buffer to a CPS value holder. And, provided there is enough memory, maintain a queue of the last 60 cps values. CPM would the simply be the sum of the 60 CPS?

Easily done on any ESP; what is possible on "your" chips? (Are these all the same chips?)

OK, the extension ".conf" of your history buffer has misled me to believe it is a configuration file. This can of course not be put into GL's configuration file.

[ullix]

Another demonstration of the problems with the tubeRate, see attached pic:

The red curve is "CPM from tubeRate call". The orange curve is a CPS curve based on your "tubePulseCount". The green curve is CPM constructed based on an estimate for 2 consecutive points of the CPS curve.

The orange curve is almost hiding behind the red curve, which is supposed to smooth the orange CPS curve. The green curve is smoother than the red curve, while based on only 2 data points, in contrast to red, which should be smoothed based on 60 data points!

You can also see it from the stats:

Variable  [Unit]       Avg ±StdDev    ±SDev%  Variance     Min ... Max    Recs
CPS3rd  : [CPS]     22.703 ±4.3176    ±19.0%    18.641      13      34      37
Temp    : [°C]    1380.175 ±269.84    ±19.6%     72813  783.46  2090.8      37
Xtra    : [x]     1340.270 ±190.64    ±14.2%     36343     960    1800      37

The CPM red curve has a StdDev% of 19.6%, even worse than the CPS orange curve, while the 2-point average green has a significantly lower 14.2%.

I don't understand how the "tubeRate" is constructed, but it effectively is averaging over only less(!) than 2 datapoints!

Not good.