| Author |
 Topic  |
|
|
ullix
Germany
1171 Posts |
 Posted - 07/27/2018 : 01:52:39
|
After a discussion in multiple threads in parallel and valuable contributions by users ikerrg and the_Mike the GLsimple500 now supports the additional new CPM*, CPS* commands and the new 4-byte (previosly only 2-byte) responses implemented in the new firmware 1.18 for the GMC-500+.
Of course, it continuous to support all other counters unchanged. More on the caveats in the included Quickstart manual.
And still running both on Python2 as well as on Python3, and still with a graphic plot program included.
Note that the order of the data columns was changed a little bit to accommodate the upcoming GeigerLog 0.9.08 (the full GUI version).
Available at the usual place:
https://sourceforge.net/projects/geigerlog/
Image Insert:
138116 bytes |
|
| Reply #1
ikerrg
United Kingdom
334 Posts |
Posted - 07/27/2018 : 02:01:14
|
| Thank you, ullix. Great job! Looking forward to seeing the new release of GeigerLog! |
 |
|
| Reply #2
Stargazer 40
USA
431 Posts |
Posted - 07/27/2018 : 04:31:47
|
Very quick implementation of software to handle new data and expanded formats. As a first time GeigerLog Simple 500+ user the software is relatively simple to install and use (including Python installation on my Windows 10 machine). Look forward to getting some plots out.
Until GQ gets their GMC Viewer software upgraded to handle the four byte data word length this is my only option to log data.
I don't think I have ever had an electronic device for less than a week and seen it and its developer and third party support work in harmony so well together, adding huge value to the user experience. For a unique two tube, high and low sensitivity GM meter, I remain more than impressed with the value I now receive from this device.
Get the new firmware (Ver. 1.18), and get GeigerLog Simple 500+ new version. You will be glad you did!
Thanks ullix! |
Stargazer 40 |
|
|
| Reply #3
ikerrg
United Kingdom
334 Posts |
Posted - 07/28/2018 : 12:38:05
|
@ullix,
I have noticed a possible bug either in GeigerLog_simple or in the new 1.18 firmware of GMC-500+. It happened to me twice. I just started the device, and connected it to the USB cable. The first execution of GeigerLog_simple returned this nonsense data:
https://www.dropbox.com/s/d3bber5eh09uqy4/WrongLog.rar?dl=0
The output of the Windows commandline is included. It looks like the CPM/CPS readings are swapping between the different counters! The CPM numbers were right (but not the counter/column where they appeared), as the device was partially on the uranium glazed plate. After closing GeigerLog_simple and starting it again, the results were in the right counter/column for hours.
Do you have any idea if that is a problem of a wrong initialization of the COM port? Or maybe is the firmware in the first connection? I don't know.
|
Edited by - ikerrg on 07/28/2018 12:40:23 |
|
|
| Reply #4
ullix
Germany
1171 Posts |
Posted - 07/29/2018 : 00:15:40
|
@ikerrg: The cause of the problem is easily identified: the counter was not giving an answer to the GETVER command providing Version info. The answer was completely empty, while the counter did respond to the other CPX commands. Strange, and the first time I ever saw this happening.
As a consequence the glsimple500 fell back to the standard 2-byte counters. But the counter was still delivering 4 bytes. So GL was reading 2 bytes (the upper 2, both zero). At the next request the counter was adding 4 more bytes to the pipeline, while GL was reading the 2 low bytes from the first call (which gave a correct value, but for the wrong call), and so on.
If the counter develops an attitude, there is nothing I can hold against it. What I did now is to make GL completely refuse to work unless the VERSION request is properly answered.
Very weird. Try rebooting, or even Factory resetting the counter! Needless to say, all works well in my 300E counter.
Please, download the new version 0.2.1 of geigerlog_simple_500plus. For testing, please also set the 'debug' variable in the customization section to 'True'. I would again need the text output as you had done this time.
|
|
|
| Reply #5
ikerrg
United Kingdom
334 Posts |
Posted - 07/29/2018 : 02:33:36
|
Thanks Ullix. Yes, it was easy to identify!
So, I confirm that there could be a bug in the new firmware! This is the output of the first run of GLSimple 0.2.1 after starting the GMC-500+:
USB-to-Serial Ports found on this system:
COM3 - USB-SERIAL CH340 (COM3)
my Version of geigerlog_simple_500plus.py : 0.2
my Python Version : 3.7.0
my Serial Port : COM3
my Serial Baudrate : 115200
my Serial Timeout (sec) : 3
my Cycle time (sec) : 1
my Log file : simple.log
DEBUG: ('getExtraByte: No extra bytes waiting for reading',)
DEBUG: ('getExtraByte: xrec:', b'')
DEBUG: ('Raw GETVER answer is:',)
DEBUG: (b'',)
DEBUG: ('Processed GETVER answer is:', '')
my Counter Version :
ERROR: The Geiger counter gave no answer to the version request.
Cannot continue without version. Try restarting geigerlog.
Perhaps the counter needs to be rebootet or even Factory resetted!
The following run went OK:
USB-to-Serial Ports found on this system:
COM3 - USB-SERIAL CH340 (COM3)
my Version of geigerlog_simple_500plus.py : 0.2
my Python Version : 3.7.0
my Serial Port : COM3
my Serial Baudrate : 115200
my Serial Timeout (sec) : 3
my Cycle time (sec) : 1
my Log file : simple.log
DEBUG: ('getExtraByte: Bytes waiting: 1',)
DEBUG: ('getExtraByte: xrec:', b'8')
DEBUG: ('Raw GETVER answer is:',)
DEBUG: (b'GMC-500+Re 1.18',)
DEBUG: ('Processed GETVER answer is:', 'GMC-500+Re 1.18')
my Counter Version : GMC-500+Re 1.18
@ Byte Counts : 4
Now logging:
DEBUG: ('getExtraByte: No extra bytes waiting for reading',)
DEBUG: ('getExtraByte: xrec:', b'')
2018-07-29 11:32:51, Command: b'<GETCPM>>' , Bytes: 4, Value: 16, Record
: b'\x00\x00\x00\x10'
2018-07-29 11:32:51, Command: b'<GETCPS>>' , Bytes: 4, Value: 0, Record
: b'\x00\x00\x00\x00'
2018-07-29 11:32:51, Command: b'<GETCPML>>' , Bytes: 4, Value: 16, Record
: b'\x00\x00\x00\x10'
2018-07-29 11:32:51, Command: b'<GETCPMH>>' , Bytes: 4, Value: 0, Record
: b'\x00\x00\x00\x00'
2018-07-29 11:32:51, Command: b'<GETCPSL>>' , Bytes: 4, Value: 0, Record
: b'\x00\x00\x00\x00'
2018-07-29 11:32:51, Command: b'<GETCPSH>>' , Bytes: 4, Value: 0, Record
: b'\x00\x00\x00\x00'
0 2018-07-29 11:32:51, CPM=16, CPS=0, CPM1st=16, CPM2nd=0, CPS1st=0, CPS2nd=0
2018-07-29 11:32:52, Command: b'<GETCPM>>' , Bytes: 4, Value: 15, Record
: b'\x00\x00\x00\x0f'
2018-07-29 11:32:52, Command: b'<GETCPS>>' , Bytes: 4, Value: 0, Record
: b'\x00\x00\x00\x00'
2018-07-29 11:32:52, Command: b'<GETCPML>>' , Bytes: 4, Value: 15, Record
: b'\x00\x00\x00\x0f'
2018-07-29 11:32:52, Command: b'<GETCPMH>>' , Bytes: 4, Value: 0, Record
: b'\x00\x00\x00\x00'
2018-07-29 11:32:52, Command: b'<GETCPSL>>' , Bytes: 4, Value: 0, Record
: b'\x00\x00\x00\x00'
2018-07-29 11:32:52, Command: b'<GETCPSH>>' , Bytes: 4, Value: 0, Record
: b'\x00\x00\x00\x00'
@EmfDev: Could you try if you hit this bug just after starting the GMC-500+?
|
Edited by - ikerrg on 07/29/2018 02:36:12 |
|
|
| Reply #6
ullix
Germany
1171 Posts |
Posted - 07/30/2018 : 02:09:47
|
I have just uploaded a Release Candidate for my new GeigerLog 0.9.08 (the full, GUI version).
There are major changes over the previous version, though if you do nothing more than you have done so far, you might actually find it easier.
I am interested to have this tested on all versions of the GMC counters, in particular those with the latest firmware(s). If you come across any bugs, please start GeigerLog with these options: 'geigerlog -dvR'. This results in a file 'geigerlog.stdlog' in the data folder, which I will need.
Image Insert:
189669 bytes
Some notes:
The manual is not yet updated. Hope, most is obvious, and more can be found out by trying. The mouse in the picture shows which button to click for connection/disconnection of the counters.
Image Insert:
17585 bytes
And plural for counters is right. GL now supports the RadMon+ as second device with Geiger tube and ambient variables Temperature, Pressure and Humidity. If you don't change the downloaded configuration this RadMon+ is automatically activated. Not a fake, it is a device sitting next to my desk, sending the data to a server in California, where you will pick them up when you start GL. The data are real and in real time (well, 110ms round trip delay).
With some 20 000km round trip some true 'remote sensing' 
GL will read the files created by the most recent geigerlog_simple500 version 0.2. If you have CSV files with a different format, I included a gconvert.py program, which allows to shuffle CSV data columns and create dummy columns when needed.
|
|
|
| Reply #7
ikerrg
United Kingdom
334 Posts |
Posted - 07/30/2018 : 03:09:26
|
The first error (when launching in a computer where the previous version worked OK) was that the module paho was not found. I installed the following:
pip3 install paho-mqtt
And now the error is even weirder:
File " geigerlog", line 6349, in <module>
main()
File " geigerlog", line 6145, in main
call(["tput", "smam"]) # tput smam: do line break on lines longer than screen
File "C:\Program Files\Python37\lib\subprocess.py", line 304, in call
with Popen(*popenargs, **kwargs) as p:
File "C:\Program Files\Python37\lib\subprocess.py", line 756, in __init__
restore_signals, start_new_session)
File "C:\Program Files\Python37\lib\subprocess.py", line 1155, in _execute_child startupinfo)
FileNotFoundError: [WinError 2] The system cannot find the file specified
|
|
|
| Reply #8
ullix
Germany
1171 Posts |
Posted - 07/30/2018 : 04:09:54
|
Indeed, this paho-mqtt module is needed. It drives the internet-of-things technology used by the RadMon+.
Sigh; all these goodies for the terminal missing on Windows. Fixed now, and corrected version uploaded.
Thanks for reporting
|
|
|
| Reply #9
ikerrg
United Kingdom
334 Posts |
Posted - 07/30/2018 : 04:47:35
|
OK. So again the bug in the new firmware with the GETVER command. See the first run of geigerlog after switching on the GMC-500+ and connecting it to the USB port:
==== Connect GMC Device ==========================================
TIMEOUT ERROR: Serial Port Timeout of 3.0s exceeded.
Failure with command b'<GETVER>>'
Got no data or not enough data from device. Retrying.
Retry successful.
Connected device: GMC-500+Re 1.1
Connection: port:'COM4', baudrate:115200, timeout:3.0 sec
Variables configured: CPM, CPS, CPM1st, CPM2nd
Calibration factor: 0.065 µSv/h/CPM
Calibration factor 2nd tube: 0.194 µSv/h/CPM
Date and Time from device: 2018-07-30 13:29:13
Date and Time from computer: 2018-07-30 13:29:10
Device is faster than computer by 3 sec
Device Power State: ON
Device History Saving Mode: OFF (no history saving)
Yes, that is a wrong identification because the last byte was not sent on time. The second run was OK:
==== Connect GMC Device ==========================================
Connected device: GMC-500+Re 1.18
Connection: port:'COM4', baudrate:115200, timeout:3.0 sec
Variables configured: CPM, CPS, CPM1st, CPM2nd, CPS1st, CPS2nd
Calibration factor: 0.065 µSv/h/CPM
Calibration factor 2nd tube: 0.194 µSv/h/CPM
Date and Time from device: 2018-07-30 13:33:41
Date and Time from computer: 2018-07-30 13:33:39
Device is faster than computer by 2 sec
Device Power State: ON
Device History Saving Mode: OFF (no history saving)
I haven’t done a deep test of every function, but I also found that the info returned by the “Show extended info” menu option was generic for the WiFi setup:
Device WiFi Data Setup
Website h**p://www.gmcmap.com
URL log2.asp
UserID 12345
CounterID 12345678901
SSID myssid
Password mypassword
Period 2
And one recommendation: I’d change the line in the .bat file that you are including for Windows users:
python "%~dp0geigerlog" –dvR
With that command, the path is included in the command whatever the directory where the extracted files is.
And you will probably need to send an initialization dummy command to the COM port (before GETVER) to overcome the possible new firmware bug. |
Edited by - ikerrg on 07/30/2018 05:06:41 |
|
|
| Reply #10
ullix
Germany
1171 Posts |
Posted - 07/30/2018 : 05:47:30
|
quote:
Yes, that is a wrong identification because the last byte was not sent on time. The second run was OK
It is as bad as in your previous simple500 tests: I am reading 14bytes (the standard version length for the old counter) and then check for more, and if there is I add the more stuff to the first read. The answer in this first read had nothing, zero length, this is what made the timeout.
So, clearly a bug. A workaround might be to click the connect button 3 times (connect--> disconnect --> connect. That should finally give a correct version answer?
quote:
the “Show extended info” menu option was generic for the WiFi setup:
Intentional. You must provide your userid, counterid, ssid, password in the configuration file 'geigerlog.cfg'. But the pre-sets allow to play with the Map without uploading any nonsense. (Which can too easily happen anyway).
quote:
python "%~dp0geigerlog" –dvR
Is that '%~dp0' really what windows wants to see, or is this a screw-up by the forum webcode?
|
|
|
| Reply #11
ikerrg
United Kingdom
334 Posts |
|
| Reply #12
ikerrg
United Kingdom
334 Posts |
Posted - 07/31/2018 : 00:24:16
|
@ullix
There is a new firmware version for GMC-500+. It fixes the initialization of the serial port after a clean start. The new firmware is identified as "GMC-500+Re 1.21", so I think you need to change your code both in GL and GLsimple to consider the firmwares after (and including) 1.18 as returning 4 byte counters.
|
|
|
| Reply #13
ullix
Germany
1171 Posts |
Posted - 07/31/2018 : 02:22:13
|
I put it into the GL and the GLsimple, but will release it only after the next bug 
as easy workarounds exist:
GL: cycle the connection: connect --> disconnect --> connect
GLsimple: restart GLsimple
The programs will now remind the user of a possible Geiger Counter Firmware Bug.
|
|
|
| Reply #14
ikerrg
United Kingdom
334 Posts |
Posted - 07/31/2018 : 02:46:49
|
Sorry, I might not explained myself correctly. The present version of GLsimple compares the ID string to "GMC-500+Re 1.18" and if it is not equal, it uses the default 2 byte counters. That makes the program fail with any newer firmware version, and that is why I was proposing to actually compare the numeric versions (i.e. 1.21 > 1.18) in the code.
I agree, there might be new firmwares soon, so that change in the code is even more important. |
|
|
| Reply #15
ullix
Germany
1171 Posts |
Posted - 07/31/2018 : 05:11:50
|
You're right, of course. I uploaded a new GLsimple version 0.2.2.
There I put the signature for the counter also into the customization section, so you can easily update the next firmware change :-) (providing nothing else is changed)
The GL can already be configured for a new version. In the file 'geigerlog.cfg' change the line:
nbytes = auto
to:
nbytes = 4
and, optionally to support the new CP* commands, the line:
variables = auto
to:
variables = CPM, CPS, CPM1st, CPM2nd, CPS1st, CPS2nd
and (re-)start GL
|
|
|
| Reply #16
ikerrg
United Kingdom
334 Posts |
Posted - 07/31/2018 : 05:45:42
|
Thanks ullix. That is a workaround that requires a lot of user input and understanding on their device (firmware version, etc.), especially for people that don't read the forum. It can be frustrating for a new user that just downloads Geigerlog to play with the counter, and might discourage them from using Geigerlog at all. As a long term solution, wouldn't it be easier if you automate the code to parse the ID string (for the GMC-500+) and find a float number in the last digits of the ID (1.18, 1.21, etc.) and then if it is bigger than 1.17 then set nbytes to 4 and variables to CPM, CPS, CPM1st, CPM2nd, CPS1st, CPS2nd? If the finding fails, just fallback to the default behaviour (2 bytes). Sorry, I do not know enough about Python language to write something, I would need a lot of googling to create some code.
|
|
|
| Reply #17
ullix
Germany
1171 Posts |
Posted - 08/01/2018 : 02:16:45
|
Currently it looks like owning a GMC-500 is already cause for frustration :-/. If you are not willing to dig into all the difficulties, better do not make this purchase!
Parsing the version info is not a problem at all. Provided you even get that version! And even if you do get it - what to do with it? There is no database, nor even a lookup table that tells you what the counter offers depending on the version info.
And whether the version gives a sufficient answer remains unknown. We have an old 'documentation' by GQ, that has not been updated since Jan2015, yet is claimed to be correct by GQ, although it is well known that it is not at various positions.
So, all auto-configuration is based on assumptions. When these are incorrect, or become incorrect later due to some unexpected changes, you can either configure your counter in GeigerLog, or not use it at all, as the GQ software may not be updated - as you experienced yourself - and you can't configure that yourself.
Pick the type of frustration you want.
|
|
|
| Reply #18
ikerrg
United Kingdom
334 Posts |
Posted - 08/01/2018 : 03:07:03
|
I agree with you that there should be a command that gives you the capabilities of the counter, so the software can configure the reading (2 or 4 byte, CPSL CPSH capability, etc.). But that does not exist yet. What we know until now is that the 4 byte counters are probably going to stay (and they might be added to other GMCs in the future). So any GMC-500+ with a firmware version > 1.17 will have 4 byte counters (and other known features). I know, it is not ideal, but it is the "less frustrating pick" that I can propose.
Anyway, Geigerlog is your software, so it is totally your call. I am not affected by the issue, and if I have time in my upcoming holidays, I might give it a try and learn some Python in the process (which could be really useful to stop depending on the expensive MATLAB for any data processing that I do).
|
Edited by - ikerrg on 08/01/2018 05:13:53 |
|
|
| Reply #19
ZLM
1261 Posts |
Posted - 08/01/2018 : 06:35:15
|
For the 4 bytes count from serial port, there is an order problem may happen sometimes. The serial port transmission/receiving may be interrupted by higher priority task. That will causes the PC host software to receive miss ordered data bytes. It could be any number of bytes in any order. That requests us to add extra bit/byte information to indicate which byte is the starting byte. So we may need to go 5 bytes format.
The old two bytes data format has reserved 2 MSB bits. Which is easier to handle this situation. |
|
|
| Reply #20
ikerrg
United Kingdom
334 Posts |
Posted - 08/01/2018 : 06:49:11
|
| Thanks for the update, ZLM. I didn't notice that problem, but to be fair, I haven't been logging through the serial port for too long with the new firmware. So we can expect more changes to the data output. I hope ullix understands better than I how to handle the miss ordered 5 byte output. |
|
|
| Reply #21
ZLM
1261 Posts |
Posted - 08/01/2018 : 07:05:56
|
| The miss ordered data bytes situation may happen more frequently when operating the device while the device reporting the data. Such as LCD backlight dim down will block the serial transmission. |
|
|
| Reply #22
ZLM
1261 Posts |
Posted - 08/01/2018 : 17:09:46
|
The 4 bytes still be fine. Actually we only need 3 bytes. 3 bytes is able to hold number 16777215. That is far enough for the CPM.
So, the first byte we can fix it to 0x55 to indicate the starting byte. |
|
|
| Reply #23
ikerrg
United Kingdom
334 Posts |
Posted - 08/01/2018 : 23:58:19
|
| I tried to see the byte ordering problem by logging data (with GLsimple) and operating the device at the same time. I could not find any error in the output. Maybe the numbers were so low that certain byte missordering was unnoticed or maybe that problem with priorities only happens in newer/older hardware. |
|
|
| Reply #24
ullix
Germany
1171 Posts |
Posted - 08/02/2018 : 00:22:12
|
@ZLM: There are several very puzzling statements in your last comments.
The interrupt technology is well established on all computing devices. Why not on the GMC counters? What actually is the mechanism of this mis-ordering, and what are the possible results?
How exactly would a fifth byte remedy the situation? What is the algorithm that recognizes, by looking at that single, 5th byte how to reshuffle the 4 other bytes?
And what am I making of this statement of yours:
quote:
The old two bytes data format has reserved 2 MSB bits. Which is easier to handle this situation.
Does this mean that not only the CPS command had the upper 2 bits used for some other purpose, and hence required to block them, limiting the max number representable to to 2^14=16383, but also the CPM command requires blocking of the 2 upper bits. So far I have only ever heard that CPM has the full 16 bit limit of 65535; apparently this is not true, limiting the upper number to CPM=16383, which is only CPS=273 ?
You know that official statements of GQ still make the claim that you have documented the commands, so that others can write software to work with your counters. This just discussed limit, however, is an extremely severe restriction, and it is documented nowhere. You are holding back essential documentation. And while the CPS case had been figured out by the users, and GeigerLog is adapted to it, the CPM crippling is news to me.
Such a crippled counter is worth sh**!
And for that crippled device we were debating how to calculate weighted averages to accommodate two tubes? Let alone that, as it turns out, the sensitivities of the 2 tubes aren't even known, as would be required for such an average. What a joke.
Now you are debating whether the new 4 bytes become 5 bytes, or perhaps the 4 bytes become 3 bytes, but plus an additional byte, so 4 bytes, but with different meaning. All the while all other counters remain 2 bytes, but not 16 bits, instead crippled down to only 14 bits???
Please, clarify this huge confusion:
When I get back 2 bytes form the current counters, be it for CPS or CPM, what property tells me whether the first byte I read is the MSB or LSB?
Likewise, what property of the 5th byte will tell me, in which sequence i must order the other 4 bytes?
Or, if the new 4 bytes become the new 3 bytes, what property of the 4th bytes tells me how to order the other 3 bytes?
But if the counter doesn't know due to this interrupt effect, in which order it is sending out data, how can the counter provide a byte with info on how to correct the wrong order, of which it doesn't know?
|
|
|
| Reply #25
ZLM
1261 Posts |
Posted - 08/02/2018 : 23:05:31
|
Ullix, thank you very much for your input. For the four bytes order, the bytes order should not be changed, but they may not arrive in exact four bytes each time. It is just my concern based on my limited knowledge. Please forgive me if it does not make sense.
For the two bytes order data, in official protocol document:
Return: A 16 bit unsigned integer is returned every second automatically. Each data package consist of 2 bytes data from GQ GMC unit. The first byte is MSB byte data and second byte is LSB byte data.
e.g.: 10 1C the returned 1 second count is 28. Only lowest 14 bits are used for the valid data bit. The highest bit 15 and bit 14 are reserved data bits.
|
|
|
| Reply #26
ikerrg
United Kingdom
334 Posts |
Posted - 08/03/2018 : 00:43:02
|
quote:
...the bytes order should not be changed, but they may not arrive in exact four bytes each time.
Sorry, I do not understand anything. If the bytes always arrive in the right order, what else can happen? That the bits inside each byte are missordered? That would make no sense!
In any case, I haven't seen that happening in my device while logging with GLsimple (4 byte with a predefined fixed order).
|
|
|
| Reply #27
ullix
Germany
1171 Posts |
Posted - 08/03/2018 : 04:08:26
|
Neither do I understand anything. And, ZLM, you are forgiven, nevertheless, it does not make sense.
When the bytes do come in order, for what purpose do I need a 5th, or a 4th, or an Nth byte?
When the bytes do come in order, and the counter delivers proper 2 byte answers, for what purpose are the upper two bits of a CPS return reserved and what do they indicate?
As this seems to be needed for CPS, is that also needed for CPM, and do we thus also have CPM limited to 14bits? If not, back to the previous question, why is it then needed for CPS?
When this is a problem for the 2-byte, or 4-byte or whatever CPM* and CPS* commands, why not for the 14-byte or 15-byte version command, or the 4096 byte SPIR command?
|
|
|
| Reply #28
ikerrg
United Kingdom
334 Posts |
Posted - 08/07/2018 : 14:00:17
|
| @EmfDev: Are there any news about this issue? Have you decided what number of bytes to return and if there is any kind of missordering in them? |
|
|
| Reply #29
EmfDev
2250 Posts |
Posted - 08/07/2018 : 14:32:52
|
The out of order data only happens in the data viewer because it's turning on the HEARTBEAT which is the automatic CPS report every
second from the device. It has nothing to do with the geigerlog or other software that uses GETCPS/CPM to get the data.
But yea we addressed this issue on the new data viewer so it won't get wrong data for the CPM.
Therefore there will be no change in the number of bytes or data format. |
|
|
| Reply #30
ikerrg
United Kingdom
334 Posts |
Posted - 08/08/2018 : 00:29:56
|
Good! Thanks for the information!
I think this is very useful for ullix and GeigerLog. Ullix might still be interested in the logic of the 2 reserved bits in the 2 byte counters, though, and the different limits in CPM/CPS counters with only 14 bits for the number representation, i.e. 16384 CPM = 273 CPS when measuring in CPM mode and 16384 CPS = 983040 CPM when measuring in CPS mode.
For the GMC-500+ and its 4 byte counters, that should not be a problem. Have you finally reserved any bits in the 32 bit output of the GMC-500+ counters? If so, how many?
In terms of the CPS/CPM numbers stored in the GMC-500+ internal memory, are those numbers 4 bytes long also or how are they represented in firmwares >= 1.18?
The DataViewer is still the same version, so I suppose you haven't uploaded the update yet, have you?
|
Edited by - ikerrg on 08/08/2018 01:09:32 |
|
|
| Reply #31
ullix
Germany
1171 Posts |
Posted - 08/08/2018 : 07:59:05
|
So all this confusion about byte order because of the heartbeat function? Which is needed for the GQ Dataviewer, because the DV cannot control the counter for a CPM/CPS recording?
GeigerLog does not use Heartbeat. It is implemented, but I couldn't figure out what it was useful for in comparison to the CPM/CPS calls well controlled by GeigerLog, so I inactivated it.
I still don't get it how the order of bytes could be influenced by the heartbeat, but let me guess: the two high bits of the MSB were used to designate this byte as MSB? Well this would have worked most of the time, because CPS is usually in the single digits, but once it gets near 256 you could have the MSB and LSB look alike, and then what?
It looks like heartbeat is a good candidate for elimination!
|
|
|
| Reply #32
ikerrg
United Kingdom
334 Posts |
Posted - 08/08/2018 : 08:17:47
|
| So the limit in the 14 byte output is only due to an implemented function that sends the data every second? You are limiting the counts that the GMCs can handle just because of that? With the full 16 bit you could handle 65535 CPM, i.e. 1092 CPS, which is a lot for the M4011 tube. I agree, get rid of a function that is limiting the device's functionality. |
|
|
| Reply #33
EmfDev
2250 Posts |
Posted - 08/08/2018 : 09:00:17
|
@ikerrg
The 2 bits reserved for the 2byte counters is for the data viewer using heartbeat. Sometimes the data becomes out of sync which
leads to wrong CPS/M reading on the data viewer even sometimes there are 3 or 1 or 4 bytes on the terminal instead of 2. So the data viewer needs to check the byte if it's the correct MSB. I was initially designed for the 300 and 320 and it was already
there at first.
We haven't reserved any bits yet for the 4 bytes counters.
The number of bytes being saved in the memory is still the same as other models. 1 byte if < 256, else 2 bytes if < 2^16, etc.
It should be updated by the support already probably the version wasn't modified.
@ullix
It was initially designed to use heartbeat instead of getcpm/cps. And yes because of this, the data can be out of sync.
The heartbeat returns 2 bytes or 4 bytes every second that depends on the counter. And the DV reads the terminal every second.
Maybe sometimes there are delays on the geiger counter that causes the DV to read either more bytes or less bytes in the
terminal.
|
|
|
| Reply #34
EmfDev
2250 Posts |
Posted - 08/08/2018 : 09:02:46
|
quote:
Originally posted by ikerrg
So the limit in the 14 byte output is only due to an implemented function that sends the data every second? You are limiting the counts that the GMCs can handle just because of that? With the full 16 bit you could handle 65535 CPM, i.e. 1092 CPS, which is a lot for the M4011 tube. I agree, get rid of a function that is limiting the device's functionality.
Maybe before, there were some noise bytes being sent by the 300 or 320
to the terminal that's why there is also reserved bytes. I'm not entirely sure about this though. Data viewer is initially designed
for the 300, 320, and older models. |
|
|
| Reply #35
ikerrg
United Kingdom
334 Posts |
Posted - 08/08/2018 : 10:45:24
|
quote:
The number of bytes being saved in the memory is still the same as other models. 1 byte if < 256, else 2 bytes if < 2^16, etc.
That means that up to 4 bytes could be used to store the CPM or CPS data in the GMC-500+ internal memory, is that OK? So it is like a space saving technique to avoid storing 4 bytes for very small numbers. |
|
|
| Reply #36
EmfDev
2250 Posts |
Posted - 08/08/2018 : 11:36:40
|
| Yes it saves only necessary bytes to the memory. |
|
|
| Reply #37
ikerrg
United Kingdom
334 Posts |
Posted - 08/08/2018 : 12:08:21
|
I don't have a way to test that the newest firmware (1.21) is actually storing 3 bytes of data at high count rates or even 4 bytes (that probably could never happen) in the internal memory. In any case, have you checked that it is working as expected? Is the DataViewer software correctly reading the new memory storage format coming from the newest GMC-500+ firmware at high count rates?
|
|
|
| Reply #38
EmfDev
2250 Posts |
Posted - 08/08/2018 : 15:56:53
|
Yes it should still be working, when saving 2 or more bytes, there's a header to differentiate from 1 byte data. 4 bytes is impossible, unless
it's hardcoded. |
Edited by - EmfDev on 08/08/2018 15:58:40 |
|
|
| Reply #39
ullix
Germany
1171 Posts |
Posted - 08/09/2018 : 01:12:49
|
So the Heartbeat function is some baggage from the beginning? I wrote a quick script and ran the heartbeat overnight for som 50000 records, and not a single one was in the wrong order. But it might happen.
But once you run Heartbeat, you must not do any other communication with the counter. I also tried heartbeat plus a GETCPM and that went ok for some 100 records, and then flipped:
111 2018-08-08 20:37:13, CPM=126, heartbeat:0
112 2018-08-08 20:37:14, CPM=123, heartbeat:1
113 2018-08-08 20:37:15, CPM=122, heartbeat:4
114 2018-08-08 20:37:16, CPM=32769, heartbeat:4
115 2018-08-08 20:37:17, CPM=32770, heartbeat:120
116 2018-08-08 20:37:18, CPM=32771, heartbeat:121
117 2018-08-08 20:37:19, CPM=32771, heartbeat:124
and eventually flipped back some time later.
No surprise, really, as one is running on the counter clock, and the other on the computer clock. I see Heartbeat as more of a nuisance than an advantage.
But even if the two reserved upper bits were originally intended as fudging this heartbeat, the remaining 14 bits or some 16000 for not only the heartbeat but also the GETCPS is more than plenty when the counter's upper end at 200µs is well below 5000!
But I am confused about the new firmware, please clarify:
- Both GETCPM and GETCPS, as well as the commands for the individual tubes, now deliver 4 bytes?
- there are no reserved bits in any of the responses to these commands?
- The history is now stored as 4 bytes also? How exactly is the storage format?
The consequence is that neither GeigerLog nor any of your software can read the history of the 500 with firmware 1.21.
|
Edited by - ullix on 08/09/2018 02:00:26 |
|
|
| Reply #40
EmfDev
2250 Posts |
Posted - 08/09/2018 : 09:04:57
|
It's been used by the data viewer for a long time. Yea you don't need to use the heartbeat.
To answer your questions,
-Yes the GETCPS and CPM returns 4 bytes for the 500+, I'm not sure about 500 and 600/+ I'll have to check if they also updated
those firmwares to use 4 bytes.
-Yes for the 4 bytes, there are no reserved bits. But normally the MSB should be zero because the count range won't reach that high.
-The history still the same and only stores necessary bytes.
Memory saved is
One byte if < 256
5 bytes if < 2^16+1 ==> [55] [AA] [01] [CPSMSB] [CPSLSB]
6 bytes if < 2^24+1 ==>> [55] [AA] [02] [CPSMSB] [] [CPSLSB]
else 7 bytes ==>> [55] [AA] [03] [CPSMSB] [] [] [CPSLSB]
Data viewer is still working for downloading the history.
|
Edited by - EmfDev on 08/09/2018 09:58:33 |
|
|
| Reply #41
ullix
Germany
1171 Posts |
Posted - 08/10/2018 : 00:02:12
|
quote:
-The history still the same and only stores necessary bytes.
Memory saved is
One byte if < 256
5 bytes if < 2^16+1 ==> [55] [AA] [01] [CPSMSB] [CPSLSB]
6 bytes if < 2^24+1 ==>> [55] [AA] [02] [CPSMSB] [] [CPSLSB]
else 7 bytes ==>> [55] [AA] [03] [CPSMSB] [] [] [CPSLSB]
@EmfDev:
thanks for the update, but with the above I see more headaches coming. The history is NOT still the same!
In particular, the 55 AA 02 code had formerly been used to designate ASCII code coming, like text that was entered at the counter as Note/Location. I just verified that this is still the case on my 300E+.
But what makes this really bad is that this existing coding is now replaced with a code indicating a 3-bytes response? So what does now designate ASCII code coming?
Furthermore, this change was completely unnecessary; even if you wanted to use this very scheme, you had 252 other choices you could have made, and remain compatible with previous coding. Instead we now get a new layer of incompatibility. Too bad.
Please, be specific: For which counters and which firmware is this new coding true?
And what else had been changed, in which counters and which firmware?
|
|
|
| Reply #42
EmfDev
2250 Posts |
Posted - 08/10/2018 : 08:34:48
|
55 AA 04 is now the location data and I think it should only apply with the 4 bytes counters or just the 500+. I'll have to check.
What do you mean ascii code for the 3 bytes response? sorry I didn't understand the question.
Edit: Only the 500 and 500+ uses 4bytes data. |
Edited by - EmfDev on 08/10/2018 11:39:04 |
|
|
| Reply #43
ullix
Germany
1171 Posts |
Posted - 08/11/2018 : 02:27:03
|
"ASCII code" meaning only printable characters in the 128 bit ASCII code. I.e. the text that you can enter via the "Note/Location" menu option.
If it isn't spread farther than the current 500 series, I urge you to revise that; it is cumbersome.
So far we had the 55 AA XX sequence signalling:
55 AA 00: timestamp
55 AA 01: double data byte
55 AA 02: Note/Location text
55 AA xx: anything else not used
Now I understand we have:
55 AA 00: timestamp
55 AA 01: double data byte
55 AA 02: triple data byte
55 AA 03: quadruple data byte
55 AA 04: Note/Location text
55 AA xx: anything else not used
The consequence is that the parser now has to check the firmware, and has to have a list of what firmware requires that, in order to correctly interpret the 55 AA 02 sequence.
It would have been a lot easier by leaving Note/Location at 55 AA 02, and use the *03 and *04 for the three and four bytes sequence (which I doubt that anyone would ever see those). Any older software not prepared for 3 and 4 data bytes would have simply ignored the seemingly wrong data, and would have caught up at least with the next timestamp.
Just modify the coding to this:
55 AA 00: timestamp
55 AA 01: double data byte
55 AA 02: Note/Location text
55 AA 03: triple data byte
55 AA 04: quadruple data byte
55 AA xx: anything else not used
and programming life is a lot easier, and no firmware needs to be tracked for the parser!
|
|
|
| Reply #44
ZLM
1261 Posts |
Posted - 08/12/2018 : 10:11:34
|
| Thanks Ulix, this is a valid request. Our software should always keep this rule. |
|
|
| Reply #45
ullix
Germany
1171 Posts |
Posted - 08/20/2018 : 06:59:00
|
Good to hear!
So, which firmware(s) have this improper mode, and from which onwards is the proper change implemented?
|
|
|
| Reply #46
EmfDev
2250 Posts |
Posted - 08/20/2018 : 09:05:28
|
| I believe it's on the 500/+ and 600/+ current firmware as they require to save 3 or 4 bytes if required. |
|
|
| Reply #47
ikerrg
United Kingdom
334 Posts |
Posted - 08/20/2018 : 09:45:55
|
| So, have you already included the fix in the firmware? |
|
|
| Reply #48
EmfDev
2250 Posts |
Posted - 08/20/2018 : 10:29:03
|
| Not yet as I'm not the one who releases them. |
|
|
| Reply #49
ullix
Germany
1171 Posts |
Posted - 08/21/2018 : 01:28:14
|
@EmfDev: I wish you would be a bit more specific. I am at a loss trying to code "I believe" in Python.
|
|
|
| Reply #50
EmfDev
2250 Posts |
Posted - 08/21/2018 : 08:26:14
|
Sorry, the fix is not out yet. The current official firmware still has
55 AA 00: timestamp
55 AA 01: double data byte
55 AA 02: triple data byte
55 AA 03: quadruple data byte
55 AA 04: Note/Location text
55 AA xx: anything else not used
for 500 and 600+ |
|
|
| |
Topic |
|
|
|
geigerlog_simple_500plus v0.2 supprts new firmware
