| Author |
 Topic  |
|
|
ullix
Germany
1171 Posts |
 Posted - 08/29/2018 : 04:32:50
|
This is a major overhaul of GeigerLog. Many more features generally means increased complications, but I am confident you find GeigerLog even easier than before.
- Continued support for GMC 300 / 320 / 500 / 600 series counters
- Now supporting 4-byte CPM and CPS values
- Now supporting double tube devices (GMC-500+) for both CPM and CPS
- Now supporting GMC-Device history for 3 and 4 byte storage values
- New: Support for RadMon+ Series devices, which offer Geiger counter function combined with a sensor for the environmental variables Temperature, Air-Pressure, and Humidity
- New: Implementing of IoT (Internet of Things) support
- GUI overhaul with more flexible graphing for up to 10 variables on 2 Y-Axis
- Slider-adjustable sub-windows for Graph, NotePad and LogPad
- Input values can be transformed with a powerful interpreter handling algebraic formulas with mathematical functions (log, trig, sqrt, power,…) to correct offsets, linearize values, convert air-pressure to sea level, account for dead time losses of Geiger counts, and more
- Overall improved handling of graph, statistics, analysis
Available at SourceForge: https://sourceforge.net/projects/geigerlog/ |
|
| Reply #1
ullix
Germany
1171 Posts |
Posted - 09/07/2018 : 06:15:27
|
The latest GeigerLog version 0.9.08 has just been replaced by version 0.9.08a.
Only some minor fixes, but the major overhaul is to the Windows-Installation instructions. You find them in the manual.
There are now two ways to install on Windows: one easy, conservative way, and one more advanced, slightly more difficult way. Ikerrg gets some credit for a contribution to the installation.
They were tested on a virgin installation of Windows 10 Pro to new hardware.
Along the way I discovered a bug in the Python et al. installation files, which I could fix. If you had installation difficulties before on Windows, I hope they can be overcome now.
Still problems? - please report!
|
 |
