GQ Electronics Technical Support Forum


GQ Electronics Technical Support Forum
Home | Profile | Register | Active Topics | Members | Search | FAQ
Username:
Password:
Save Password
Forgot your Password?

 All Forums
 GQ Electronics Forums
 2.GQ Geiger Muller Counter
 GeigerLog 0.9.07 released with new features
 New Topic  Reply to Topic
 Printer Friendly
Author Previous Topic Topic Next Topic  

ullix

Germany
346 Posts

Posted - 05/20/2018 :  04:13:26  Show Profile  Reply with Quote
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/
Reply #1

the_mike

Switzerland
28 Posts

Posted - 05/22/2018 :  05:02:01  Show Profile  Reply with Quote
...hey if you find something you're good at, stay with it, right? ;-)

(ebarassing - for me or for you?)

thanks for the new version!
Go to Top of Page
Reply #2

ikerrg

United Kingdom
291 Posts

Posted - 07/13/2018 :  09:12:45  Show Profile  Reply with Quote
Hi ullix,

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,

Many thanks.

Edited by - ikerrg on 07/13/2018 09:19:15
Go to Top of Page
Reply #3

ullix

Germany
346 Posts

Posted - 07/13/2018 :  23:54:33  Show Profile  Reply with Quote
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?
Go to Top of Page
Reply #4

ikerrg

United Kingdom
291 Posts

Posted - 07/14/2018 :  00:40:12  Show Profile  Reply with Quote
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.
Go to Top of Page
Reply #5

the_mike

Switzerland
28 Posts

Posted - 07/17/2018 :  16:25:39  Show Profile  Reply with Quote
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)
Go to Top of Page
Reply #6

ikerrg

United Kingdom
291 Posts

Posted - 07/18/2018 :  13:08:10  Show Profile  Reply with Quote
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.
Go to Top of Page
Reply #7

ullix

Germany
346 Posts

Posted - 07/20/2018 :  01:02:36  Show Profile  Reply with Quote
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:
geigerlog -dv

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?
Go to Top of Page
Reply #8

ikerrg

United Kingdom
291 Posts

Posted - 07/20/2018 :  04:13:14  Show Profile  Reply with Quote
You're right. Line 14 says:
2018-07-20 13:01:57 VERBOSE: QCoreApplication.libraryPaths(): No Library Paths

How can I configure those paths?
Go to Top of Page
Reply #9

ullix

Germany
346 Posts

Posted - 07/20/2018 :  23:18:54  Show Profile  Reply with Quote
Good question.

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:
'phonon_backend':
'C:\Python27\Lib\site-packages\PyQt4\plugins\phonon_backend\phonon_ds94.dll'

Although for an older Python, it may give the necessary hint of what needs to be where.

Edited by - ullix on 07/20/2018 23:29:44
Go to Top of Page
Reply #10

ikerrg

United Kingdom
291 Posts

Posted - 07/20/2018 :  23:55:27  Show Profile  Reply with Quote
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.
Thanks.
Go to Top of Page
Reply #11

ullix

Germany
346 Posts

Posted - 07/21/2018 :  04:13:15  Show Profile  Reply with Quote
Suggestion: First try to create:

'C:\Program Files\Python37\Lib\site-packages\PyQt4\plugins\phonon_backend\phonon_ds94.dll'

Go to Top of Page
Reply #12

ikerrg

United Kingdom
291 Posts

Posted - 07/21/2018 :  05:26:23  Show Profile  Reply with Quote
It already esxists. It is where I found the file phonon_ds94.dll
Go to Top of Page
Reply #13

ullix

Germany
346 Posts

Posted - 07/21/2018 :  09:22:45  Show Profile  Reply with Quote
Duh.

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/ ?
Go to Top of Page
Reply #14

ikerrg

United Kingdom
291 Posts

Posted - 07/21/2018 :  10:33:53  Show Profile  Reply with Quote
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.
Go to Top of Page
Reply #15

ikerrg

United Kingdom
291 Posts

Posted - 07/21/2018 :  11:10:54  Show Profile  Reply with Quote
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!
Go to Top of Page
Reply #16

the_mike

Switzerland
28 Posts

Posted - 07/21/2018 :  11:27:18  Show Profile  Reply with Quote
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?
eg.
c:\>set PYTHONPATH=%PYTHONPATH%;C:\path_to_the_python_libs


?

otherwhise - try python 2.7 - at least that version runs fine so far on windows... :-/
Go to Top of Page
Reply #17

ullix

Germany
346 Posts

Posted - 07/21/2018 :  22:21:38  Show Profile  Reply with Quote
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.
Go to Top of Page
Reply #18

ikerrg

United Kingdom
291 Posts

