| T O P I C R E V I E W |
| donghelan |
Posted - 11/05/2018 : 15:37:48
Pulled this issue from another gmcmap time related issue I submitted a few days ago to the right place here :)
3. Why the GMC-500+ does not have its own RTC active, run from battery (or USB power)?
The internal clock is always "sleeping".
It is totally meaningless to synchronize the GMC-500+ clock with the host PC.
Last time the Date/time was updated, was on 4 Nov on the GC.
Is the sleeping GC clock a FW (1.20) or HW problem?
Used Ullix's Geigerlog from the beginning over USB serial link that is why I kind of ignored the problem.
Also wifi is not needed (yet), disabled from the beginning.
Is wifi link always necessary? i.e. does the internal clock always depend on a NTP sync?
I didn't open up the Geiger counter yet.
Can you Please provide verification points on the PCB to narrow down the RTC problem?
|
| 50 L A T E S T R E P L I E S (Newest First) |
| donghelan |
Posted - 12/09/2018 : 15:27:21
After a few days having a much faster ticking RTC with more than 2 min per day faster, today it starts to slow down to only 80sec faster over 24hrs.
Ambient Temperature about 12 degrees Celsius lower.
The trend will be downwards again. As the designer of GQE advised 10ppm stability is not enough.
5ppm Chrystals are more expensive than a complete DS3231 mini board. |
| donghelan |
Posted - 12/08/2018 : 07:11:28
227JPY@amazon jpn will be worth trying ;) https://www.amazon.co.jp/dp/B00YQZFMMQ/
Guess I am old school without ntp syncing ability, devices need their own accurate RTC.
|
| EmfDev |
Posted - 12/05/2018 : 17:18:41
It's more expensive though. |
| donghelan |
Posted - 12/05/2018 : 05:46:56
quote:
Originally posted by EmfDev
It's possible that temperature has something to do with the change. And according the our engineer, you need a crystal with 5ppm tolerance or lower to get a more accurate RTC.
But don't worry about it, the local RTC is only for reference.
Yeah right. the one I bought is 10ppm which is not bad. I wouldn't expect this strong fluctuation with temperature.
The RTC is usually used for the base time-stamp that is why accuracy is relevant.
The DS3231 is definitely the best way to go with a build-in TXCO:
->https://blog.heypete.com/2017/07/29/a-look-inside-the-ds3231-real-time-clock/
Downside is that this chip has 16 legs. |
| EmfDev |
Posted - 12/04/2018 : 16:27:07
It's possible that temperature has something to do with the change. And according the our engineer, you need a crystal with 5ppm tolerance or lower to get a more accurate RTC.
But don't worry about it, the local RTC is only for reference. |
| donghelan |
Posted - 12/04/2018 : 15:46:03
Couldn't get a new X-tal yet.
Maybe it is not useful at all because the RTC got faster now more than 7min. (438 sec!).
Must be due to higher ambient temperature since yesterday in Yokohama and Tokyo.
Meaning the RTC is very much temperature dependent.
Lets observe the coming days what is happening when King Winter is taking over again 
See observation from Geigerlog below:
=== Connect GMC Device ==========================================
Connected device: GMC-500Re 1.20
Connection: port:'/dev/cu.wchusbserial410', baudrate:115200, timeout:1.0 sec
Variables configured: CPM, CPM1st, CPM2nd, CPS1st, CPS2nd
Number of bytes in CP* records: 4
Geiger tube calibration factor: 0.0065 µSv/h/CPM
Geiger tube#2 calibration factor: 0.48 µSv/h/CPM
Date & Time from device: 2018-12-05 08:41:06
Date & Time from computer: 2018-12-05 08:33:48
Device is faster than computer by 438 sec
Device Power State: ON
Device History Saving Mode: OFF (no history saving)
Device History Threshold Mode: CPM
Device History Threshold CPM: 100
Device History Threshold µSv/h: 0.500 |
| EmfDev |
Posted - 12/03/2018 : 14:22:38
@donghelan,
Yes but it needs to be verified, he needs to maybe check in your location or other ways to see if the CPM drops to around 14. Maybe his tube is little different sensitivity(but I doubt it). |
| donghelan |
Posted - 12/01/2018 : 08:33:51
@Sannexus you should keep the conversion factor as specified by GQE for both tubes. Then you can asses better if one of them should be replaced by GQE.
The 2nd tube could also be more sensitive than usual.
First verify if CPM1st value is close to CPM(sum of CPM1st and CPM2nd) or not. to rule that out.
Also verify the other 3 points mentioned above. |
| donghelan |
Posted - 12/01/2018 : 08:21:54
@Sannexus You are lucky with such RTC! Could you make high resolution image of the Crystal and RTC chip and publish here?.
Maybe you have the right one that compensates stray capacitance in the PCB design. GQE should make a note of that and trace back what exact crystal and brand from which source. |
| donghelan |
Posted - 12/01/2018 : 08:12:23
@emfdev nothing is normal when it deviates from the norm of about 14 CPM. We can only asses it to be normal if:
1. Background radiation appears to be slightly higher (due to the building's material near the sensor, the natural environment, the elevation above sea level or other yet unknown source)
2. Mine or other similar counter shows similar deviation from here in Yokohama at Sannexus's location
3. The counter's main tube(4011?) is not sensitive to photons like other users discovered with theirs (mine is definitely not)
|
| donghelan |
Posted - 12/01/2018 : 07:59:12
@sannexus this map published by the SAFECAST project is useful to check the baseline background radiation for your location. I noticed some locations in Japan have significant higher background historically.
Select AIST/GSJ Natural Bkg in this map to see the background baseline before Fukushima NPP1 disaster:
->https://safecast.org/tilemap/
|
| EmfDev |
Posted - 11/27/2018 : 16:33:00
Hi sannexus, CPM below 50 is normal. Readings are different from location to location so it's hard to tell whether your units is higher than others. I think yours is ok. |
| sannexus |
Posted - 11/27/2018 : 04:30:28
hello Donghelan,
Sorry it took me a while to get back.
from what I can see of the display, my clock doesn't seemed to have deviated at all.
I have the clock sent a few month ago and since then it is plugged in to my iMac USB for power and connected to wifi.
As for the measurements, yes I have noticed that my GMC-500+ shows up quite high.
At the moment showing up as average of 20.29 CPM.
I have another dosimeter PKC-107 and it shows about 10-12#956;Sv/h which I think is normal these days.
I've adjusted the pcm to #956;Sv/h conversion factor down so that GMC also shows up about the same 10-12#956;Sv/h.
Just had a look at other on the map and mine does seemed to show very high, indeed.
Could it have something to do the GMC itself? |
| EmfDev |
Posted - 11/21/2018 : 13:07:28
I wanna go to Japan XD |
| ikerrg |
Posted - 11/21/2018 : 02:50:59
Oh, what good memories brings me that name, Akihabara. I was in Japan more than 10 years ago and that area was truly a paradise for electronics (photo cameras, laptops, watches....) |
| donghelan |
Posted - 11/20/2018 : 15:50:34
Will go to Akihabara today, the "electronic paradise" of Tokyo.
This shop has huge assortment: Akizukidenshi
->https://akizukidenshi.com/catalog/default.aspx.
See if they have the same x-tals on the shelf for same low price as mouser. |
| EmfDev |
Posted - 11/20/2018 : 11:35:35
@donghelan,
Thank you for your hard work! They might work. |
| donghelan |
Posted - 11/19/2018 : 15:48:52
quote:
Originally posted by ikerrg
500+ V1 crystal: A324J
500+ V2 crystal: A748N
Both crystals are in identical position (at the same distance from the DS1302 chip).
I don't find any designed for CL=6pF at Mouser (but cheap):
FC-135 32.768KHZ ( a748n links to FC-135):
-->https://www.mouser.jp/All-Manufacturers/_/N-0?Keyword=FC-135 crystal&No=25&FS=True
a748n expensive if you buy 1, without proper specifications Made in China:
-->https://www.yoycart.com/Product/567838256708/
Could imply that a748n X-tal is designed for higher CL.
The identification of Epson crystals is hard to grasp.
What is printed on it does not match the product id. Or am I overlooking something again?
This spec is close, not designed for CL=6pF:
-->https://www5.epsondevice.com/en/products/crystal_unit/fc135r.html
You really wouldn't like to design a RTC with DS1302 chip.
When you read all these different specifications it ends up a real trial and error exercise.
|
| donghelan |
Posted - 11/19/2018 : 15:07:32
quote:
Originally posted by EmfDev
@donghelan, Thank you for your work and very helpful information. We will forward it to our hardware engineer.
Thank you! I will study till I die |
| EmfDev |
Posted - 11/19/2018 : 10:38:45
@donghelan, Thank you for your work and very helpful information. We will forward it to our hardware engineer. |
| ikerrg |
Posted - 11/19/2018 : 09:33:10
500+ V1 crystal: A324J
500+ V2 crystal: A748N
Both crystals are in identical position (at the same distance from the DS1302 chip). |
| donghelan |
Posted - 11/19/2018 : 06:55:58
quote:
So my 500+V2 seems to have a crap crystal!
I had to read this sentence from the application note a few times:
quote:
If the capacitive load is less than the crystal was designed for, the oscillator runs fast. If the capacitive load is greater than what the crystal was designed for, the oscillator runs slow.
Then the V2 crystal's specified Load Capacitance could be too high, much more than 6pF.
V1 is acceptable, maybe half minute per month deviation.
Then it looks like my Crystal could be right because it is the necessary specified 6pF but additional stray capacitance slows the oscillator down.
With a next order of components I will try crystals designed for CL of 7pF and 9pF to see if that compensates the stray capacitance in the PCB design.
As I have shown in the beginning of this thread, a DS1302 RTC chip has a bad reputation in the Arduino community.
Now we experience why. It is a very sensitive exercise to get it in tune.
|
| Stargazer 40 |
Posted - 11/19/2018 : 06:11:35
Any difference in markings on the two crystals? |
| ikerrg |
Posted - 11/19/2018 : 06:07:29
Last time that I synchronized the 500+ (V1 and V2) clocks with my PC was during the last firmware update. I did it at about 9 in the morning, GMT. Now the readings are:
COUNTER Start Date/Time [GMT] Final Date/Time [GMT] Final GMC date Time[GMT] Deviation
500+V1 2018.11.09 09:00:00 2018.11.19 14:02:10 2018.11.19 14:02:18 +00:00:08
500+V2 2018.11.09 09:00:00 2018.11.19 14:02:10 2018.11.19 14:03:25 +00:01:15
So my 500+V2 seems to have a crap crystal!
|
| donghelan |
Posted - 11/19/2018 : 04:49:48
I will start at 22:00:00 this evening.
Correction: actually started at 22:01:00 JST (Tokyo time) |
| donghelan |
Posted - 11/19/2018 : 04:46:54
quote:
Originally posted by Stargazer 40
I guess I could sync with phone on the first of the month and we could tabulate. I take it the RTC will continue at along as there is power to the meter. So stationary or take it with you and keep it charged?
My Phone and PC are always in sync. PC syncs with NTP servers. Phone might sync with GPS, Mobile Network or also NTP servers, it is usually good within 1 sec.
Just keep it charged, stationary on USB or in the field and sometimes on the charger.
I just take note of the starting date time of sync[JST], final date time [JST], and the final date time [JST] on the GMC-500 e.g..:
Start Date/Time [JST] Final Date/Time [JST] Final GMC date Time[JST] Deviation
2018.11.19 22:30:00 2018.12.19 22:30:00 2018.12.19 22:19:45 -00:10:15
Total deviation is minus 10 minutes and 15 seconds over 30 Days.
|
| Stargazer 40 |
Posted - 11/18/2018 : 14:12:44
I guess I could sync with phone on the first of the month and we could tabulate. I take it the RTC will continue at along as there is power to the meter. So stationary or take it with you and keep it charged? |
| donghelan |
Posted - 11/17/2018 : 17:53:47
To put my observations in perspective we will need the monthly performance of the RTC from other GMC-500+ (or other counters with same RTC design):
Something like:
TABLE RTC PERFORMANCE
User Counter Monthly difference Faster/Slower than RT
Donghelan GMC-500+v2 10min58sec Slower
Stargazer 40 GMC-500+v2 9min30sec Slower
|
| donghelan |
Posted - 11/17/2018 : 17:28:51
After 11 hours(-2min), the RTC was 10 sec behind the PC clock.
PC Clock is NTC synced towards time.asia.apple.com.
Approximate room temperature: 20 C.
The GMC-500+ RTC would be almost 11 minutes per month behind real time at this rate.
Possible causes and remedy:
1. Stray capacitance of PCB board design. The X-tal is placed relatively far away from DS1302 chip.
Review PCB design to put as close as possible as recommended by Dallas Semiconductor/ Maxim.
2. Any Presence of Noise that might stop the RTC sometimes due to PCB signal routing?
Confirm if any signal lines cross the X-tal lines and review multilayer PCB design accordingly.
3. Select X-tal with Load Capacitance CL less than 6pF if significant Stray Capacitance observed.
[edit 2018.11.20:] This should be opposite: a X-tal designed for CL higher than 6pF.
It is easy to misinterpret application notes .
4. Temperatures lower than 20 C contributes only less than 1min per month. No need for Temperature verification.
[edit 2018.11.20] If I heat up the space around the counter to 25 C it would beat a little faster.
Oscillator Accuracy check points:
Image Insert:
191100 bytes
Start sync 2018-11-17 at 22.32.00:
Image Insert:
22036 bytes
Re sync at 2018-11-18 at 09.30.00.
Observed time difference is 10 sec over 11 hours(-2min).
Image Insert:
20712 bytes
X-tal best location. a smaller X-tal is available to match the available space.
Image Insert:
163426 bytes |
| donghelan |
Posted - 11/17/2018 : 02:53:00
Additional pictures of the crystal and work bench.
Mouser Serial Number:
Image Insert:
83814 bytes
xtal reelpackage:
Image Insert:
80429 bytes
Xtal dimensions:
Image Insert:
73918 bytes
Image Insert:
31068 bytes
Before placing:
Image Insert:
109451 bytes
Irons:
Image Insert:
125954 bytes
Xtal in place:
Image Insert:
161587 bytes
|
| donghelan |
Posted - 11/17/2018 : 02:03:35
GOOD NEWS!
The Geiger counter stays in sync with the PC within 0-1 secs.
Finally able to monitor long term stability of the RTC now 
Despite of the fact that my soldering irons are much too big for this sub-millimeter work it takes 20 seconds to get the crystal in place.
As always read the Data sheets well ;)
1. The Micro Crystal CM7V-T1A fits exactly:
- Standard freq.: 32.768 kHz
- Freq. tolerance: 10 ppm (better than recommendation)
- Dimensions: 3.2 x 1.5 x 0.65 mm
- Load Capacitance CL: 6pF
- Series resistance typ./max.: 50 / 70 kOhm;
Only the series resistance is not according the Dallas Semiconductors DS1302 RTC chip recommendation for Crystals:
- Nominal Frequency fO 32.768 kHz
- Series Resistance ESR 45 kOhm;
- Load Capacitance CL 6 pF
- Freq. tolerance, typical: 20 ppm
*The crystal, traces, and crystal input pins should be isolated from RF generating signals. Refer to
Application Note 58: Crystal Considerations for Dallas Real-Time Clocks for additional specifications.
->www.maximintegrated.com/en/app-notes/index.mvp/id/58
2.Soldering work/Processing: 260°C / 20 - 40 s
I didn't have to pass over 20 s. You know when the solder is fluid enough.
Image Insert:
170858 bytes
Image Insert:
201449 bytes |
| EmfDev |
Posted - 11/13/2018 : 16:33:26
@donghelan,
Great! Good luck! Let us know if it works. |
| donghelan |
Posted - 11/13/2018 : 16:10:33
@EmfDev,
No problem, that part can only be so bloody cheap because I had to order other stuff, eliminating transportation costs .
This is an exercise in improving my soldering skills with SMD parts using two soldering irons AND taking care about limiting the Temperature rise towards the other parts on the PCB.
|
| EmfDev |
Posted - 11/12/2018 : 10:02:15
@donghelan, thanks for ordering it yourself and trying to put it to the pcb.
I hope you can make it work. If not then just send back and then we can repair it.
Also you can email support for the payment of the X2 X-tal. |
| Stargazer 40 |
Posted - 11/12/2018 : 04:17:28
@donghelan - Thanks for explaining that. I have GeigerLog installed so will try. |
| donghelan |
Posted - 11/11/2018 : 16:43:02
I have ordered the correct X2 X-tal of 32.768 KHz at mouser Japan for only JPY70. We shouldn't pick just any X-tal.
It is very important what type you insert with the DS1302, Real Time Clock (RTC), TimeKeeping Chip, to keep the RTC ticking accurately.
After it has arrived and I have inserted it successfully I will elaborate on the importance of the quality of this X-tal and the importance of how it should be soldered, located near the chip.
Current location on the PCB is actually not so good.
It is just a matter of reading and following up the data sheets well.
I am curious about the Time deviation to UTC, QC geiger counter owners observe with their counter per month?
Based on that we will know if a matching X-tal was inserted.
If it is in the order of seconds then it was OK.
If it is in the order of minutes then the X-tal wasn't right.
|
| donghelan |
Posted - 11/11/2018 : 15:59:25
@Stargazer 40,
The file gcommands.py of geigerlog contains all commands.
Assuming you have your PC, MAC or Linux box correctly configured to connect over USB link with the GMC,
you can try yourself from a terminal program like TerraTerm, Hyperterminal, Putty or Minicom (Linux/MAC), to send commands to the serial port.
The format of the return values are explained in gcommands.py as well.
That could be a mix of readable ASCII and hexadecimal format binary values, also returned in ASCII format.
You can see below that there is a millennium problem with the returned date format from the Geiger counter, missing 2000.
In 2018, when memory/storage is much less of an issue than in previous century, programmers are still creating these problems for later.
Serial port settings: Baudrate 115200, 8bits, No parity, 1 stopbit and No handshaking.
E.g. get basic configuration by entering in the terminal screen: <GETCFG>>
Get CPM1st, enter: <CPM1st>>
Get date and time, enter: <GETDATETIME>>
Example from the geigerlog gcommands.py file how you have to send commands to the GMC by using Python's serialCOMM function:
def getDATETIME():
# Get year date and time
# send <GETDATETIME>> and read 7 bytes
# returns 7 bytes data: YY MM DD HH MM SS 0xAA
#
# This routine returns date and time in the format:
# YYYY-MM-DD HH:MM:SS
# e.g.: 2017-12-31 14:03:19
dprint(gglobs.debug, "getDATETIME:")
debugIndent(1)
# yields: rec: b'\x12\x04\x13\x0c9;\xaa' , len:7
# for: 2018-04-19 12:57:59
rec, error, errmessage = serialCOMM(b'<GETDATETIME>>', 7, orig(__file__))
|
| Stargazer 40 |
Posted - 11/11/2018 : 11:57:31
quote:
Originally posted by donghelan
EmfDev, thanks for follow up again :)
Yes, it is FW 1.20 as already reported at the start of this thread.
I can only use Unix/Linux compatible software like GeigerLog since I don't own a windows PC.
Geigerlog runs on an old Mac Mini with macOS High Sierra version 10.13.6 (Darwin BSD Unix) .
The hardware version on the PCB is GMC 500 v3.4 20180205.
See additionally below the output from GeigerLog's extended info.
Wifi would only have to do something with the clock if there is a NTP client implemented that would synchronize with a NTP server like time.asia.apple.com or time.nist.gov over the Wireless LAN.
My understanding from your answer is that there isn't a NTP client included in the firmware.
However my mac is synchronized with a NTP server.
Would make sense that GMCMAP accepts date/time stamps (and unchanged).
It surprises me that it does not as you advised in my other thread under gmcmap.
It is rather strange that time stamps of the time of arrival are accepted with delays possible over communication links and on the data acquisition system itself. For scientific purpose this should be reconsidered imho.
23:20:30.728 DEBUG : Connected device: GMC-500Re 1.20
23:20:30.763 DEBUG : Variables configured: CPM, CPM1st, CPM2nd, CPS1st, CPS2nd
23:20:30.784 DEBUG : Number of bytes in CP* records: 4
23:20:30.825 DEBUG : Geiger tube calibration factor: 0.0065 µSv/h/CPM
23:20:30.845 DEBUG : Geiger tube#2 calibration factor: 0.48 µSv/h/CPM
23:20:31.093 DEBUG : Date & Time from device: 2018-11-06 21:24:18
23:20:31.113 DEBUG : Date & Time from computer: 2018-11-06 23:20:31
23:20:31.442 DEBUG : Device is slower than computer by 6973 sec
23:20:31.445 DEBUG : Device Power State: ON
23:20:31.463 DEBUG : Device History Saving Mode: OFF (no history saving)
23:20:31.569 DEBUG : Baudrate read from device: 115200
23:20:31.597 DEBUG : Device Battery Voltage: 4.9v Volt
23:20:31.617 DEBUG : Device Battery Type Setting: ReChargeable
23:20:31.738 DEBUG : Device Alarm State: ON
23:20:31.760 DEBUG : Device Speaker State: OFF
23:20:31.771 DEBUG : Max CPM (invalid if 65535!): 32
23:20:31.790 DEBUG : Device Calibration Points:
Calibration Point 1: 60 CPM = 0.39 µSv/h (0.006500 µSv/h / CPM)
Calibration Point 2: 240 CPM = 1.56 µSv/h (0.006500 µSv/h / CPM)
Calibration Point 3: 1000 CPM = 6.50 µSv/h (0.006500 µSv/h / CPM)
23:20:31.807 DEBUG : Device WiFi Data Setup
Website www.gmcmap.com
URL log2.asp
UserID 01734
CounterID 7472099179
SSID
Password
Period 2
23:20:31.823 DEBUG : GeigerLog's Configuration for Device Firmware:
23:20:31.845 DEBUG : Memory (bytes): 1,048,576
SPIRpage Size (bytes): 2,048
SPIRbugfix: (True | False) False
Config Size (bytes): 512
Calibration (µSv/h / CPM): 0.0065
Voltagebytes (1 | 5): 5
Endianness: (big | little) big
@donghelan or ullix - forgive my ignorance, but where is GeigerLog getting this information? Is it available in the programming of the GQ meters such that GeigerLog or other software is looking somewhere specific for it and can extract it? Just wondering. |
| donghelan |
Posted - 11/08/2018 : 16:15:24
EmfDev,
Thanks for the advice - will do that if I cannot find one in my abandoned electronics recycle box |
| EmfDev |
Posted - 11/08/2018 : 10:26:43
Can you please send email to support@gqelectronicsllc.com? That's the best way. They can send you the crystal. Thanks. |
| donghelan |
Posted - 11/07/2018 : 22:05:52
EmfDev,
Thanks, yes please send to me. Contact me privately through my forum's account for further handling please. |
| EmfDev |
Posted - 11/07/2018 : 16:50:17
From your picture, looks like the X2 is missing (X3 is ok, not supposed to be tehre). That is for RTC.
Can we ask if you are able to solder? If yes, we can send you x2 instead rather than ship back the whole device twice.
Or you can buy X2 on your local store. Then we discuss how to do it. The x2 is 32768 Hz cyrstal.
Thanks! Sorry for the inconvenience. |
| donghelan |
Posted - 11/07/2018 : 16:05:54
I would expect something like a DS3231 chip for the RTC without external X-tal, powered by a separate Lithium battery cell so the rechargeable battery can be replaced independently.
Image Insert:
308102 bytes |
| donghelan |
Posted - 11/07/2018 : 15:12:07
EmfDev,
Thanks, I gave it a try.
I am not able to find it on this PCB. Maybe my eyes are too bad or x-tals are very, very tiny nowadays?
Could you please provide reference pictures with explanatory text?
[Edit:]
This issue was there from the beginning. Opening the geiger counter and zoom in on the components explains very clear now why.
Now I see my own picture nicely magnified in this thread I can see X1, the 8MHz unit that is ticking only for the ARM processor.
X3 is empty (missing?) left from the USB2serial chip CH340C and X2 is where?
Aahhh  !! clearly it is missing right of the Arm processor!
****** Please contact me privately for handling this missing part asap, and also please check from the images if anything else is missing!
This statement about the DS1302 RTC chip that is used, is a bit shocking too(quoted from Arduino playground):
"The DS1302 is a Real Time Clock (RTC) or TimeKeeping Chip with a build-in Trickle-Charger.
Important note : Cheap modules with the DS1302 and DS1307 have often problems with the crystal and the voltage. They often don't work very well. You are strongly advised to use a DS3231, which is very reliable and accurate and needs only a battery to run (the crystal is inside the DS3231)."
-->https://playground.arduino.cc/Main/DS1302
Image Insert:
777726 bytes
Image Insert:
594434 bytes |
| EmfDev |
Posted - 11/07/2018 : 09:43:57
@donghelan, did you have this issue when received the device or was it working at first? Thanks. |
| EmfDev |
Posted - 11/06/2018 : 15:32:01
It looks like the RTC's crystal oscillator isn't working. If you can, just resolder it to see if it can be fixed. This is not going to void warranty in your case. |
| donghelan |
Posted - 11/06/2018 : 13:54:00
It does not start. Stays at the set time. |
| EmfDev |
Posted - 11/06/2018 : 10:03:50
We thought of it before but it would require users to have WiFi.
On your device, after settings the Date and Time correctly, it becomes unsynced after a while? or after turning the unit off? |
| donghelan |
Posted - 11/06/2018 : 07:02:04
EmfDev, thanks for follow up again :)
Yes, it is FW 1.20 as already reported at the start of this thread.
I can only use Unix/Linux compatible software like GeigerLog since I don't own a windows PC.
Geigerlog runs on an old Mac Mini with macOS High Sierra version 10.13.6 (Darwin BSD Unix) .
The hardware version on the PCB is GMC 500 v3.4 20180205.
See additionally below the output from GeigerLog's extended info.
Wifi would only have to do something with the clock if there is a NTP client implemented that would synchronize with a NTP server like time.asia.apple.com or time.nist.gov over the Wireless LAN.
My understanding from your answer is that there isn't a NTP client included in the firmware.
However my mac is synchronized with a NTP server.
Would make sense that GMCMAP accepts date/time stamps (and unchanged).
It surprises me that it does not as you advised in my other thread under gmcmap.
It is rather strange that time stamps of the time of arrival are accepted with delays possible over communication links and on the data acquisition system itself. For scientific purpose this should be reconsidered imho.
23:20:30.728 DEBUG : Connected device: GMC-500Re 1.20
23:20:30.763 DEBUG : Variables configured: CPM, CPM1st, CPM2nd, CPS1st, CPS2nd
23:20:30.784 DEBUG : Number of bytes in CP* records: 4
23:20:30.825 DEBUG : Geiger tube calibration factor: 0.0065 µSv/h/CPM
23:20:30.845 DEBUG : Geiger tube#2 calibration factor: 0.48 µSv/h/CPM
23:20:31.093 DEBUG : Date & Time from device: 2018-11-06 21:24:18
23:20:31.113 DEBUG : Date & Time from computer: 2018-11-06 23:20:31
23:20:31.442 DEBUG : Device is slower than computer by 6973 sec
23:20:31.445 DEBUG : Device Power State: ON
23:20:31.463 DEBUG : Device History Saving Mode: OFF (no history saving)
23:20:31.569 DEBUG : Baudrate read from device: 115200
23:20:31.597 DEBUG : Device Battery Voltage: 4.9v Volt
23:20:31.617 DEBUG : Device Battery Type Setting: ReChargeable
23:20:31.738 DEBUG : Device Alarm State: ON
23:20:31.760 DEBUG : Device Speaker State: OFF
23:20:31.771 DEBUG : Max CPM (invalid if 65535!): 32
23:20:31.790 DEBUG : Device Calibration Points:
Calibration Point 1: 60 CPM = 0.39 µSv/h (0.006500 µSv/h / CPM)
Calibration Point 2: 240 CPM = 1.56 µSv/h (0.006500 µSv/h / CPM)
Calibration Point 3: 1000 CPM = 6.50 µSv/h (0.006500 µSv/h / CPM)
23:20:31.807 DEBUG : Device WiFi Data Setup
Website www.gmcmap.com
URL log2.asp
UserID 01734
CounterID 7472099179
SSID
Password
Period 2
23:20:31.823 DEBUG : GeigerLog's Configuration for Device Firmware:
23:20:31.845 DEBUG : Memory (bytes): 1,048,576
SPIRpage Size (bytes): 2,048
SPIRbugfix: (True | False) False
Config Size (bytes): 512
Calibration (µSv/h / CPM): 0.0065
Voltagebytes (1 | 5): 5
Endianness: (big | little) big
|
| EmfDev |
Posted - 11/05/2018 : 17:00:38
Hi donghelan,
I answered your questions from the other thread.
The GMC-500+ has its own RTC. Have you tried using data viewer to set the clock? or enter it manually in the settings menu?
Is 1.20 your firmware revision? you can check it on the Menu->About->Revision. Also, you can check the hardware version
by removing the battery cover. Can you please check your hardware version if you are able to?
WiFi doesn't have anything to do with the clock so it is not that issue.
Don't open it yet if you're afraid of voiding the warranty. I need to check to see what we can do before proceeding.
Thank you and sorry for the inconvenience. |
