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
 GQ Geiger Muller Counter
 History data format
 New Topic  Reply to Topic
 Printer Friendly
Author Previous Topic Topic Next Topic  

rimbus

8 Posts

Posted - 02/12/2017 :  08:53:19  Show Profile  Reply with Quote
By SPIR command I can read the internal ring buffer/memory of GMC-320.
But how do I interpret the data?

Which bytes, how many and in which format they code the time (only time -- or date as well?)?
Reply #1

ullix

Germany
93 Posts

Posted - 02/13/2017 :  04:47:33  Show Profile  Reply with Quote
To my knowledge, an official documentation does not exist. But Phil Gillaspy has done a commendable job creating such a documentation. As he told me, done in collaboration with ZLM.

You find it here https://sourceforge.net/projects/gqgmc/files/gqgmc/ in the GQ-GMC-ICD.odt document. I followed the description for the SPIR command and so far have not run into an error.

I uploaded a demo python script to read history data from the device and parse and write a history log file. You find it on my source site https://sourceforge.net/projects/geigerlog/files/ as geiger_SPIRparseTest.py

It is stripped down to only do this SPIR task. Create a writable subdir "data", connect the Geiger device, and run the script. It prints samples of the data and creates these files in the ./data subdirectory :
default.hist.bin : binary data as read from device
default.hist.log : the binary data in human readable hex and dec values
default.hist.log : the parsed data as log file with time stamps

Of course, it takes into account the firmware bug in reading the history from the device. Tested with "GQ GMC-300E plus" with firmware "GMC-300Re 4.20".

The default.hist.log can be used with the plot script if you eliminate the the 1st column (the index to the byte). However, I prefer to simply copy this log into a spreadsheet and go from there.

Output seems to be correct, but as the storage method is rather complicated, I appreciate feedback about success or failure!
Go to Top of Page
Reply #2

rimbus

8 Posts

Posted - 02/13/2017 :  11:25:54  Show Profile  Reply with Quote
Thanks, works fine!
I see your trick about handling bytes by Char. Does it work in general even if you define UTF-8 (in UTF-8 some characters are more than one byte long; in Python 3 there are UTF-characters only)?

How to download all 16 x 4k memory pages?
Do I start at address 0 and dump 4095+1 bytes, then go to addresses 1000H, 2000h ...F000h?
Is there a chronological order between the pages?
According to the interface document each page contains at least one date/time string.
Go to Top of Page
Reply #3

ullix

Germany
93 Posts

Posted - 02/14/2017 :  02:32:21  Show Profile  Reply with Quote
Don't even think of touching UTF-8 in context with the Geigers; that's a whole different world! (And UTF-8 can be anything from 1 to 4 and potentially up to 8 bytes long)

The chr to int conversion is lastly a workaround due to a limitation in Python2. It is different in Python3. (But I had trouble with numpy in P3, so I stayed in P2).

The SPIR command delivers a series of 8bit-bytes. All byte values from 0...255 are possible.

In P2 all you can do is to let this be assembled as a string, each element being a char with values 0...255. To calculate and plot with them you need to convert to int by ord(char).

In P3 you can define to let this be assembled as a sequence of bytes by putting a 'b' in front of the string, like b'abcd' (has no effect whatsoever when done in P2), and then handle each element as an 8bit unsigned integer.

Run this little script in P2 and P3 and see the difference:
a =  "AB\xfe"
x = b"XY\xfe"

print (a, x)

for i in a:
    print (i)
      
for i in x:
    print (i)

Yes, to read all 64k you do as you said. Note that by uncommenting line 262, and commenting out line 263, you achieve exactly that.

I surely expect the pages to be in chronological order; it would be strange otherwise. In my device only the bytes up to ~3800 are written so far. Everything beyond that up to the end of 64k comes back as 0xFF. The Python rstrip function (see line 271) nicely allows to clip off all trailing(!) 0xFF, without touching any 0xFF which might be part of the data.

Go to Top of Page
Reply #4

Distelzombie

Germany
188 Posts

Posted - 02/16/2017 :  21:27:54  Show Profile  Reply with Quote
As i was converting ullix scripts to Windows and python 3.5, i fixed the issues of reading bytes in different ways:
Try "ser = byte.decode('latin-1')" if you need string
... where ser is data from serial.Serial(port, baud) in my case.
Or "rec = int.from_bytes(rec, byteorder='big')" if you need integer
... where rec is data from <GETCPM>> command.

