| Author |
 Topic  |
|
|
David Rice
USA
7 Posts |
 Posted - 03/12/2021 : 08:12:01
|
My device refuses to log data. The configuration is identical to another GMC-300Re 4.54 that logs data correctly. My USB connection to my device is working properly, as I can use USB to read and write to the device. The device logs a long stream of 255 (no data), and that data I can download. This tells me the device is logging data every minute, but the data are only a few control characters, and 255s.
How is it possible that the device is not recording the actual data?
Model and version: GMC-300Re 4.54
Model serial number: f488c473018563
Device temperature: +0.0
Battery voltage: 4.200000
Device date 12/Apr/21 time 16:00:17
PowerOnOff: 0
AlarmOnOff: 1
SpeakerOnOff: 1
GraphicModeOnOff: 2
BacklightTimeoutSeconds: 31
IdleTitleDisplayMode: 0
AlarmCPMValueHigh: 0
AlarmCPMValueLow: 100
IdleDisplayMode: 1
AlarmType: 0
Save Data Type: 1 (Once a minute)
DataSaveAddress-0: 255
DataSaveAddress-1: 255
DataSaveAddress-2: 255
PowerSavingMode: 0
SensitivityMode: 1
CounterDelayHigh: 0
CounterDelatLow: 120
VoltageOffset: 25
MaxCPMHigh: 255
MaxCPMLow: 255
SensitivityAutoModeThreshold: 60
|
|
| Reply #1
David Rice
USA
7 Posts |
Posted - 03/12/2021 : 11:58:44
|
| "Factory reset" did not work. |
 |
