GQ Electronics Technical Support Forum Active Users: / Visits Today:
Highest Active Users:
GQ Electronics Technical Support Forum
Home | Profile | Register | Active Topics | Members | Search | FAQ
Username:
Password:
Save Password
Forgot your Password?

 All Forums
 GQ Electronics Forums
 1.Geiger Counter World Map(www.GMCmap.com)
 Time issues with GMC-500+ and gmcmap

Note: You must be registered in order to post a reply.
To register, click here. Registration is FREE!

Screensize:
UserName:
Password:
Format Mode:
Format: BoldItalicizedUnderlineStrikethrough Align LeftCenteredAlign Right Horizontal Rule Insert HyperlinkInsert EmailInsert Image Insert CodeInsert QuoteInsert List Spell Checker
   
Message:

* HTML is OFF
* Forum Code is ON
Smilies
Smile [:)] Big Smile [:D] Cool [8D] Blush [:I]
Tongue [:P] Evil [):] Wink [;)] Clown [:o)]
Black Eye [B)] Eight Ball [8] Frown [:(] Shy [8)]
Shocked [:0] Angry [:(!] Dead [xx(] Sleepy [|)]
Kisses [:X] Approve [^] Disapprove [V] Question [?]

   Insert an Image File
Check here to include your profile signature.
    

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

GQ Electronics Technical Support Forum © Copyright since 2011 Go To Top Of Page
Generated in 0.05 sec. Snitz's Forums 2000