Rad Pro: Suggestions for new features/ideas

[Davegsm82]

Firstly thanks Gissio for developing this firmware, and secondly I would like to suggest a couple of modifications which may improve usability/safety and/or battery life.

I've developed my own devices, one of which isn't a million miles away from the overall hardware architecture of the GC-01 but based on a PIC micro and has other stuff like GPS and SD card etc (under the radiacode in the attached picture).

1 - HV/Tube failure detection - If no pulses from the GM tube are detected within a defined period of time, set an alert (visual/audible) to notify the user there may be an issue.

2 - A potential power saving feature - the crude nature of the HV generator circuit in the GC-01 is a bit like holding your foot on your cars accelerator and pressing the brake to regulate your speed. It should be possible to gradually increase the PWM pulse width until GM pulses begin to be detected and set that (+a little extra if the HV runs from B+, I didn't check) as a baseline for minimum PWM at ambient radiation levels. Then whenever in elevated radiation levels the PWM could simply be ramped up to the factory default (which appears to be 9.2khz - 75%) to ensure correct operation.

3 - Serial/USB command/control? - potentially via Geigerlog - more for development purposes than anything else, USB logging is great, would be awesome to be able to send commands to the device to change parameters/UI settings.

4 - GM Tube self-irradiation/background offset null - Something sadly missing from all cheaper GM Counters, the ability to subtract a small amount of the counts/dose rate/whatever. Basically, everything is radioactive to some degree, including the GM tube and components within the counter, and this can really skew the results in low dose rate environments. With the Default config my GC-01 shows 0.17uSv/h on my desk at work, but I know from my own and company owned and calibrated equipment that the dose rate is actually pretty much 0.05-0.07uSv/h at all times here (I work with LINACs and live sources). In my own device I subtract about 0.08uSv from the reading which brings it surprisingly close to my Radiacode (ignoring dosimetric calibration).

5 - Tube saturation detection - Unlikely anyone would ever encounter this, but it's a great safety feature. A saturated tube (or a gassy/shorted one) will basically appear like a resistor, so the GM counts input to the microcontroller will see this as a constant high/low signal instead of a pulse (sort of the opposite of #1 above).

6 - Clicker threshold/beeper - for people who have counters running pretty much constantly like myself, it's nice to have a way to gate the clicker so it isn't going constantly and annoying people. Similarly you don't want to have your dose rate alarm set so low that it frightens people around you when you walk past someone who's had TC-99 or you encounter some other elevated radiation level. A nice way of doing this is applying a threshold to the clicker level, so it only clicks above say 0.3uSv for example.
6.1 - This can be coupled with the display timeout function so that when the screen is on the threshold is disabled, and when it's off then only when above a certain level it will start clicking.
6.2 - Also, an option for beeps instead of clicks? I implemented a function to change the volume/pitch of beeps depending on radiation level.

[Gissio]

Thanks for the suggestions. Will be taken into consideration for the next versions.

[Gissio]

A lot of your suggestions made it to 2.0rc3.

The second suggestion is a bit of a problem. As you work with LINACs, I can afford a more technical explanation. It is my understanding that the radiation level-count rate curve can be non-monotonic (e.g. https://www.nature.com/articles/s41598-021-81571-3/figures/1 ). Therefore, a given count rate might correspond to a lower or a higher radiation level value. Therefore, it would be dangerous to select the tube voltage solely on the count rate. You might argue that, of course, it is possible to lower or increase the voltage and determine which region of the curve is active. But this requires a lot of experimental effort (Rad Pro supports 7 device variants so far) and time, which I lack.

Regarding your third suggestion. Is it so hard to set up Rad Pro with the keyboard? I don't see a favorable cost-benefit in adding this capability.

Beeps are unfortunately not possible due to hardware limitations.

I'm eager to hear your comments.

[dc1rdb]

Thanks Gissio for this great firmware. I have a suggestion for a future version, too.
How about some color coding on the history bargraph, e.g. indicating user defined thresholds like warning and danger thresholds, similar to this screenshot?

[Gissio]

Dankeschön!

[Gissio]

Implemented in 2.0rc3 using the OpenBridge design system!

[DG0MG]

@Davegsm82

I find it very interesting to read your thoughts on RadPro. I have also written a series of suggestions, perhaps you have read them: #40
Of course, the suggestions do not only refer to RadPro alone, but may even reach commercial manufacturers who sometimes completely ignore the wishes of the users in the features of their software. Perhaps the reason for this is that the programmer is not a "professional".

#1 is a great idea and certainly not difficult to implement. If there is no impulse for a minute (or 2 minutes) to display HARDWARE ERROR, it can save lives in certain circumstances.

#2 I had suggested adding a control loop to save power, but that requires a hardware modification. I find it very difficult to do this solely via software, given the large number of supported devices.

#4 Yes, with larger meter tubes (which could be connected) there is an inherent zero effect that must be subtracted from the calibration factor before calculation.

#6 This is the case with the RADEX ONE: If an alarm threshold is set, then the ticker only starts ticking when this is exceeded.

Regards,

• Steffen, DG0MG -

---

visit https://www.geigerzaehlerforum.de

[Wolftech-github]

First of a big thank you to Gissio for the development of the Rad Pro replacement firmware - amazing work!

I am currently running the v2.0rc2 on a late 2023 model FNIRSI GC-01 that originally came with the HH614 tube, it has since been upgraded with a J305 tube.

The GC-01 communicates via USB-serial with my Mac computer and a small test program shows the device parameters, sets the device time as well as downloads the device log data to a file.

However as noted elsewhere, the firmware upgrade has to be performed on a Windows computer - in my case a borrowed unit, thus i can't easily reflash the device to reset the device log data. This leads me to a couple of suggestions in addition to the ones mentioned above:

Add a menu item/key shortcut in the Data logging menu and/or add a serial command to reset the device log data.

Display the number of device log entries in the Statistics summary.

/Wolf

[Gissio]

There is actually a design decision for not adding data log reset: flash wear. Not doing so also keeps the design simpler (on the GC-01 with a WCH, I'm actually close to running out of flash space).

If you wish to download only new data, simply store the timestamp of the most recently downloaded record. Then, use the GET datalog command with the timestamp parameter, and Rad Pro will stream only the newest records.

I thought about showing datalog statistics in the Statistics view, but it's not that easy. Will be considered for future releases.

[gruzefix]

First off, naturally mad props to the dev, you've turned a barely functioning Geiger counter into a powerful device.
I don't know where else to ask this but I feel like this might be the proper place:

Is there any way to sync the device's internal clock with, say, an Android phone connected via USB-C?

The reason I'm asking is because I want to conflate radiation data with GPS data, if possible automatically. I want to go to different places and see if there's radiation hotspots in certain ones. I live near an area that a) has been affected by Chernobyl fallout more than other surrounding areas and b) used to be a swamp that has only been drained in the past 2-300 years, so there's still lots of radon coming out of the ground. I used to spend a significant part of my clinical rotation in oncology and a few of my colleagues and I noticed that unusually many of our patients seem to come from that specific area. The area is pretty flat, so it's ideal for a Sunday bike tour in the summer, so why not gather data while you're at it?

Or are there already any readily available solutions? GMCMap seems promising but from what I gather it only features stationary detectors, not mobile ones.

--gruzefix

[Gissio]

radpro-tool does that (from a PC): https://github.com/Gissio/radpro/blob/main/docs/manual.md#radpro-tool

The clock skew within a day should be sufficient for your requirements.

May I also suggest that you contact some government authority, radiology institute or university department before starting your undertaking? I am sure they will be able to give you good advice.