|T O P I C R E V I E W
||Posted - 05/20/2018 : 04:13:26
The recent disclosures of GQ in this record-long topic http://www.gqelectronicsllc.com/forum/topic.asp?TOPIC_ID=4948 made it possible to fully implement not only the 300 and 320 versions, but also the 500 and 600 versions. So, thanks to GQ. Not everything is solved, but the remaining issues should not impact the successful use of GeigerLog with the counters.
Thanks also to user 'the_mike' for testing the release candidates, and his embarrassing ability to find bugs :-/ !
What’s New in GeigerLog 0.9.07 ?
#9679; GeigerLog now uses Python 3
#9679; Now supporting GMC-300, GMC-300E+, GMC-320+, GMC-320+V5, GMC-500(+), GMC-600(+)
#9679; Auto-detecting Geiger Counter model, and adjusting internal settings, calculations, calibration, as well as work-arounds for firmware-bugs automatically
#9679; Customization possible to accommodate older counters, and potentially even for new ones not yet on the market
#9679; Supports World Radiation Maps even for devices without WiFi
#9679; Customizable graphics (colors, line widths, line types, markers)
#9679; Count Rate Display area click sensitive to allow manually triggered count rate measurements
as always, available for download at https://sourceforge.net/projects/geigerlog/
|33 L A T E S T R E P L I E S (Newest First)
||Posted - 07/26/2018 : 09:36:38
Always use ullix's version. Mine is only a personal test that I shared to everybody just in case ullix did not have time to fix it.
||Posted - 07/26/2018 : 09:21:29
So I can confirm that the change made by ikerrg works for me. Changed serial port and things are printing out like clockwork.
ullix - are you saying there is already a gls posted that handles both 2 byte systems and 4 byte systems and uses your struct command? Or should I continue to use ikerrg's changes?
||Posted - 07/26/2018 : 09:06:57
The code was never wrong. It was a consequence of this last byte of the version having never been read. So it propagated through all the other calls ...
This can't happen in full GL, as there is a provision against exactly such problem as I got burned before. Now also in the simple version.
The struct module could have been used, but for conversion of bytes to integers, a little bit shifting is just as good. When floating point numbers come into play (think calibration) you really want struct!
So the new rc2 version is up in the testing folder. Supports Py2, Py3, 2-byte and 4-byte counter.
Please note, I have changed the columns order to make it match the upcoming GeigerLog 0.9.08, which supports multiple data columns and more.
Hopefully it works this time.
||Posted - 07/26/2018 : 08:16:45
OK, so I did a very quick modification using the above, and it seems to work for the new 4 byte counter!. Probably it wouldn't work for the 2 byte counters, as I changed the output format and didn't check anything, but I can start using it in my experiments.
Here it is:
||Posted - 07/26/2018 : 07:42:33
Couldn't you use just Python struct as in:
value = struct.unpack('>I', srec)
It seems to work perfectly to get the integer in get23 function, but then it needs changes in the formatting for the log file output.
||Posted - 07/26/2018 : 07:15:22
Well spotted! Yes, sorry, I copied the wrong string of bytes to the previous message. It was: 47 4D 43 2D 35 30 30 2B 52 65 20 31 2E 31 38 , which in ASCII is: GMC-500+Re 1.18. So you are right, 15 bytes. In fact, DataViewer software itself detects the device as GMC-500+Re 1.1 in the log window, so the 14 bytes string seems to be something that was changed at some time.
Thanks a lot for your work on this!
||Posted - 07/26/2018 : 05:43:56
Oh, of course, the string 'GMC-500+Re 1.18' is 15 bytes long, while GQ's 'documentation' says it is 14 bytes long
The other stuff I need to test. The simple code is a disadvantage as it creates no debug code for cases like this
||Posted - 07/26/2018 : 04:41:46
Yes, it is 1.1 in your code. However, I checked that in the terminal mode inside DataViewer, and the command GETVER correctly returns GMC-500+Re 1.18 (or 3C 47 45 54 56 45 52 3E 3E). Somehow that is being truncated in Python.
The result of your new code does not work, and that is why I ordered the bytes this way (see my file):
rec = chr(srec) + chr(srec) + chr(srec) + chr(srec)
However, I had a double mistake, so I just was lucky. I do not have time now to try to find why Python requires that to process a 32 bit integer. I have no idea of Python, I only mimicked your operations and used my logic (and some 15 year old knowledge in Pascal programming that I once had).
The resulting log is just a nonsense:
# Log file created with: 'geigerlog_simple_500plus.py', Version: 0.2.rc1 (code °µ°)
# Python Version: 3.7.0 (v3.7.0:1bf9cc5093, Jun 27 2018, 04:59:51) [MSC v.1914 64 bit (AMD64)]
# Index, DateTime, CPM, CPS, CPM1st, CPM2nd, CPS1st, CPS2nd
0, 2018-07-26 13:33:09, 0.00, 0.00, 0.00, 14.00, 0.00, 0.00
1, 2018-07-26 13:33:10, 0.00, 0.00, 0.00, 0.00, 0.00, 0.00
2, 2018-07-26 13:33:11, 0.00, 0.00, 0.00, 0.00, 14.00, 0.00
3, 2018-07-26 13:33:12, 0.00, 0.00, 0.00, 0.00, 13.00, 0.00
4, 2018-07-26 13:33:13, 12.00, 0.00, 0.00, 0.00, 0.00, 0.00
5, 2018-07-26 13:33:14, 12.00, 0.00, 0.00, 0.00, 0.00, 0.00
6, 2018-07-26 13:33:15, 12.00, 0.00, 0.00, 0.00, 0.00, 0.00
7, 2018-07-26 13:33:16, 10.00, 0.00, 0.00, 0.00, 0.00, 0.00
8, 2018-07-26 13:33:17, 9.00, 0.00, 0.00, 0.00, 0.00, 0.00
9, 2018-07-26 13:33:18, 9.00, 0.00, 0.00, 2.00, 0.00, 0.00
10, 2018-07-26 13:33:19, 11.00, 0.00, 0.00, 0.00, 0.00, 0.00
11, 2018-07-26 13:33:20, 11.00, 0.00, 0.00, 0.00, 0.00, 0.00
12, 2018-07-26 13:33:21, 10.00, 0.00, 0.00, 0.00, 0.00, 0.00
13, 2018-07-26 13:33:22, 10.00, 0.00, 0.00, 0.00, 0.00, 0.00
14, 2018-07-26 13:33:23, 9.00, 0.00, 0.00, 1.00, 0.00, 0.00
15, 2018-07-26 13:33:24, 10.00, 0.00, 0.00, 0.00, 0.00, 0.00
16, 2018-07-26 13:33:25, 10.00, 0.00, 0.00, 0.00, 0.00, 0.00
17, 2018-07-26 13:33:26, 10.00, 0.00, 0.00, 0.00, 0.00, 0.00
18, 2018-07-26 13:33:27, 9.00, 0.00, 0.00, 0.00, 0.00, 0.00
19, 2018-07-26 13:33:28, 8.00, 0.00, 0.00, 0.00, 0.00, 0.00
20, 2018-07-26 13:33:29, 8.00, 0.00, 0.00, 0.00, 0.00, 0.00
21, 2018-07-26 13:33:30, 8.00, 0.00, 0.00, 0.00, 0.00, 0.00
22, 2018-07-26 13:33:31, 8.00, 0.00, 0.00, 0.00, 0.00, 0.00
23, 2018-07-26 13:33:32, 8.00, 0.00, 0.00, 0.00, 0.00, 0.00
24, 2018-07-26 13:33:33, 8.00, 0.00, 0.00, 0.00, 0.00, 0.00
25, 2018-07-26 13:33:34, 8.00, 0.00, 0.00, 0.00, 0.00, 0.00
26, 2018-07-26 13:33:35, 8.00, 0.00, 0.00, 0.00, 0.00, 0.00
27, 2018-07-26 13:33:36, 8.00, 0.00, 0.00, 1.00, 0.00, 0.00
28, 2018-07-26 13:33:37, 9.00, 0.00, 0.00, 1.00, 0.00, 0.00
29, 2018-07-26 13:33:38, 10.00, 0.00, 0.00, 0.00, 0.00, 0.00
30, 2018-07-26 13:33:39, 10.00, 0.00, 0.00, 0.00, 0.00, 0.00
31, 2018-07-26 13:33:40, 10.00, 0.00, 0.00, 0.00, 0.00, 0.00
32, 2018-07-26 13:33:41, 10.00, 0.00, 0.00, 0.00, 0.00, 0.00
33, 2018-07-26 13:33:42, 10.00, 0.00, 0.00, 0.00, 0.00, 0.00
34, 2018-07-26 13:33:43, 10.00, 0.00, 0.00, 1.00, 0.00, 0.00
||Posted - 07/26/2018 : 03:40:57
That 4-byte firmware is giving headaches. I'd appreciate, if you could clarify:
- The 4 byte word is a 32bit unsigned integer?
- The 4 bytes come in the sequence first MSB, then yadda, yadda, LSB?
- Are all bits valid in all 4 bytes for each of the CPM* and CPS* commands, or is there a clipoff of the high bits in any command, as is currently needed in the CPS command?
- How can one distinguish between counters offering 2 bytes from those offering 4 bytes?
I had expected the GETVER command to deliver the essential signature, but if a counter with firmware 1.18 delivers only '1.1' then this is not helping? It will be a nightmare if not properly done!
||Posted - 07/26/2018 : 03:29:19
@ikerrg: Darn, forgot to test on Py3
Now it works, and the resulting string is:
Version: b'GMC-500+Re 1.1'
This leaves me puzzled and surprised. You're sure there is no 2nd decimal?
I read that the firmware 1.18 allowed 4 decimals, while 1.17 did not. If your counter identifies itself as '1.1' this is really calling for trouble! You can't distinguish between them anymore!!!
I just uploaded a release candidate for the new glsimple500 under the testing folder:
If you could give it a try, please. That simple version ain't that simple anymore, but you do seem to understand Python enough to try a correction, if it fails. See byte-ordering in the code; I sure hope it is a true unsigned 32bit number. Decoding a byte sequence in Py3 to string also in the code (str.decode() is the solution)
||Posted - 07/26/2018 : 01:47:40
Your code fails with this message:
TypeError: can only concatenate str (not "bytes") to str
I changed the last line according to other parts of your code (no idea of Python language) to
Now it works, and the resulting string is:
Version: b'GMC-500+Re 1.1'
About the byte sampling, EmfDev said that all the commands return 4 bytes ordered as (MSB)(x)(x)(LSB). That is a pure 32 bit unsigned integer to me. (see post #40 in http://www.gqelectronicsllc.com/forum/topic.asp?TOPIC_ID=5304). Could you do the change in Python to translate the 32 bit integer to a string?
||Posted - 07/26/2018 : 01:21:51
@ikerrg: almost correct. Line 81 has the terms in incorrect sequence, but that was corrected by a second error in line 84, which did not take the 4 bytes into account. The results were then correct because they were below the 2-byte word limit.
Challenge is now to figure out which counters need 2 byte and which need 4 byte sampling.
Can you help me and put these commands in your modification of GLsimple right after the 'ser=' command:
ser = serial.Serial(my_port, my_baudrate, timeout=my_timeout) # open serial port
# add next 5 lines
srec = ser.read(14)
print("Version: " + getVersion())
and post the printout of this segment, thanks.
||Posted - 07/25/2018 : 10:42:54
I need the GeigerLogSimple to keep recording in my experiments. However, with the new firmware version, the data has changed from 2 to 4 bytes, and v.0.1 does not work. I have modified your Python code to support only the new firmware (there is some background logging data to probe that it works):
As this is my first approach to Python (and I have no idea about the structure of the 4 bytes of data), could you check what I did specially in line 81? You need to change line 84 which is for an old Python version.
||Posted - 07/22/2018 : 03:41:35
The PyQt4 support in Windows seems totally buggy. I found erratic behavior in different machines. I just tried to install geigerlog and Python in a different Windows machine, and I cannot make it load the PyQt4 DLL!!! That makes no sense. It says:
Traceback (most recent call last):
File "geigerlog", line 44, in <module>
from PyQt4 import QtGui, QtCore
ImportError: DLL load failed: The specified module could not be found.
I have used the same commands as in the previous computer (in fact I have a batch script to do it), and I tried everything I found in google, but with no luck.
python -m pip install --upgrade pip
pip3 install scipy
pip3 install pyserial
pip3 install matplotlib
pip3 install PyQt4-4.11.4-cp37-cp37m-win_amd64.whl
Don't worry, I do not want to waste more time.
Update: I have installed Python 3.4 with your recommended PyQt4 distribution for Windows (PyQt4-4.11.4-gpl-Py3.4-Qt4.8.7-x64.exe) in the other Windows computer, and now PyQt4 is correctly detected and Geigerlog works. Phonon still shows the same warning.
||Posted - 07/22/2018 : 01:21:29
Indentation in Python is immensely helpful to keep the code well organized and neatly formatted. One advice here: never, ever use an editor, which cannot be set to automatically convert tabs to spaces! Mixing the two becomes a nightmare.
Re Windows, I give up. Good that it runs properly on Ubuntu.
Looks like there many people having phonon issues with a variety of programs on Windows. I'll make its use optional in the next GeigerLog release. Next GeigerLog version is almost ready.
Thanks for the bug report on the GeigerLog manual; it is always much appreciated. In this case it is a carry over from Python2 - I had missed the renaming of the packages. Glad you caught it. Thanks.
||Posted - 07/21/2018 : 23:53:00
I am using Windows 7. I could try installing python in a user folder instead of in a system folder. Just in case there is a bug in the PyQt4 distribution. But I have tried running geigerlog in admin mode and the warning still appears.
Adding your line, I initially got a python error and the program does not even started:
File "geigerlog", line 5211
QtCore.QCoreApplication.addLibraryPath(gglobs.progPath + "/custom_libs/")
TabError: inconsistent use of tabs and spaces in indentation
I fixed it by indenting with spaces instead of a tab. I did not know that Python was able to discern between spaces an a tab! Anyway, the phonon error is still there, sorry. And the debug message about the library paths is still:
08:57:48 VERBOSE: QCoreApplication.libraryPaths(): No Library Paths
On the other hand, I tried installing geigerlog in my Ubuntu 18.04 and everything worked perfectly (including phonon). It was not easy to find the same modules that you specified in the geigerlog manual (especially to install PyQt4). I finally used these commands, just in case you might want to update geigerlog's manual:
sudo apt-get install python3-pip
sudo -H pip3 install scipy
sudo -H pip3 install pyserial
sudo -H pip3 install matplotlib
sudo apt-get install python3-pyqt4
sudo apt-get install python3-pyqt4.phonon
||Posted - 07/21/2018 : 22:21:38
Do NOT install Python 2.x! The geigerlog_simples are the last ones to work with Py2 (but also with Py3), the full GeigerLog now requires Python 3.x !
This is getting really strange, when neither new nor old Python versions make it. Does not look like a bug in Python, but in the specific packaging of Python for Windows.
The only common thing is now the Windows version. Which version is it actually?
I guess my last idea is to fix it with a patch to GeigerLog: from the original GeigerLog 0.9.07 take the file 'geigerlog', open in an editor and find line 5210, which reads:
app = QtGui.QApplication(sys.argv)
Directly AFTER this line, as line 5211, insert:
QtCore.QCoreApplication.addLibraryPath(gglobs.progPath + "/custom_libs/")
Then create the folder path/to/geigerlog/custom_libs/ and put the phonon*.dll there.
||Posted - 07/21/2018 : 11:27:18
maybe this is a (very) stupid input...
but as i understood the issue, python isn't able to find the libs because in vers. 3.4, it runs from program files, instead of c: ...
have you tried setting the path "old style" to the libraries?
otherwhise - try python 2.7 - at least that version runs fine so far on windows... :-/
||Posted - 07/21/2018 : 11:10:54
Everything I try fails. I have installed python 3.4 with your recommended PyQt4 distribution for Windows (PyQt4-4.11.4-gpl-Py3.4-Qt4.8.7-x64.exe) and same issue. Even after copying phonon_backend folder as indicated. Nothing works!
||Posted - 07/21/2018 : 10:33:53
No luck. I even reinstalled python in c:\Python37 to avoid spaces in the path, but also no luck. It has to be something related to the latest versión and its incompatibility with the PyQt4 package I am using.
Adding the phonon_backend directory to the system path also does not work.
||Posted - 07/21/2018 : 09:22:45
One guy was happy with this:
The backend needs to be in the subdirectory "/phonon_backend/" of the qt library paths so my solution was to put the backend-files from the "qt/plugins/phonon_backend/"-folder into the folder in which I executed the programm - but in the subdirectory "/phonon_backend/"
So, put the dll into geigerlog/phonon_backend/ ?
||Posted - 07/21/2018 : 05:26:23
It already esxists. It is where I found the file phonon_ds94.dll
||Posted - 07/21/2018 : 04:13:15
Suggestion: First try to create:
||Posted - 07/20/2018 : 23:55:27
Yes, the library is that one (phonon_ds94.dll), but it does not help copying into the geigerlog folder. I am starting to see a possibility here: PyQt4 is not designed for the newest Python versions, which by default install in 'C:\Program Files\Python37'. That is a folder with spaces in the name, and sometimes that creates problems in some bad programmed apps. When I find time I could try to reinstall my Python in 'C:\Python37' to see if that fixes the problem.
||Posted - 07/20/2018 : 23:18:54
On Linux, the library path /usr/lib/x86_64-linux-gnu/qt4/plugins has a dozen or so subfolders with various plugins.
Among them is as subfolder 'phonon_backend' with a sole file 'phonon_gstreamer.so'. This is the equivalent to a Windows *.dll file (dynamic link library).
I suggest: search for '*phonon*.*'. There hopefully will be one (or more) with the '.dll' extension. Copy all those into the folder where 'geigerlog' resides. (I believe that PyQt4 also searches in that folder for libraries; otherwise I don't know where they are supposed to be)
If that doesn't help, some googling may be needed. My guess is that there will be a few postings for this brand new 3.7 Python version :-/
P.S. Just came across this one:
Although for an older Python, it may give the necessary hint of what needs to be where.
||Posted - 07/20/2018 : 04:13:14
You're right. Line 14 says:
2018-07-20 13:01:57 VERBOSE: QCoreApplication.libraryPaths(): No Library Paths
How can I configure those paths?
||Posted - 07/20/2018 : 01:02:36
The Phonon module seems to be installed, or the error message would have been different. It may have to do with an incorrect library path.
After starting geigerlog with the dv options, like:
please, look into the geigerlog.proglog file again. Near the 15th line should be one or several lines, such as this on my Linux system, giving a library path :
2018-07-20 10:51:44.993 VERBOSE: QCoreApplication.libraryPaths(): /usr/lib/x86_64-linux-gnu/qt4/plugins
Could you copy and post them?
||Posted - 07/18/2018 : 13:08:10
Thanks, but I can't find anything like that for Windows. The phonon library seems to be correctly installed in my PyQt4 package. I think the problem will be solved if I install a lower version of Python, but I don't bother trying.
||Posted - 07/17/2018 : 16:25:39
jkerrg - try to find a "pyqt4.phonon"-package, i remember having to install it to avoid the issue on linux mint 18.3 (cinnamon edition)
||Posted - 07/14/2018 : 00:40:12
Everything else seems to be working fine. I haven't noticed the beeps though, but I didn't know they should be there! No worries, it is not a big deal.
||Posted - 07/13/2018 : 23:54:33
I am afraid this is a bug not under my control. The internet is full of such reports, and they point to something missing in the installation. The cause is probably a packaging oversight. Your use of the most modern Python may contribute to the issue. Have you ever had an older Python and did it work then?
You can try to just install any Python stuff that is related to media playing; for some users it helped. Phonon is used for acoustic feed back, i.e. to play the beep and bopp sounds. I guess you don't hear any sounds?
Unfortunately I can't test this hear, because on my system it is just working :-/. Is GeigerLog otherwise behaving properly or is something else impacted?
||Posted - 07/13/2018 : 09:12:45
I am getting this warning (several times) when running geigerlog (not geigerlog_simple):
WARNING: bool __cdecl Phonon::FactoryPrivate::createBackend(void) phonon backend plugin could not be loaded
The software seems to run fine and everything seems to work (data log, plots, etc). Do you know what the problem could be?
I am using Python 3.7 x64 and I have installed PyQt4 from the wheel file PyQt4-4.11.4-cp37-cp37m-win_amd64.whl in https://www.lfd.uci.edu/~gohlke/pythonlibs/#pyqt4
The starting message has this additional info for debugging:
2018-07-13 18:04:36 PROGRAM: pid:4580 ########### GeigerLog 0.9.07 -- mi no märpfupf underm füdli ! ##################################################
18:04:36 DEBUG : Version status:GeigerLog: 0.9.07, Python: 3.7.0 (v3.7.0:1bf9cc5093, Jun 27 2018, 04:59:51) [MSC v.1914 64 bit (AMD64)], matplotlib: 2.2.2, numpy: 1.14.5, Qt version: 4.8.7, SIP version: 4.18.1, PyQt version: 4.11.4, pyserial: 3.4, scipy: 1.1.0,
||Posted - 05/22/2018 : 05:02:01
...hey if you find something you're good at, stay with it, right? ;-)
(ebarassing - for me or for you?)
thanks for the new version!