| T O P I C R E V I E W |
| donghelan |
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 |
| 6 L A T E S T R E P L I E S (Newest First) |
| donghelan |
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.
|
| EmfDev |
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. |
| veryber |
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. |
| donghelan |
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 |
| EmfDev |
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.
|
| donghelan |
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 |
