| T O P I C R E V I E W |
| 7007hp4573 |
Posted - 09/19/2019 : 16:34:28
Hello. I am currently writing some C code to change configuration values on a GMC-300e plus revision 4.22 for a project. I have managed to read the configuration memory and even change some of the values with expected results, things like the backlight timeout, speaker on and off, alarm on and off.. they all work correctly. What I can't seem to work out is the alarm uSv value. While it does appear to be a little endian float almost identical to that on x86, it differs somehow. For instance on x86, the float value 0.0 is represented as 00 00 00 00 in hex, however the same value in the counters configuration appears as 00 00 C8 34. On x86 0.1 appears to be CD CC CC 3D, on the counter it appears as FF CC CC 3D. I've tried to find more information on this, even looking through source code of other projects but I can't seem to find anything about it. Any information would be greatly appreciated. Thank you.
Update: After some searching I realised it could also be a fixed point number, something I wasn't aware of until just now. I'll try interpreting the values using a fixed point library and report back with how that goes. |
| 11 L A T E S T R E P L I E S (Newest First) |
| 7007hp4573 |
Posted - 09/23/2019 : 14:00:16
quote:
Originally posted by EmfDev
7007hp4573, have you fixed the floating point issue? We'll check the 300E code. Not sure if that was intended.
I have, thank you. It turns out I was reading from the wrong address, I was changing the value in the counters menu then reading a hex dump of the configuration and must have read the wrong line. After double checking everything I've managed to read and change all of the floating point values.
It seems the LED issue isn't quite what I thought either, when the alarm is set to CPM the LED turns red when above the limit, however I've just double checked, when the alarm is set to uSv the LED doesn't seem to blink red when above the limit, it blinks green as normal. Is this it's intended functionality or a limitation/bug? It doesn't affect the use of the counter obviously, I was simply curious. |
| EmfDev |
Posted - 09/23/2019 : 09:57:08
7007hp4573, have you fixed the floating point issue? We'll check the 300E code. Not sure if that was intended. |
| 7007hp4573 |
Posted - 09/23/2019 : 03:09:45
Well now I feel stupid xD
Turns out not only was I reading the wrong address in the hex dump of the configuration, even if I had read the right address the bytes do differ very slightly anyway so I'd have thought something was wrong just looking at it in hex.
Oh well, at least it's working now. 
Thanks again for your help 
Edit: hope I'm not imagining this too but the led indicator on my GMC-300e rev 4.22 seems to have a bug also, it's following the wrong alarm value, it turns red based on CPM when the alarm is set to uSv and vice versa. Just thought I'd add that in case anyone at GQ wants to fix that in future firmwares (if not already). |
| 7007hp4573 |
Posted - 09/23/2019 : 00:37:37
quote:
Originally posted by ullix
The SPIR data are coded Big Endian in all counters, as far as I can tell.
All the config data that I had touched are coded little endian in all 3xx series counters, and big endian in all 500/600.
I doubt that within the config data the endianess has changed, but with GQ one never knows :-)
The calibration data are read out from the counters by GeigerLog, and shown as "extended info", so you have some reference.
By the way, this read-out calibration is not used within GL; it does not make sense. For a discussion of the calibration issues see among discussion in this forum the GeigerLog manual.
But I suggest to demonstrate using an easy task that you can read dfata out and perhaps write them back. The calibration values would be an easy task and proof correct programming.
Python's very helpful documentation on struct is here:
https://docs.python.org/3/library/struct.html
Oops, you're right, I was thinking of the SPIR data and command arguments, not the configuration xD
I'm about to try reading the calibration values, I'll compare that with GeigerLogs output and see if they match up. I'll leave the alarm threshold until I've got that working
Edit: I can interpret the calibration uSv value just fine, 0.39 is 0.39002 on PC but close enough xD
So I'm almost certain now that the alarm threshold is a fixed point number, could anyone from GQ confirm this? It just makes a lot of sense, the earliest models of counter maybe lacked a floating point unit. Did the earliest models support calibration by the way? If they didn't then it makes even more sense, if they did then maybe it uses fixed point for the alarm threshold to save on CPU power? |
| ullix |
Posted - 09/22/2019 : 23:43:45
The SPIR data are coded Big Endian in all counters, as far as I can tell.
All the config data that I had touched are coded little endian in all 3xx series counters, and big endian in all 500/600.
I doubt that within the config data the endianess has changed, but with GQ one never knows :-)
The calibration data are read out from the counters by GeigerLog, and shown as "extended info", so you have some reference.
By the way, this read-out calibration is not used within GL; it does not make sense. For a discussion of the calibration issues see among discussion in this forum the GeigerLog manual.
But I suggest to demonstrate using an easy task that you can read dfata out and perhaps write them back. The calibration values would be an easy task and proof correct programming.
Python's very helpful documentation on struct is here:
https://docs.python.org/3/library/struct.html
|
| 7007hp4573 |
Posted - 09/22/2019 : 03:45:36
quote:
Originally posted by ullix
did you notice that for the interpretation of the configuration GQ had switched from little-endian in the 300 series to big-endian in the 500/600 series?
In the function getCFG() search for "endian" and understand the struct.unpack() Python commands.
P.S. is setting the alarm level really worth your while? The first thing I do is to switch it off via GeigerLog ;-)
Ah, thanks for the heads up about the endian change, hadn't noticed that. I'll admit I'm not too familiar with python, I don't fully understand python structs but I assume the idea is similar to using a union or a pointer to convert the bytes to a float in C. I have also asked a friend who is more familiar with python to have a look at the source code in case I misunderstood.
By the way, are you sure it's only the 500 and 600 that are big endian? I have a 300e plus revision 4.22 and most of its values appear to be big endian as well, oddly the floating point numbers, or at least the alarm threshold is little endian, that or FF CC CC 3D on the counter and CD CC CC 3D on x86 both meaning 0.1 is a coincidence. Either way GeigerLog works with my 300e so it must be using the correct endianness for it.
And yes I do see your point, the only time I use the alarm is when I have the counter on standby in the event something triggers it, however the project I'm working on is a library and command line tool to change the counters configuration, I was hoping to add support for as many of the configuration values as possible for situations like having the counter connected to a raspberry pi with remote access. I suppose I could just calculate an equivalent CPM, but ideally that would mean reading the calibration values which are also floating point xD
I'll keep trying to find a way to interpret the bytes for now, I'm thinking that the alarm uSv threshold might be a fixed point number with it going up in set increments, it doesn't need the decimal to move around and it avoids the need for an FPU. If it is fixed point I'm just hoping it's a standard of some kind that I can find a library for.
I need to take a closer look at the GeigerLog source code again too, it lets you set the calibration values, right? Perhaps trying to read those float values first might help me work out if the alarm threshold is in fact a float or not.
Thanks for your help by the way |
| ullix |
Posted - 09/22/2019 : 01:59:25
did you notice that for the interpretation of the configuration GQ had switched from little-endian in the 300 series to big-endian in the 500/600 series?
In the function getCFG() search for "endian" and understand the struct.unpack() Python commands.
P.S. is setting the alarm level really worth your while? The first thing I do is to switch it off via GeigerLog ;-)
|
| 7007hp4573 |
Posted - 09/21/2019 : 10:09:02
quote:
Originally posted by ullix
Hi, my program GeigerLog has so far been correct in its interpretation of the GMC counters outputs. If you know a bit of Python, you are likely to find the answer in the sourcecode, gcommands.py would be the one to review.
Download from here: https://sourceforge.net/projects/geigerlog/
Hi, thanks for the reply. Yes I'm aware of GeigerLog, it's definitely one of the most complete programs for the GMC Geiger counters in terms of functionality, in fact it's the only program I'm aware for GMC counters that runs on Linux apart from some smaller python scripts. So thanks for creating such a great program!
I've already been referring to its source code to understand things like the SPIR length issue and some counters only supporting 2048 byte reads. However it seems like GeigerLog doesn't support changing the alarm threshold values? It does mention a save mode "save every second/minute if exceeding threshold", I assume this refers either to the alarm threshold or SaveThresholdValue0-3 in the config memory, but I can't seem to find anything about setting floating point values in the source code, or at least not to set the alarm uSv threshold.
The issue I'm having in particular is interpreting the alarm uSv value that's currently set in the configuration, simply reading the 4 bytes in the correct order and attempting to cast them to a float results in seemingly random values like infinity, NaN, and random numbers. Which is when I compared numbers like 0.0 and 0.1 on x86 and the counter itself. The value 0.1 set as the alarm threshold results in a different set of bytes in the configuration to what a regular C float would result in, and I can't seem to work out what the problem is.
I've tried interpreting it backwards, forwards.. all giving garbled values. Right now my only ideas are to either try interpreting it as a fixed point number (which would make sense with increments of 0.1 for the alarm threshold), and if that fails, make a lookup table of the byte values the counter uses for different numbers.
Is it possible that the CPU/microcontroller in the counter has an incompatible FPU or does floating point in software using a different standard to x86? Sorry if I'm missing something obvious here. |
| ullix |
Posted - 09/21/2019 : 08:27:01
Hi, my program GeigerLog has so far been correct in its interpretation of the GMC counters outputs. If you know a bit of Python, you are likely to find the answer in the sourcecode, gcommands.py would be the one to review.
Download from here: https://sourceforge.net/projects/geigerlog/
|
| 7007hp4573 |
Posted - 09/21/2019 : 05:23:25
quote:
Originally posted by EmfDev
Hi 7007hp4573, the floating point number is coded as a union with 4 bytes. the bytes are then saved to the configuration as byte3, then byte2, byte1, byte0.
Hi, thanks for the reply. Ah so it is a float and not a fixed point number? I did think it was written to the config that way, byte 3, 2, 1 and 0. I just can't seem to interpret or set the value correctly.
When I set the alarm uSv to 0.1 using the counters menu, bytes 3-0 are FF CC CC 3D, whereas on a PC the same value of 0.1 is represented by CD CC CC 3D. Is there any way I can convert between the Geiger counters floating point format and an x86/PC float? |
| EmfDev |
Posted - 09/20/2019 : 10:11:09
Hi 7007hp4573, the floating point number is coded as a union with 4 bytes. the bytes are then saved to the configuration as byte3, then byte2, byte1, byte0. |
|
|
