| Author |
 Topic  |
|
|
Erwin55
Germany
41 Posts |
 Posted - 05/17/2022 : 09:45:19
|
Dear All,
I'am downloading the history of GMC300E+ directly in octave/matlab, parseing it there and it works fine. A simple thing what is not clear for me is the double byte handling. Phil Gillaspy writes in his document, "External Interface Control Document" (Thank you for it):
1. The double byte data sample string is [55][AA][01][DH][DL] where 55AA is start of sequence marker, 01 is the enumeration code that two byte data follows ...
2. The sample, some lines below, shows "something like 55AA02a355AA027555AA01b8" and no enumerator.
Also the following examples are showing only "[55][AA][DH][DL]". Hence, do I have to care about the numerator or not or when? I can't test it in reality and to be honest, I don't want to do it (private use of the GMC only).
Thanx for the enlightenment in advance
Erwin
|
|
| Reply #1
ullix
Germany
1107 Posts |
Posted - 05/17/2022 : 21:11:03
|
You'll find a lot more on this stuff in the GeigerLog manual, and in the GeigerLog code. For the latter I suggest to look for the "geigerlog-simple*" versions of the Python code.
https://sourceforge.net/projects/geigerlog/
look under "Files". |
 |
|
| Reply #2
Erwin55
Germany
41 Posts |
Posted - 05/18/2022 : 01:29:10
|
Thanx Ullix, the link was very helpful, especially the appendix E of the manual. But my problem when I have to care about [55][AA][01][DH][DL] and wenn I have to care about [55][AA][DH][DL] was not solved. As you mentioned in your text there is a lack of information which can only be closed by GQ and I wonder why they don't do it.
Maybe this part of the firmware was programmed 15 years ago, the programmer has left the company many years ago and nobody knows exactly what he was thinking when programming (naughty said). |
|
|
| Reply #3
ullix
Germany
1107 Posts |
Posted - 05/18/2022 : 22:32:32
|
Welcome to the rude world of GMC counter firmware ;-)
If you want to dig deeper, look into parsing in file gdev_gmc_hist.py of GeigerLog. Be aware that the firmware may not only be counter model dependent, but also version dependent, and going back to old status in between versions.
No documentation beyond what is in code and its comments.
So far it seems that I have correctly captured all versions, as bugs have not been found. Be the first to report one!
|
|
|
| Reply #4
Erwin55
Germany
41 Posts |
Posted - 05/19/2022 : 05:28:21
|
With Geigerlog you have done a great job. The one or other item I will pick up and implement it in my matlab scripts. But my main question was not solved. I'am now going in an other direction. I downloading the whole data stream and replace all wellknown markers with my own markers (eg. EEDD01 instead of 55AA01, CPM/M). The remaining 55AA or 55AA01 (?) must be double byte and as mentioned above, I hopfully will never see them (home use only).
A question by the way do you (or anyone else in this forum) have a dataset (.bin file) with (more or less many) double bytes in it, from a real radioactive probe? I would appreciat it, if passing this or a link to it onto this forum. |
|
|
| Reply #5
ullix
Germany
1107 Posts |
|
| Reply #6
Erwin55
Germany
41 Posts |
Posted - 05/21/2022 : 22:36:08
|
| It took some time to inspect the files. I only found one file with double byte, 20181225_17_56_41-London-to-Madrid (LHR-_MAD).bin. But at least one. So, as I assumed, the double byte was found only in the form [55][AA][DH][DL]. I altered my scripts accordingly. Thanx again. |
|
|
| |
Topic |
|
GMC 300E+ Double Byte Handling
