| T O P I C R E V I E W |
| rimbus |
Posted - 02/12/2017 : 08:53:19
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?)? |
| 11 L A T E S T R E P L I E S (Newest First) |
| Distelzombie |
Posted - 02/24/2017 : 04:53:57
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. |
| rimbus |
Posted - 02/24/2017 : 00:10:11
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. |
| Distelzombie |
Posted - 02/23/2017 : 03:55:27
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. |
| rimbus |
Posted - 02/22/2017 : 23:56:36
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?)
|
| ullix |
Posted - 02/21/2017 : 03:51:26
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 |
| Distelzombie |
Posted - 02/19/2017 : 10:43:31
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 |
| rimbus |
Posted - 02/19/2017 : 02:38:38
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?
|
| Distelzombie |
Posted - 02/16/2017 : 21:27:54
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. |
| ullix |
Posted - 02/14/2017 : 02:32:21
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.
|
| rimbus |
Posted - 02/13/2017 : 11:25:54
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. |
| ullix |
Posted - 02/13/2017 : 04:47:33
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!
|
