Author |
Topic |
|
donghelan
Japan
65 Posts |
Posted - 11/03/2018 : 03:26:01
|
3 Time related issues:
1. Why gmcmap adds a few seconds to the original data time stamp? Don't touch data which are NTP synchronized. You should keep as original logged.
2. Wrong GMT-7 header info in history data of gmcmap. The data in history show in UTC/GMT which is correct imho even when the data sent are in UTC+9 (Japan) but please don't show in the header of history incorrectly that it is GMT-7 (probably your Timezone?). Of course I could change temporarily into Local time zone but UTC is fine.
3. Why the GMC-500+ does not have its own RTC, run from battery (or USB)? The internal clock is always "sleeping". It is totally meaningless to synchronize the GMC-500+ clock with the host PC now.
See data history here from Yokohama Japan: www.gmcmap.com/historyData.asp?Param_ID=7472099179
The CPM1st data are automatically sent from Ullix's Geigerlog.py, pulled from a GMC-500+ with FW 1.20 over USB cable. Please Notice that the correct CPM1st values are logged and sent and not wrongly the Summation of CPM1st and CPM2nd. It is no meaning and incorrect to send the sum of both sensors. The 2nd sensor could be useful only when close to a contaminated area like Fukushima NPP1
Image Insert:
82881 bytes |
To bug or not debug, that is the Q |
Edited by - donghelan on 11/03/2018 17:47:50
|
|
Reply #1
donghelan
Japan
65 Posts |
Posted - 11/03/2018 : 17:37:33
|
CPM is sent every minute as a positive Integer value. Floating point values with decimals are unnecessary. It is also unnecessary to send ACPM which has to be the same anyway. From now on: - ACPM value is omitted. - CPM (CPM1st value) is positive integer.
gmcmap popup window of the monitoring station should not show 0 value for ACMP. Should be left empty instead See image below.
Image Insert:
44528 bytes |
To bug or not debug, that is the Q |
|
|
Reply #2
EmfDev
2260 Posts |
Posted - 11/05/2018 : 15:52:46
|
Hi donghelan,
Sorry for the inconvenience. 1. The the device doesn't send the time to the server, the time you see in the history is the time the server received the data. 2. That header is going to be removed. Yes that is probably a mistake. 3. The 500+ should have RTC, have you tried syncing the time? How do you know it's sleeping?
The device sends a string to the server and not decimals/numbers but yea we'll let the developer know about these issues. Thank you for your feedback.
|
|
|
Reply #3
donghelan
Japan
65 Posts |
Posted - 11/06/2018 : 04:17:39
|
EmfDev thanks for the follow up. As written I use Ullix's GeigerLog over USB link. Wifi is disabled. GeigerLog has this feature to Set dateTime on the device, the result tells me enough:
=== Set Date&Time of Device ===================================== Date and Time from device is: 2018-11-04 14:59:26 Date and Time from computer is: 2018-11-06 21:13:49 Device is slower than computer by 195263 sec
Setting device time to computer time New Date and Time from device is: 2018-11-06 21:13:49 |
To bug or not debug, that is the Q |
|
|
Reply #4
veryber
USA
3 Posts |
Posted - 11/07/2018 : 03:51:14
|
I am having the same problem. Glad to find this thread. I hope you guys will sort out this issue. |
|
|
Reply #5
EmfDev
2260 Posts |
Posted - 11/07/2018 : 09:42:19
|
@veryber, did you have this issue when you received the unit? or was it working at first? Thanks. And what is the version of your firmware? We're still looking if you guys need to ship it back for repair or replacement. |
Edited by - EmfDev on 11/07/2018 10:10:45 |
|
|
Reply #6
donghelan
Japan
65 Posts |
Posted - 11/08/2018 : 16:11:30
|
quote: Originally posted by veryber
I am having the same problem. Glad to find this thread. I hope you guys will sort out this issue.
Check the result under my issue "GMC-500+ RTC HW or FW issue?" in the Geiger Counter forum: www.gqelectronicsllc.com/forum/topic.asp?TOPIC_ID=5552 From the high resolution image you will be able to compare and recognize if your counter misses X-tal X2 for the RTC too.
|
To bug or not debug, that is the Q |
|
|
|
Topic |
|