FNIRSI GC-01: Installing on Linux, debugging

[ullix]

I have a FNIRSI GC-01 with chip CH32F103. I want to use it on an AMR5 Mini PC (https://acemagic.de/products/amr5-minipc) which I had setup for doubleboot with Win11 and Linux Mint LMDE 6. This PC has only USB3 connectors - no others. I test both OSs and start each one with GC-01 being Off.

Linux: Simply upon plugging in, a drive "GC01 BOOT" is mounted and shows a single file "Readme.TXT" with size 0 bytes. On pressing the OK button on the gc01 the drive un-mounts, next press the drive re-mounts, etc.

Win11: Upon plugging in nothing happens. On pressing the OK button, the file manager shows me a drive D: with name "GC01 BOOT". Its only content is a file "Readme.txt" with size 0 bytes. Pressing OK again, the drive D: disappears; another press and D: is back, etc.

So far it looks like the situation is identical for both OS?

And now what? I have to download the new firmware and copy it next to the Readme file? And then the GC01 takes this as new firmware and boots with it? Would be cute, but based on my experience with various other micro-processors I have my doubt that this simple copying to the file system would install a firmware.

Then what 3-, 4-, 5-finger salutes do I need to give and on which keyboard to install the new firmware?

[Gissio]

It turns out there are at least four different bootloaders in the wild, each with a different behaviour. Some work with all OSes, and some only on Windows (and there goes the answer to your question). And there is one bootloader which presents a cryptic "AIR01" interface, which seems to not show up as a USB drive.

So my advice is to install Rad Pro from Windows, even though it could work from other OSes as well (I have read a report of somebody installing it successfully from Linux).

The bootloader you mention (drive "GC01") is known to work. Just follow the instructions (indeed, copy the firmware next to Readme.txt) and let us know.

And even if there were a serious issue with the bootloader, you can fix the GC-01 with an STLINK dongle.

[ullix]

Holy Moly - it works!

Well, almost. Here my steps:
I used fw (firmware) radpro-fnirsi-gc01-ch32f103r8-2.0rc2-install.bin
Remember, the computer AMR5 Mini PC has only USB3 ports!

Linux:

• copy fw into mounted drive GC01 BOOT
• Unplugged gc-01 and restarted --> old firmware is active
• switching-off and replug --> fw file has disappeared
• copy again fw into mounted drive GC01 BOOT
• explicit unmount
• remount
• Readme.TXT is gone, now file UNKNOWN.TXT (also 0 Bytes) shows; fw file not showing
• unmount, unplug
• reboot gc-01 --> same old firmware is running
• replug (nothing happens)
• pressing ok--> GC01 BOOT is mounted, showing file Readme.TXT (0 bytes); no file fw showing
• --> failure on Linux

Windows11:

• plugging gc-01 in --> nothing happens
• pressing ok on gc-01 --> nothing happens
• unplugging, pressing ok --> gc-01 starts with old firmware
• plugging in running gc-01 --> Win error message, "USB device malfunctioning"
• switching-off gc-01
• replugging --> drive D: with GC01 BOOT appears with content: file Readme.TXT size 0
• copy fw into GC01 BOOT
• NOT unplugging, NOT rebooting: --> Rad pro 2.0rc2 works already! Strange, how comes ????

I can get some clicks, walk through the menus, change a few settings, so far ok. Nice!

Now to the almost part: there is no USB connection! Neither on Win, nor on Lin. The fw's USB mode says "USB connection enabled".

No, it isn't. So, GeigerLog has no chance to talk to it.

[Gissio]

I'm glad you managed to flash the firmware!

In 2.0rc2, data communications requires the following sequence:

• Enable "USB Mode".
• Plug the USB device in.

Fortunately, in the next release this won't be needed!

[ullix]

That worked! Steps:

• gc-01is unplugged
• change display to show "USB mode"
• now plugin --> gc-01 is USB-connected

For now this has to be done every time one wants to plug it in.
dmesg is reporting this:

[1246731.861130] usb 3-1: new full-speed USB device number 108 using xhci_hcd
[1246732.011075] usb 3-1: New USB device found, idVendor=0483, idProduct=5740, bcdDevice= 1.00
[1246732.011088] usb 3-1: New USB device strings: Mfr=1, Product=2, SerialNumber=254
[1246732.011094] usb 3-1: Product: Rad Pro
[1246732.011099] usb 3-1: Manufacturer: Gissio
[1246732.011102] usb 3-1: SerialNumber: 018C7130
[1246732.012955] cdc_acm 3-1:1.0: ttyACM0: USB ACM device

I am delighted to see Manufacturer: Gissio, because this allows to test the USB properties directly and not having to resort to successfully communication. Can you assure that in all the different counters the Gissio Manufactuerre will be implemented in the firmware?

Because testing serial ports for a device by writing to the ports may have significant unwanted side effects!

[Gissio]

Please don't check the Manufacturer string (it might change). Use the Product string.

Also, remember that the Bosean FS-600/FS-1000 use a CH340E serial port USB adapter which does not follow this scheme.

[ullix]

Which scheme are they following then?

Either Manufacturing or product string are ok, plus the vID and pID, as long as they are known. Is there a list with the strings/IDs to expect?

It is always better to have confirmed the device before writing to it. As I said, there can be side effects.

And all the devices on your "supported" list follow the very same Radpro code? I'll need to buy some of those cheapest ones!

[Gissio]

Let me cite from this message I sent you before:

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.

[ullix]

but I'm also sending an id request over the serial port, so it does not connect if the test fails.

This is ok to do when you basically already know that this is the correct device. But sending any command to just whatever is visible can really ruin your day when you send this command to a device, which then does something unexpected and undesirable with this command!

As the last resort - ok. But using vid, pid, manufacturer, product is much preferred! I don't mind using either or all, but it is always better to be safe than sorry!

Python can read all of these identifiers, I am sure you know.

[ullix]

I am having connection issues. In order to make a USB connection, I have to switch to the "USB mode" screen on the counter, and only then plug in the USB cable. Ok.

But in the moment I switch away from the "UDB Mode" screen, the USB connection is lost? RadPro can no longer communicate with the counter? The USB device /dev/ttyACM* is still there, GeigerLog can no longer read/write to it?

[Gissio]

WCH MCUs require that you stay in USB mode for accessing the USB device.

[ullix]

Well, you can't stay in USB mode, while allowing to view e.g. the count rates?

[Gissio]

I'm not on your payroll. If you ask nicely, I might consider doing this.

[ullix]

I am sorry that you feel being pressured. Your firmwares are a great achievement, and I really would like to see them taking main stage. So I actually put quite a bit of effort into testing. The development status is good. But I don't see it at ready for primetime! I would very much like to encourage further development.

[ullix]

Is there a way to empty the History memory?

[Gissio]

No.

[ullix]

I did more testing on the History memory. It works, and I find it more reliably than the logging results!
However, I find the maximum memory for my GC-01 at around 2500 records. A decent size, however, it only about half of your claims: Quote: "Data logging can store up to 5060 data points. ". No, not possible. What has changed since that statement?
Do I see it right that the memory is organized as a ring-buffer, where pages of 4k bytes are overwritten at the bottom when the memory had filled up? I also assume 8 bytes for 1 records (time 4B, counts 4B), i.e. 2500 records take up 5 blocks of 4k?

[Gissio]

In English, "can" means possibility, not condition.

The actual memory capacity depends on these factors:

• Flash paging.
• Data compression.

[ullix]

I have another finding, which I find more disturbing. Logging over hours goes mostly well, but there are certain events, as shown in the pic. Arrows are pointing to it. The CPS has values of zero, followed by a value of about twice the average. So the counter is delivering nothing in the first call, and makes up for it in the second by sending the sum of the second and what would have been the first call!

Next pic is a blowup of such events, showing the individual jumps down to zero, up to double and down to average. The data table lists 2 such events. The time increases monotonically, with a delta spread of 0.99 to 1.02 sec. The pulse count also increases strictly monotonically (though the increase may be zero).

Poisson of CPS is almost ok, though one sees the impact of the events.

This is using nothing but your command "GET tubePulseCount"; GeigerLog has no influence on what this reports. Is there a limit on the cycle time the counter is supporting? I used a cycle of 1 sec.

[ullix]

In my previous post I demonstrated this "zero & double" effect of CPS count-rate, and wondered it may come from the counter being overworked from the 1 sec cycle. So I set the cycle to 3 sec. The "zero & double" was not seen over some 20 hours, however something else equally unpleasing came up.

I marked some bad spots with 1...4 (there may be more, but not as obvious), and a blow up of # 4 in the next pic. This is clearly not right!

Checking Poisson is no help here, because the CPS rate is determined from a "CD3S" rate - the counts over 3 sec - by dividing by 3, which renders the distribution non-Poissonian anyway.

In the present form the firmware is not giving the right answers. Why?

[Gissio]

In 2.0rc2, Rad Pro updates tubePulseCount every second, in order to apply dead-time compensation. There were missing or double values because the timers of the counter and computer are not synchronized.

In 2.0rc3, Rad Pro does not apply dead-time nor background compensation to the tubePulseCount, and tubePulseCount is updated continuosly, so what you propose should work now.

[Gissio]

Regarding the issue you raised on Sourceforge:

• I verified that tubeRate returns exactly the same value as the instantaneous rate display (when set to CPM units).
• I also verified that the tubeRate adaptive averaging is functioning properly. Other users posted images of the tubeRate and tubePulseCount-derived signals on this forum, you might want to peruse them.

[ullix]

Sorry if I offended you by using frank words. That surely was not intended; I apologize.

However, the tech problems that I see remain. I do not know what "adaptive averaging window" (I would have to study the code) and I really don't care, as long as the result of that adaptive thing is reasonable.

But, when the result of averaging CPS is a function with basically the same Std.Dev, something is not working correctly! As the count rates follow a Poisson distribution, summing 60 CPS values to CPM should give CPM data with a StdDev 1/sqrt(60). The adaptive thing is far away from this! You can just as well multiply CPS by 60; it is barely different.

When I first showed the data your response was that I had mixed up the curves. Could have been, but was not, as I verified. Nevertheless, it did show that you also expected something significantly smoother than what tubeRate showed; so the two of us are of the same opinion in this regard!

CPS is around 16 in the previous post. You consider this as "quite high"? I don't think so. The tube & counter should easily handle CPS=1000.

[Gissio]

I'm glad you wrote back!

Let me share my thoughts. You and I are not God. We make mistakes. That's why I asked you if you might have made a mistake. I did not mean to say that you are not capable. If that were the case, you wouldn't have been able to make such a wonderful tool as GeigerLog.

Why did you not ask how tubeRate works? I would have been happy to answer.

Here's how it works.

For instantaneous rate measurements, there are two conflicting objectives: getting low-noise estimates, but, at the same time, a fast response. In Rad Pro, this problem was solved by choosing an averaging window that keeps the confidence interval of the measurements independent of the instantaneous rate.

In particular, the chosen window length aims for a confidence interval of 50%. This is also recursive, as the previous instantaneous rate measurement provides the window length for the next measurement.

If you plot this window length (y-axis) vs. instantaneous rate (x-axis) in a log-log plot, you get a line. The offset of this line depends on the conversion ratio of the tube: tubes with a higher conversion ratio will have a line further down the plot (as less time is needed for getting a 50% confidence interval).

The problem with this line is that, with certain tubes and under levels of radiation around 1 µSv (which start becoming dangerous), the window length becomes too long, and the response, therefore, slow. So, if the radiation level is above 1 µSv, I limit the window length to a maximum of 5 s.

In the instantaneous rate falls between 0.3 µSv - 1 µSv, I modify the curve to ensure continuity.

Moreover, Rad Pro performs instantaneous rate updates each second, so the actual averaging time window is quantized by multiples of 1 s.

You can see the actual curve for the J614 tube in this simulation:

https://github.com/Gissio/radpro/blob/main/tests/adaptiveaveraging.ipynb

By changing the conversion_factor = lines, you can also calculate the curve for other tubes.

As you see, this is quite more complicated as it might seem at first sight.

I tested this thoroughly, as it is at the core of Rad Pro. But of course it is possible that I made a mistake (remember, I'm not God).

So, how is it possible to explain what you are seeing? It might be that your radiation rate is around 1 µSv. In this case, the resulting confidence interval would be quite high (check the second graph in the adaptiveaveraging.ipynb notebook). And this is ok, in order to ensure a fast response (under 5 s).

If you do find an error, it would be greatly helpful if you send me a .csv file with the raw cps data and the tubeRate value. I would also need to know your "Conversion factor" setting and the approximate "Time" value displayed in the instantaneous rate view.

Once again (as I mentioned in my first messages): if you think the tubeRate confuses users rather than helping them, it would be best to not make it available in GeigerLog. I made it available in the serial port interface as certain users might need access to the instantaneous rate displayed by Rad Pro. But, in the case of GeigerLog, I think it confuses more than it helps.

[ullix]

I see that your adaptive algorithm is as complex as I suspected. But I have little inclination to dig into this challenge, because I see the outcome and this is not satisfactory as I think I have clearly shown! When the smoothing result is as wildly fluctuating as the original, it is not smoothing.

What raises my discomfort with the matter is that in arguing for it you switch to Sievert. Well, the "currency" of radioactive decay is Counts, and most importantly counts with a Poisson distribution. This has the wonderfully simple feature of StdDev = sqrt(Counts). Scaling to Sievert makes you loose this! So, why do it?

This adaptive thing reminds me of the "FET" feature of GQ. I have argued since its first existence to switch it off. Recently, on a user complaint that the numbers fluctuated inconsistently, GQ recommended to switch FET off! Sound similar. Alas, they still, by default, have it on in its worst setting.

[Gissio]

My suggestion: remove tubeRate from GeigerLog.

[ullix]

It is been removed already!

But GeigerLog is flexible. You can enter RADPROCPM() into the Formula Interpreter, and GeigerLog will also create the data using the "GET tubeRate" command. This is how the above data were made.

But this does not help when you look at the counter's display. The numbers do fluctuate wildly. Much, much more so than any other e.g. GMC counter! I don't think that users will be pleased.