GMC-300E+ V4.20 with sbt-11a alpha tube

My statements are "stuff-a-hobbyist-says" and not in any way professional.

Edited by - Distelzombie on 02/16/2017 21:30:14
Go to Top of Page
Reply #5

rimbus

8 Posts

Posted - 02/19/2017 :  02:38:38  Show Profile  Reply with Quote
The last few days I was very diligent. Now there is a routine which extracts date/time tags, double byte counts bytes and strings (if present) out of the memory hex dump and transforms it to the .log format (ie date-time : counts).

In case you did not do the work for yourself: is there a place where I may upload the script?
Go to Top of Page
Reply #6

Distelzombie

Germany
188 Posts

Posted - 02/19/2017 :  10:43:31  Show Profile  Reply with Quote
Hi rimbus.
Could you do the log file output in this format?
quote:
The log file must have precisely(!) this format:
2017-02-12 15:51:52, 23
2017-02-12 15:51:57, 23
2017-02-12 15:52:17, 18
2017-02-12 15:52:22, 22

It can be plotted by ullix script then.

Because I was thinking about doing the same thing and remembered that you're working on it and I made it possible to call the script from shell with filepath argument

GMC-300E+ V4.20 with sbt-11a alpha tube

My statements are "stuff-a-hobbyist-says" and not in any way professional.

Edited by - Distelzombie on 02/19/2017 10:48:06
Go to Top of Page
Reply #7

ullix

Germany
93 Posts

Posted - 02/21/2017 :  03:51:26  Show Profile  Reply with Quote
rimbus: got your mail message, but return answer may not have come through. Yes, email contact ok.

Make sure to have checked my published "hexdump and parser" program before. You find it here as geiger_SPIRparseTest.py:

https://sourceforge.net/projects/geigerlog/files/?source=navbar
Go to Top of Page
Reply #8

rimbus

8 Posts

Posted - 02/22/2017 :  23:56:36  Show Profile  Reply with Quote
Observation:
"save history" mode "save cpm every hour" following data will be written every hour:

1) date/time tag
2) location tag
3) cpm value

Compared to other modes (cpm, cps) it repeats time and location. If only cpm value was saved the device could record hourly data for seven years...

Request:
A mode "counts per hour" instead of a mean value for cpm would give better statistics.

(In case the firmware would be updated: is there a way to write the new firmware to the device?)


Go to Top of Page
Reply #9

Distelzombie

Germany
188 Posts

Posted - 02/23/2017 :  03:55:27  Show Profile  Reply with Quote
quote:

(In case the firmware would be updated: is there a way to write the new firmware to the device?)
Yes, if you email them you'll be provided with the newest firmware and a little flasher. 4.20 seems to be the newest atm. So you must have made an an update earlier, did you not?

I guess counts per hour would pretty easily reach 65535 and therefore be of little use.

GMC-300E+ V4.20 with sbt-11a alpha tube

My statements are "stuff-a-hobbyist-says" and not in any way professional.
Go to Top of Page
Reply #10

rimbus

8 Posts

Posted - 02/24/2017 :  00:10:11  Show Profile  Reply with Quote
About the open quetions:

1) 65000/60 = 1000 cpm (100 times background -- quite heavy)
2) thanks about hint for newest firmware. So 4.2 seems to be fine.
3) Parser: I sent Ullix my CLI Python script for parsing the recorded data by GMC (he has his own version as well). I have no idea where to publish elsewhere. And it would be better to have only one branch.
Go to Top of Page
Reply #11

Distelzombie

Germany
188 Posts

Posted - 02/24/2017 :  04:53:57  Show Profile  Reply with Quote
1. Yeah, OK. Depends where you live I guess and what tube you have installed. Background for me and my tube is i. E. 35 with spikes to 68. That makes it only about 30 times background. Imagine someone has a SBT-10, which I'm laying eyes on. Get two of them and you'll probably reach it. xD (There are cases for that)
3. I'm trying to make him include my version of his scripts too. He's not much online.

GMC-300E+ V4.20 with sbt-11a alpha tube

My statements are "stuff-a-hobbyist-says" and not in any way professional.
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.09 sec. Snitz Forums 2000