|
| Reply #2
EmfDev
2250 Posts |
Posted - 03/12/2021 : 12:24:30
|
| Hi David Rice, does the every second saving time work? Does the config get saved when turning off/on the device? |
|
|
| Reply #3
damotclese
USA
4 Posts |
Posted - 03/12/2021 : 12:27:03
|
Here is what your data looks like. What I don't recognize is the header field type of 001. From my documentation, the header for CPM data is 002 however your data contains 001, and your following data counts are either 000, 001, or 002 which is wrong since you're showing 29 or so CPMs on your display:
085 170
000 timestamp 021 003 011 023 030 011
085 170
001
085 170
000 timestamp 021 003 011 023 030 011
085 170
001
085 170
000 timestapm 021 003 011 023 030 022
085 170
001 000 000 000 000 001 001 001 001 000 000 001 000
000 000 000 001 000 000 000 000 000 001 000 002 000 000 001 000
000 001 000 001 000 000 000 000 000 001 000 001 000 000 000 000
002 002 000 001 000 001 000 001 000 001 000 000 001 000 000 001
001 000 000 000 000 000 001 000 001 000 000 001 001 000 000 000
000 001 000 000 000 000 000 000 001 001 000 000 000 000 000 002
000 000 000 000 000 002 000 000 001 000 002 000 000 001 001 000
000 000 000 001 000 000 001 001 000 000 001 000 000 001 001 000
000 001 000 000 000 000 001 000 001 000 000 000 000 000 000 000
000 000 000 000 000 000 000 000 000 000 001 000 000 000 000 001
000 001 000 001 001 000 003 001 000 000 000 000 001 001 000 001
000 001 000 000 001 000 000 000
085 170
000 timestamp 021 003 011 023 033 032
085 170
001 001 000 000 002 000 000 000 000 000 001 000 002
001 000 000 000 001 000 001 000 000 000 000 001 000 001 001 000
000 001 000 000 000 000 000 000 000 000 000 000 003 000 000 000
001 000 000 000 000 000 001 000 000 000 000 000 001 000 000 000
000 000 000 000 000 000 002 000 000 001 000 000 000 000 000 001
000 000 000 001 001 000 000 001 000 000 000 000 001 000 001 000
000 001 001 000 000 001 000 000 001 000 000 000 000 000 000 000
002 000 000 000 001 000 002 000 000 001 000 001 000 000 001 001
000 000 000 001 000 000 001 001 000 000 001 000 000 000 001 000
000 000 000 000 000 001 000 000 001 002 002 001 000 001 000 000
000 000 000 000 000 000 000 000 001 000 000 001 001 000 000 002
000 000 002 001 000 002 000 000
085 170
000 timestamp 021 003 011 023 036 033
085 170
001 002 000 001 000 001 000 000 000 000 000 000 001
000 001 000 000 000 002 000 000 001 000 000 002 000 001 000 000
000 000 000 001 000 000 001 000 000 000 000 000 000 000 001 000
000 001 000 001 000 000 000 000 000 001 000 000 000 000 000 001
000 001 000 000 000 000 001 000 000 002 001 001 002 000 000 000
000 000 001 001 000 001 000 001 000 000 002 000 002 000 001 002
001 002 000 001 000 000 000 000 000 000 001 000 000 000 000 000
000 000 000 000 000 000 002 000 000 000 001 000 000 001 001 000
000 000 000 000 000 000 000 000 000 001 001 000 001 001 000 001
000 000 000 001 000 000 001 000 000 000 000 000 000 000 001 000
000 002 000 000 000 000 001 000 000 000 001 000 000 001 001 000
000 000 000 002 001 000 001 000
085 170
|
|
|
| Reply #4
damotclese
USA
4 Posts |
Posted - 03/12/2021 : 12:41:47
|
The 001 following your 0x55 0xAA header means "0x01 - CPS is double byte" so somewhere maybe in the configuration there is a way to make CPM a single digit so that it records type "002 - Location data"
Hopefully someone here will be able to answer your question. This TEXT data here should help someone who knows what's going on explain what configuration needs to be changed so that you start recording CPM in single-digit counts.
|
|
|
| Reply #5
damotclese
USA
4 Posts |
Posted - 03/12/2021 : 12:46:16
|
quote:
Originally posted by EmfDev
Hi David Rice, does the every second saving time work? Does the config get saved when turning off/on the device?
He emailed to me his ROM data in ASCII text which I have looked at and posted some of below. The header value of 001 means that CPM is 2 bytes, I believe that he needs to configure his device so that CPM is one byte and the field value is 002. I don't know how to do that.
|
|
|
| Reply #6
damotclese
USA
4 Posts |
Posted - 03/12/2021 : 12:50:06
|
Here is what mine looks like. The data field header value is 002 which is "location data" in the documentation. Your value is 001 which means "CPM is two bytes"
085 170
000 timestamp 021 002 011 000 050 059
085 170
002 location data
020 024 020 022 018 023
085 170
000 timestamp 021 002 011 000 057 013
085 170
002 location data
085 170
000 timestamp 021 002 011 000 059 023
085 170
002 location data
085 170
000 timestamp 021 002 011 000 059 028
085 170
002 location data
015 019 015 022 025 023 019 018 019 017
018 020 023 018 016 015 019 028 020 019 012 015 022 021 024 024
019 017 018 020 015 015 015 017 023 017 022 020 010
|
|
|
| Reply #7
David Rice
USA
7 Posts |
Posted - 03/12/2021 : 14:51:27
|
quote:
Originally posted by EmfDev
Hi David Rice, does the every second saving time work? Does the config get saved when turning off/on the device?
Greetings. Those are good questions. No, setting data save to seconds does not cause the device to save data. Argh! Yes, the configuration is being saved when the power is cycled. I suspect the device is faulty. I received the device six days ago, and I have yet to see it record data. How very odd.
|
|
|
| Reply #8
David Rice
USA
7 Posts |
Posted - 03/12/2021 : 14:57:26
|
quote:
Originally posted by damotclese
The 001 following your 0x55 0xAA header means "0x01 - CPS is double byte" so somewhere maybe in the configuration there is a way to make CPM a single digit so that it records type "002 - Location data"
Hopefully someone here will be able to answer your question. This TEXT data here should help someone who knows what's going on explain what configuration needs to be changed so that you start recording CPM in single-digit counts.
Greetings. I have not seen any option for "Location data." On the digital screen there is a namespace for writing a note under "Note/Location" as I assume the device does not record Latitude/Longitude.
When I look at the "History" option I see the control codes you mentioned, and long strings of 000 and 255. This suggests to me that the device is saving a record every seconds (as configured), but not writing that data (CPM) at all. |
|
|
| Reply #9
David Rice
USA
7 Posts |
Posted - 03/12/2021 : 15:02:37
|
quote:
Originally posted by damotclese
Here is what mine looks like. The data field header value is 002 which is "location data" in the documentation. Your value is 001 which means "CPM is two bytes"
085 170
000 timestamp 021 002 011 000 050 059
085 170
002 location data
020 024 020 022 018 023
085 170
000 timestamp 021 002 011 000 057 013
085 170
002 location data
085 170
000 timestamp 021 002 011 000 059 023
085 170
002 location data
085 170
000 timestamp 021 002 011 000 059 028
085 170
002 location data
015 019 015 022 025 023 019 018 019 017
018 020 023 018 016 015 019 028 020 019 012 015 022 021 024 024
019 017 018 020 015 015 015 017 023 017 022 020 010
I see that your location data are not your location. I wonder why the CPM data are called that.
I will try erasing all data. |
|
|
| Reply #10
Damien68
France
780 Posts |
Posted - 03/13/2021 : 00:25:18
|
quote:
Originally posted by damotclese
Here is what mine looks like. The data field header value is 002 which is "location data" in the documentation. Your value is 001 which means "CPM is two bytes"
085 170
000 timestamp 021 002 011 000 050 059
085 170
002 location data
020 024 020 022 018 023
085 170
000 timestamp 021 002 011 000 057 013
085 170
002 location data
085 170
000 timestamp 021 002 011 000 059 023
085 170
002 location data
085 170
000 timestamp 021 002 011 000 059 028
085 170
002 location data
015 019 015 022 025 023 019 018 019 017
018 020 023 018 016 015 019 028 020 019 012 015 022 021 024 024
019 017 018 020 015 015 015 017 023 017 022 020 010
framing have not updated documentation and subject to interpretation.
ullix made a presentation in his GeigerLog manual in Appendix E - GMC Device: Internal Memory, Storage Format and Parsing Strategy. It's interesting you can read it.
the protocol is quite particular, let's say that I will not have done it like that, the idea is to compress the data.
based on my observations here is how it works at least on my 500+ but it looks similar
timestamp bloc (085 170 000 year Month day Hours minutes seconds):
085 170 000 021 002 011 000 050 059
Data Block just after timestamp bloc specifying if you are in CPS or CPM mode
Data Bloc (085 170 mode):
085 170 002
if mode = 1 it's CPS
if mode = 2 it's CPM
after this header there is CPS or CPM data on 1 bytes format.
if you have CPS or CPM value over 255, the data will then be coded on 2 or 3 or 4 bytes.
in this case before each data coded other than on 1 bytes you have to have one of the following sequence
085 170 001 before each 16 bits coded value
085 170 003 before each 24 bits coded value
085 170 004 before each 32 bits coded value
--------------------------------------------------
so the right interpretation is the following:
--------------------------------------------------
timestamp
085 170 000 021 002 011 000 050 059
Data bloc (CPM mode)
085 170 002
Data values
020 024 020 022 018 023
timestamp
085 170 000 021 002 011 000 057 013
Data bloc (CPM mode)
085 170 002
timestamp
085 170 000 021 002 011 000 059 023
Data bloc (CPM mode)
085 170 002
timestamp
085 170 000 021 002 011 000 059 028
Data bloc (CPM mode)
085 170 002
Data values
015 019 015 022 025 023 019 018 019 017
018 020 023 018 016 015 019 028 020 019 012 015 022 021 024 024
019 017 018 020 015 015 015 017 023 017 022 020 010
so there is a confusion on the interpretation of the header 085 170 002, according to the documentation it is the localization, in the implementation not at all.
this needs to be checked but that's about how it works.
The frame 085 170 001 can have 2 different meanings depending on where it is placed:
- data bloc in CPS mode
- data coded on 2 bytes.
this is what is subject to interpretation:
what I call the 'Data block Header' (085 170 001 or 085 170 002) systematically follows a block of timestamps. it should perhaps be seen as a suffix to the timestamp and not as a separate element.
and not sure of how it work if there are many consecutives values coded on 16 24 or 32 bits. is there a control block for each value? or only once? how back to 8bits values?
All is my interpretation.
don't forget that a recording can be truncated at the end, if for example the counter loses its power while writing in flash.
The recording can also be truncated at the beginning because the data is recorded in a loop and erased by blocks. also at the start of the history reading, we can start to read a frame whose beginning has been cut |
Mastery is acquired by studying, with it everything becomes simple |
Edited by - Damien68 on 03/13/2021 04:11:31 |
|
|
| Reply #11
ullix
Germany
1171 Posts |
Posted - 03/13/2021 : 01:50:30
|
The storage format in a GQ counter is complex and ambiguous at times. GQ's description is limited. I believe I have given the best description which exists in the GeigerLog manual, see chapter "Appendix E – GMC Device: Internal Memory,
Storage Format and Parsing Strategy"
So far it comes out correct for every GQ device, even after firmware bugs. Since you do seem to have unexpected problems, I suggest to try it out. If it shows a failure, I hope this can be fixed in GeigerLog.
After downloading data from a GQ counter with GeigerLog you have the option in the History menu to "Show History Data with Parse Comments". This tells you how GeigerLog interpreted the binary data coming from the counter. Here an example:
# Index, DateTime, CPM, CPS, CPM1st, CPS1st, CPM2nd, CPS2nd, ParseInfo
# 35, 2021-03-08 09:45:39, Date&Time Stamp; Type:'CPS, save every second', Interval:1 sec
34, 2021-03-08 09:45:40, 11.0, 2.0, , , , , ---single digit---CPS, save every second
47, 2021-03-08 09:45:40, 11.0, 0.0, , , , , ---single digit---CPS, save every second
48, 2021-03-08 09:45:41, 11.0, 0.0, , , , , ---single digit---CPS, save every second
49, 2021-03-08 09:45:42, 13.0, 2.0, , , , , ---single digit---CPS, save every second
50, 2021-03-08 09:45:43, 13.0, 0.0, , , , , ---single digit---CPS, save every second
# 51, 2021-03-08 09:45:43, Date&Time Stamp; Type:'CPM, save every minute', Interval:60 sec
63, 2021-03-08 09:45:43, 58.0, , , , , , ---single digit---CPM, save every minute
64, 2021-03-08 09:46:43, 50.0, , , , , , ---single digit---CPM, save every minute
You can also look at binary data and more.
|
|
|
| Reply #12
David Rice
USA
7 Posts |
Posted - 03/13/2021 : 11:00:48
|
It appears that my device failed to record a byte at the beginning of the data stream--- I thought a cheksum would have caught that. As it is, that one byte shift rendered all subsequent records as "no data." I do not know how it did this. I cleared all data and now the device is recording properly. Goodness!
Thank you, people, for helping me look at the data. |
|
|
| |
Topic |
|
|
|
It all works fine except recording data
