| T O P I C R E V I E W |
| EmfDev |
Posted - 07/13/2018 : 15:19:15
We did some modifications to the code. But it's not official yet.
GETCPM, GETCPMH, GETCPML, GETMAXCPS, GETACPM, GETCPS, now return
4 bytes of data. Turning HEARTBEAT1 will also report 4 bytes of data
per second.
Also added GETCPSH, GETCPSL, and looping through menu.
We tried to implement @ullix's uSv formula from https://www.gqelectronicsllc.com/forum/topic.asp?TOPIC_ID=5278
where weights can also be adjusted,
uSv = (tube1Count * tube1Weight + tube2Count * tube2Weight) / 2 * <calib.usv/calib/cpm>
In this formula, if tube2Weight is high for the example 30, then 1
count(cant be noise) in tube 2 will significantly change the resulting uSv in lower levels of radiation.
One way to fix this is to ignore tube2Count until certain level and only use tube1Count (best is until tube1 saturation count) but
we need time to determine those values. It's hard to find the saturation count because each tubes have different saturation limit. |
| 100 L A T E S T R E P L I E S (Newest First) |
| EmfDev |
Posted - 09/13/2018 : 14:16:02
There should be some differences in the hardware but I don't know exactly. |
| Stargazer 40 |
Posted - 09/13/2018 : 11:44:31
Another question. When ZLM used the LND 7317 tube with the 500+ power supply he cranked up the voltage to the PS. It is true that the PS in the 500+ is essentially the same build/components as in the 600 and 600+ (except for the separation hardware to feed two tubes? I think ZLM said the PS could support 600V by design. |
| EmfDev |
Posted - 09/13/2018 : 09:27:43
Do you mean to connect it in parallel to the SI3BG tube? Yes it can work. As long as it's in the working voltage of
the two tubes. And yea, the count will more likely to come from the more sensitive tube. |
| Stargazer 40 |
Posted - 09/13/2018 : 09:02:00
So if I wire the LND 712 to the positive ahead of the anode resistor on the SI3BG and its ground, with the M4011 turn off with hardware switch, the counts will most likely be coming from the LND which is much more sensitive than the SI3BG. |
| EmfDev |
Posted - 09/12/2018 : 09:25:25
@ullix is correct. There are 2 counter interrupts separate for those 2 tubes.
edit. sorry I accidentally deleted ullix's answer.
|
| EmfDev |
Posted - 09/11/2018 : 15:47:17
I think there is a circuit that generates a low when there is a current in the tube. Each tube has one.
It's probably that discharge in the capacitor is detected then generates a low if the charge goes
below a threshold. But I need to confirm this. |
| Stargazer 40 |
Posted - 09/11/2018 : 14:45:04
@EmfDef - May I ask how you know which tube it is that has discharged? Is there a trigger that occurs in a separate counter circuit for each side of the PCB? How is the analog changed to digital? |
| EmfDev |
Posted - 09/11/2018 : 11:41:01
This time you probably don't need to reboot after changing the tube setting if you want to keep the total count and uSv. |
| ikerrg |
Posted - 09/11/2018 : 03:11:30
Thanks to you for the extremely quick response and fix, EmfDev.
Yesterday after going through the airport security, the total uSv was slowly increasing (without any counts measured) and suddenly it dropped a big amount and continued increasing slowly. I have pictures and a video! That made no sense for an integral of the dose rate during the whole period. Now the calculation seems to be right: TotalCounts*sensitivity/60, and it stays unchanged until there is another count. I cannot imagine what you were calculating before!
I'll also check the algorithm when I install the M4011 tube again.
By the way, the new firmware version is 1.23.
|
| EmfDev |
Posted - 09/10/2018 : 12:19:55
@ikkerg, We changed the total uSv now and should be working. Try to email support to get available firmware update.
@Stargazer. Looks like the total uSv becomes 0 after certain time.
Thank you guys! |
| ikerrg |
Posted - 09/10/2018 : 08:52:16
I am now at an airport and I have just passed through security only with the si-3bg tube installed. Probably tomorrow I will show you very interesting data regarding the dose rate integration and the CPM measured with the low sensitivity tube compared to the M4011 measurement of a few weeks ago. Just to start, the si-3bg counted 228 counts in one second! Translate that to the M4011 with a sensitivity ratio of 73 and see how the HV circuit was totally saturated in the data of three weeks ago! |
| ikerrg |
Posted - 09/09/2018 : 10:25:54
Yes I did restart the device. I said I removed the Tube 1 (turning off the counter), so I cannot have readings from Tube 1. The bug might be only in 1.21. See the picture after 7 hours running:
Image Insert:
47296 bytes |
| Stargazer 40 |
Posted - 09/09/2018 : 10:16:34
I still have 1.18 and the total uSv are being tallied with only tube 2 in place. I did reboot after selecting tube 2. |
| EmfDev |
Posted - 09/09/2018 : 09:39:14
Did you restart the device after selecting tube 2? If not, it might have included the counts from tube 1 and calculated tube 2 dose rate using values of tube 1. |
| ikerrg |
Posted - 09/09/2018 : 07:48:22
Hello,
I have found another possible bug in the GMC-500+ latest firmware (v1.21). The accumulated dose rate shown in the “Text Mode” screen is not correctly calculated when Tube 2 is selected in the calibration menu. All the other figures are correctly displayed using the counts coming only from Tube 2, but not the accumulated dose (mR or uSv). I discovered this bug when physically removing the Tube 1 for my next flight, so now (until I install the Tube 1 again) I cannot check if the accumulated dose is calculated from the counts of Tube 1, or if it is always 0 when Tube 2 is selected (which is what I am watching now, no matter what are the counts measured by Tube 2).
Please EmfDev, confirm (and fix) the bug.
Thanks.
|
| EmfDev |
Posted - 08/10/2018 : 08:45:57
Oh I thought I was testing the same hardware version as you but checked it and actually it's an older version.
Will have to replace my testing units with a new one then I'll try again.
Edit: Also didn't find this error in the same model, maybe it's some
communication issue between the software and the counter. |
| ikerrg |
Posted - 08/10/2018 : 08:40:47
Well, nothing should be random, is just my poor understanding what makes it look random! |
| Stargazer 40 |
Posted - 08/10/2018 : 04:17:44
I don't know if this is random, but I tried again after reconnecting and it works this time. I don't normally go get any data at this point, so to catch it the first time I tried that command is interesting. Thanks ikerrg for comfirming. |
| ikerrg |
Posted - 08/10/2018 : 02:03:54
I've seen that bug several times. It happens randomly when you connect the device to the viewer software. It seems that the device becomes unresponsive, or that the software is waiting for something until there is a timeout. I just disconnect it and connect it again and it usually works. EmfDev, if you cannot reproduce it, maybe it is related to the harware version of the GMC-500+. Afaik, Stargazer_40 has the same version as I. And you had problems reproducing some bugs in your hardware. This reminds me the battery charging problem that you couldn't reproduce, which you fixed by removing the possibility of selecting a non-rechargeable battery. I think that bug was related to the new hardware of the GMC-500+!
|
| EmfDev |
Posted - 08/09/2018 : 08:45:02
Can you please try it again? Does the Sync Date and Time work? I just tested again and it still works. |
| Stargazer 40 |
Posted - 08/09/2018 : 06:43:29
@EmfDev - Thanks for updating the viewer software. New version appears to work just fine, except I can't get any response to GETDATETIME. Simply get error.
|
| Stargazer 40 |
Posted - 08/01/2018 : 16:24:19
Same as yours - 3.4 02052018 |
| EmfDev |
Posted - 08/01/2018 : 16:03:02
The support knows more about hardware revisions. I have a few test units but the one I use recently is probably
very old. |
| ikerrg |
Posted - 08/01/2018 : 13:53:27
quote:
Originally posted by Stargazer 40
So if we've solved a couple of issues related to the newer hardware and we understand that only turned on tubes have click and LED flash, what is the current best version of firmware one should request from support?
What is your hardware version written on the PCB near the battery?
|
| Stargazer 40 |
Posted - 08/01/2018 : 13:21:41
So if we've solved a couple of issues related to the newer hardware and we understand that only turned on tubes have click and LED flash, what is the current best version of firmware one should request from support?
Thanks |
| EmfDev |
Posted - 08/01/2018 : 08:35:26
Newer hardware should be better than the old one.
Just contact support for the firmware. |
| ikerrg |
Posted - 08/01/2018 : 00:04:49
Thanks, that is good news! What I do not understand is why you could not reproduce the bug in the older hardware. Shouldn't the different hardware versions behave exactly the same? Unless the firmware is developed specifically for the hardware version...
Please, tell me when you have the fix available. |
| EmfDev |
Posted - 07/31/2018 : 15:53:02
Found it. I was using an older model(2017). In the latest firmware, we tried to turn off the tick sound
when selecting individual tube. But I didn't know that turning off the tick also turns off the led.
So in the end turning off the speaker won't turn off the LED, and when selecting only one tube,
the other tube tick will disappear including its led. So only the tick and led of the selected tube will work. |
| ikerrg |
Posted - 07/31/2018 : 15:04:27
I have reset the device many times. It still disables the LED when I mute the speaker (until the next reboot if I don't touch that menu again). It is annoying that my device is behaving so differently! There must be a reason. As additional info, my hardware version (written on the PCB near the battery) is GMC500 V3.4 20180205.
I can try downgrading to v1.18 (if that is possible) and check for the bug again.
About Data Viewer, thanks for the clarification. I did not know that. I suppose that it is uploading null values for the rest of the configs and that is why the device is a total mess.
|
| EmfDev |
Posted - 07/31/2018 : 14:32:21
Can you try to factory reset the device to see if the LED problem is solved? Because I can't produce the bug.
When I turn off the speaker, the LED still works.
For using GMC Data Viewer, just use it when the device is ON. It's not writing to the wrong configuration,
it's using commands to write WiFi configs to the device then tries to save all the configs. But all the config variables might not be initialized correctly when it's off so it might have saved the wrong configs for those variables. |
| EmfDev |
Posted - 07/31/2018 : 10:53:15
Ok I'll check where this bug came from. |
| ikerrg |
Posted - 07/31/2018 : 10:31:33
Update: Something weird is happening after the update to the new firmware. Now, when I write the WiFi config using the GMC Data Viewer software (with the device switched off), the device's configuration is totally screwed after switching it on. The alarm sounds, sometimes the LED blinks red with events, etc. It is like the Data Viewer software is writing the config data to a wrong memory location! A reset to factory defaults seems to solve the problem, though.
All this does not change the issue with the speaker and the LED that I mentioned previously.
|
| ikerrg |
Posted - 07/31/2018 : 10:00:35
Sorry, I've tried everything: Resetting when off (through terminal), resetting when on (using device's menu). When I switch off the speaker, the LED does not work. Only if I reboot with the speaker set to OFF, the led works without the speaker. That didn't happen before in v1.18.
Selecting only tube 1 or tube 2 does not help also.
Do you want me to do any specific test?
|
| ikerrg |
Posted - 07/31/2018 : 09:48:58
Arrrgh, what a bad luck. Another bug that you cannot reproduce. Let me reset again the config and see if it does the same. |
| EmfDev |
Posted - 07/31/2018 : 08:37:00
Tried rebooting it while speaker is on, then turned it off. The LED is still working. Hmm.. |
| ikerrg |
Posted - 07/31/2018 : 08:28:23
No, no, the dummy command is not needed. The problem is not related to the connection now.
I am in the default configuration of tube1+tube2 (I didn't change it after the firmware update, i.e. after the config reset).
|
| EmfDev |
Posted - 07/31/2018 : 08:19:47
Do you still have to send a dummy command?
That's strange, which tube configuration are you in?
If tube 2 it should turn off the speaker/led for tube 1. Tried to turn off the speaker but led's still working. |
| ikerrg |
Posted - 07/31/2018 : 00:21:44
Thank you. That was really quick!
Now running GMC-500+Re 1.21
The serial initialization bug has been corrected.
However, I already found a regression:
If you go to the speaker and turn it off, it also turns off the notification led (but does not change the menu option of the notification led). The only way to have the speaker off and the led on at the same time is by rebooting and not touching the speaker menu option anymore. Then the led works and the speaker can be off.
|
| EmfDev |
Posted - 07/30/2018 : 15:19:22
@ikerrg The customer support will contact you. |
| ikerrg |
Posted - 07/30/2018 : 14:44:02
To be honest, I don't know if I waited 15 s. I saw that the screen was frozen and nothing happened when touching the buttons for a while, so I removed the battery. If it happens again I'll wait.
In any case, the dummy command is only a workaround. Do you plan to fix the bug? It does not happen in other devices. |
| EmfDev |
Posted - 07/30/2018 : 14:16:58
Does it freeze a long time and doesn't reboot?
There should be a watchdog timer that reboots it automatically after around 15 seconds.
Hopefully this dummy command also fixes this issue of freezing. |
| ikerrg |
Posted - 07/30/2018 : 13:49:50
I have reset the configuration of my GMC-500+ and I'll tell you if it freezes again. However, I don't want to be constantly trying to freeze the device by turning it on and off and connecting and disconnecting it. I could break it!
I confirm that a dummy empty command works for the initialization bug:
import serial
my_port = 'COM3'
my_baudrate = 115200
my_timeout = 1
ser = serial.Serial(my_port, my_baudrate, timeout=my_timeout)
ser.write(b'<>>')
dummy = ser.read(1)
ser.write(b'<GETVER>>')
srec = ser.read(15)
print("ID:", srec)
|
| EmfDev |
Posted - 07/30/2018 : 11:12:31
Maybe just fix it with a dummy command <>> to confirm the connection between the two devices. |
| EmfDev |
Posted - 07/30/2018 : 11:08:12
It could be the usb driver/software problem from the computer.
I tried it with a usart terminal I also don't receive anything after first command.
Still cannot reproduce the freezing bug using a usart terminal. |
| ikerrg |
Posted - 07/30/2018 : 10:58:46
Yes, after turning it on, the first GETVER command does not get the requested info. The second time it works.
About the freeze, it is a bit more difficult to reproduce, but I have hit that bug a couple of times. Follow this process:
Turn on the GMC-500+ (screen is the Large Font just in case it makes a difference)
Connect to USB
Start geigerlog_simple
GETVER command returns no ID or wrong ID, never mind...
Disconnect USB
Connect again to USB
Start geigerlog_simple again
GMC froze at some point and I had to disconnect the battery.
The freezing problem must be related to the connection to the COM port, as it never happens when I do not connect the device to the USB.
|
| EmfDev |
Posted - 07/30/2018 : 09:59:58
@ikerrg,
Did you mean after turning on the device? Yes I just checked it. It sends out some debugging information.
It's the current SPI address. Anywhere from 0x00 - 0xFFFFF and then loops when full.
Edit. Sorry I didn't get the question,
did you mean that the device won't respond after the first command?
Thanks.
I need to confirm the other bug where you said it froze.
|
| ikerrg |
Posted - 07/30/2018 : 04:56:37
@EmfDev: The bug is even worse. I managed to freeze the GMC-500+ and I had to remove the battery (twice).
Switch on the GMC-500+ (screen is the Large Font just in case it makes a difference)
Connect to USB
Start geigerlog_simple
GETVER command returns no ID or wrong ID
Disconnect USB
Connect again to USB
GMC froze at some point
It seems that the problem does not happen with DataViewer because when you enter in the terminal, the program sends some other COM port command that somehow initializes the GMC-500+ and ther it answers correctly to the GETVER command at the first time.
With this very simple python program, you can see the problem:
import serial
my_port = 'COM4'
my_baudrate = 115200
my_timeout = 1
ser = serial.Serial(my_port, my_baudrate, timeout=my_timeout)
ser.write(b'<GETVER>>')
srec = ser.read(15)
print("ID:", srec)
If you run just after connecting the GMC-500+ for the first time, it will return:
ID: b''
And the second time you run it, it will return:
ID: b'GMC-500+Re 1.18'
However, if you add a dummy command just before GETVER like:
ser.write(b'<GETCPM>>')
then the GETVER command returns the right data at the first attempt.
|
| ikerrg |
Posted - 07/29/2018 : 07:49:54
@EmfDev: There is a possible bug in the new firmware with the GETVER command after starting the GMC-500+. Please, check the last posts in:
http://www.gqelectronicsllc.com/forum/topic.asp?TOPIC_ID=5331
|
| EmfDev |
Posted - 07/27/2018 : 10:13:59
Yes that's correct. That only downside to this is you can't distinguish from which tube a count is from.
The current hardware design doesn't support this mechanism. The only way to do that is to remove the tube.
|
| ikerrg |
Posted - 07/27/2018 : 00:04:12
Good! Thanks EmfDev. So we can now store the CPS of tube 2 in the internal memory by just selecting tube 2 in the menu. And then if I change the tube selection to tube 1 when the device is storing the results for tube 2, the device will continue storing the CPS/CPM of the tube 1 seamlessly in the same data file. Am I right?
I have another related question. I suppose that the non-selected tube (for tube 1 or tube 2 selections) is not switched off in hardware, is it? I see a good advantage if you could switch off the voltage of the unused tube (especially for tube 1): the lifetime of the tube. If a user wants to do high radiation measurements for a long time, they could protect the high sensitivity tube by switching it off while only measurements are being taken with tube 2. That would be transparent to the user, same menu as now, everything identical. Just the hardware has to switch off the non-selected tube. Is that even possible in your hardware?
|
| EmfDev |
Posted - 07/26/2018 : 15:01:08
@ikerrg,
- rebooting is to reset the counts in some displays like the total cpm in text display mode but not necessary if your don't care about it.
- the current structure doesn't know which tube the cpm belongs to, it just saves the cpm of the tube selection.
i.e. saves the cps of tube 1 only if you select tube1, cpm/s of tube 2 if you save tube 2.
and cpm1+2 for both tubes selected. |
| ikerrg |
Posted - 07/26/2018 : 12:57:14
@EmfDev
I have a few questions about the new firmware:
- Why a reboot is needed when you change which tube is being used? I thought that the tube selection only affected to the calculation of the dose rate in µSv/h, and if it is only a calculation, why the reboot? It seems that after selecting one of the tubes (e.g. tube 2) without rebooting, the reading of µSv/h is immediately calculated with the new rules (i.e. 0CPM*0.194=0 µSv/h for tube 2 in background radiation).
- Could you comment on what is finally stored into the device’s internal memory in all the possible selections for the tubes? (tube1, tube 2 and tube1+tube2). What is the storage format now?
Many thanks.
|
| ikerrg |
Posted - 07/26/2018 : 11:18:22
Seems to work OK, ullix. Thanks for the quick update! |
| Stargazer 40 |
Posted - 07/26/2018 : 09:46:31
So a different screen listing comes from your release. Each reading is numbered with date and time and the six parameters with data, comma delimited. This is followed by date time and each call with whether 2 or 4 byte, the bytes displayed and the reading. So a total of seven lines where before only the first line was displayed. May just be for viewing as the data file output is as it was before so no problem getting into spreadsheet.
This is GREAT! Thanks |
| ullix |
Posted - 07/26/2018 : 09:27:08
Good. The geigerlog_simple500 issue seems also to be solved. If the latest rc
https://sourceforge.net/projects/geigerlog/files/testing/geigerlog_simple_500plus.py/download
has no bugs, this will be it.
|
| Stargazer 40 |
Posted - 07/26/2018 : 09:06:30
Okay, reinstalled Python and installed pyserial and it runs just fine. Now just need the byte thing dealt with.
Thanks for your efforts there.
|
| Stargazer 40 |
Posted - 07/26/2018 : 08:26:14
Doesn't appear Python is in my system path. How can I make that so? |
| Stargazer 40 |
Posted - 07/26/2018 : 07:37:46
So don't even go into a Python command prompt window. Very nice. Thanks for working with ullix to sort out the bytes! |
| ikerrg |
Posted - 07/26/2018 : 05:41:11
If you have python in your system path, just open a Windows command prompt, change to the directory where the geigerlog_simple_500plus.py is and then issue this command:
python geigerlog_simple_500plus.py
quote:
Really like the looping through menus change. We'll put a lot less wear on the buttons now!
Thanks a lot! xD, it was my idea ;)
|
| Stargazer 40 |
Posted - 07/26/2018 : 04:47:15
I'll wait till you two sort it out.
Do I run this simple.py from the command line? How do I change to the folder I have it in to run or do I need path ahead of simple.py in the Python terminal window?
EmfDef - Really like the looping through menus change. We'll put a lot less wear on the buttons now!
|
| ikerrg |
Posted - 07/25/2018 : 14:06:52
Just use the file in my link, it is already modified, though it needs ullix to check what I did and change something (it is his code, not mine) |
| Stargazer 40 |
Posted - 07/25/2018 : 13:28:02
Did read everything in the thread, but obviously don't know enough about Python to take his comment at anything other than face value. Sorry.
I'll see if I can find something that tells me how to run simple. Did the adjustment to get right Comm Port and speed, but need to make the change you did to get 4 bytes read instead of 2.
Thanks |
| ikerrg |
Posted - 07/25/2018 : 13:20:14
If you read the whole thread, he said that about the phonon problem, which is related to the Qt4 libraries in any Windows, and it only limits GeigerLog in the sense that it cannot produce sounds. Everything else works perfectly! |
| Stargazer 40 |
Posted - 07/25/2018 : 13:02:18
ullix said he was giving up on Windows. I went ahead and installed Python 3.4 and it installed fine, and I downloaded geigerlog 500 simple, but don't really know how to run anything. My attempts at the command line with the py file all yielded syntax errors. |
| ikerrg |
Posted - 07/25/2018 : 12:51:50
quote:
Ullix's logger apparently has unresolvable issues with Windows 10 (if I misread that I apologize).
What "unresolvable" issues? I couldn't find any, apart from phonon/Qt4 library problems in any Windows. |
| EmfDev |
Posted - 07/25/2018 : 11:00:21
Yes, we'll let you know if it's ready.
I think you can still read it's history and play it back, however the usv/h conversion could still be
the one from old firmware. |
| Stargazer 40 |
Posted - 07/25/2018 : 10:54:31
Updating Viewer is not priority for me. Ullix's logger apparently has unresolvable issues with Windows 10 (if I misread that I apologize). GMC.MAP properly presents the counts so that is fine. Thanks for getting around to upgrading the Viewer when time and making announcement on the forum when ready. |
| EmfDev |
Posted - 07/25/2018 : 10:49:03
The firmware update is new so the data viewer will be updated later.
In the mean time, maybe you can use ullix's program. Sorry about this. |
| Stargazer 40 |
Posted - 07/25/2018 : 10:46:07
EmfDef,
Reading MSB for the most part will be zero, so that is likely the issue for the Viewer. Says that the viewer will likely need an upgrade as well so it can read the new 4 byte data.
Thanks! |
| EmfDev |
Posted - 07/25/2018 : 10:37:44
@Stargazer40, maybe the software read the first 2 bytes of the data and it discarded the other 2, I don't know how it is coded I didn't write the software.
@ikerrg,
getcpm outputs ==>> (MSB) (x) (x) (LSB)
example.
CPM of 10 is going to be
00 00 00 0A |
| ikerrg |
Posted - 07/25/2018 : 10:29:52
@EmfDev
Could you tell us what is the structure of the 4 bytes of data returned by the functions GETCPM, GETCPMH, GETCPML, GETCPSH and GETCPSL in the new 1.18 firmware? Are they just 32 bit integers?
Thanks. |
| Stargazer 40 |
Posted - 07/25/2018 : 10:17:49
Not able to get readout on GMC Data Viewer. Comm port good and Real Time Monitoring started, but nothing showing up on screen for any of the tube combinations.
I very much like under the large font option that the selected tube combo is large letters CPM and both tubes whether selected or not show counts beneath that.
|
| EmfDev |
Posted - 07/25/2018 : 08:50:59
Thank you guys too for your suggestions in improving 500+! |
| Stargazer 40 |
Posted - 07/25/2018 : 08:44:30
I think you have just added a lot of value to this meter. For me to acquire it at the cusp of a firmware release of this magnitude is really great. Thanks for what is to me simply amazing responsiveness from a developer. VERY NICE INDEED! |
| EmfDev |
Posted - 07/25/2018 : 08:38:02
Yeap If you don't like the new software, you can just install the old one. |
| Stargazer 40 |
Posted - 07/25/2018 : 08:37:50
With Tube 2 only, the number reported to GMC.MAP is from Tube 2 only. If GMC.MAP is expecting M4011 tube counts, and the SI3BG tube is in place the software should be selectable for which tube's CPM is reported to GMC.MAP. We might want to always report Tube 1 CPM to GMC.MAP no matter what we are actually monitoring local. Might add that in future.
Otherwise all appears to work as expected. |
| Stargazer 40 |
Posted - 07/25/2018 : 08:26:49
Found it all under Init Setup/Calibrate.
Thanks |
| Stargazer 40 |
Posted - 07/25/2018 : 08:21:46
Oops, V 2.02 is Firmware Update software version.
So Firmware 1.18 was installed.
Where can we select tube and weighting? |
| Stargazer 40 |
Posted - 07/25/2018 : 08:10:29
Loaded new Version 2.02. When complete with good write shows Re 1.18
I believe the unit arrived with version 1.17 installed.
Is there a problem with installer?
Couldn't find any tube selection or weighting factor input in the menus.
Thanks |
| EmfDev |
Posted - 07/24/2018 : 14:40:27
It's not really an error, it's just caused by different tube sensitivity. Because they can vary a lot.
Like even 2 same sensitivity tubes, 1 time reading can be 15 for 1 tube and 20 for other, or can be
5 vs 15, 10 vs 20, that's basically 100% differnce, which one is higher doesn't really
mean that's more accurate. So we'll use the other lower point calibration of tube1 to be the threshold to not check the tube2 reading.
if(tube1CPM < somethreshold.0) use tube1 and lower calib of tube1
else if(tube1CPM < somethreshold.1 and tube2CPM is somethreshold2) use tube1 and second calib of tube 1
else use weighting algoritm and second calib of tube, and calib of tube 2
the 2 calibs of tube1 (uSv/h / CPM) are basically equal but just diff values of usv and cpm.
Changed it to 1.25*threshold
You guys can contact customer support to check if the final version
is ready.
Thank you all for your suggestions, let us know if you find any
critical bugs.
|
| ikerrg |
Posted - 07/24/2018 : 12:50:26
I would probably use less than 50% as the "courtesy error" for the calculation of some_threshold2. Something in the range of the expected error (15 to 20%), like some_threshold2 = (1.2*some_threshold1/tube2Weight)
I see what you mean about the automatic range, those numbers are already in my Excel file. It is fair enough, as the user can select to use only tube 2.
Let's see how this updated firmware behaves! |
| EmfDev |
Posted - 07/24/2018 : 09:19:00
@Stargazer 40 Thanks!
quote:
if ((CPM1 < SOME_TRHESHOLD1) & (CPM2 < SOME_TRHESHOLD2)), then use tube1CPM
for this one I can add some_threshold2 = (1.5*some_threshold1/tube2Weight)
quote:
However, if you avoid the third step, you will increase the error at high radiation (see the last Excel I uploaded changing the nonlinearity column in tube 1) and you will depend on the tube 1 behaving more or less correctly in high radiation (the error would be more than 15% at “only” 6500 uSv/h). It is true that probably nobody will use that device in such high radiation and that it is not so important now that the user can decide to use only the second tube. However, it is almost costless (just some more programming). It is obviously your call. You can always implement only the 2 steps as you indicated and do a battery of tests with the two signal generators to see what the readings in different scenarios are. If that does not work as expected, you can try with the three step algorithm.
That's ok because users can already configure which tube to use.
On the other hand, we should be using the weighing formula even in under tube1-30,000 CPM (with more weight on tube1) since
the user picked both tubes to use. They might get confused if the tube2 generated count at low cpm but the uSv'h didn't increase.
Some quick calculations for worst case scenario at tube1 theoretical saturation(.2ms dead time or 300,000CPM or could be higher
MAx CPM = 655,350 from website) where tube1CPM = 0;
at 1950 uSv/h
then uSv = (0 + (300,000/30)*30*X)/(1+X) = 253583.101105 effective cpm compared to 300000CPM
which is 15.47% error, which is already the worst case scenario.
if this happens the user can just change the tube to tube 2 or whatever they prefer.
quote:
And, what do you think about using the CPS instead of the CPM in the comparisons to have a more dynamic response?, as in:
That's actually ok but it could generate instant jump/fall becasue of inconsistent CPM sources. Also 1 pulse doesn't really mean that much
in uSv per HOUR.
It will switch the formula anyway if CPS is equal to some_threshold1 or slowly change if it's lower than some_threshold.
And user again can just configure tube 2 if they want. That's why we added configuring tubes to
just remove a lot of complexities in the calculations that might be unnecessary. |
| ikerrg |
Posted - 07/24/2018 : 00:47:32
quote:
in 3, there's only 2 steps calculation.
1. if CPM < SOME_TRHESHOLD, then use tube1CPM
Be careful with that algorithm. If tube 1 saturates in an unexpected mode, i.e. reducing the number of counts for whatever reason, the device could behave erratically at high radiation levels. It is worth adding a comparison that takes into account the tube 2 reading just in case the tube 1 is not doing what we expect, something like:
if ((CPM1 < SOME_TRHESHOLD1) & (CPM2 < SOME_TRHESHOLD2)), then use tube1CPM
To avoid more user input, the value SOME_TRHESHOLD2 can be automatically estimated from SOME_TRHESHOLD1 as SOME_TRHESHOLD2 = SOME_TRHESHOLD1/tube2Weight.
quote:
2. else use uSv/h = (tube1CPM*tube1Weight + tube2CPM*tube2Weight*X)/(1+X) * (calib_usv1/calib_cpm1) where X = sqrt(tube2weight/tube1weight)
**The threshold depends on the second calibration CPM data of tube 1
** this is just to avoid complexity in picking which tube to use, since the user can already pick which tube to display.
I very like the idea that the threshold (SOME_TRHESHOLD1) is user customizable using the current three point calibration of the device. Well spotted!
However, if you avoid the third step, you will increase the error at high radiation (see the last Excel I uploaded changing the nonlinearity column in tube 1) and you will depend on the tube 1 behaving more or less correctly in high radiation (the error would be more than 15% at “only” 6500 uSv/h). It is true that probably nobody will use that device in such high radiation and that it is not so important now that the user can decide to use only the second tube. However, it is almost costless (just some more programming). It is obviously your call. You can always implement only the 2 steps as you indicated and do a battery of tests with the two signal generators to see what the readings in different scenarios are. If that does not work as expected, you can try with the three step algorithm.
In any case, whatever algorithm you pick, some debugging is needed in order to find unexpected behaviours in different tube CPM scenarios.
And, what do you think about using the CPS instead of the CPM in the comparisons to have a more dynamic response?, as in:
if ((CPS1 < SOME_TRHESHOLD1) & (CPS2 < SOME_TRHESHOLD2)), then use tube1CPM
where SOME_TRHESHOLD1=second calibration point/60.
Thanks.
|
| Stargazer 40 |
Posted - 07/23/2018 : 15:32:04
I don't believe I have ever seen this kind of response from an electronics vender. Simply amazing! THANK YOU!
Got my 500+ about a half hour ago. Charging. Looks really nice. Probably get another for a second home in mountains.
You guys are great!
|
| EmfDev |
Posted - 07/23/2018 : 13:59:26
tube2Weight = (nCalibtationData2.uSv/(nCalibtationData2.nCPM))
/ ((nCalibtationData1.uSv)/(nCalibtationData1.nCPM));
==> for example this is going to become (.194/.0065) which is close to 30
X = sqrt(tube2Weight) |
| EmfDev |
Posted - 07/23/2018 : 13:53:54
I just edited my comment, let me know if its ok. |
| ikerrg |
Posted - 07/23/2018 : 13:48:33
Thanks for keeping us informed, EmfDev. And thanks again for hearing us!
Please, tell us when the new firmware is available so we can contact the technical support. |
| EmfDev |
Posted - 07/23/2018 : 10:10:09
Thanks for all your inputs, we will try to implement this:
3 options for the user to select,
1. Tube 1 (Low dose tube) only use tube 1
2. Tube 2 (High dose tube) preferable for high CPM/S readin
3. Combination.
in 3, there's only 2 steps calculation.
1. if CPM < SOME_TRHESHOLD, then use tube1CPM
2. else use uSv/h = (tube1CPM*tube1Weight + tube2CPM*tube2Weight*X)/(1+X) * (calib_usv1/calib_cpm1) where X = sqrt(tube2weight/tube1weight)
**The threshold depends on the second calibration CPM data of tube 1
** this is just to avoid complexity in picking which tube to use,
since the user can already pick which tube to display.
From the menu, after changing which tube to use, user might want to
restart the device to reset the counts.
For 500+ users, there will be an option to display tube1, and tube2
CPM's in the large font mode.
The CPM displayed and SAVED to the memory will be the CPM/S of the
selected tube. |
| ikerrg |
Posted - 07/21/2018 : 04:28:49
@EmfDev,
First of all, congratulations for the support that you are providing about this problem. We are much closer now to unlock the real potential of the GMC-500+!
Whatever is the algorithm that you finally pick to automatically calculate the uSv/h with both tubes at low and high ranges (like the autorange in a multimeter), I still think that the best option to add to the device is what I proposed some days ago in Reply #12:
quote:
- There is another option, which probably is the best one. Add a menu option so the user can select which tube to get readings from, with the options “high sensitivity tube”, “low sensitivity”, and “combination”. In this way, the user that only does background radiation, will have their devices set at "high sensitivity" and only the data from tube one and the conversion factor for tube 1 would be used. The user that wants to play inside the Fukushima reactor can select “low sensitivity”, or “combination” where the previous algorithm will be used by the software to automatically combine or switch between tubes.
By this way the user can select “manual range” and pick one of the two options ("high sensitivity" or "low sensitivity"), or select “auto range”, and the firmware does the combination with any of the proposed methods (it might also indicate on the screen which range it is using as Stargazer 40 was proposing). With this menu option, the advanced user could also find the sensitivity of both tubes independently when immersed in the same radiation field, and therefore set customized calibration factors with much more accuracy. It is a win-win option!
Now, only about the automatic “auto range” algorithm:
quote:
The problem of just switching to tube2 (only) above the threshold 30000 CPM is, if tube1 is 30,000CPM (195 uSv), we expect tube2 to be 1000 CPM (195uSv), but the reading won't be exactly 1000CPM, it can vary maybe 900, 800, 1200 CPM, or even higher or lower, then the uSv reading will be at the maximum error compared to if we average them.
That is effectively saying that the sensitivity of tube 2 is not known and the calibration factors we use are not good. OK, to smooth that behavior whatever the calibration factor is, you could easily add a comparison that makes sure that the switching from tube 1 to tube 2 only happens when the CPM in tube 2 is enough to match the uSv/h calculation from tube 1. And the same in the opposite direction. Something like:
quote:
if( (uSv/h of tube2 - uSv/h of tube1)/uSv of tube1 is greater than 10%?, then we will use uSv/h of tube2, also vice versa if tube1 uSv/h is significantly greater than tube2.
After doing some simulations in Excel (download it here: https://www.dropbox.com/s/n4xjnfddmfpeahg/TubeCombination2.xlsx?dl=0 ), my vote goes for these options (three ranges):
1.- if tube1CPM < 30,000 (CPS < 500) then uSv/h = tube1CPM*(calib_usv1/calib_cpm1) ==>> this will give equal uSv/h as GMC-500, 300, and 320. The other option that you propose is very good if saturation of tube1 starts earlier that 30,000, but it adds complexity and weighting factors to something that is not actually needed.
2.- if 30,000 < tube1CPM < 60,000 (or any other higher value) then uSv/h = (tube1CPM*tube1Weight + tube2CPM*tube2Weight*X)/(1+X) * (calib_usv1/calib_cpm1) where X = sqrt(tube2weight/tube1weight), as you proposed.
3.- if tube1CPM > 60,000 (or any other higher value) OR tube2CPM > 2000 (or any other higher value) then first check if (tube2CPM*(calib_usv2/calib_cpm2)) > (tube1CPM*(calib_usv1/calib_cpm1)) and, if true, then uSv/h = tube2CPM*(calib_usv2/calib_cpm2) (only tube2 data being used). If false, keep using tube1 until the condition is met. This third range avoids the big error that will happen if tube1 sensitivity drops massively in high radiation for whatever reason (try in the attached Excel), and it seems sensible to use only tube2 at very high radiation levels. I still think that you should show on the screen both CPMs of the tubes independently (there is space on the screen!), but if you prefer a combined number at this 3rd step that is continuously smooth with the step 2, you can continue showing the combined CPM as calculated in step 2, i.e. CPMequiv = (tube1CPM*tube1Weight + tube2CPM*tube2Weight*X)/(1+X). Again, see the effect in the Excel file.
In your formulas, when you say (calib_usv/calib_cpm), I suppose you are always referring to tube1 values (0.0065). I have specified above whether the numbers are from tube1 (0.0065) or tube2 (0.194). For the tube weights, I suppose that they are automatically calculated from the calibrated sensitivities, with no need for additional user input for the weights.
And I would use CPS for the comparisons because at these high radiations the jump between steps depends a lot on the distance to the source, and the user might want to see the instantaneous dose rate in uSv/h without having to wait around 1 minute for the auto range algorithm to swap between calculations.
|
| Stargazer 40 |
Posted - 07/20/2018 : 18:37:51
We really then need to deal only with the transition from all tube 1 to all tube 2, smoothing that out. The line above about switching to all tube 2 when (uSv/h of tube2 - uSv/h tube1)/uSv of tube1 is greater than 10% may make actual smoothing algorithm less critical if getting to that point is narrow range of CPM increase versus jump to tube 2 uSv/h.
To be honest, I think safest approach may be to simply manually set range of meter by menu to either tube1 or tube2 with indicator on display. Like analog meters of old with simple switch for 5, 50, 500 mR/H. |
| EmfDev |
Posted - 07/20/2018 : 16:03:43
From the previous algorithm, the limit is 4250 uSv/h for 500, and 42500 for 500+. I am not sure how it was calculated (probably testing
the limit to high radiation). I'll have to check later. 4250 uSv = 655350 CPM
But in the new solution, the the limit will be the max CPM (saturation) of both tubes.
As long as the processor can handle the counts (up to 3.9 Million CPM or 65000 CPS for each counter),
but the Tubes will already be saturated far before they reach that CPM.
The problem of just switching to tube2 (only) above the threshold 30000 CPM is,
if tube1 is 30,000CPM (195 uSv), we expect tube2 to be 1000 CPM (195uSv), but the reading
won't be exactly 1000CPM, it can vary maybe 900, 800, 1200 CPM, or even higher or lower,
then the uSv reading will be at the maximum error compared to if we average them. It can also
confuse the user for example if you are moving closer to a high radiation source and the tube1 count jumped from 29000
to 3100 but tube2 during that time is 900, then you will notice the uSv convertion is now much lower
than your expected value because it used the 900 to convert it to uSv (we expect more than 1000CPM to get the expected uSv).
But we'll see which one we'll be using.
Right now the firmware should be good for your liking if you're not concerned about critical numbers because the
algorithm is coded that way.
Hahaha most cases people will already know they're in lethal range if they see that much CPM.
|
| Stargazer 40 |
Posted - 07/20/2018 : 14:59:22
And to be clear the tube 1 solution is limited to 4250 uSv and the tube 1 and 2 solution is limited to 42500 uSv?
If I could implement all three of the solutions EmfDev just laid out in settings, I think that would be great. I wouldn't know how they could be tested however on the higher limits, so likely would simply employ the one that above 30,000CPM only makes use of tube 2. For me it's about order of magnitude of radiation, not lab critical number.
Also if 30,000 counts exceeded and switch to tube 2 or one of the combined mixes, it would be nice if the 'HIGH' warning could change to something like 'LETHAL'
Thanks |
| EmfDev |
Posted - 07/20/2018 : 14:32:07
@Stargazer
Thanks for your comments. Yeah we just want to improve the GMC-500+ uSv conversion.
@ullix, @ikerrg
As of now, we have
if tube1CPM < 30,000, then uSv/h = tube1CPM*(calib_usv/calib_cpm) ==>> this will give equal uSv/h as GMC-500, 300, and 320
OR
if tube1CPM < 30,000, then uSv/h = (tube1CPM*tube1Weight + tube2CPM*tube2Weight)/(1+1) * (calib_usv/calib_cpm)
But we might want to
if tube1CPM > 30,000, then uSv/h = tube2CPM*(calib_usv/(calib_cpm*(tube2Weight/tube1Weight))) (only tube2)
OR
if tube1CPM > 30,000, then uSv/h = (tube1CPM*tube1Weight + tube2CPM*tube2Weight)/(1+1) * (calib_usv/calib_cpm)
this willl give the average of the 2 tubes but we might want to increase the weight of tube2 so that
it can reduce the error during tube1 saturation.
==> uSv/h = (tube1CPM*tube1Weight + tube2CPM*tube2Weight*X)/(1+X) * (calib_usv/calib_cpm) where X = sqrt(tube2weight/tube1weight)
There is also
if( (uSv/h of tube2 - uSv/h of tube1)/uSv of tube1 is greater than 10%?, then we will use uSv/h of tube2,
also vice versa if tube1 uSv/h is significantly greater than tube2
This is to reduce errors in non-homogeneous radiation fields.
The tube weights can be configured by the user.
@ikerrg, Sorry but I don't think we will support saving both CPSs to the EEPROM, at least not in GMC_500+. |
| Stargazer 40 |
Posted - 07/20/2018 : 12:04:18
Thanks for going through all this. I do like the idea of the last sentence in first post -
"One way to fix this is to ignore tube2Count until certain level and only use tube1Count (best is until tube1 saturation count) but
we need time to determine those values. It's hard to find the saturation count because each tubes have different saturation limit."
and of using only a single tube at a time. I agree that there is likely a cutoff number that will work quite well with an estimate of saturation of the more sensitive tube and not have poor performance of the less sensitive tube. Hopefully GQ can go through some testing and come up with a number that works the majority of times. Just ordered a 500+ and given this conversation have some concerns about just what the two tubes are telling me if they are combined somehow.
Thanks |
| EmfDev |
Posted - 07/20/2018 : 10:28:07
Someone else tested and I don't have access to the data.
I think you misunderstood my statement, I was saying different tubes will have different sensitivity.
There are 2 independent 32bit counters attached to each tube. We can switch off the counters or just ignore
its reading. But what is the point? |
| ullix |
Posted - 07/20/2018 : 00:01:09
@EmfDev: quote:
Not all tubes(tube2) have same sensitivity at lower level of radiation that's why the calibration of tube 2 is 30 times of tube 1 because is was assumed to be a low sensitive tube and is tested in high levels of radation.
So you have tested the tube in high levels of radiation? Can you show us the data?
I am very surprised about your claim that the tube has lower sensitivity at low radiation level. I never heard that before, and I find it hard to imagine given the mechanism of its functioning.
When a count is generated in the tube, the pulse of the electric discharge in the tube plus any pulse lengthening in the electronics last 0.2 millisecond (or less). At high rates the tube then sits idle for, let's say, a millisecond before the next pulse comes, or only 5 times the pulse length, it responds well. But when the tube has to wait for 1000 milliseconds, totally undisturbed, everything well charged, the tube becomes less responsive?
I think this is a major discovery, which will certainly have been published somewhere. Please, provide us with a link or reference to your source for this important information.
I had asked a question ina previous post, which you may have overlooked; I'd appreciate an answer:
quote:
Let me ask: Is it even possible to switch off the 1st tube in this way in the current 500+ unit?
|
| EmfDev |
Posted - 07/19/2018 : 11:19:41
The display CPM is just there to display, but the uSv/h is calculated differently.
I remember I mentioned before from other threads that the counter is 32 bits and can handle up to 65KHz (3.9M CPM for each
tube).
Not all tubes(tube2) have same sensitivity at lower level of radiation that's why the calibration of tube 2 is 30 times
of tube 1 because is was assumed to be a low sensitive tube and is tested in high levels of radation. |
| ikerrg |
Posted - 07/18/2018 : 01:20:30
Adding both tube’s CPM is like adding pears and apples. They are not the same at all, the sum does not represent anything.
Anyway, about the uSv/h conversion:
- First of all, the conversion in the present calibration is not 0.195, but 0.194 (4.85/25). I suppose that those numbers for the formula will be taken from the user customizable calibration in the device, so their exact value does not matter at this time.
- Assuming that the tube 2 is working as expected, at 195 uSv/h (30000 CPM in tube 1) it should be quite sensitive by itself (detecting about 1005 CPM or 16.75 CPS), so I do not see why we need to consider the tube 1 above that radiation level. The formula you proposed cannot take into account an unknown reduction in sensitivity of the first tube with increasing CPM, and it will keep returning the CPM readings of the tube 1 slightly corrected by the readings of tube 2 (but still with plenty of error), hence the conversion to uSv/h will be wrong at higher radiation levels (see and play with the spreadsheet in https://www.dropbox.com/s/bj3tgun2z3b9xpf/TubeCombination.xlsx?dl=0 ).
- I agree that for non homogeneus radiations (when the CPMs are not related by the sensitivity ratio of the tubes), the firmware should return the readings of only the biggest corrected reading from both tubes, or just do nothing due to a wrong use of the device as ullix says. It is easy enough though that if the first tube is reading 1000 CPM and the second is reading 6.7 CPM, the firmware could internally calculate the dose rate of both independently (6.5 uSv/h and 1.3 uSv/h respectively in this case) and discard the lowest one.
- There is another option, which probably is the best one. Add a menu option so the user can select which tube to get readings from, with the options “high sensitivity tube”, “low sensitivity”, and “combination”. In this way, the user that only does background radiation, will have their devices set at "high sensitivity" and only the data from tube one and the conversion factor for tube 1 would be used. The user that wants to play inside the Fukushima reactor can select “low sensitivity”, or “combination” where the previous algorithm will be used by the software to automatically combine or switch between tubes.
I hope I did not say something too stupid ;)
|
| ullix |
Posted - 07/17/2018 : 23:46:48
@EmfDev: I am not sure I can follow.
Are you now trying to accommodate a user who inappropriately handles the counter by bringing it into an inhomogeneous radiation field, where one tube gets more than the other?
Don't!
It is your responsibility to explain to the user the more demanding requirements of this more complex counter (here a homogeneous radiation field). But for your firmware you assume this condition is met. It is complicated enough anyway.
Your true main problem is the saturation of the 1st tube. At a certain point, at the very latest at CPS=5000, the tube will be in saturation and probably not deliver any counts at all, because they follow so close to each other that the electronics cannot distinguish between them. And even if it could, we'd see CPM=300 000, which it coulnd't handle as a 16bit number, limited to 65000.
To avoid this, well before this limit, the tube must be switched off. Preferably by switching off the high voltage, but at least by switching off the access to the counting circuitry.
Let me ask: Is it even possible to switch off the 1st tube in this way in the current 500+ unit?
|
| EmfDev |
Posted - 07/17/2018 : 10:25:57
** This is for calculating uSv/h, the CPM displayed will still be the sum of both tubes.
for calculating uSv/h
We thought of using tube1 for cpm lower than 30k. Then use the formula
(10000 * 1 * 5.48 + 333.333 * 30 * 1) / (5.48 + 1) = 9999.998
if tube1 is higher than 30k. However, we need to find a point where
we need to use tube2 instead of tube1 at <30k tube1cpm if tube2 uSv/h convertion (tube2count*.195)
is significantly higher than tube1 uSv/h convertion. It can happen if the users try to put a source
much close to the low sensitivity tube. So need to find point where the uSv/h convertion of tube2
is significantly high enough that we only use the tube2(or both). can also happen during saturation.
Then tube 2 can go much higher than tube 1. |