|
| Reply #2
ikerrg
United Kingdom
334 Posts |
Posted - 11/19/2018 : 03:16:15
|
@ullix: Do you plan to add the new codes to the GeigerLog parser in order to indicate the tube type in the 500+ meters? It is shown in http://www.gqelectronicsllc.com/forum/topic.asp?TOPIC_ID=5461&whichpage=2 . EmfDev indicated that:
quote:
Also in the current 500/+, if you see a 55 AA 05, that is tube type, and 00 = both, 1 = tube 1, and 2 is tube 2.
|
Edited by - ikerrg on 11/19/2018 03:16:58 |
|
|
| Reply #3
Stargazer 40
USA
431 Posts |
Posted - 11/19/2018 : 06:10:27
|
Time to get some long term measures and figure out how to get those nifty plots. Thanks for an easier install on Windows. I will be trying first time on a new machine and will let you know how 'easy' it was.  |
Stargazer 40 |
|
|
| Reply #4
donghelan
Japan
65 Posts |
Posted - 11/19/2018 : 15:55:22
|
I am still into modifying Ullix's code to get the data being sent at more accurate 60sec intervals to gmcmap.
Tube identification could be part of that exercise.
If he likes he can commit the new code to his sourceforge project after his review. |
To bug or not debug, that is the Q |
|
|
| Reply #5
ullix
Germany
1171 Posts |
Posted - 11/29/2018 : 06:16:59
|
The gmcmap is a conceptual mess, on a par with adding the counts of two tubes with different sensitivities as in the 500+.
I am reluctant to add any further code to GeigerLog, which implements even more non-meaningful measures. It probably was a mistake to add this to GeigerLog at all.
If GMCMAP is to be made useful, a lot more needs to be done. Perhaps this can be done, if GQ is willing.
|
|
|
| Reply #6
ikerrg
United Kingdom
334 Posts |
Posted - 11/29/2018 : 07:05:43
|
Ullix, please, don’t give up. I know that it can be frustrating, but GQ is usually willing to collaborate. They have done what you said about the codes for the 32 bit integers (keeping 55 AA 02 to define the location data), and they added the 55 AA 05 to define the tube selection. And the most important thing is that there is no alternative software, as DataViewer is not very useful to say the least.
About sending the radiation data to the online map, I agree, it is not worth spending time on it when there are other thousand more important problems not yet solved.
|
|
|
| Reply #7
ullix
Germany
1171 Posts |
Posted - 11/30/2018 : 02:31:37
|
Adding the tube differentiation to the history parser is a good chunk of work but possible.
What is a lot more annoying is that the damage had already been done with the release of firmware, which changed the order of identifiers as e.g. given by EmfDev's Reply 22 here http://www.gqelectronicsllc.com/forum/topic.asp?TOPIC_ID=5461&whichpage=2
@EmfDev: can you please give the exact firmware versions, which have the modified order? It is my understanding that this unfortunate change is only present in a few firmwares?
|
|
|
| Reply #8
ikerrg
United Kingdom
334 Posts |
Posted - 12/01/2018 : 01:32:58
|
@ullix: Thanks for considering the change. Yes, the damage is done, but as far as I know it is very localized in a few firmware versions of the 500+. For the 600 series the fix has been recently made after I flagged the problem to EmfDev. My recommendation is that you just ignore the details about firmware versions and make the programming only for the latest, and tell the GeigerLog users that they must upgrade their firmware to the latest version in order to use the software (that is a typical requirement for other software).
On the other hand, please, read this post: https://www.gqelectronicsllc.com/forum/topic.asp?TOPIC_ID=5572 and you will see why it is important to add the new tube selection code to the GeigerLog parser. I think it could be failing now due to that. |
Edited by - ikerrg on 12/01/2018 01:33:56 |
|
|
| Reply #9
ullix
Germany
1171 Posts |
Posted - 12/01/2018 : 02:35:22
|
If the firmware really had been corrected quickly, there can't be that many versions of it, and they should be defined.
It is easier to catch those, than to add code to block GeigerLog from executing when the counter has the wrong software. Correctly detecting is a lot more ambiguous.
@EmfDev: please specify which firmware(s) have this order problem.
|
|
|
| Reply #10
donghelan
Japan
65 Posts |
Posted - 12/01/2018 : 07:34:03
|
@ullix I don't think it is big problem for GQE to improve the GMCMAP. I have pointed out the few minor problems with that map and the GMC500+ here www.gqelectronicsllc.com/forum/topic.asp?TOPIC_ID=5567.
Any way gmcmap should not insert date/time stamps. date/time stamps should be sent from data loggers like the geiger counter itself or Geigerlog requiring a data exchange format change.
That is clearly the weakest point in the design now. The exchange format.
True, if that is solved properly applications can be changed accordingly.
B.t.w. the crowd sourced, volunteer, citizen science project SAFECAST map is the best public available example of global radiation monitoring, triggered by the Fukushima disaster: https://realtime.safecast.org/map/ - Delete the s of https in the URL.
It is already more than 7 years ago they started.
However the Safecast Open Source geiger counter is sold for a price that is not acceptable for most of us(self assembly package starting from $550!). |
To bug or not debug, that is the Q |
Edited by - donghelan on 12/05/2018 06:10:04 |
|
|
| Reply #11
EmfDev
2250 Posts |
Posted - 12/03/2018 : 14:57:11
|
@ullix,
According to support, firmware before 1.22 have location at 0x04.
so 1.22 have the location at 0.02. |
|
|
| Reply #12
ullix
Germany
1171 Posts |
Posted - 12/04/2018 : 02:45:45
|
@EmfDev: could you please be a bit more specific here: so far I am aware only of 1.18 and 1.21 firmware versions.
Do you now say that there also has been 1.19 and 1.20? And how far back does it go - all 18 versions from 1.17 to 1.00? Or even below the 1.0 version?
|
|
|
| Reply #13
ullix
Germany
1171 Posts |
Posted - 12/04/2018 : 03:57:11
|
@EmfDEv: quote:
Also in the current 500/+, if you see a 55 AA 05, that is tube type, and 00 = both, 1 = tube 1, and 2 is tube 2.
I am not fully sure how this is to be interpreted. My take is that with an occurrence of the 55 aa 05 tag all subsequent data are to be interpreted as coming either from tube1 alone or from tube2 alone or are the sum of the tube1 and tube2 counts? Is that a correct interpretation?
The last option of the three would be the not meaningful addition of counts from 2 tubes with very different sensitivities. We have talked at length about this. And yet this is recorded and is actually the default?
GeigerLog is able to record and store both tubes individually and separately, so, handling either tube1 or tube2 is not a problem. But what to do with sum of the two?
If the tube2 count is very low - the standard case - the sum is basically the same as tube1.
If the tube2 count is high, the tube1 likely has an overflow condition and could be anything from high to low, eliminating any meaning from the "sum of the two".
I'd say, if you want to store data from both tubes, you need to store the count values from both tubes! Technically, a DateTime tag would be followed by first the tube2 count, and second the tube2 count. Not a major problem; in the worst case it will reduce the memory by half, but this is still good enough. You will then no longer need the 55 AA 05 tag.
If you don't want to do this, then allow to save only either tube1 or tube2, but never ever the sum of the two!
|
|
|
| Reply #14
EmfDev
2250 Posts |
Posted - 12/04/2018 : 11:12:27
|
quote:
Originally posted by ullix
I am not fully sure how this is to be interpreted. My take is that with an occurrence of the 55 aa 05 tag all subsequent data are to be interpreted as coming either from tube1 alone or from tube2 alone or are the sum of the tube1 and tube2 counts? Is that a correct interpretation?
That is correct, anything after the 55 AA 05 is interpreted as either tube1 or tube2 or sum.
Honestly, we don't have much time right now to change the data logging code and parsing code with the software that's why we just put a simple addition there and keep most of the code the same. We know that some of you guys still can't accept the sum of two tubes, that's why we included an option to only store tube1 or tube2. |
|
|
| Reply #15
EmfDev
2250 Posts |
Posted - 12/04/2018 : 11:47:31
|
Yes there are 1.19 and 1.20 versions, you can ask support if there's available update for your hardware.
And according to support, it is before 1.22 that the location data is different. And yes there are 1.19 and 1.20 versions.
And there existed 1.00(initial release) and up to 1.17. And now there is V2 that started at 2.00. I'm not sure how far back it started because I don't release the firmware.
|
Edited by - EmfDev on 12/04/2018 11:48:41 |
|
|
| Reply #16
ullix
Germany
1171 Posts |
Posted - 12/06/2018 : 09:34:06
|
A release candidate update to GeigerLog, named GeigerLog v0.9.08b-rc1 has just been uploaded. You find it under the testing folder
https://sourceforge.net/projects/geigerlog/files/testing/
GeigerLog is now aware of the tube selection saved in the history, and makes multiple attempts to repair the firmware mess created by GQ.
Please, report any issues. |
|
|
| Reply #17
ikerrg
United Kingdom
334 Posts |
Posted - 12/06/2018 : 12:49:00
|
Thanks ullix. I briefly tested GeigerLog with another file (saved using only tube 2), and it seems to detect that perfectly. Only one hint: When only tube 1 or tube 2 are stored, the default selection in the drop-down list (CPM, CPS, CPM1st, CPM2nd,...) is always CPM (even if that option is grayed out and cannot be selected), so all the graphs are dimmed and the stats, poisson and fft buttons don't work by default. It is necessary to manually select one of the valid stored magnitudes (CPM1st, CPM2nd, etc.) so the graphs become solid coloured and the statistics buttons work again. During the weekend I can try to save a file with multiple changes of tube selections during the recording, and see how GeigerLog processes that.
|
|
|
| Reply #18
ullix
Germany
1171 Posts |
Posted - 12/07/2018 : 06:06:08
|
Sigh. Though it does not result in errors. Will be taken care of it in next release.
Any other observations? Wishes?
|
|
|
| Reply #19
ikerrg
United Kingdom
334 Posts |
Posted - 12/10/2018 : 02:23:47
|
@ullix: I added some relevant information about this mess in reply #8 at www.gqelectronicsllc.com/forum/topic.asp?TOPIC_ID=5572 . I do not think it is GeigerLog's fault, but it is clearly something that could affect the way you program GeigerLog.
With regards to wishes, I would like to be able to change the "calibration factor" (uSv/h/CPM) in GeigerLog's GUI. A pair of text boxes close to the "Units" drop-down list (for both tubes) could do the trick. With that feature, it would be easier to check how different calibrations affect the tubes' responses.
|
|
|
| Reply #20
ullix
Germany
1171 Posts |
Posted - 12/10/2018 : 11:25:08
|
| Try RC2, either Device Menu --> Set Calibration Factors, or button Set Calib in Graph Options |
|
|
| Reply #21
ikerrg
United Kingdom
334 Posts |
Posted - 12/10/2018 : 12:07:54
|
It seems that your new version requires LabJackPython, but that module seems incompatible with Python 3, as when I try to get it with "pip install LabJackPython" the error is
LabJackPython requires Python 2.5 or later but does not work on any version
of Python 3. You are using version 3.7.1 (v3.7.1:260ec2c36a, Oct 20 2018, 14:57
:15) [MSC v.1915 64 bit (AMD64)]. Please install using a supported version.
The error from GeigerLog is:
File "D:\Descargas\geigerlog\geigerlog", line 117, in <module>
import glabjack
File "D:\Descargas\geigerlog\glabjack.py", line 22, in <module>
import LabJackPython
ModuleNotFoundError: No module named 'LabJackPython'
|
|
|
| Reply #22
ullix
Germany
1171 Posts |
Posted - 12/11/2018 : 03:27:13
|
sorry, some leftover experimental stuff.
rc3 is up.
|
|
|
| Reply #23
ikerrg
United Kingdom
334 Posts |
Posted - 12/11/2018 : 11:26:29
|
Yes, tested and working OK. Thanks ullix.
@EmfDev, any updates about the tube selection code not being written to memory? |
|
|
| Reply #24
EmfDev
2250 Posts |
Posted - 12/11/2018 : 21:15:09
|
@ullix, ikkerg
Thanks for helping improve user experience . We appreciate your effort.
@ikerrg,
Do you mean its not being saved on the config?
Im out of town for few weeks so I wont be able to answer some questions or edit the code. |
Edited by - EmfDev on 12/11/2018 21:17:52 |
|
|
| Reply #25
ikerrg
United Kingdom
334 Posts |
Posted - 12/12/2018 : 01:15:00
|
| @EmfDev: No I mean that the tube selection changes are not logged in the internal memory while recording data, by using the 55 AA 05 XX codes. |
|
|
| Reply #26
ikerrg
United Kingdom
334 Posts |
Posted - 12/25/2018 : 10:52:23
|
| @ullix: A geigerlog possible fix: When I change the colour of one line in the graph, the legend colour for that line is not updated accordingly in the graph. Could you confirm and fix the problem? I am using GeigerLog 0.9.08b.rc3 |
|
|
| Reply #27
ullix
Germany
1171 Posts |
Posted - 12/27/2018 : 04:06:53
|
How did you even manage to change a color of one line in the graph?
In the config file it says:
# LINECOLOR:
# Note: linecolor is deprecated; will be ignored.
#
and it does indeed not have any effect whatsoever?
If you must change a linecolor, you have two options:
a) in the code in file gglobs.py change variable varcolor in line 286ff (CAREFUL!), or
b) use the upward-flash icon in the toolbar (2nd from right) to temporarily edit the colors, line types and a lot more.
I found it hard to define a consistent set of colors for 10 variables, which are easy to recognize among all others and plotting conditions. If you find a better set, please, let me know!
|
|
|
| Reply #28
ikerrg
United Kingdom
334 Posts |
Posted - 12/27/2018 : 11:25:41
|
In "Edit axis, curve and image parameters" button, you select the axis and then in the "Curves" tab you can select _line0, _line1, etc. and change the colour of the line and marker points.
You are right, it is difficult to select 10 colours different enough and clear enough. I might think about it. |
|
|
| |
Topic |
|
GeigerLog 0.9.08 released - some major changes
