GQ Electronics Technical Support Forum


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
 2.GQ Geiger Muller Counter
 GMC-500+ RTC HW or FW issue?
 New Topic  Reply to Topic
 Printer Friendly
Author Previous Topic Topic Next Topic  

donghelan

Japan
23 Posts

Posted - 11/05/2018 :  15:37:48  Show Profile  Reply with Quote
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?



To bug or not debug, that is the Q
Reply #1

EmfDev

303 Posts

Posted - 11/05/2018 :  17:00:38  Show Profile  Reply with Quote
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.
Go to Top of Page
Reply #2

donghelan

Japan
23 Posts

Posted - 11/06/2018 :  07:02:04  Show Profile  Reply with Quote
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

To bug or not debug, that is the Q

Edited by - donghelan on 11/06/2018 07:45:33
Go to Top of Page
Reply #3

EmfDev

303 Posts

Posted - 11/06/2018 :  10:03:50  Show Profile  Reply with Quote
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?
Go to Top of Page
Reply #4

donghelan

Japan
23 Posts

Posted - 11/06/2018 :  13:54:00  Show Profile  Reply with Quote
It does not start. Stays at the set time.

To bug or not debug, that is the Q
Go to Top of Page
Reply #5

EmfDev

303 Posts

Posted - 11/06/2018 :  15:32:01  Show Profile  Reply with Quote
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.

Edited by - EmfDev on 11/06/2018 15:32:29
Go to Top of Page
Reply #6

EmfDev

303 Posts

Posted - 11/07/2018 :  09:43:57  Show Profile  Reply with Quote
@donghelan, did you have this issue when received the device or was it working at first? Thanks.
Go to Top of Page
Reply #7

donghelan

Japan
23 Posts

Posted - 11/07/2018 :  15:12:07  Show Profile  Reply with Quote
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)."

h**ps://playground.arduino.cc/Main/DS1302

Image Insert:

777726 bytes

Image Insert:

594434 bytes

To bug or not debug, that is the Q

Edited by - donghelan on 11/07/2018 16:45:46
Go to Top of Page
Reply #8

donghelan

Japan
23 Posts

Posted - 11/07/2018 :  16:05:54  Show Profile  Reply with Quote
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

To bug or not debug, that is the Q
Go to Top of Page
Reply #9

EmfDev

303 Posts

Posted - 11/07/2018 :  16:50:17  Show Profile  Reply with Quote
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.
Go to Top of Page
Reply #10

donghelan

Japan
23 Posts

Posted - 11/07/2018 :  22:05:52  Show Profile  Reply with Quote
EmfDev,

Thanks, yes please send to me. Contact me privately through my forum's account for further handling please.

To bug or not debug, that is the Q
Go to Top of Page
Reply #11

EmfDev

303 Posts

Posted - 11/08/2018 :  10:26:43  Show Profile  Reply with Quote
Can you please send email to support@gqelectronicsllc.com? That's the best way. They can send you the crystal. Thanks.
Go to Top of Page
Reply #12

donghelan

Japan
23 Posts

Posted - 11/08/2018 :  16:15:24  Show Profile  Reply with Quote
EmfDev,
Thanks for the advice - will do that if I cannot find one in my abandoned electronics recycle box

To bug or not debug, that is the Q
Go to Top of Page
Reply #13

Stargazer 40

USA
243 Posts

Posted - 11/11/2018 :  11:57:31  Show Profile  Reply with Quote
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.

Stargazer 40
Go to Top of Page
Reply #14

donghelan

Japan
23 Posts

Posted - 11/11/2018 :  15:59:25  Show Profile  Reply with Quote
@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__))


To bug or not debug, that is the Q

Edited by - donghelan on 11/11/2018 16:29:00
Go to Top of Page
Reply #15

donghelan

Japan
23 Posts

Posted - 11/11/2018 :  16:43:02  Show Profile  Reply with Quote
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.


To bug or not debug, that is the Q

Edited by - donghelan on 11/11/2018 17:00:40
Go to Top of Page
Reply #16

Stargazer 40

USA
243 Posts

Posted - 11/12/2018 :  04:17:28  Show Profile  Reply with Quote
@donghelan - Thanks for explaining that. I have GeigerLog installed so will try.

Stargazer 40
Go to Top of Page
Reply #17

EmfDev

303 Posts

Posted - 11/12/2018 :  10:02:15  Show Profile  Reply with Quote
@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.
Go to Top of Page
  Previous Topic Topic Next Topic  
 New Topic  Reply to Topic
 Printer Friendly
Jump To:
GQ Electronics Technical Support Forum © Copyright since 2011 Go To Top Of Page
Generated in 0.16 sec. Snitz Forums 2000