| T O P I C R E V I E W |
| Kaban |
Posted - 03/23/2018 : 02:49:45
Hello.
I bought a GQ GMC-600 plus and downloaded the geigerlog.
I could connect it but with a different baud rate and com port than the default ones. Also the CPM calibration number should be changed.
So i tried to change the geigerlog.cfg, but without success.
If i just open the file with the notepad, change some data and save it again, the DEBUG says that the configuration file exists but could not be read.
Even if i open it with the notepad, and withot changing a single comma i press ctrl-s and save it again, it does not work.
I guess i am doing something wrong, i am not an expert with computers.
Thanks.
David. |
| 51 L A T E S T R E P L I E S (Newest First) |
| EmfDev |
Posted - 05/23/2018 : 08:45:27
Hopefully it's bug free :D but if you find any or others complain about bugs then we'll try to address them.
You have to email support@gqelectronicsllc.com for available firmware updates. |
| ullix |
Posted - 05/23/2018 : 00:02:46
 Some cooperative work between Germany, Switzerland and US!
And "fixed" means we are now getting firmware updates? How?
With that bug fixed, GeigerLog is running bug-free on the 500s! |
| EmfDev |
Posted - 05/22/2018 : 11:17:40
Alright after a lot of debugging, we finally found the problem.
The problem came from sending the command for the address 0x000A.
On address 0x000A, the data byte is 62 which in hex is 0x3E which is also the same as the command terminator '>' (terminator is >>) in ascii
so the 0x0A address command is...
<WCFG[00][0A][3E]>> which in hex is 3C 57 43 46 47 00 0A 3E 3E 3E
The command was cut off(being executed) at the 2nd 3E.
So the last 3E is now the first byte on the next command <WCFG[00][0B][C7]>>
so the command looks like ><WCFG[00][0B][C7]>> from the buffer.
So the processor can't find keyword "WCFG" after the second byte (now starts with '<'). That's why it looks like it didn't get the 0x00B command. But actually it received the command but it didn't process. And that's why sending it again instantly works.
Sorry for the trouble. Now it's fixed.
Edit: Only some of them. One particular is the WCFG. |
| ullix |
Posted - 05/22/2018 : 06:02:58
quote:
Have you tried delaying after 10th byte instead of 9? or if it timeouts for 3ms then resend the command instantly. Or even delaying for 1ms after you got an 0xAA reply.
I don't think it makes sense to hope for a different outcome, but just to please the question:
Sleeping after writing byte #10 for: 1 sec
2018-05-22 14:57:36 VERBOSE: WriteConfig: i==A0= 11(0x00B), cfgval==D0=199(0xC7)
2018-05-22 14:57:36 VERBOSE: serialCOMM: sendtxt: 'b'<WCFG\x00\x0b\xc7>>'', returnlength: 1, caller: '('gcommands.py', 'writeConfigData', 673)'
2018-05-22 14:57:39 VERBOSE: serialCOMM: got 0 bytes, first (up to ten) bytes: b''
2018-05-22 14:57:39 VERBOSE: getExtraByte: No extra bytes waiting for reading
2018-05-22 14:57:39 VERBOSE: serialCOMM: Timing (ms): write: 0.11, read:3003.2, read per byte:3003.2, extraread: 0.9
2018-05-22 14:57:39 DEBUG : serialCOMM: TIMEOUT ERROR: Serial Port Timeout of 3.0s exceeded.- rtime:3003.2ms
2018-05-22 14:57:39 DEBUG : serialCOMM: Failure with command b'<WCFG\x00\x0b\xc7>>'
2018-05-22 14:57:39 DEBUG : serialCOMM: ERROR: Received length: 0 is less than requested: 1
2018-05-22 14:57:39 DEBUG : serialCOMM: rec: (len=0):
2018-05-22 14:57:39 DEBUG : serialCOMM: RETRY: to get full return record, trial #1
2018-05-22 14:57:39 VERBOSE: getExtraByte: No extra bytes waiting for reading
2018-05-22 14:57:40 DEBUG : Timing (ms): Retry read: 0.1
2018-05-22 14:57:40 DEBUG : serialCOMM: RETRY: returnlength is 1 bytes. OK now. Continuing normal cycle, rec:b'\xaa'
2018-05-22 14:57:40 VERBOSE: getExtraByte: No extra bytes waiting for reading
Sleeping right before the bad byte gives the same outcome; at this position only and nowhere else. Four repeats with identical behaviour. The 500 has a bug.
To clarify: My timeout times are in second, like 3 second for read-timeout, or 3000 millisec. The timing measurements are in milliseconds. |
| ullix |
Posted - 05/22/2018 : 01:32:44
quote:
The commands always sends either 0xAA(for success) or 0x55(if fail) IF the unit actually got the command. Always sends a reply for that specific command whether it is a success or fail. If you didnt get anything in reply then probably means the CPU didn't get the command.
Well, since when and for what devices is that so? Your PR states that GQ-RFC1201 is still valid for 600+ device, and there is clearly no mentioning of 0x55 anywhere! In fact, some commands are stated to give no response at all (key, PowerOn/OFF, Reboot) no 0xAA, no 0x55, and that is what I see, i.e. nothing.
How can I distinguish between the CPU not giving an answer, and the CPU not even hearing the command? I never see a write-timeout, so it is like throwing commands into a black hole.
What responses does the firmware give to a write command from the computer that let's me decide on success or failure? Are there any of the serial port flags used for anything?
|
| EmfDev |
Posted - 05/21/2018 : 09:26:40
The firmware code is the same if you write 1 byte. after you write the next byte, it's going to the same code all over again. So the fact that the first 9 works means that that part of code has nothing wrong because the same part code is being executed all over again. So one problem could be that the CPU didn't catch the command because it was busy doing something.
However, the fact that it's always at the 10th byte makes it weird. But i'll double check the code to make sure I didn't miss anything.
Have you tried delaying after 10th byte instead of 9? or if it timeouts for 3ms then resend the command instantly. Or even delaying for 1ms after you got an 0xAA reply.
Edit:
The commands always sends either 0xAA(for success) or 0x55(if fail) IF the unit actually got the command. Always sends a reply for that specific command whether it is a success or fail. If you didnt get anything in reply then probably means the CPU didn't get the command.
|
| ullix |
Posted - 05/19/2018 : 07:42:38
Tried a delay- no change.
Sleeping after writing byte #9 for: 1 sec
2018-05-19 15:01:57 VERBOSE: WriteConfig: i==A0= 10(0x00A), cfgval==D0= 62(0x3E)
2018-05-19 15:01:57 VERBOSE: serialCOMM: sendtxt: 'b'<WCFG\x00\n>>>'', returnlength: 1
2018-05-19 15:01:57 VERBOSE: serialCOMM: got 1 bytes, first (up to ten) bytes: b'\xaa'
2018-05-19 15:01:57 VERBOSE: getExtraByte: No extra bytes waiting for reading
2018-05-19 15:01:57 DEBUG : Timing (ms): write: 0.07, read: 3.0, read per byte: 3.0, extraread: 0.8
2018-05-19 15:01:57 VERBOSE: WriteConfig: i==A0= 11(0x00B), cfgval==D0=199(0xC7)
2018-05-19 15:01:57 VERBOSE: serialCOMM: sendtxt: 'b'<WCFG\x00\x0b\xc7>>'', returnlength: 1
2018-05-19 15:02:00 VERBOSE: serialCOMM: got 0 bytes, first (up to ten) bytes: b''
2018-05-19 15:02:00 VERBOSE: getExtraByte: No extra bytes waiting for reading
2018-05-19 15:02:00 DEBUG : Timing (ms): write: 0.07, read:3003.2, read per byte:3003.2, extraread: 1.0
2018-05-19 15:02:00 DEBUG : TIMEOUT ERROR: Serial Port Timeout of 3.0s exceeded.- rtime:3003.2ms
2018-05-19 15:02:00 DEBUG : Failure with command b'<WCFG\x00\x0b\xc7>>'
2018-05-19 15:02:00 DEBUG : serialCOMM: ERROR: Received length: 0 is less than requested: 1
2018-05-19 15:02:00 DEBUG : serialCOMM: RETRY: to get full return record, trial #1
2018-05-19 15:02:01 VERBOSE: getExtraByte: No extra bytes waiting for reading
2018-05-19 15:02:01 DEBUG : Timing (ms): Retry read: 0.1
2018-05-19 15:02:01 DEBUG : serialCOMM: RETRY: returnlength is 1 bytes. OK now. Continuing normal cycle, rec:b'\xaa'
2018-05-19 15:02:01 VERBOSE: getExtraByte: No extra bytes waiting for reading
A 1sec sleep every 10 bytes of writing the config. Segment shows after writing config byte #9, a 1 sec sleep. Byte #10 was read in 3ms, Byte #11 timed out at >3000ms. Repeating results in a byte read of 0.1ms
The whole thing repeated 6 times; in these 6 runs always timeout at #11, and never elsewhere.
Time for you to check the firmware code!
|
| EmfDev |
Posted - 05/18/2018 : 09:36:10
So that means after the 10th byte will always give a timeout?
Then maybe try to put a delay every 10commands because the CPU might be busy when sending commands continuously. |
| ullix |
Posted - 05/18/2018 : 03:00:17
Well, regarding bugs, all models I've looked at, 300E, 320. 500 are somewhat unreliable in their responses, sometimes timing out at commands as simple as getVER, getCPM. These timeouts seem to occur at random.
The 500, not the 3xx series, has an additional bug. When writing the individual bytes of the config, there is ALWAYS, no exception in dozens of runs, a timeout at byte #11 (0x00B) (Port timeout 3sec):
WriteConfig:...i==A0= 11(0x00B), cfgval==D0=199(0xC7)
serialCOMM:....sendtxt: 'b'<WCFG\x00\x0b\xc7>>'', returnlength: 1
getExtraByte:..No extra bytes waiting for reading
Timing (ms):...write: 0.04, read:3003.2
serialCOMM:....ERROR: Received length: 0 is less than requested: 1
serialCOMM:....RETRY: to get full return record, trial #1
getExtraByte:..No extra bytes waiting for reading
serialCOMM:....RETRY: returnlength is 1 bytes. OK now. Continuing normal cycle, rec:b'\xaa'
getExtraByte:..No extra bytes waiting for reading
Resending the #11 command, so the identical command, always gave immediately the proper answer within milliseconds.
There may be additional timeouts, but they vary in frequency and byte no. But the n0 #11 timeout is always there. |
| EmfDev |
Posted - 05/17/2018 : 12:13:24
It looks like there's indeed a firmware bug that sends the "0071\r\n" before 0xAA for the 1.08 revision. And you can ask support for the update.
Thanks for noticing these bugs anyway. |
| EmfDev |
Posted - 05/17/2018 : 11:54:28
quote:
Originally posted by ullix
After the unit was set correctly, it will rather quickly - a few days - be some 100sec off. However, after some repeat experimentation. the unit might be at the exact time. The mis-setting is not always, every now and then it works flawlessly. So trying with gmc dv might or might ot give relevant info.
because the GMC data viewer sends exactly the same command.
I just tried it on a new 500+ and only got 0xAA.
You can write email to support@gqelectronicsllc.com to check if your firmware need to be updated. |
| ullix |
Posted - 05/17/2018 : 11:13:08
quote:
Can you please try to reboot(and reconnect) the unit, then try to restart your software and make sure the pipeline is clean maybe clear it before sending update. They try to send only the CFGUPDATE command after restart and nothing else to verify if the return is still 7 bytes.
So, here is the answer (from the log):
getVER: len:14, rec:"b'GMC-500Re 1.08'"
getExtraByte: No extra bytes waiting for reading
serialCOMM: sendtxt: 'b'<CFGUPDATE>>'', returnlength: 1
serialCOMM: got 1 bytes, first (up to ten) bytes: b'0'
getExtraByte: Bytes waiting: 5
getExtraByte: Got 6 extra bytes from reading-pipeline:[48, 55, 49, 13, 10, 170]
getExtraByte: Extra bytes as ASCII: '071...'
getExtraByte: No extra bytes waiting for reading
updateConfig: rec: b'0071\r\n\xaa', rec + extra: b'0071\r\n\xaa'
The unit was rebooted, switched off/ON, reconnected, and GeigerLog started. Then the port is opened and
- getver is read; correct answer: GMC-500Re 1.08
- no bytes in the pipeline
- no other commands, not ECFG, and not a single WCFG, given, just CFGUPDATE
- again, 1 + 6 bytes are read
- again they are: b'0071\r\n\xaa', i.e., with spaces inserted, b' 0 0 7 1 \r \n \xaa ' (7 bytes)
Hmmm? Did you 500 have the same Revision?
|
| ullix |
Posted - 05/17/2018 : 11:02:30
After the unit was set correctly, it will rather quickly - a few days - be some 100sec off. However, after some repeat experimentation. the unit might be at the exact time. The mis-setting is not always, every now and then it works flawlessly. So trying with gmc dv might or might ot give relevant info. |
| EmfDev |
Posted - 05/17/2018 : 09:57:14
when you try to set date and time, does the unit have the correct time or not?
Can you try setting the date and time of the unit using the GMC data viewer if they have the same result? (meaning the unit will have 2023 as year after the sync date and time command from the gmc data viewer). |
| ullix |
Posted - 05/17/2018 : 00:02:06
quote:
From your script, it's missing 2 parameters why might have caused the error.
Maybe try putting 6 param.
No, there is nothing wrong with my command; there are 6 bytes.
The native Python3 way of printing byte sequences is a bit awkward. It becomes clear when I insert spaces to separate each byte:
b'\x12\x05\x0c\x013.' --> b'\x12 \x05 \x0c \x01 3 .'
in decimal..........................18.......5....12.....1.51..46
The '3' has ASCII code 51decimal and the '.' ASCII 46, and that is what I wanted to send and did send.
We'll try the other stuff later. |
| EmfDev |
Posted - 05/16/2018 : 09:40:29
Can you please try to reboot(and reconnect) the unit, then try to restart your software and make sure the pipeline is clean maybe clear it before sending update. They try to send only the CFGUPDATE command after restart and nothing else to verify if the return is still 7 bytes.
setDATETIME: now: [2018, 5, 12, 1, 51, 46] , coded: b'\x12\x05\x0c\x013.'
Based from the protocol, the command must take 6 parameters which are
YY - year
MM - month
DD - Day
HH - hr
MM - minute
SS - second
From your script, it's missing 2 parameters why might have caused the error.
Maybe try putting 6 param.
|
| ullix |
Posted - 05/16/2018 : 00:36:27
Here is what we got in several runs with the 500, consistently with the same outcome, while 300E and 320 always yielded the expected single byte 0xAA only:
Device is 'GMC-500Re 1.08'
WriteConfig: i==A0=269(0x10D), cfgval==D0= 34(0x22)
....serialCOMM: sendtxt: 'b'<WCFG\x01\r">>'', returnlength: 1, caller: '('gcommands.py', 'writeConfigData', 658)'
....getExtraByte: No extra bytes waiting for reading
WriteConfig: Update Config
....serialCOMM: sendtxt: 'b'<CFGUPDATE>>'', returnlength: 1, caller: '('gcommands.py', 'updateConfig', 679)'
....getExtraByte: Bytes waiting: 5
....getExtraByte: Got 6 extra bytes from reading-pipeline:[48, 55, 49, 13, 10, 170]
....getExtraByte: Extra bytes as ASCII: '071...'
....getExtraByte: No extra bytes waiting for reading
....updateConfig: rec: b'0071\r\n\xaa', rec + extra: b'0071\r\n\xaa'
First 3 lines is sending the last non-FF byte to the config (byte 0x22 @ addr 0x10D). getExtraByte confirms that there are no bytes waiting in the read pipeline.
Then I send <CFGUPDATE>>, and in addition to the expected 1 byte, I get 6 bytes more. In total [48] [48, 55, 49, 13, 10, 170], or b'0071\r\n\xaa'. So the 0xAA bytes comes, but only after the other 6 bytes.
Regarding the date setting, here is a often seen sequence:
getDATETIME: 2018-05-12 00:51:51
setDATETIME:
..setDATETIME: now: [2018, 5, 12, 1, 51, 46] , coded: b'\x12\x05\x0c\x013.'
..serialCOMM: sendtxt: 'b'<SETDATETIME\x12\x05\x0c\x013.>>'', returnlength: '1'
......getExtraByte: No extra bytes waiting for reading
......serialCOMM: ERROR: Received length: 0 is less than requested: 1
......serialCOMM: rec: (len=0):
......serialCOMM: RETRY: to get full return record, trial # 1
......serialCOMM: RETRY: returnlength is 1 bytes. OK now. Continuing normal cycle
getDATETIME:
..serialCOMM: sendtxt: 'b'<GETDATETIME>>'', returnlength: '7', caller: '('gcommands.py', 'getDATETIME', 772)'
..getExtraByte: No extra bytes waiting for reading
..serialCOMM: ERROR: Received length: 1 is less than requested: 7
..serialCOMM: rec: (len=1): AA
..serialCOMM: RETRY: to get full return record, trial # 1
..serialCOMM: RETRY: returnlength is 7 bytes. OK now. Continuing normal cycle
..getDATETIME: raw: b'\x17\x02\x0c\x013.\xaa' , len: 7
..getDATETIME: 2023-02-12 01:51:46
First line is a readout from the counter (~1h off)
Then comes the setting, which times out (3 sec) and is ok immediately after retry.
The readout also times out, is also immediately ok after a retry, and returns the year 2023
Longer timeouts don't help; I see an answer between 5 and 500ms or none at all.
|
| EmfDev |
Posted - 05/15/2018 : 09:29:34
or please try to manually set the year from the device and see if it works. |
| EmfDev |
Posted - 05/15/2018 : 09:13:28
I just tried CFGUPDATE on a 500+ and it only returned 0xAA. Can i ask what bytes you received with this command?
And the SetDateTime should also behave the same way as the 300 series. |
| ullix |
Posted - 05/12/2018 : 05:57:00
@EmfDev: could you please explain how the CFGUPDATE cmd has changed with the 500 series? It is now returning multiple bytes instead of 1, and what do these bytes mean?
Also, the SetDateTime on the 500 is behaving strangely, insisting on the year being 2023. What has changed there? |
| ullix |
Posted - 05/07/2018 : 22:31:37
That is helping, Thanks |
| EmfDev |
Posted - 05/07/2018 : 08:15:42
The signature is written on the software correctly in 300/500/600 series but the problem came from the versions 300 and 320 where the GETVER returns fixed 7-bytes model name and 7-bytes revision name which is wrong.
On the 500 and 600 series, the return can be any length.
So far its only 14 bytes or 15 bytes. But it should return any given model name completely so the length is variable.
And the '+' sign is included in the model name. e.g. GMC500+Re 1.10
But I don't think the 300 or 320 has been updated so maybe you can ask support for the fix. |
| ullix |
Posted - 05/05/2018 : 00:26:29
What I am looking for is the signature delivered by GETVER.
In the new models is the GETVER string still 14 characters or longer? If longer, is there a new fixed limit or can it have any length?
As the 500 without plus clearly has 14 chars only, what length have the 500+ and 600+? And where within the string will I find the '+' sign? Your manual on the 600+ shows only outdated information on the 320 or 500 (no plus) at best.
|
| EmfDev |
Posted - 05/04/2018 : 13:06:58
I'm so sorry it seems like there's a software bug on the 300 and 320. But it is now fixed.
Your device model is GMC-300E+V4 for both. The V4 comes from the Re "4".20 the 4 is the version of the model. All the V4 of the
GMC300 is called GMC-300E+ so yours is GMC-300E+V4.
Your 320 model is also V4 so it is the GMC-320V4.
For 500 and 600 models. GETVER should return with "+" or without "+". so your 500 is the one with one tube.
|
| ullix |
Posted - 05/04/2018 : 12:37:25
That is not what I have seen; would you mind double-checking this statement?
I have data from 4 different devices, and all came out the same: the GETVER response wasalways 14 bytes, nothing extra, definitely NOT longer than 14 bytes! And all stuck to your comments in your previous comment. So, what I have are these responses:
model 300E+..: 'GMC-300Re 4.20'
model 300E+..: 'GMC-300Re 4.22'
model 320+...: 'GMC-320Re 4.19'
model 500....: 'GMC-500Re 1.00'
model 500....: 'GMC-500Re 1.08'
This looks pretty consistent, and that would be great. Hope this isn't a fluke and some recent modifications to the firmware have changed this.
Still, makes me wonder: what is your procedure to detect the model? By the way, in your 500 manual you are also showing 'GMC-500Re 1.00'.
|
| EmfDev |
Posted - 05/03/2018 : 10:16:47
Actually, I also got this wrong, but GETVER should return the full model version and the firmware revision.
Using GETVER on your 300 4.22 should return GMC-300E+V4Re 4.22. Response actually is not fixed to 14 bytes as said
from the GQ RFC1201 protocol. |
| ullix |
Posted - 05/02/2018 : 23:44:09
Well, if it is not possible to deduce model numbers from the GETVER response, how else can you distinguish the different products?
You must succeed with that in your software as well; how are you doing it? Are you using a table of serial numbers; do they fall into certain categories which are unique? |
| EmfDev |
Posted - 05/02/2018 : 10:14:31
Yes. There's a difference in hardware.
So far.
300..........Re 3.xx (no more)
300E+V4......Re 4.xx
320+V4.......Re 4.xx
320+V5.......Re 5.xx
500/+........Re 1.xx
600/+........Re 1.xx
With this, it is not possible to translate firmware revision to model. But GQ stopped releasing GMC300 long ago. |
| ullix |
Posted - 05/02/2018 : 07:18:02
Sigh. I guess it was a hardware issue with the 300 hardware having only 256 bytes?
So now the question is how I can tell apart all those devices. The model names, like '300E+' are not seen in the GETVER response, only something like 'GMC-300' and 'Re 4.22', though before the repair (I guess it was a replacement) I had the same model, but reporting 'Re 4.20'.
Is there a list that translates Firmware version into model?
Can I rely on the firmware response always being 'Re x.yz' ?
So far I have:
300.....Re 3.??
300E+...Re 4.20 or 4.22
320.....Re 4.19
500.....Re 1.00
600.....????
|
| EmfDev |
Posted - 05/01/2018 : 09:56:54
I don't think that's a good idea. Because the default value is 0xFF after a successful erase, when writing to the chip, and if it didn't process the write (or it failed for some reason), we would not be able to detect it. Reading that address then will be 'true'/0xFF but actually it might be wrong/invalid.
The GMC-320 V5 has different config. SSID starts at address 69 (0x45h)
EEPROM_nSaveThresholdMode,
EEPROM_nSaveThresholdValue3,
EEPROM_nSaveThresholdValue2,
EEPROM_nSaveThresholdValue1,
EEPROM_nSaveThresholdValue0,
EEPROM_SSID_0,
EEPROM_SSID_1, //70
EEPROM_SSID_2,
EEPROM_SSID_3,
EEPROM_SSID_4,
EEPROM_SSID_5,
EEPROM_SSID_6,
EEPROM_SSID_7,
EEPROM_SSID_8,
EEPROM_SSID_9,
EEPROM_SSID_10,
EEPROM_SSID_11, //80
EEPROM_SSID_12,
EEPROM_SSID_13,
EEPROM_SSID_14,
EEPROM_SSID_15,
EEPROM_Password_0,
EEPROM_Password_1,
EEPROM_Password_2,
EEPROM_Password_3,
EEPROM_Password_4,
EEPROM_Password_5, //90
EEPROM_Password_6,
EEPROM_Password_7,
EEPROM_Password_8,
EEPROM_Password_9,
EEPROM_Password_10,
EEPROM_Password_11,
EEPROM_Password_12,
EEPROM_Password_13,
EEPROM_Password_14,
EEPROM_Password_15, //100
EEPROM_Website_0,
EEPROM_Website_1,
EEPROM_Website_2,
EEPROM_Website_3,
EPROM_Website_4,
EEPROM_Website_5,
EEPROM_Website_6,
EEPROM_Website_7,
EEPROM_Website_8,
EEPROM_Website_9, //110
EEPROM_Website_10,
EEPROM_Website_11,
EEPROM_Website_12,
EEPROM_Website_13,
EEPROM_Website_14,
EEPROM_Website_15,
EEPROM_Website_16,
EEPROM_Website_17,
EEPROM_Website_18,
EEPROM_Website_19, //120
EEPROM_Website_20,
EEPROM_Website_21,
EEPROM_Website_22,
EEPROM_Website_23,
EEPROM_Website_24,
EEPROM_URL_0,
EEPROM_URL_1,
EEPROM_URL_2,
EEPROM_URL_3,
EEPROM_URL_4, //130
EEPROM_URL_5,
EEPROM_URL_6,
EEPROM_URL_7,
EEPROM_URL_8,
EEPROM_URL_9,
EEPROM_URL_10,
EEPROM_URL_11,
EEPROM_UserID_0,
EEPROM_UserID_1,
EEPROM_UserID_2, //140
EEPROM_UserID_3,
EEPROM_UserID_4,
EEPROM_UserID_5,
EEPROM_UserID_6,
EEPROM_UserID_7,
EEPROM_UserID_8,
EEPROM_UserID_9,
EEPROM_UserID_10,
EEPROM_UserID_11,
EEPROM_CounterID_0, //150
EEPROM_CounterID_1,
EEPROM_CounterID_2,
EEPROM_CounterID_3,
EEPROM_CounterID_4,
EEPROM_CounterID_5,
EEPROM_CounterID_6,
EEPROM_CounterID_7,
EEPROM_CounterID_8,
EEPROM_CounterID_9,
EEPROM_CounterID_10, //160
EEPROM_CounterID_11,
EEPROM_Period,
EEPROM_WIFIONOFF,
//this one uses 6 byte space and always keep it at last
EEPROM_Save_DateTimeStamp, //this one uses 6 byte space and always keep it at last
EEPROM_MaximumBytes
|
| ullix |
Posted - 05/01/2018 : 09:12:23
Yes, that's how I did it. Except that I excluded all right-most 0xFF from this lengthy process. Can I rely on all empty values - like after erasing the config - being FF is true also in the future?
One last question (I hope ): the 320+ V5 appears to need a config of 512 bytes to support its WiFi. Is it otherwise to be treated as an 320 or as an 500? Otherwise like big-endian, SPIR, Volt, Baudrate, ...
|
| EmfDev |
Posted - 04/30/2018 : 10:13:12
@ullix
The <ECFG>> and <CFGUPDATE>> still work.
But the <WCFG[A0][D0]>> is now <WCFG[Hi][Lo][Ch]>>
So instead of 2, there are 3 params.
Hi - High byte
Lo - Low byte
Ch - Byte to write
3c 57 43 46 47 00 02 01 3e 3e example for writing 1 to the speaker.
I think you already know that you can't change a byte from 0x00 to 0x01 but you can change it from 0x01
to 0x00
So one way users can change config is to:
1. <GETCFG>> copy each byte of the config
2. <ECFG>> erase config from the device
3. Edit the config you got from 1 like you can change speaker from 1 to 0 or 0 to 1
4. <WCFG[0x00 - 0x01][0x00 - 0xFF][valid 8bits]>> starting from position 0 to the end of config
5. <CFGUPDATE>> |
| ullix |
Posted - 04/28/2018 : 00:27:41
@EmfDev: I am stumbling over another problem, if you could please help:
In your GQ-RFC1201 doc from 2015 I find these commands realted to updating the config:
8. Erase all configuration data
Command: <ECFG>>
Return: 0xAA
Firmware supported: GMC-280, GMC-300 Re.2.10 or later
9. Write configuration data
Command: <WCFG[A0][D0]>>
A0 is the address and the D0 is the data byte(hex).
Return: 0xAA
Firmware supported: GMC-280, GMC-300 Re.2.10 or later
13. Reload/Update/Refresh Configuration
Command: <CFGUPDATE>>
Return: 0xAA
Firmware supported: GMC-280, GMC-300 Re.2.20 or later
This can't work anymore, since the new config is now 512 bytes long while the A0 in WCFG is a byte and thus limited to 256. What is the new command?
Are the other commands of erasing and updating unchanged? |
| ullix |
Posted - 04/27/2018 : 20:45:29
Thanks, again. |
| EmfDev |
Posted - 04/27/2018 : 12:04:57
@ullix
quote:
The logic for Power is really reversed to that used for Alarm and Speaker (where 0 means OFF and 1 means ON)?
That's correct and is intended.
quote:
The 500 manual is rather "restraint", just saying: "The GM-500 built-in intelligent algorithm always select one of the most adequate sensors to measure the target, so that to guarantee the accuracy of the measurement."
Hmmm.
How does it do that? Apparently there is no switch in hard- or software that the user must press? What is the user seeing in terms of CPM and in terms of µSv/h? There has to be a break somewhere in at least one of the measurement units? Does the counter flicker between different numbers at the switching point of the tubes?
Looking at the sensitivity of the two tubes, one is at 0.0065, the other at 0.39. The ratio is 60 , so the 2nd tube is 60 times LESS sensitive. Yet the counter's upper limit goes up only 10fold, not 60fold. Why?
That information can't be disclosed to the public. But they are all intended and suppose to work correctly.
quote:
The specs in the manual state an upper limit of 42500 µSv/h (it actually says Sv/h - I guess the 'µ' is missing? ok, only off by a factor of 1 million).
Yes it is supposed to have µ, this needs to be updated.
quote:
The occupational safety limit in Germany limits the exposure to 20mSv PER YEAR. Your upper limit would reach this yearly limit in less than half an hour! The worker's lifetime radiation dosage, like for Japan's Fukushima workers, was set to 1,000 millisieverts in line with recommendations made by the International Commission on Radiological Protection. That limit would be reached in less than a day.
What are you trying to achieve, eradicate your customers by encouraging them to go to lethal radioactive sites with a GMC-500+ in their hands???
The 500 (without plus) counter has an upper limit of 4250 µ(?)Sv/h. At this limit you reach your YEARLY limit within less than 5 hours, and your lifetime dose in less than 10 days.
It doesn't encourage costumers expose themselves to high radiation sites. You're like saying selling knives and guns encourage people to kill another.
Why would people buy more expensive phones if they don't even need to? and don't even use all their functions?
Some consumers feel more satisfied when they get a version of a product with more capabilities. The 500/+ can be used properly to reach the upper limits.
quote:
@ZLM or @EmfDev: please, be so kind to recheck your list in Reply #9, some things don't add up:
* the first SSID byte is overlapping with the last SaveThresold byte
* if the URL postition is right, then the website would have only 31 bytes, not 32
* in the last bytes there is either 1 byte missing, or one is a double byte
The numbers in the comments are indeed incorrect. But when saving/reading the config, the enumeration names were used so none of them overlaps.
With correction:
CFG_nSaveThresholdValue3, //65
CFG_nSaveThresholdValue2,
CFG_nSaveThresholdValue1,
CFG_nSaveThresholdValue0,
CFG_SSID_0, // 69
//...
CFG_SSID_31 = CFG_SSID_0 + 31, //69 + 31
CFG_Password_0, //101
//...
CFG_Password_31 = CFG_Password_0 + 31, //101 + 31
CFG_Website_0, //133
//....
CFG_Website_31 = CFG_Website_0 + 31, //133 + 31
CFG_URL_0, //165
//....
CFG_URL_31 = CFG_URL_0 + 31, //165 + 31
CFG_UserID_0, //197
//...........
CFG_UserID_31 = CFG_UserID_0 + 31, //197+31
CFG_CounterID_0, //229
//....
CFG_CounterID_31 = CFG_CounterID_0 + 31, //229 + 31
CFG_Period, //261
CFG_WIFIONOFF, //262
CFG_TEXT_STATUS_MODE,
/
CFG_Save_DateTimeStamp, //this one uses 6 byte space
CFG_MaximumCFGBytes,
quote:
What is the CFG_TEXT_STATUS_MODE used for?
CFG_TEXT_STATUS_MODE is for displaying the "normal/medium/high" text in the large font mode.
0 - "Off" - not displayed
1 - "On" - black text and white background
2 - "Inverted" - White text and black background |
| ullix |
Posted - 04/27/2018 : 08:32:58
@ZLM or @EmfDev: please, be so kind to recheck your list in Reply #9, some things don't add up:
* the first SSID byte is overlapping with the last SaveThresold byte
* if the URL postition is right, then the website would have only 31 bytes, not 32
* in the last bytes there is either 1 byte missing, or one is a double byte
What is the CFG_TEXT_STATUS_MODE used for?
Thanks |
| ullix |
Posted - 04/27/2018 : 06:31:42
Thank you very much; this is really helpful. Just to be sure: quote:
-PowerOnOff byte: 0 for ON, and 1 for OFF
The logic for Power is really reversed to that used for Alarm and Speaker (where 0 means OFF and 1 means ON)?
The calibration issue remains fuzzy to me, and though it has little programming relevance, it is of general interest to me and perhaps others. Can you help?
The 500 manual is rather "restraint", just saying: "The GM-500 built-in intelligent algorithm always select one of the most adequate sensors to measure the target, so that to guarantee the accuracy of the measurement."
Hmmm.
How does it do that? Apparently there is no switch in hard- or software that the user must press? What is the user seeing in terms of CPM and in terms of µSv/h? There has to be a break somewhere in at least one of the measurement units? Does the counter flicker between different numbers at the switching point of the tubes?
Looking at the sensitivity of the two tubes, one is at 0.0065, the other at 0.39. The ratio is 60 , so the 2nd tube is 60 times LESS sensitive. Yet the counter's upper limit goes up only 10fold, not 60fold. Why?
The specs in the manual state an upper limit of 42500 µSv/h (it actually says Sv/h - I guess the 'µ' is missing? ok, only off by a factor of 1 million).
The occupational safety limit in Germany limits the exposure to 20mSv PER YEAR. Your upper limit would reach this yearly limit in less than half an hour! The worker's lifetime radiation dosage, like for Japan's Fukushima workers, was set to 1,000 millisieverts in line with recommendations made by the International Commission on Radiological Protection. That limit would be reached in less than a day.
What are you trying to achieve, eradicate your customers by encouraging them to go to lethal radioactive sites with a GMC-500+ in their hands???
The 500 (without plus) counter has an upper limit of 4250 µ(?)Sv/h. At this limit you reach your YEARLY limit within less than 5 hours, and your lifetime dose in less than 10 days.
That is not enough for people buying your counters?
Did I make an error in my calcs?
|
| EmfDev |
Posted - 04/26/2018 : 10:29:49
@ullix
- You are correct, the system is now in big-endian.
- The Calibration Point 3: 25 CPM = 9.75 µSv/h (0.39000 µSv/h / CPM) is for 500+ 2nd tube. So it is different from the 500 and 300.
- The baudrate config is now
baudrate = 115200 # config setting: 0
baudrate = 1200 # config setting: 1
baudrate = 2400 # config setting: 2
baudrate = 4800 # config setting: 3
baudrate = 9600 # config setting: 4
baudrate = 14400 # config setting: 5
baudrate = 19200 # config setting: 6
baudrate = 28800 # config setting: 7
baudrate = 38400 # config setting: 8
baudrate = 57600 # config setting: 9
so default value for #57 is 0
-PowerOnOff byte: 0 for ON, and 1 for OFF
- The GETVOLT returns a string and GETTEMP has been removed (might be included on future models) although you can still get some output using GETTEMP. |
| ZLM |
Posted - 04/26/2018 : 10:19:28
@ullix, thanks for the information.
If you need more information, you can write email to support@gqelectronicsllc.com
EmfDev will answer your questions.
|
| ullix |
Posted - 04/26/2018 : 03:19:40
@ZLM: thanks for the effort. Though your information is partially wrong and partially incomplete.
Let's start with the calibration bytes. You state they are identical in 500 and 600 to the 300 series. Not true. The order of the bytes has been reversed, or in computer parlance, you have gone from little-endian to big-endian. I think it was quite an achievement on my part to figure this out based on 4 binary bytes ;-)
It was further complicated by the fact that the results didn't make sense. But that was due to grossly nonsensical firmware setting of the calibration, resulting in this output for GMC-500:
Device setting:
Calibration Point 1: 60 CPM = 0.39 µSv/h (0.00650 µSv/h / CPM)
Calibration Point 2: 10000 CPM = 65.00 µSv/h (0.00650 µSv/h / CPM)
Calibration Point 3: 25 CPM = 9.75 µSv/h (0.39000 µSv/h / CPM)
Not sure if this has been fixed? If someone wonders about very strange µSv readings - maybe this is the cause.
The baudrate config setting is now defined differently. Before it had been these complex settings:
baudrate = 1200 # config setting: 64
baudrate = 2400 # config setting: 160
baudrate = 4800 # config setting: 208
baudrate = 9600 # config setting: 232
baudrate = 14400 # config setting: 240
baudrate = 19200 # config setting: 244
baudrate = 28800 # config setting: 248
baudrate = 38400 # config setting: 250
baudrate = 57600 # config setting: 252
baudrate = 115200 # config setting: 254
At the baudrate position #57 I now read out 0 (zero) instread of 254. Is the coding now different, if so what is it? Or is 115200 the only allowed baudrate adn there is no other coding at all?
The PowerOnOff byte had been 0 for ON and 255 for OFF. Now it appears to be reversed and changed to 0 for OFF and 1 for ON. True?
Your advertisement even for the 600 still refers to the GQ-RFC1201 document from 2015 as being your "open GQ RFC1201 communication protocol". Again, only partially true. E.g. your voltage readout on the 300 is 1 byte; it is now 5 bytes and needs completely different interpretation; likewise, the temperature has to be evaluated differently between 300 and 500/600, and it is not fully clear what it is.
So, with that brief list already showing many things different from what you claim they are, how can I possibly know what differences are in the other settings, which I haven't touched yet?
It does not look like GeigerLog is doing any harm to your business - perhaps the opposite - and since you are claiming "open" protocol, why not provide the whole picture? If you can't do that, get me in contact with someone in your shop who can. You do have my contact info.
|
| ullix |
Posted - 04/25/2018 : 22:08:06
thanks, ZLM |
| ZLM |
Posted - 04/25/2018 : 12:58:59
For GMC-500, GMC-600 history data C code structure:
(this should be same as GMC-300, no change)
In history data, it start with 0x55AA00 prefixed for timestamp and followed by the date time data. and then always followed by 0x55AA and one of the bellow data length byte.
typedef enum
{
YYMMDDHHMMSS, // Time Stamp
DOUBLEBYTE_DATA, //the data are double bytes
THREEBYTE_DATA, //the data are three bytes
FOURBYTE_DATA, //the data are four bytes
LOCATION_DATA, //the data is a text string,the first byte data is the length of the text, followed by the text
TOTAL_EEPROM_SAVE_TYPE
}HistoryDataFormatMarkingT;
Also, the 0x55AA also can follow a one of following history data type:
typedef enum
{
SAVEOFF,
SECONDLY,
MINUTETLY,
HOURLY,
SaveByThresholdSecond, //only save the data if exceed the preset threshold value
SaveByThresholdMinute, //only save the data if exceed the preset threshold value
TotalSavedType
}SaveDataTypeT;
|
| ZLM |
Posted - 04/25/2018 : 12:45:07
The GMC-500 and GMC-600 still accept configuration commands same as GMC-320, no change.
But GMC-500 and GMC-600 extended (added new) commands for new features.
Here is the latest configuration data structure in C code on GMC-500 and GMC-600:
typedef enum {
CFG_PowerOnOff,
CFG_AlarmOnOff, //1
CFG_SpeakerOnOff,
CFG_IdleDisplayMode,
CFG_BackLightTimeoutSeconds,
CFG_IdleTitleDisplayMode,
CFG_AlarmCPMValueHiByte, //6
CFG_AlarmCPMValueLoByte,
CFG_CalibrationCPMHiByte_0,
CFG_CalibrationCPMLoByte_0,
CFG_CalibrationuSvUcByte3_0,
CFG_CalibrationuSvUcByte2_0, //11
CFG_CalibrationuSvUcByte1_0,
CFG_CalibrationuSvUcByte0_0,
CFG_CalibrationCPMHiByte_1,
CFG_CalibrationCPMLoByte_1, //15
CFG_CalibrationuSvUcByte3_1,
CFG_CalibrationuSvUcByte2_1,
CFG_CalibrationuSvUcByte1_1,
CFG_CalibrationuSvUcByte0_1,
CFG_CalibrationCPMHiByte_2, //20
CFG_CalibrationCPMLoByte_2,
CFG_CalibrationuSvUcByte3_2,
CFG_CalibrationuSvUcByte2_2,
CFG_CalibrationuSvUcByte1_2,
CFG_CalibrationuSvUcByte0_2, //25
CFG_IdleTextState,
CFG_AlarmValueuSvByte3,
CFG_AlarmValueuSvByte2,
CFG_AlarmValueuSvByte1,
CFG_AlarmValueuSvByte0, //30
CFG_AlarmType,
CFG_SaveDataType,
CFG_SwivelDisplay,
CFG_ZoomByte3,
CFG_ZoomByte2, //35
CFG_ZoomByte1,
CFG_ZoomByte0,
CFG_SPI_DataSaveAddress2,
CFG_SPI_DataSaveAddress1,
CFG_SPI_DataSaveAddress0, //40
CFG_SPI_DataReadAddress2,
CFG_SPI_DataReadAddress1,
CFG_SPI_DataReadAddress0,
CFG_nPowerSavingMode,
Reserved_1, //45
Reserved_2,
Reserved_3,
CFG_nDisplayContrast,
CFG_MAX_CPM_HIBYTE,
CFG_MAX_CPM_LOBYTE, //50
Reserved_4,
CFG_nLargeFontMode,
CFG_nLCDBackLightLevel,
CFG_nReverseDisplayMode,
CFG_nMotionDetect, //55
CFG_bBatteryType,
CFG_nBaudRate,
Reserved_5,
CFG_nGraphicDrawingMode,
CFG_nLEDOnOff, //60
Reserved_6,
CFG_nSaveThresholdValueuSv_m_nCPM_HIBYTE,
CFG_nSaveThresholdValueuSv_m_nCPM_LOBYTE,
CFG_nSaveThresholdMode,
CFG_nSaveThresholdValue3, //65
CFG_nSaveThresholdValue2,
CFG_nSaveThresholdValue1,
CFG_nSaveThresholdValue0,
CFG_SSID_0,
//...
CFG_SSID_31 = CFG_SSID_0 + 31, //68 + 31
CFG_Password_0, //100
//...
CFG_Password_31 = CFG_Password_0 + 31, //100 + 31
CFG_Website_0, //132
//....
CFG_Website_31 = CFG_Website_0 + 31, //132 + 31
CFG_URL_0, //163
//....
CFG_URL_31 = CFG_URL_0 + 31, //163 + 31
CFG_UserID_0, //195
//...........
CFG_UserID_31 = CFG_UserID_0 + 31, //195+31
CFG_CounterID_0, //227
//....
CFG_CounterID_31 = CFG_CounterID_0 + 31, //227 + 31
CFG_Period, //259
CFG_WIFIONOFF, //260
CFG_TEXT_STATUS_MODE,
/
CFG_Save_DateTimeStamp, //this one uses 6 byte space
CFG_MaximumCFGBytes,
}EEPROMDATAT;
|
| EmfDev |
Posted - 04/25/2018 : 12:36:13
Just tested the protocol commands using the latest GQ GMC Data Viewer (the protocols are located on the terminal window under settings) and you can verify they still work on GMC-500 and GMC-600 (like the GETCPM, alarm and speaker). |
| ullix |
Posted - 04/16/2018 : 06:15:52
I had hoped for GQ providing the missing infos so that all geigers can be supported, but that does not seem to happen. So in the next version I will grey out the menu items, that aren't supported. Indeed, they are only in Device menu.
While the missing items may not so relevant, I find it annoying having to use the to fumble though their menus to e.g. change the saving mode.
|
| Kaban |
Posted - 04/15/2018 : 14:28:02
Hello again.
I have been using the software and the counter for a while now.
As i said in my previous message, everything works pretty well except the items under the tab device. It only lets my use connect and disconnect; but, alarm, speaker and the other items do not work. Not really important anyway.
Otherwise, the software works pretty well!
David.
|
| ullix |
Posted - 04/07/2018 : 08:32:44
@Kaban: Good to hear it is working for a 600 with the 500 setting! Now that you had it for a few days, has anything changed? What is not working besides the Device Info stuff?
@Distelzombie: ok, ok, ok, you'll get your configurable colors and linewidths in the next version, promised ;-))
But now that I feel convinved-by-arm-twisting to fulfill custom wishes, what else is really needed or even only wanted? What is missing in the features? What do you want to do, that currently is impossible? Let's do a complete job.
In my mind this is the full support of the 500 and 600 series (although, I personally will not buy anything beyond a 300e Series!).
This is hampered by the lack of info from GQ. They have made some undisclosed changes to the firmware, though continue saying they have not. They did; which is why the 500 and 600 device settings are messed up.
The latest website says even for the latest 600 series: "GQ GMC-600 Plus provides open GQ RFC1201 communication protocol for easier system integration." Followed by a link to the document "GQ-RFC1201, GQ Geiger Counter Communication Protocol, Ver 1.40, Jan-2015".
That protocol is fully implemented in GeigerLog, and it is NOT working correctly for 500 or 600! While this is called an open protocol, it has actually become a closed protocol.
Let's ask directly:
@ZLM: I am sure you are fully aware of the changes in the communication protocol, and that system integration, as promised, is impossible. If your and/or GQ's goal is still to make integration possible, when can you publish the proper documentation for the coding of the 500 and 600 counters? If you can't, can I get a copy for my use and implementation in GeigerLog? If not, is GQ's policy in that regard different from what you state on your web page?
Hope we get a positive answer.
|
| Distelzombie |
Posted - 04/01/2018 : 15:55:50
Forget WordPad. Download Notepad++ and forget almost all other ware. It's so good with all things except writing letters and documents. So basically just random files and color coding code from codefiles with code in them. :D
It's small and if you download it I'll get paid. (jk)
Ullix can probably tell you the exact row in a certain file you have to change in an instant. He's a good programmer. (Except for his lack of options-menu-implementation-philosophy xD)
****. I didn't write anything of use. Just have to send it fast, so that nobody notices it... |
| Kaban |
Posted - 03/24/2018 : 15:29:44
Hello again.
Using the WordPad for editing solved most problems.
Now it does connect automatically as i changed the configuration file to 115200 baud and COM4.
Regarding the calibration, i just wanted to change the default CPM * 0.0065 and i set it to 0,002637 as GQ is using that number in my device.I know that number maybe not correct anyway, but i am using it for the time being. I managed to edit it with WordPad.
The unit connects now without problems to geigerlog, data is uploaded from the device also.
I could not change the name of the device, so i am using GMC-500. Using WordPad did not help in this one.
I can not use the items in the tab "device", that is, show device info, switch it on or off, etcetera, but i do not think that is important anyway.
Thanks a lot for your software.
It is waaaay better than the GQ Data viewer!
David. |
| ullix |
Posted - 03/24/2018 : 07:04:11
With respect to calibration read this topic:
http://www.gqelectronicsllc.com/forum/topic.asp?TOPIC_ID=4578 |
| ullix |
Posted - 03/24/2018 : 06:55:07
David, sorry to hear about your problems. They appear to be resulting from Window and from GQ.
If your problems remain, please use the 'Discussion' tab at the GeigerLog website ( https://sourceforge.net/projects/geigerlog/ ) and provide the EXACT error message. You will get more info by starting GeigerLog with 'geigerlog -dv'.
The unreadable file issue:
I'd be surprised if there were a drive or file issue on your computer, but - assuming GeigerLog is on drive c: - check with Windows command 'chkdsk c:'. If problems are found, repair with 'chkdsk c: /f'
More likely, notepad is inadequate as editor and is messing up the file. Try if Windows' 'WordPad' works for editing the config file. If not, get an editor like 'Notepad++', or - my recommendation - get Geany ( https://www.geany.org/Download/Releases )
But before you do that, try something simpler. Install the original config file; download again if needed.
The older Geiger counters have a default baudrate of 57600, the newer ones of 115200. Your com port may be com13: Start GeigerLog with 'geigerlog -dv -p COM13 -b 115200'.
That should give you a running system.
The GMC-600 issue:
I have no access to a GMC-600 and have no knowledge whether GeigerLog works with this device at all. I can say that GeigerLog does work with the GMC-500, but not fully. Although GQ stated that all software communication remained the same, that is not true. And as long as GQ is not forthcoming with the basic information, there is little that I can do.
If you sense a bit frustration on my part, you do sense right.
My guess is that logging CPM counts from the 600 into GeigerLog will work. History, and setting changing at the counter probably not.
The 'calibration' is yet another issue. It is not a calibration. It is only the introduction of a factor to multiply the CPM with, claiming the result is µSv/h. It has never been told by GQ how they came up with that factor, and for what situation it is adequate to use.
And even this simple thing had been grossly messed up by GQ in the 500 series. Whether this severe bug has been corrected in the 600, I don't know.
What is your reason for saying that the calibration needs to be changed?
|
|
|