Posted - 07/21/2018 :  23:53:00  Show Profile  Reply with Quote
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
pip3 list
sudo -H pip3 install scipy
sudo -H pip3 install pyserial
sudo -H pip3 install matplotlib
pip3 list
sudo apt-get install python3-pyqt4
sudo apt-get install python3-pyqt4.phonon
./geigerlog -d

Edited by - ikerrg on 07/21/2018 23:59:04
Go to Top of Page
Reply #19

ullix

Germany
346 Posts

Posted - 07/22/2018 :  01:21:29  Show Profile  Reply with Quote
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.

Go to Top of Page
Reply #20

ikerrg

United Kingdom
291 Posts

Posted - 07/22/2018 :  03:41:35  Show Profile  Reply with Quote
No problem!

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 list
pip3 install scipy
pip3 install pyserial
pip3 install matplotlib
pip3 install PyQt4-4.11.4-cp37-cp37m-win_amd64.whl
pip3 list


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.

Edited by - ikerrg on 07/22/2018 23:30:53
Go to Top of Page
Reply #21

ikerrg

United Kingdom
291 Posts

Posted - 07/25/2018 :  10:42:54  Show Profile  Reply with Quote
@ullix,

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):
https://www.dropbox.com/s/lu8p3y0q118nujm/geigerlog_simple_500plus.rar?dl=0

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.

Thanks!
Go to Top of Page
Reply #22

ullix

Germany
346 Posts

Posted - 07/26/2018 :  01:21:51  Show Profile  Reply with Quote
@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
def getVersion():
    ser.write(b'<GETVER>>')
    srec = ser.read(14)
    return srec
print("Version: " + getVersion())


and post the printout of this segment, thanks.
Go to Top of Page
Reply #23

ikerrg

United Kingdom
291 Posts

Posted - 07/26/2018 :  01:47:40  Show Profile  Reply with Quote
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

print("Version: {}".format(getVersion()))


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?


Edited by - ikerrg on 07/26/2018 01:49:11
Go to Top of Page
Reply #24

ullix

Germany
346 Posts

Posted - 07/26/2018 :  03:29:19  Show Profile  Reply with Quote
@ikerrg: Darn, forgot to test on Py3

quote:
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:
https://sourceforge.net/projects/geigerlog/files/testing/geigerlog_simple_500plus.py/download

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)

Go to Top of Page
Reply #25

ullix

Germany
346 Posts

Posted - 07/26/2018 :  03:40:57  Show Profile  Reply with Quote
@EmfDev:

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!


Go to Top of Page
Reply #26

ikerrg

United Kingdom
291 Posts

Posted - 07/26/2018 :  04:41:46  Show Profile  Reply with Quote
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[2]) + chr(srec[3]) + chr(srec[0]) + chr(srec[1])

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

Edited by - ikerrg on 07/26/2018 05:34:07
Go to Top of Page
Reply #27

ullix

Germany
346 Posts

Posted - 07/26/2018 :  05:43:56  Show Profile  Reply with Quote
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
Go to Top of Page
Reply #28

ikerrg

United Kingdom
291 Posts

Posted - 07/26/2018 :  07:15:22  Show Profile  Reply with Quote
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!

Edited by - ikerrg on 07/26/2018 07:21:17
Go to Top of Page
Reply #29

ikerrg

United Kingdom
291 Posts

Posted - 07/26/2018 :  07:42:33  Show Profile  Reply with Quote
@ullix
Couldn't you use just Python struct as in:

import struct
value = struct.unpack('>I', srec)[0]

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.

Edited by - ikerrg on 07/26/2018 08:09:09
Go to Top of Page
Reply #30

ikerrg

United Kingdom
291 Posts

Posted - 07/26/2018 :  08:16:45  Show Profile  Reply with Quote
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:
https://www.dropbox.com/s/v2kkr05mfwdw6wt/geigerlog_simple_500plus-v0.2rc2.rar?dl=0
Go to Top of Page
Reply #31

ullix

Germany
346 Posts

Posted - 07/26/2018 :  09:06:57  Show Profile  Reply with Quote
Bummer!

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.
Go to Top of Page
Reply #32

Stargazer 40

USA
252 Posts

Posted - 07/26/2018 :  09:21:29  Show Profile  Reply with Quote
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?

Stargazer 40
Go to Top of Page
Reply #33

ikerrg

United Kingdom
291 Posts

Posted - 07/26/2018 :  09:36:38  Show Profile  Reply with Quote
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.
Go to Top of Page
  Previous Topic Topic Next Topic  
 New Topic  Reply to Topic
 Printer Friendly
Jump To:
GQ Electronics Technical Support Forum © Copyright since 2011 Go To Top Of Page
Generated in 0.25 sec. Snitz Forums 2000